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
-
perhaps
diffuse<'t>anddiffuse<'-t>? to avoid glyph issues and to steal some shit from Rust. -
A [email protected] shared this topic
-
@[email protected] it sounds just like someone is trying to pronounce like how they think the French would say it
-
@aud I am once again reminded of the code-base that consumed much of my programming attention in grad school where there were both finalize() and finalise() methods
-
There HAS to be some language or idea where this is a thing though. It should, at least, be theoretically possible.
I would uhhhh not advise implementing crypto (in the cool Turing sense, not the fuckboi sense) in it though -
@[email protected] please lie and tell me they were just the same function call
-
@aud [visibly sweating] well uh they *gulp* did the same thing
-
@[email protected] THAT JUST MEANS THEY'RE DEGENERATE THAT'S NOT THE SAME THING
-
Inga is looking for a jobreplied to Asta [AMP] last edited by
@aud but consider this: either you'll have accelerate and decelerate duplicating each other meanings, or you'll have to pick one time direction as special.
Or perhaps "t" here should be a generic parameter, passed through the entire call chain.
-
@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. -
A [email protected] shared this topic
-
A [email protected] shared this topic
-
-
@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... -
A [email protected] shared this topic
-
A [email protected] shared this topic
-
@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”. -
A [email protected] shared this topic
-
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.
