One day I'm going to sit computer scientists down and teach them about the concept of reversibility and how that might apply to verbs/functions/etc

Inga is looking for a job

@aud the assumed direction has the same problem, with one direction being special and more important than the other.

Also might make sense to consider pure functions and functions with side effects separately. Reversed pure function should return arguments of the original pure function when supplied with its return value; while reversed function with side effects should undo its effects.

For example, if f<t>(x) returns x*2, then f<-t>(x) returns x/2. But if f<t>(obj) does obj.x *= 2, then f<-t>(obj) does obj.x /= 2.

Asta [AMP]

@[email protected] yeah! I actually thought more about it after posting and realized they don't need to be the same; you're just swapping your inputs/outputs is all. Don't know why I initially assumed that (probably just thinking of a particular case).

You make a good point about considering "side effects" separately; if information is lost then it would necessarily have to be regained in some fashion. But not all transformations are "lossy" so those are probably somewhat trivial in a sense.

Asta [AMP]

@[email protected] I strongly suspect that it would be hard to automatically differentiate between functions that lose/gain information vs. those that do not that, on a programmatic level.

Inga is looking for a job

@aud maybe information being lost is a skill issue, and true reversible language should not allow for information loss.
After all, most of the physics is not just reversible but doesn't even have a special time direction; it's only enthropy that makes one of the directions dedicated, and even it only does so in the sense that "your brain can store memories, and direction in which all the parts of the brain work (which are aligned between each other, or you wouldn't be able to form memories) aligns with the direction of all other stuff around you"

Inga is looking for a job

@aud programmers should just define every function in both directions and supply it with formal proof that both directions cancel each other out.

Asta [AMP]

@[email protected] hmmmm, perhaps what we're not interested in, then, is whether or night the function increases, decreases, or is neutral with regards to entropy. Maybe that's the right approach.

A so called lossy function is entropy generating in a normal universe (that stuff is going somewhere, right?), whereas the inverse of that function would require a different type of universe where entropy is always decreasing (and ergo, rebuilds the original state). Likewise, functions that are neither lossy nor generative are "entropy neutral" in a sense. Consider an array transformation that is just simply a matter of swapping indices around or as indicated by @[email protected] , a conversion of a list of chars to a string. Your type information changes but fundamentally the underlying data is the same.

hmmmm...

Asta [AMP]

@[email protected] finally, a good programming take

Asta [AMP]

@[email protected] this would certainly solve the inevitable garbage collection and memory issues that would arise from keeping track of every single bit that ever existed in the program runtime

Asta [AMP]

@[email protected] I think to some extent #spritelygoblins has had to do something with this since I believe the idea of reversibility is baked in fresh and hot, right into it.

Inga is looking for a job

@aud but do you even need to _run_ a program in your language, or is it enough for this program to _exist_?

Asta [AMP]

@[email protected] there are two types of computer people, and the group that would be happy with the second is far too busy making out to even implement the language in the first place.

Charles U. Farley

@aud You can, but the actual function you're applying is the one that includes any garbage/"entropy" outputs/inputs. It's kind of like reversing an egg breaking and needing to collect back the sound waves it made, along with any heat that was released. (But actually possible and even practical for some applications.)

Asta [AMP]

@[email protected] Yeah, that was my thought too, basically. I think in such a case you'd have to be careful about memory management, because tracking all that state could get rather expensive.

If it's a compiled language, I'm sure there's some static analysis stuff that could help the compiler eliminate the need to track memory (a trivial example would be, "is the reverse function ever called anywhere?"; no need to keep track of something you're never gonna use).

Interestingly, I wonder if having it as a functional (or functions as a first class type) could help; functions could have some sort of built-in sink for lost data. Actually, in that case, I suppose that might make memory management rather trivial: in that event you're not deleting memory, just changing who owns it (transferring ownership from, say, an array, to the function).

You'd have to have a method for freeing memory from the function; perhaps some sort of entropy flush function or something where you know you're not interested in reversing the operation.