this post was submitted on 21 Jun 2024
470 points (98.4% liked)
Programmer Humor
19585 readers
575 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
TBH I fail to see the significant difference between this and a function declaration.
A function will be called by code and go to that point in code. To implement functions, you store necessary things to memory and goto the function definition. To implement that with comefrom you'd have to have a list of all the places that need to call the function as comefroms before the function definition. It'd be a mess to read. We almost never care where we are coming from. We care where we're going to. We want to say "call function foo" not "foo takes control at line x."
Its like if subroutine
bar
could say its going to execute at line N of routinefoo
. But if you were just readingfoo
then you'd have no clue that it would happen.You can simulate this effect with bad inheritance patterns.
This will print A, B, C and then F. D and E will be skipped because of the comefrom.
it's semantic
at the end of the day everything boils down to sequence and branchifs
I'd say it's more like setting up a handler for a callback, signal, interrupt or something along those lines.
Function declarations by themselves don't usually do that. Something else has to tell the system to run that function whenever the correct state occurs.
That doesn't account for unconditional come-froms.¸but I expect there'd have to be a label at the end of some code somewhere that would give a hint about shenanigans yet to occur. Frankly that'd be worse than a goto, but then, we knew that already.
Doesn't it steal control flow? More like a break point, except you define where execution continues.
I wonder if it's a compile error to have multiple conflicting COMEFROM statements, or if it's random, kind of like Go's select statement.
How awesome would it be to be able to steal the execution stack from arbitrary code; how much more awesome if it was indeterminate which of multiple conflicting COMEFROM frames received control! And if it included a state closure from the stolen frame?
Now I want this.
I think there's at least one INTERCAL implementation where that's how you start multi-threading