4 ms·

What are some more obscure control flow structures? It's easy to think that eg conditionals, loops, goto, function calls are the only ones that exist. But there

by itmag 15y ago

What are some more obscure control flow structures? It's easy to think that eg conditionals, loops, goto, function calls are the only ones that exist. But there is also stuff like jump tables and co-routines for instance.

brlewis 15y ago
I don't know if it gets any more obscure than Scheme's call/cc, which is a building block for other control flow structures. You can use it for cool things like the Racket web server, where event-driven programming can be made to feel like sequential, procedural-style programming. You can also use it for sick mind twisters like ((call/cc call/cc) (call/cc call/cc))
- skimbrel 15y ago
  I remember being shown call/cc briefly in CS 61A at Berkeley and then forgetting about it until recently when I saw an article on it while I was in the middle of writing an event-driven web application using Perl and Plack. I immediately saw how useful it would be and wished I had it available to use there.
- itmag 15y ago
  Please explain :)
  - brlewis 15y ago
    Good explanation here: http://lambda-the-ultimate.org/node/86#comment-3806 http://lambda-the-ultimate.org/node/86#comment-3806 But you have to read it slowly.
    - itmag 15y ago
      Mine lisp-peen is too small. Now, off to study! Thanks, btw.
      - spacemanaki 15y ago
        I don't think I ever really understood call/cc until I read Lisp in Small Pieces. The author makes a great effort to implement call/cc in each of the interpreters and compilers he presents, and examines the hairy issues that come up when you decide to support first-class continuations. Highly recommended.
- JonnieCache 15y ago
  Ruby has call/cc http://rubydoc.info/stdlib/core/1.9.3/Kernel:callcc http://rubydoc.info/stdlib/core/1.9.3/Kernel:callcc Thus you can implement pretty much anything you want in ruby, including COME FROM.
masklinn 15y ago
Conditions maybe? They're what lies beyond exceptions: exceptions will unwind the stack looking for a handler (`catch` or the likes), and when found will execute that handler in its (the handler's) context (scope). Conditions walk the stack instead of unwinding it, and execute the handler in their own context. This gives the handler the possibility of logging an error and bailing out, of course, but also of fixing the local data and resuming running the code[0], as if nothing had happened. A condition system essentially allows callees to reach into callers and ask them what to do, without having to lose any state or data. This also gives more power to tools: without any specific instrumentation, a Smalltalk environment or a Common Lisp IDE can drop you at the error site (where the condition was signaled) without needing more than registering a condition handler when starting your code (if conditions are already handled by a condition handler in your stack, this default behavior won't happen until your handlers let the condition propagate further). [0] Actual flexibility depends on the runtime, I'm not completely up to snuff with everything, I know in Common Lisp there's a concept of "restart": the one who signaled the condition or any of its callers can provide "restarts", which are essentially possible choices for resuming work. A log-parsing API could provide restarts to skip a corrupted or unreadable entry, to display a user prompt to ask him to "manually" parse the value or to provide the API with a value to use instead (could be a default, a placeholder, or a value obtained by calling the older log-parser you're trying to replace) (note: it's an inclusive or, the API provides all three and the developer using the API picks the one he wants depending on the situation). Or a dict's `get` method could signal on an invalid key and provide a restart making it return a default value of some sort.
program 15y ago
In the original COBOL specification there is the infamous "ALTER X TO PROCEED TO Y" statement which modify a GOTO X in a GOTO Y.

by itmag 15y ago

brlewis 15y ago

I don't know if it gets any more obscure than Scheme's call/cc, which is a building block for other control flow structures. You can use it for cool things like the Racket web server, where event-driven programming can be made to feel like sequential, procedural-style programming. You can also use it for sick mind twisters like ((call/cc call/cc) (call/cc call/cc))

skimbrel 15y ago
I remember being shown call/cc briefly in CS 61A at Berkeley and then forgetting about it until recently when I saw an article on it while I was in the middle of writing an event-driven web application using Perl and Plack. I immediately saw how useful it would be and wished I had it available to use there.
itmag 15y ago
Please explain :)
- brlewis 15y ago
  Good explanation here: http://lambda-the-ultimate.org/node/86#comment-3806 http://lambda-the-ultimate.org/node/86#comment-3806 But you have to read it slowly.
  - itmag 15y ago
    Mine lisp-peen is too small. Now, off to study! Thanks, btw.
    - spacemanaki 15y ago
      I don't think I ever really understood call/cc until I read Lisp in Small Pieces. The author makes a great effort to implement call/cc in each of the interpreters and compilers he presents, and examines the hairy issues that come up when you decide to support first-class continuations. Highly recommended.
JonnieCache 15y ago
Ruby has call/cc http://rubydoc.info/stdlib/core/1.9.3/Kernel:callcc http://rubydoc.info/stdlib/core/1.9.3/Kernel:callcc Thus you can implement pretty much anything you want in ruby, including COME FROM.

masklinn 15y ago

Conditions maybe? They're what lies beyond exceptions: exceptions will unwind the stack looking for a handler (`catch` or the likes), and when found will execute that handler in its (the handler's) context (scope). Conditions walk the stack instead of unwinding it, and execute the handler in their own context. This gives the handler the possibility of logging an error and bailing out, of course, but also of fixing the local data and resuming running the code[0], as if nothing had happened. A condition system essentially allows callees to reach into callers and ask them what to do, without having to lose any state or data. This also gives more power to tools: without any specific instrumentation, a Smalltalk environment or a Common Lisp IDE can drop you at the error site (where the condition was signaled) without needing more than registering a condition handler when starting your code (if conditions are already handled by a condition handler in your stack, this default behavior won't happen until your handlers let the condition propagate further). [0] Actual flexibility depends on the runtime, I'm not completely up to snuff with everything, I know in Common Lisp there's a concept of "restart": the one who signaled the condition or any of its callers can provide "restarts", which are essentially possible choices for resuming work. A log-parsing API could provide restarts to skip a corrupted or unreadable entry, to display a user prompt to ask him to "manually" parse the value or to provide the API with a value to use instead (could be a default, a placeholder, or a value obtained by calling the older log-parser you're trying to replace) (note: it's an inclusive or, the API provides all three and the developer using the API picks the one he wants depending on the situation). Or a dict's `get` method could signal on an invalid key and provide a restart making it return a default value of some sort.

program 15y ago

In the original COBOL specification there is the infamous "ALTER X TO PROCEED TO Y" statement which modify a GOTO X in a GOTO Y.