Re: settor functions

[Paul Haahr <haahr@mv.us.adobe.com>]

> Can you precisely state the semantics for {}?  At first I thought that
> { foo } might be equivalent to @ { foo }, but it isn't.

{foo} is equivalent to @ x {foo} provided:
	that foo does not throw the return exception
	that foo does not refer to x

> Ah, but now we see that it is "return" that is misbehaving.  When you
> write "return" in function foo, you really want it to mean is
> "call-escape-continuation-for-function-foo"

yes and no.  i think of it as throwing an exception.  in a language with
first class continuations (which es is not, at least currently) that would
be one way of implementing es's lambda invocation + return semantics.
for now, i model this part of es (along with just about everything else)
with operational semantics.  a denotational semantics is probably possible,
although trying to explain fork and exec might be difficult.

> But the following is magic, and exits after one iteration:
>	fn borg { while {sleep 1} $1 }
>	borg { echo 'new operating system Deep-Space-9'; return; } 

i would call that incorrect but legal.  it might do what you want,
but i would not want to write the language spec (if such a thing
was to be written) to require it.  for example, w/the above defn of
borg, i might write

	fn foo {
		if {test -f /gnope} {
			borg { echo 'new operating system Deep-Space-9'; return; }
		}
		echo conventional operating system from murray hill
	}

and have the return be bound to the escape function from foo.  i'm not clear that
that's not more satisfactory, and i'd like to be able to implement things that
way.

anyway, for now, return (and the rest of the exception mechanism) is strictly
dynamic.  if and when we add first class continuations, we can start thinking
about lexically scoping things like return.

> Orthogonality is key.  Lambda is irresistable.  You will be assimilated. :-)

yep, fine, i agree.  but we all know that already, and that's why we've done
away with shells and are working only on lisp machines.  :-)