Re: Semantics of let

[haahr@mv.us.adobe.com (Paul Haahr)]

> Paul> re letrec:  currently the only way to create recursive structures
> Paul> is to use assignment or something like the y combinator. [...]

> I don't think I quite understand.  The only recursiveness you create
> using letrec is indirect, in the sense that a program fragment would
> not contain a copy of itself, but has to dereference a variable to
> refer to itself.  In fact, you can get the effect of
>     letrec (a=foo; b=bar) {cmd}
> by rewriting it as
>     let (a=; b=) {a=foo; b=bar; cmd}
> which certainly causes no problem.  Of course, this means that letrec
> can simply be implemented as syntactic sugar, just like let* can, given
> the "real" let.

yes, but, how about...

	letrec (x = {echo $x}) $x

which is equivalent to

	let (x = ) { x = { echo $x }; $x }

[this one happens not to crash the interpreter, so feel free to try
it out.  on the other hand, it doesn't work correctly.  and, by the
way, i believe that minor variations on this will cause the interpreter
to die, so be careful]

note that the closure here contains a pointer to itself.  it has to.
there's no two way around it;  otherwise, you don't have real lexical
scoping.

> Heck, even let can be written as syntactic sugar in terms of lambda!
> You just have to use some program fragments to get around the fact
> that es doesn't have hierarchical lists:

> ; x=foo zoo; y=bar zar
> ; # Think if this as a rewrite of  let (x=$y; y=$x) echo $x $y
> ; @ x y {x=<=$x; y=<=$y; echo $x $y} {result $y} {result $x}
> bar zar foo zoo

yes, it probably could be, but i'm not sure it's any cleaner, or makes
things any smaller.  (but a very clever piece of code, i must say.
took me a long time to figure out what it was doing.)

paul