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
-
@aud whats your preference on double negatives? Do they cancel, or just more emphatic "no"
-
Is there a unit vector commonly used to denote "forward" and "reverse"? hm.
-
@aud Reversible computing in the physics sense is a thing, which also let me to this in wikipedia: https://en.wikipedia.org/wiki/Janus_(time-reversible_computing_programming_language)
-
@aud There's a whole field of computing around it. "Normal" logic and Turing machines and their equivalents are irreversible, though. Which interestingly requires them to dissipate energy. A reversible computer could theoretically dissipate no energy, but in exchange it builds up its own form of entropy in the form of information needed to reverse the computations that nevertheless aren't useful output for whatever you're trying to do.
-
Asta [AMP]replied to Inga is looking for a job last edited by
@[email protected] I thought about that second one, but if it's a whole language then it would be a lot of unnecessary boilerplate per function call.
Perhaps there's an "assumed", implicit direction? IE,diffuse()
is shorthand fordiffuse<t>()
or some such.
Unique symbols for each direction (apply and reverse) would work too, although I like the correctness of simply reversing the arrow of time as what it would mean.
Of course that does start to mean things if you're not careful; input/output must be the same. So it'd have to be a special feature where those remain the case... at least. -
-
-
-
@aud unyes
-
@[email protected] my first thought was about functions that are lossy in that they involve some sort of one-way compression; to make them reversible requires retaining that information
But interestingly, if going backwards is a valid state, then ideally you'd like to be able to apply a reverse operation despite never having run a forward operation... -
-
-
@aud prolog has implicit forward/reverse! For example:
string_to_chars(“hey”, X).
X = [h,e,y].And:
string_to_chars(X, [h,e,y]).
X = “hey”. -
-
Inga is looking for a jobreplied to Asta [AMP] last edited by
@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]replied to Inga is looking for a job last edited by
@[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. -
@[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 jobreplied to Asta [AMP] last edited by
@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 jobreplied to Asta [AMP] last edited by
@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]replied to Inga is looking for a job last edited by
@[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]replied to Inga is looking for a job last edited by
@[email protected] finally, a good programming take
-
Asta [AMP]replied to Inga is looking for a job last edited by
@[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]replied to Inga is looking for a job last edited by
@[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 jobreplied to Asta [AMP] last edited by
@aud but do you even need to _run_ a program in your language, or is it enough for this program to _exist_?
-
Asta [AMP]replied to Inga is looking for a job last edited by
@[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.