4 ms·

How about call/cc and setjmp/longjmp ?

• emn13 14y ago
  And those control flow methods are also widely considered to be tricky and cause a maintenance burden.
  • shurcooL 14y ago
    Just making an observation here. The reason they are tricky and cause a maintenance burden is because they create non-obvious dependencies. You'd have to read a lot of seemingly unrelated code to spot them. Without the explicit knowledge of these dependencies, your changes will have unexpected consequences. (Hence, in a system that tracks all dependencies perfectly, this might not be a problem. This is an experiment I'm trying to run right now.)
    • astrobe_ 14y ago
      Exceptions have been called "glorified goto" for a reason. In fine, the OP says that GOTOs are perfectly acceptable.
    • shurcooL 14y ago
      Interestingly, what I'm considering seems to be very similar to http://en.wikipedia.org/wiki/Dataflow_programming http://en.wikipedia.org/wiki/Dataflow_programming. Yet it doesn't seem like that has spread to be the most common type of programming. Why not? What makes dataflow programming not viable for creating software today?
• BruceM 14y ago
  Or my comment elsewhere in this thread about condition systems in Common Lisp and Dylan.
  • astrobe_ 14y ago
    I said standard. Since that condition system is proper to Lisp, it is henceforth non-standard. And come on, you don't see setjump/longjump every 10 LOC, not even every 10 source file.
    • BruceM 14y ago
      In Lisp, every bind-exit or unwind-protect may be doing something like a setjmp. That's how it is implemented in the C runtime for Dylan as well. In JavaScript, you have the ability to break to a label to escape nested loops. That's a limited form of a non-local exit. Ola Bini was working with a condition system in his experimental / hobby language Ioke as well. These ideas get around. You'd probably be surprised at how some of this works in Smalltalk as well.