[murisitarusenga]

L2 is an experimental programming language that maps efficiently to machine code (like C). I think it is interesting because I have not seen 1) control flow primitives that are like Scheme's continuations but that are also efficient 2) L2's variant of s-expressions that do not need a symbol or string data type 3) a macro system that is equivalent to but operates differently from Common Lisp's

[fao_]

As far as I know, scheme's continuations are efficient. That's kind of the basis of RABBIT, Orbit, and a chunk of Appel's work, isn't it?

(See also: http://lambda-the-ultimate.org/node/2406#comment-36369)

[shakna]

As far as I can tell, L2's continuations look very similar to the Cheney on the M.T.A. [0] approach to continuations.

[0] http://home.pipeline.com/~hbaker1/CheneyMTA.html

[murisitarusenga]

Thanks for the link. I am not sure if I see the similarity. L2 neither uses the heap nor garbage collection nor are its programs converted into continuation-passing-style. Am I missing something?

[gsg]

Those compilers use CPS as an intermediate language - a bit like SSA form for functional languages - which is (mostly) independent of supporting first class continuations.

Support for first class continuations is a matter of tradeoffs. It's quite reasonable for an implementation to choose 'slow' continuations (in which call/cc copies the stack) in order to be able to use the more efficient native stack for function calls.

(EDIT: and in response to the linked post, it is quite possible to efficiently compile what would be contifiable functions in direct style - see the recent paper Compiling Without Continuations in which the GHC hackers do exactly that.)

[murisitarusenga]

I will try to read into the details of Scheme's implementation of continuations...

The reason I made the claim about efficiency is because Scheme's continuations have an unlimited lifetime. This is in contrast to L2's continuations that can only have a dynamic lifetime. (The rules for manipulating continuations in L2 are analogous (and only analogous) to the rules for returning the addresses of local variables in C.) So I just assumed that Scheme implementations must occur an overhead for the greater generality of their continuations.

[bitwize]

Different Scheme implementations, presumably, have different implementations of continuations.

An implementation of call/cc can be efficient provided you are willing to sacrifice the notion of a single execution stack and embrace constructs like spaghetti stacks that allow for indefinite lifetime of an execution context.

[nickpsecurity]

Very interesting. Especially combining a language primitive, English description, and assembly. I proposed that with a minimal Lisp for bootstrapping recently. The one I was looking at you might find interesting as you experiment with this stuff:

https://en.m.wikipedia.org/wiki/PreScheme

Both the PreScheme and VLISP papers have stuff about it.

[murisitarusenga]

Thank you. I personally struggled to understand Scheme continuations from their English descriptions, so I made a point of including concrete implementation details in my write-up.

Thank you for the link to PreScheme. It seems to have exactly the same goals that I was aiming for. I will look into it.

[notjack]

It's hard to tell from a cursory overview, but I'm pretty sure L2's macro system is roughly equivalent to "fexpr" based macro systems used by some other lisps and schemes.

[murisitarusenga]

I'm not sure if this is correct. Googling fexprs takes me to this Lambda the Ultimate post: http://lambda-the-ultimate.org/node/3640#comment-51665. There it says that fexprs map from s-expressions (of the operands to fexpr) to a value (which replaces the fexpr call). L2's macro system does not do this. L2 maps from s-expressions (of the operands to the macro) to s-expressions (that are supposed to replace the macro call).