Re: return when desugaring to closures

On Oct 16, 2008, at 7:01 PM, Brendan Eich wrote: On Oct 16, 2008, at 3:33 PM, Brendan Eich wrote: On Oct 16, 2008, at 1:20 PM, Waldemar Horwat wrote: I don't think you can come up with a consistent "shift" or "greedy" notion. Funny, yacc has had one for decades, used to resolve dangling-

Re: return when desugaring to closures

On Thu, Oct 16, 2008 at 5:49 PM, David-Sarah Hopwood <[EMAIL PROTECTED]> wrote: > [lots of good stuff snipped] I agree. > The degenerate syntax "let {...}" allowed by this grammar at first-sight > doesn't seem very useful, until you realize that it has a similar effect > (apart from not preventin

Re: return when desugaring to closures

Brendan Eich wrote: > On Oct 16, 2008, at 1:20 PM, Waldemar Horwat wrote: > >> I don't think you can come up with a consistent "shift" or "greedy" >> notion. > > Funny, yacc has had one for decades, used to resolve dangling-else. > > >> The one you may be thinking of will happily accept code s

Re: return when desugaring to closures

On Oct 16, 2008, at 3:33 PM, Brendan Eich wrote: On Oct 16, 2008, at 1:20 PM, Waldemar Horwat wrote: I don't think you can come up with a consistent "shift" or "greedy" notion. Funny, yacc has had one for decades, used to resolve dangling-else. Which ES1-3 also use: 12.5 The if Statement

Re: Lambda vs. function

Dave Herman wrote: >>> b) creating a clearer place in the language syntax to enforce tail >>> calling by eliminating `return' >> >> I don't understand what you mean in point b. > > Consider two different syntaxes for a function performing a tail call: > > lambda(x) { f(x) } > function(x)

Re: Lambda vs. function

Brendan Eich wrote: > On Oct 16, 2008, at 1:55 PM, Waldemar Horwat wrote: > >> var: Not an issue if you're not using var inside the lambda. Code >> generation that wants to use lambda would use var why? >> >> arguments: Again, not an issue if you're not using the arguments >> array. If a cod

Re: return when desugaring to closures

Mark S. Miller wrote: > On Wed, Oct 15, 2008 at 4:49 PM, Dave Herman <[EMAIL PROTECTED]> wrote: >> In the grammar for proposed ES4, LetExpression was under >> PrimaryExpression. That's where I'm suggesting LambdaExpression might >> fit. IOW: >> >> PrimaryExpression ::= ... >>|

Re: return when desugaring to closures

On Oct 16, 2008, at 3:33 PM, Brendan Eich wrote: > SpiderMonkey historically used SyntaxError, not ReferenceError, and > throw at compile-time. This pre-dates ES1. Another example not > involving let expressions: > > js> a + b = c > typein:1: SyntaxError: invalid assignment left-hand side: > t

Re: return when desugaring to closures

On Oct 15, 2008, at 1:28 PM, Mark S. Miller wrote: > On Wed, Oct 15, 2008 at 12:31 PM, Dave Herman <[EMAIL PROTECTED]> > wrote: >> Do you prefer (lambda Formals Block | lambda Formals Expression)? >> [Personally I'm fine with that.] Or do you oppose any lambda >> expressions >> at all? Or did

Re: Lambda vs. function

On Thu, Oct 16, 2008 at 3:04 PM, Brendan Eich <[EMAIL PROTECTED]> wrote: > On Oct 16, 2008, at 1:55 PM, Waldemar Horwat wrote: > >> var: Not an issue if you're not using var inside the lambda. Code >> generation that wants to use lambda would use var why? >> >> arguments: Again, not an issue if

Re: return when desugaring to closures

On Oct 16, 2008, at 1:20 PM, Waldemar Horwat wrote: I don't think you can come up with a consistent "shift" or "greedy" notion. Funny, yacc has had one for decades, used to resolve dangling-else. The one you may be thinking of will happily accept code such as let (a = 5) x + y.foo = 2; y

Re: Lambda vs. function

On Oct 16, 2008, at 1:55 PM, Waldemar Horwat wrote: > var: Not an issue if you're not using var inside the lambda. Code > generation that wants to use lambda would use var why? > > arguments: Again, not an issue if you're not using the arguments > array. If a code generator is updated for

Re: Lambda vs. function

>> b) creating a clearer place in the language syntax to enforce tail >> calling by eliminating `return' > > I don't understand what you mean in point b. Consider two different syntaxes for a function performing a tail call: lambda(x) { f(x) } function(x) { return f(x) } The traditio

Lambda vs. function

Dave Herman wrote: >> I don't see enough of a benefit to warrant inclusion of a new lambda >> concept. It's just another way of doing what local functions can do. > > As I see it, the major benefits of `lambda' are > > a) introducing a low-level and compositional primitive that is useful > for

Re: return when desugaring to closures

On Wed, Oct 15, 2008 at 4:49 PM, Dave Herman <[EMAIL PROTECTED]> wrote: > In the grammar for proposed ES4, LetExpression was under > PrimaryExpression. That's where I'm suggesting LambdaExpression might > fit. IOW: > > PrimaryExpression ::= ... >| LetExpression >

Re: return when desugaring to closures

Brendan Eich wrote: > On Oct 16, 2008, at 11:38 AM, Waldemar Horwat wrote: > >> Brendan Eich wrote: >>> That's not a valid grammar. > > It is unambiguous. How do you define "valid"? > >>> You can't have an AssignmentExpression terminating a >>> PrimaryExpression. It leads to trouble such as:

ES3.1 draft, 13 Oct 2008 --15.9.5.43 Date.prototype.toISOString ( )

This section doesn't address the precision to which the date should be printed. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/

Re: return when desugaring to closures

On Oct 16, 2008, at 11:38 AM, Waldemar Horwat wrote: > Brendan Eich wrote: >> That's not a valid grammar. It is unambiguous. How do you define "valid"? >> You can't have an AssignmentExpression terminating a >> PrimaryExpression. It leads to trouble such as: > > let a = b + c > > being inter

Re: return when desugaring to closures

Brendan Eich wrote: > On Oct 15, 2008, at 2:36 PM, Waldemar Horwat wrote: > >> There is no such thing as a "let expression". > > Let expressions > in > JS1.7 (Firefox 2+), based on the ES4 proposal >

ByteArray

Hi, ECMAScript 4 had a ByteArray feature that the W3C WebApps WG wanted to use for XMLHttpRequest Level 2, to expose the raw response data and also to allow any entity body to be transmitted to the server the author could think of. However, ByteArray is no longer there. HTML5 has a concept