I wonder how ccc in Arc/Scheme compares to return in Ruby with respect to efficiency. Hopefully ccc is very lightweight. It really does make me question why return wasn't defined to be part of the language.
Basically the most important realization is that the return address on the stack may be modeled as the address for a different procedure, which by a staggering coincidence just so happens to point to the code after the function call. So basically a return is itself equivalent to a function call.
ccc is one of the strangest things in Scheme (and Arc now). Hard to get everything behind it, but it can be used to implement return statements, try-catch à la C++/Java, coroutines à la Lua, generators à la Python and of course continuation-based web apps à la Arc...
A very strange beast, and as far as I know the thing Scheme has that CL hasn't (and cannot trivially implement).
Actually, the form of closure used by Arc is highly similar to a continuation passing style, so although it doesn't use 'ccc, it does use continuations.
cl-cont is a library that implements closures and runs on many CL implementations. So it's not a matter of CL can't do it, CL just has to use a library to do it.
I think there are conceptual problems mixing unwind-protect-like constructs and call/cc.
The cl-cont lib appears to only support a subset of CL (in particular unwind-protect is not supported).
So cl-cont doesn't demonstrate that CL can support it, only that a restricted subset of CL can.
I don't know if it is possible to sensibly accommodate unwind-protect and call/cc in the same language, it seems smarter people than I have avoided doing so.
Scheme's dynamic-wind serves the same purpose as unwind-protect (except with entry conditions as well, since a continuation could suddenly return into your protected code), and plays nicely with continuations. I'm not sure about the details, though.
Thanks for that, pretty interesting. I guess that makes writing entry and exit conditions a little more interesting, since they could end up being invoked multiple times.
i am learning how to write scheme compilers now it it looks like you just jump around your CCC's like GOTO labels - very fascinating and lower over head then functions calls (if you compile to machine level)
Thanks. And from your comment ( http://arclanguage.com/item?id=4432 ) on the 8 Queens thread, the Ruby snippet in the OP above could be implemented as:
That said catch-throw is in ArcN, although they do have different intended usages. breakable: is supposed to be used as a modifier for existing control structures, while (catch ...) is supposed to be a control structure in its own right.
Sure, ccc is here for that. Let's say we want the equivalent of this Python code :
def a:
for i in (1, 2, 3):
if i < 2:
return i
return None
It can be written this way in Arc :
(def a (return)
(each i '(1 2 3)
(if (< i 2)
(return i)))
nil)
arc> (ccc a)
1
To those who don't know ccc : in this code, return is not a defined macro or function, it is the current continuation, waiting for a value. We could have called it another way, k for example.
Once you "throw" it a value (i in this case), it's happy and goes on to the next calculation. (ccc a) thus tells to perform a and, once the return parameter is called, exit a and go back to the REPL (with the specified value).
Thanks for the quick reply. That seems like an awkward way to accomplish a simple thing - Python & Ruby win on this IMO.
I submitted a new article ( http://arclanguage.com/item?id=4431 ) on the topic. It might be good to re-post your comment there and have followups on that thread.
The challenge is to produce all 92 solutions as the Ruby code does in the OP. I linked to wikipedia for the description of the problem, not the algorithm.
I also showed the ellided output for clarification.
pg, what do you think of adding regular expressions to the poll since we have 8 votes here? Not sure if folks would come back to vote the poll, but it's worth a shot.
I'd love to see regular expressions in Arc, but just like my comment on infix notation, I don't think it needs to be part of the core language. A module system is already in the list of candidates and I believe with a good module system, regular expressions could be added to the language by an outside and benevolent hacker or by the core team (i.e., PG and RM) as an included module rather than as part of the Arc language itself. By the same token, I would love to see of the code now (e.g., the app.arc, srv.arc, and html.arc) refactored into modules once the system is complete.
As an aside, both me and raymyers have written basic module systems.
The hardest part (which we haven't built yet) is macros, both private in the module, and macros defined by the module for use by external code/other modules.
Hmm... I guess others aren't as curious as I am regarding the distribution of platforms for Arc coders.
Of course, at this stage, I suppose most people click on "new" in addition to only reading the front page stuff, so there may not be a big difference with "front page exposure" vs. being only in the new section.
