Lex Spoon wrote:
>>> (function(x, y) {
>>> print(y);
>>> })(2, x)
>> We've been over this. What if you replace print(y) with return y?
>
> Desugaring to closures is highly worthwhile, so it looks worth solving
> these. Defining good variable-definition semantics is hard, as the
> experience with var shows, so it's good to reuse function literals if
> at all possible.
>
> The problems you describe are actually not hard to fix. All that has
> to happen is that return is labeled with the function it applies to.
> If at parse time no label is supplied, then the parser can manufacture
> a label to use.
>
> The simplest implementation is that if whenever you create a function
> object with a return in it, you record in the object the stack frame
> that that return would apply to. This stack frame will always be
> either the current stack frame, or one that was passed in from a
> surrounding frame. When a return actually happens, you can then pop
> the stack until you get to that frame, or else signal an error if that
> frame has already popped.
>
> Common Lisp works this way, and as far as I know it has worked out
> nicely. Scala faced this exact problem, and it added non-local
> returns to address them. Smalltalk has non-local returns, presumably
> because it, too, uses a lot of nested anonymous functions, and they
> work well there, too.
>
> So, I agree that return, etc., need to be fixed up if you desugar to
> closures, but they can indeed be fixed up. Further, you probably want
> non-local return anyway if people are going to use a lot of function
> literals in their code.
>
> Likewise for break and continue (which are already labeled), and
> arguments (which could certainly be labeled).
and 'var'? (See the discussion of let-statements in the other thread.)
Waldemar
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
