Re: Features to remove: return and noreturn

[hanche@ams.sunysb.edu (Harald Hanche-Olsen)]

Paul> (a) return is only half of the problem.  break is the other half.
Paul>     as far as i'm concerned, getting rid of return implies getting
Paul>     rid of break.  (i don't think that's necessarily a bad thing.)

I agree.  I thought about including break in my proposal, but rejected
it for some reason I cannot now remember or guess at (so it was
probably not a good reason).

Paul> (c) tag doesn't, however, address the fundamental problem with
Paul>     break and return, which is that they have completely dynamic
Paul>     behavior, and don't follow lexical scope.  if you use the
Paul>     same tag name in two places, you have exactly the same problem
Paul>     as you do with break or return.

Of course there are times when you want dynamic rather than lexical
behaviour, but I can certainly see why you would prefer the latter by
default.  I suppose something that follows lexical scoping rules can
be kludged given a command %make-unique-identifier:

  let (lexical-tag = <={%make-unique-identifier})
    tag $lexical-tag {
       .....
       throw $lexical-tag $answer ...}

Gack.  This reminds me of lisp macros using (gensym).

Paul> (d) John and Scott were right in critizing es back in october for
Paul> 	(1) not having first-class continuations

We're not talking about something as powerful as Scheme's
call-with-current-continuation here, are we?

Paul> (g) what i think i want, at the moment, is the current dynamic behavior,
Paul>     except that break and return would be bound lexically over their
Paul>     bodies to things like
Paul>     	throw break while-0x12345678
Paul>     where the word after the word ``break'' in the exception would be
Paul>     a unique (or ``unique-enough'') tag that would allow the ``right''
Paul>     catch routine to catch the tag, and all others to ignore it.

It would also tend to violate the current (desired, I presume?)
feature of the language that function names are not looked up
lexically but only dynamically:

	; fn foo {echo outer}
	; let (fn foo {echo inner}) {foo; $fn-foo}
	outer
	inner

Enough said for now, I think.  This requires more thought, still, and
I am curious to hear what other people might say.

- Harald