NireBryce

reality is the battlefield

the first line goes in Cohost embeds

🐥 I am not embroiled in any legal battle
🐦 other than battles that are legal 🎮

I speak to the universe and it speaks back, in it's own way.

mastodon

email: contact at breadthcharge dot net

I live on the northeast coast of the US.

'non-functional programmer'. 'far left'.

conceptual midwife.

https://cohost.org/NireBryce/post/4929459-here-s-my-five-minut

If you can see the "show contact info" dropdown below, I follow you. If you want me to, ask and I'll think about it.

posts from @NireBryce tagged #nire-random-papers

also:

Introduction

In this post I plan to give an introduction to reversible programming languages, and some introduction to the programming language Rust. Then I will introduce my amalgamation of those two things, RRust. The overview I will give here is not going to be too deep, In the end, I will provide some articles which go deeper into it all. RRust was produced for my Master’s Thesis, so the recounting here goes into some details which may already be known to Rust users. Finally, any comments or questions are welcome and can be sent to blog@erk.dev.

Reversible Computing

Introduction
Reversible computing is the idea that you can for a given function f(x) := y you can generate the inverse function that takes the output and generates the input f^-1(y) := x. This of course could be done by hand, but we want to make a machine, here donoted by I, that can make the transformation of the code. That is that I(f) := f^-1. To generalize this a bit we can look at x and y as states and f as a function that goes from state x to state y, this is how we will look at it in the following chapters since we are going to model our functions as mutations to variables. So we want to generate the inverse function f^-1 that takes state y and mutates it to state x.



shorter pull quote:

My first thought was that this paper tagged the pivot point of a Kuhnian paradigm shift.2 This was bolstered by my be- lief that engineering papers had become rather suddenly unwelcome at programming language conferences around the same time. Their choice of papers to reference seems odd: a paper about Flavors [10], a brief overview of CLOS from an ECOOP paper [17], and a programmer’s guide written by a technical writer at Symbolics [18]. This was after the CLOS specification had been widely publicized—it was published in full in September 1988 in SIGPLAN Notices [19]. My first thought was that this paper tagged the pivot point of a Kuhnian paradigm shift.2 This was bolstered by my be- lief that engineering papers had become rather suddenly unwelcome at programming language conferences around the same time. My initial hypothesis was that the paradigms in question were engineering on one side and science on the other. But the paradigms in question turn out to be more technically focussed.

But: how fascinating! —That incommensurability could be real. I had lived through this micro-paradigm shift, and my realization came as a surprise because it explained so much while remaining hidden from me all these years. The real paradigm shift? Systems versus languages. Be- fore 1990, a person interested in programming could work comfortably both in programming languages and in pro- gramming systems, but not so easily after. To tell the truth, I never even noticed the different words—language versus system—never attached any significance to the word choice until this exploration. I used the phrases interchangeably for many years: Programming System / Programming Language.