grammar update

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

grammar update

Jeff Dyer
Hi,

I've updated the ES4 grammar files linked from

  http://wiki.ecmascript.org/doku.php?id=proposals:normative_grammar

This version is my best attempt to describe the syntax of the language that
the ES4 working group is converging on. This convergence is reflected in the
feature spreadsheet posted at:

  http://spreadsheets.google.com/pub?key=pFIHldY_CkszsFxMkQOReAQ&gid=2

I expect the syntax described by the updated grammar to be fairly
representative of the final language that will be proposed by the ES4
working group as the next edition of ECMAScript. Most of the recent changes
are either bug fixes or feature cuts. There are few notable additions
(SplatExpression may be the only one) or feature redesigns (use strict and
LikedPattern being examples). Changes are logged in the Revision History
section in the wiki and at the bottom of the spreadsheet.

NOTE: I have removed from the PDF the columns that show the translation from
concrete to surface syntax, as they are out of date. However, you will find
these obsolete columns in the updated XLS spreadsheet. I will provide a text
based description of this translation in the next week or so.

Comments welcomed. Enjoy!

Jd

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: grammar update

Lars Hansen-3
Observed on page 1:

'enum' and 'wrap' do not belong in the list of reserved words.

If 'has' is contextually reserved then so is 'invoke'.

--lars

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Jeff Dyer
> Sent: 30. mars 2008 18:30
> To: es4-discuss
> Subject: grammar update
>
> Hi,
>
> I've updated the ES4 grammar files linked from
>
>   http://wiki.ecmascript.org/doku.php?id=proposals:normative_grammar
>
> This version is my best attempt to describe the syntax of the
> language that the ES4 working group is converging on. This
> convergence is reflected in the feature spreadsheet posted at:
>
>   http://spreadsheets.google.com/pub?key=pFIHldY_CkszsFxMkQOReAQ&gid=2
>
> I expect the syntax described by the updated grammar to be
> fairly representative of the final language that will be
> proposed by the ES4 working group as the next edition of
> ECMAScript. Most of the recent changes are either bug fixes
> or feature cuts. There are few notable additions
> (SplatExpression may be the only one) or feature redesigns
> (use strict and LikedPattern being examples). Changes are
> logged in the Revision History section in the wiki and at the
> bottom of the spreadsheet.
>
> NOTE: I have removed from the PDF the columns that show the
> translation from concrete to surface syntax, as they are out
> of date. However, you will find these obsolete columns in the
> updated XLS spreadsheet. I will provide a text based
> description of this translation in the next week or so.
>
> Comments welcomed. Enjoy!
>
> Jd
>
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: grammar update

Jeff Dyer
IIRC, 'enum' is one of the four extra IE reserved words that we've reserved
for posterity. 'wrap' and 'has' should be removed from their respective
lists.

Thanks,

Jd


On 3/30/08 8:31 PM, Lars Hansen wrote:

> Observed on page 1:
>
> 'enum' and 'wrap' do not belong in the list of reserved words.
>
> If 'has' is contextually reserved then so is 'invoke'.
>
> --lars
>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Jeff Dyer
>> Sent: 30. mars 2008 18:30
>> To: es4-discuss
>> Subject: grammar update
>>
>> Hi,
>>
>> I've updated the ES4 grammar files linked from
>>
>>   http://wiki.ecmascript.org/doku.php?id=proposals:normative_grammar
>>
>> This version is my best attempt to describe the syntax of the
>> language that the ES4 working group is converging on. This
>> convergence is reflected in the feature spreadsheet posted at:
>>
>>   http://spreadsheets.google.com/pub?key=pFIHldY_CkszsFxMkQOReAQ&gid=2
>>
>> I expect the syntax described by the updated grammar to be
>> fairly representative of the final language that will be
>> proposed by the ES4 working group as the next edition of
>> ECMAScript. Most of the recent changes are either bug fixes
>> or feature cuts. There are few notable additions
>> (SplatExpression may be the only one) or feature redesigns
>> (use strict and LikedPattern being examples). Changes are
>> logged in the Revision History section in the wiki and at the
>> bottom of the spreadsheet.
>>
>> NOTE: I have removed from the PDF the columns that show the
>> translation from concrete to surface syntax, as they are out
>> of date. However, you will find these obsolete columns in the
>> updated XLS spreadsheet. I will provide a text based
>> description of this translation in the next week or so.
>>
>> Comments welcomed. Enjoy!
>>
>> Jd
>>
>> _______________________________________________
>> Es4-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es4-discuss
>>

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: grammar update

Jon Zeppieri-2
In reply to this post by Jeff Dyer
On 3/30/08, Jeff Dyer <[hidden email]> wrote:
> Hi,
>
>  I've updated the ES4 grammar files linked from
>
>   http://wiki.ecmascript.org/doku.php?id=proposals:normative_grammar

Thanks, Jeff.

- Allowing splat expressions in array literals is a nice addition, but
restricting them to the end of element lists seems unnecessary.  Is
the purpose uniformity between array literals and array patterns?

- (Not entirely a grammar issue.)  What is the intended effect of:

var o = { get x() { ... } }
delete o.x

Currently the RI allows the deletion.  That seems fine, but the
grammar doesn't permit:

({ const get x() { ... } })

Could FieldKind be allowed before 'get' or 'set' in a LiteralField?

-Jon
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: grammar update

Dave Herman-2
> - Allowing splat expressions in array literals is a nice addition, but
> restricting them to the end of element lists seems unnecessary.  Is
> the purpose uniformity between array literals and array patterns?

Almost: uniformity between array literals and function calls. But
another issue was typeability-- it won't be possible for a statically
typed mode to type-check splicing in the middle of an array. But even if
we allowed splatting in the middle of *both* array literals and function
calls (though a statically typed mode would reject them), the patterns
would still probably need to be more restricted, which can be confusing.

Dave
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: grammar update

Dave Herman-2
> Almost: uniformity between array literals and function calls. But
> another issue was typeability-- it won't be possible for a statically
> typed mode to type-check splicing in the middle of an array.

Maybe I spoke too soon on that point-- depending on the array types, it
might not be problematic. But it certainly would be problematic to
type-check splatting into the middle of the actuals list for a function
call.

Dave
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: grammar update

Eric Suen-4
In reply to this post by Jeff Dyer
Hi,

Does the order of rules means different priority? otherwise why
PropertyName is same as PrimaryName, and what is that number before
each rule means?

Regards

Eric Suen


_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: grammar update

Jeff Dyer



On 3/31/08 8:12 AM, Eric Suen wrote:

> Hi,
>
> Does the order of rules means different priority?

The order of the rules has no meaning.

> otherwise why
> PropertyName is same as PrimaryName,

These two symbols have converged with recent changes. The use of
PropertyName in PropertyOperator should be replaced with PrimaryName, and
the definition of PropertyName should be removed from the grammar. Good
catch!

> and what is that number before
> each rule means?

The edition of ECMAScript that the production was introduced.

Jd

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: grammar update

Lars Hansen-3
In reply to this post by Jeff Dyer
It's not clear that 'has' should be removed, but it could be removed for
the time being.  The discussion on this list in the past couple of weeks
(Subject: "ES4 draft: Object initializers") indicates that the following
forms should possibly be allowed for catchalls:

  { get() ...,
    set() ...,
    has() ...,
    delete() ...
    invoke() ... }

These forms create fixtures and stand for the meta::invoke etc methods.
Anyhow those five names become reserved contextually.  All of that is of
course subject to further discussion as soon as I can get a new draft
out of the feature spec.

I disagree that 'enum' should be reserved in ES4.  E262-3 ch 16 is
explicit in allowing syntactic extensions and it appears that Opera and
Firefox do not reserve 'enum', suggesting that 'enum' is not in use on
the public web.

Which are the three other IE reserved words?  So far as I can see, the
list of reserved and contextually reserved identifiers contain only ES4
keywords.

--lars

> -----Original Message-----
> From: Jeff Dyer
> Sent: 30. mars 2008 21:52
> To: Lars Hansen; es4-discuss
> Subject: Re: grammar update
>
> IIRC, 'enum' is one of the four extra IE reserved words that
> we've reserved for posterity. 'wrap' and 'has' should be
> removed from their respective lists.
>
> Thanks,
>
> Jd
>
>
> On 3/30/08 8:31 PM, Lars Hansen wrote:
>
> > Observed on page 1:
> >
> > 'enum' and 'wrap' do not belong in the list of reserved words.
> >
> > If 'has' is contextually reserved then so is 'invoke'.
> >
> > --lars
> >
> >> -----Original Message-----
> >> From: [hidden email]
> >> [mailto:[hidden email]] On Behalf Of Jeff Dyer
> >> Sent: 30. mars 2008 18:30
> >> To: es4-discuss
> >> Subject: grammar update
> >>
> >> Hi,
> >>
> >> I've updated the ES4 grammar files linked from
> >>
> >>  
> http://wiki.ecmascript.org/doku.php?id=proposals:normative_grammar
> >>
> >> This version is my best attempt to describe the syntax of the
> >> language that the ES4 working group is converging on. This
> >> convergence is reflected in the feature spreadsheet posted at:
> >>
> >>  
> >>
> http://spreadsheets.google.com/pub?key=pFIHldY_CkszsFxMkQOReAQ&gid=2
> >>
> >> I expect the syntax described by the updated grammar to be fairly
> >> representative of the final language that will be proposed
> by the ES4
> >> working group as the next edition of ECMAScript. Most of
> the recent
> >> changes are either bug fixes or feature cuts. There are
> few notable
> >> additions (SplatExpression may be the only one) or feature
> redesigns
> >> (use strict and LikedPattern being examples). Changes are
> logged in
> >> the Revision History section in the wiki and at the bottom of the
> >> spreadsheet.
> >>
> >> NOTE: I have removed from the PDF the columns that show the
> >> translation from concrete to surface syntax, as they are
> out of date.
> >> However, you will find these obsolete columns in the updated XLS
> >> spreadsheet. I will provide a text based description of this
> >> translation in the next week or so.
> >>
> >> Comments welcomed. Enjoy!
> >>
> >> Jd
> >>
> >> _______________________________________________
> >> Es4-discuss mailing list
> >> [hidden email]
> >> https://mail.mozilla.org/listinfo/es4-discuss
> >>
>
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: grammar update

Jeff Dyer



On 3/31/08 10:33 AM, Lars Hansen wrote:

> I disagree that 'enum' should be reserved in ES4.  E262-3 ch 16 is
> explicit in allowing syntactic extensions and it appears that Opera and
> Firefox do not reserve 'enum', suggesting that 'enum' is not in use on
> the public web.

I don't remember why we decided to add 'enum' to ReservedIdentifiers.
Perhaps it was sympathy with the other three. Perhaps Brendan will remember.

>
> Which are the three other IE reserved words?  So far as I can see, the
> list of reserved and contextually reserved identifiers contain only ES4
> keywords.

They are 'class', 'extends' and 'super'. Of these 'extends' should be
contextually reserved. The other two have special meaning in a broad enough
context that they should probably be generally reserved.

Jd

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: grammar update

Brendan Eich-2
On Mar 31, 2008, at 1:24 PM, Jeff Dyer wrote:

> On 3/31/08 10:33 AM, Lars Hansen wrote:
>
>> I disagree that 'enum' should be reserved in ES4.  E262-3 ch 16 is
>> explicit in allowing syntactic extensions and it appears that  
>> Opera and
>> Firefox do not reserve 'enum', suggesting that 'enum' is not in  
>> use on
>> the public web.
>
> I don't remember why we decided to add 'enum' to ReservedIdentifiers.
> Perhaps it was sympathy with the other three. Perhaps Brendan will  
> remember.

At one point we were entertaining an enum proposal based on JScript.NET:

http://wiki.ecmascript.org/doku.php?id=proposals:enumeration_type

Old Firefox and Mozilla browsers would reserve, but we unreserved  
'enum' and the rest a while ago (Firefox 1.5? I forget), instead  
making any use of one of these words cause a strict warning.

/be
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: grammar update

Eric Suen-4
In reply to this post by Jeff Dyer
Page 11
 FunctionDeclaration ::= function FunctionName FunctionSignature
should be
 FunctionDeclarationW ::= function FunctionName FunctionSignature SemicolonW

following statement:
  type function() like AAA

Should it be:
 RelationalExpression like TypeExpression (like is operator)
 [type function()] like [AAA]
or
 type FunctionType (like is ResultType)
 type [function() like AAA]

Regards,

Eric Suen


_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: grammar update

Eric Suen-4
Hi,

the statement is:

var a = function() type function() like AAA

RelationalExpression ::= RelationalExpression like TypeExpression

RelationalExpression -> PostfixExpression -> PrimaryExpression
 -> FunctionExpression

FunctionExpression ::= function FunctionSignature FunctionExpressionBody

FunctionExpressionBody ::= AssignmentExpression

AssignmentExpression -> ConditionalExpression -> UnaryTypeExpression
-> type TypeExpression -> type FunctionType
 -> type function FunctionSignature

FunctionSignature ::= TypeParameters '(' Parameters ')' ResultType

ResultType ::= $empty
 | ':' 'void'
 | ':' TypeExpression
 | 'like' TypeExpression  -- conflict on this rule with $empty

So, is it
 var a = FunctionExpression like AAA
or
 var a = function() type FunctionType


----- Original Message -----
From: "Eric Suen" <[hidden email]>
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: <[hidden email]>
Sent: Tuesday, April 01, 2008 7:35 PM
Subject: Re: grammar update


> Page 11
> FunctionDeclaration ::= function FunctionName FunctionSignature
> should be
> FunctionDeclarationW ::= function FunctionName FunctionSignature SemicolonW
>
> following statement:
>  type function() like AAA
>
> Should it be:
> RelationalExpression like TypeExpression (like is operator)
> [type function()] like [AAA]
> or
> type FunctionType (like is ResultType)
> type [function() like AAA]
>
> Regards,
>
> Eric Suen


_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: grammar update

Jeff Dyer
It should be

  var a = (function () type function ()) like AAA

In other words, your first option

  var a = FunctionExpression like AAA

where AAA must be a TypeExpression.

Jd


On 4/1/08 8:37 PM, Eric Suen wrote:

> Hi,
>
> the statement is:
>
> var a = function() type function() like AAA
>
> RelationalExpression ::= RelationalExpression like TypeExpression
>
> RelationalExpression -> PostfixExpression -> PrimaryExpression
>  -> FunctionExpression
>
> FunctionExpression ::= function FunctionSignature FunctionExpressionBody
>
> FunctionExpressionBody ::= AssignmentExpression
>
> AssignmentExpression -> ConditionalExpression -> UnaryTypeExpression
> -> type TypeExpression -> type FunctionType
>  -> type function FunctionSignature
>
> FunctionSignature ::= TypeParameters '(' Parameters ')' ResultType
>
> ResultType ::= $empty
>  | ':' 'void'
>  | ':' TypeExpression
>  | 'like' TypeExpression  -- conflict on this rule with $empty
>
> So, is it
>  var a = FunctionExpression like AAA
> or
>  var a = function() type FunctionType
>
>
> ----- Original Message -----
> From: "Eric Suen" <[hidden email]>
> Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
> To: <[hidden email]>
> Sent: Tuesday, April 01, 2008 7:35 PM
> Subject: Re: grammar update
>
>
>> Page 11
>> FunctionDeclaration ::= function FunctionName FunctionSignature
>> should be
>> FunctionDeclarationW ::= function FunctionName FunctionSignature SemicolonW
>>
>> following statement:
>>  type function() like AAA
>>
>> Should it be:
>> RelationalExpression like TypeExpression (like is operator)
>> [type function()] like [AAA]
>> or
>> type FunctionType (like is ResultType)
>> type [function() like AAA]
>>
>> Regards,
>>
>> Eric Suen
>
>
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: grammar update

Jason Orendorff
In reply to this post by Jeff Dyer
On Sun, Mar 30, 2008 at 7:29 PM, Jeff Dyer <[hidden email]> wrote:
>  I've updated the ES4 grammar files linked from
>   http://wiki.ecmascript.org/doku.php?id=proposals:normative_grammar

Thanks for doing this.  I noticed that the grammar doesn't allow this:

  [addr
    for each (user in users)
      if (user.isAdministrator)
        for each (addr in user.addresses)]

Is this intentional?  Both Python and Haskell allow the analogous
listcomp.  (Oddly enough, if you anti-optimize this, moving the
IfCondition to be after the last ForInExpression, the proposed ES4
grammar accepts that.)

Separately, I would appreciate let clauses in ArrayComprehensions:

  [[trial, phi]
    for each (trial in trials)
      let (phi = hugeExpensiveCalculation(trial))
        if (phi < 1000)]

Haskell has this feature.  I occasionally reach for it in Python and
it isn't there.

-j
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: grammar update

Lars Hansen-3
Looks like those restrictions (condition only at the end, only 'for',
'for each',
and 'if' clauses) originate in Brendan's original (too-sketchy)
proposal, see
the "Comprehensions" section of this page:

http://wiki.ecmascript.org/doku.php?id=proposals:iterators_and_generator
s

IMO we're looking for simple and useful comprehensions for ES4.  I
think extensions like the ones you are suggesting, though clearly
useful,
should be prototyped elsewhere before going into the language spec, or
at a minimum, be presented in a better developed proposal.

--lars

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Jason Orendorff
> Sent: 2. april 2008 13:46
> To: Jeff Dyer
> Cc: es4-discuss
> Subject: Re: grammar update
>
> On Sun, Mar 30, 2008 at 7:29 PM, Jeff Dyer <[hidden email]> wrote:
> >  I've updated the ES4 grammar files linked from
> >   http://wiki.ecmascript.org/doku.php?id=proposals:normative_grammar
>
> Thanks for doing this.  I noticed that the grammar doesn't allow this:
>
>   [addr
>     for each (user in users)
>       if (user.isAdministrator)
>         for each (addr in user.addresses)]
>
> Is this intentional?  Both Python and Haskell allow the
> analogous listcomp.  (Oddly enough, if you anti-optimize
> this, moving the IfCondition to be after the last
> ForInExpression, the proposed ES4 grammar accepts that.)
>
> Separately, I would appreciate let clauses in ArrayComprehensions:
>
>   [[trial, phi]
>     for each (trial in trials)
>       let (phi = hugeExpensiveCalculation(trial))
>         if (phi < 1000)]
>
> Haskell has this feature.  I occasionally reach for it in
> Python and it isn't there.
>
> -j
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: grammar update

Brendan Eich-2
On Apr 2, 2008, at 1:03 PM, Lars Hansen wrote:

> Looks like those restrictions (condition only at the end, only 'for',
> 'for each',
> and 'if' clauses) originate in Brendan's original (too-sketchy)
> proposal, see
> the "Comprehensions" section of this page:
>
> http://wiki.ecmascript.org/doku.php?
> id=proposals:iterators_and_generator
> s

This is my fault -- I went by the examples in

http://www.python.org/dev/peps/pep-0202/

and did not include the full grammar from

http://www.python.org/doc/current/ref/lists.html#l2h-238

cited therein -- apologies to all and thanks to Jason for pointing  
this out.

> IMO we're looking for simple and useful comprehensions for ES4.  I
> think extensions like the ones you are suggesting, though clearly
> useful,
> should be prototyped elsewhere before going into the language spec, or
> at a minimum, be presented in a better developed proposal.

This is all thin syntactic sugar, so I don't agree it rocks the boat  
too much to follow the full prototype in Python. I'll update the  
proposal, since it claims to follow the PEP, but fails since the PEP  
cites the RM.

Jason wrote:

>> Separately, I would appreciate let clauses in ArrayComprehensions:
>>
>>   [[trial, phi]
>>     for each (trial in trials)
>>       let (phi = hugeExpensiveCalculation(trial))
>>         if (phi < 1000)]
>>
>> Haskell has this feature.  I occasionally reach for it in
>> Python and it isn't there.

Lars, you didn't cite this use-case for let statements, aka let  
blocks :-P. Firefox 2 and 3 (JS1.7 and 1.8) have support for let  
blocks, but again not embedded in comprehensions. As Jason notes,  
Python didn't follow Haskell here (if that was the order of  
evolution). I don't propose we do this for ES4, since let blocks are  
"out" according to all who've opined on the spreadsheet.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: grammar update

Lars Hansen-3
> -----Original Message-----
> From: Brendan Eich [mailto:[hidden email]]
> Sent: 2. april 2008 17:15
> To: Lars Hansen
> Cc: Jason Orendorff; Jeff Dyer; es4-discuss
> Subject: Re: grammar update
>
> On Apr 2, 2008, at 1:03 PM, Lars Hansen wrote:
>
> > Looks like those restrictions (condition only at the end,
> only 'for',
> > 'for each', and 'if' clauses) originate in Brendan's original
> > (too-sketchy) proposal, see the "Comprehensions" section of
> this page:
> >
> > http://wiki.ecmascript.org/doku.php?
> > id=proposals:iterators_and_generator
> > s
>
> This is my fault -- I went by the examples in
>
> http://www.python.org/dev/peps/pep-0202/
>
> and did not include the full grammar from
>
> http://www.python.org/doc/current/ref/lists.html#l2h-238
>
> cited therein -- apologies to all and thanks to Jason for
> pointing this out.
>
> > IMO we're looking for simple and useful comprehensions for ES4.  I
> > think extensions like the ones you are suggesting, though clearly
> > useful, should be prototyped elsewhere before going into
> the language
> > spec, or at a minimum, be presented in a better developed proposal.
>
> This is all thin syntactic sugar, so I don't agree it rocks
> the boat too much to follow the full prototype in Python.
> I'll update the proposal, since it claims to follow the PEP,
> but fails since the PEP cites the RM.

The PEP is scarcely relevant; what we need are comprehensive
proposals for ES4.

> Jason wrote:
>
> >> Separately, I would appreciate let clauses in ArrayComprehensions:
> >>
> >>   [[trial, phi]
> >>     for each (trial in trials)
> >>       let (phi = hugeExpensiveCalculation(trial))
> >>         if (phi < 1000)]
> >>
> >> Haskell has this feature.  I occasionally reach for it in
> Python and
> >> it isn't there.
>
> Lars, you didn't cite this use-case for let statements, aka
> let blocks :-P. Firefox 2 and 3 (JS1.7 and 1.8) have support
> for let blocks, but again not embedded in comprehensions. As
> Jason notes, Python didn't follow Haskell here (if that was
> the order of evolution). I don't propose we do this for ES4,
> since let blocks are "out" according to all who've opined on
> the spreadsheet.

The syntax Jason uses is not for let blocks, but for let
expressions.  Not that I see how it matters, since surely the
'for each' and 'if' forms in array comprehensions are not
meant to be taken to be the same as their statement counterparts
in all ways.

Please do update the spec for comprehensions; I will not make
it my job to figure out what you meant by studying Python.  The
spec that's there is too informal as well, consisting only of
illustrative examples.  It needs (probably) a grammar and
semantics at a minimum.

(The page the generator proposal is on is already far too large;
I suggest that you break generators out as a separate proposal.)

--lars
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: grammar update

Brendan Eich-2
On Apr 2, 2008, at 6:01 PM, Lars Hansen wrote:

>> This is all thin syntactic sugar, so I don't agree it rocks
>> the boat too much to follow the full prototype in Python.
>> I'll update the proposal, since it claims to follow the PEP,
>> but fails since the PEP cites the RM.
>
> The PEP is scarcely relevant; what we need are comprehensive
> proposals for ES4.

Touché (again; last time, I won't grovel :-/). My point is that the  
proposal is intended to avoid novelty in comparison to Python,  
especially novelty due to my poor mistake. Not all of ES4 is yet  
fully or even well-specified (e.g., packages -- this was clear from  
the last TC39 meeting). But where use-cases are strong, we are  
persevering, not rejecting over surface-syntax transcription errors,  
or even deeper issues.

> The syntax Jason uses is not for let blocks, but for let
> expressions.

Syntax is secondary to context in making the point that let forms  
containing statements are useful. I'm not quibbling, or trying to  
revive let statements; I am simply citing a use case for the record.

>  Not that I see how it matters, since surely the
> 'for each' and 'if' forms in array comprehensions are not
> meant to be taken to be the same as their statement counterparts
> in all ways.

They de-sugar internally to statements. The implementation in JS1.7  
transforms the AST in the obvious way before handing it off to the  
code generator. The only new AST node is the one representing the  
consumer of the displayed expression (the expression on the left of  
'for'), which is a built-in form of Array push, as noted in the  
proposal.

These are not anything but statements as far as the programmer can  
tell, but of course the syntax is restricted. I'm happy to fix the  
unintended over-restriction.

> Please do update the spec for comprehensions; I will not make
> it my job to figure out what you meant by studying Python.  The
> spec that's there is too informal as well, consisting only of
> illustrative examples.  It needs (probably) a grammar and
> semantics at a minimum.

Ok.

> (The page the generator proposal is on is already far too large;
> I suggest that you break generators out as a separate proposal.)

Will do.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss