On May 24, 2011, at 7:20 PM, Jon Zeppieri wrote:
> On Tue, May 24, 2011 at 3:29 PM, Brendan Eich wrote:
>>
>>
>> BlockArguments :
>>BlockLambda
>>BlockArguments [no LineTerminator here] BlockLambda
>>BlockArguments [no LineTerminator here] ( Expression )
>>
>
> The interleaved par
On Tue, May 24, 2011 at 3:29 PM, Brendan Eich wrote:
>
>
> BlockArguments :
> BlockLambda
> BlockArguments [no LineTerminator here] BlockLambda
> BlockArguments [no LineTerminator here] ( Expression )
>
The interleaved parenthesized expression worries me for two reasons:
- Waldemar's
I've updated the grammar to fix the bugs Waldemar and Jon pointed out:
http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival
ElementList : // See 11.1.4
Elisionopt InitialValue
ElementList , Elisionopt InitialValue
PropertyAssignment :
On May 24, 2011, at 7:44 AM, Brendan Eich wrote:
> You're right, this would be unambiguous because a block can't initialize a
> var. The only interpretation is an expression, which with Allen's proposal
> combined with object intiialiser shorthand would parse {!b}.
One more thing: {b} in expres
On May 24, 2011, at 7:37 AM, Sean Eagan wrote:
> I am definitely a grammar classification noob, so feel free to rake me
> over the coals on this if necessary, but how is :
>
> var a = {!b};
>
> ... any more difficult to parse than ...
>
> var a = {b};
>
> ... both {b} and {!b} and valid blocks
On Tue, May 24, 2011 at 9:10 AM, Brendan Eich wrote:
> On May 24, 2011, at 7:02 AM, Sean Eagan wrote:
>
>>> This conflicts with the existing:
>>> var foo = "bar";
>>> {foo} // "bar"
>>> {!foo} // false
>>>
>>
>> No, just because |{!b}| is current syntax, doesn't mean that |var a = {!b}|
>> is.
>
On May 24, 2011, at 7:02 AM, Sean Eagan wrote:
>> This conflicts with the existing:
>> var foo = "bar";
>> {foo} // "bar"
>> {!foo} // false
>>
>
> No, just because |{!b}| is current syntax, doesn't mean that |var a = {!b}|
> is.
I've been working on syntax lately, and based on that work, I t
On Tue, May 24, 2011 at 9:02 AM, Sean Eagan wrote:
> // ->
>
> function A (){
> var a = arguments[0];
> Object.defineProperty(this, "b", {configurable: false, enumerable:
> false, writable: true, arguments[1]})
> Object.defineProperty(this, "c", {configurable: true, enumerable:
> true, writable
On Mon, May 23, 2011 at 4:44 PM, Rick Waldron wrote:
> Please excuse me, I'm just looking for clarification - thanks in advance:
>
>>
>> Also, the current infix writable mark does not compose with "Implicit
>> property initialization expressions" [1] as noted in [2]. Using a
>> prefix fixes this:
On May 24, 2011, at 6:20 AM, Andreas Rossberg wrote:
> - Treat projection from a module M (which we can distinguish
> statically) specially. If we project a yet unclosed function:
> * if it's called right away, pass M.Env as the environment,
> * if it's not called, allocate a proper closure for
On May 24, 2011, at 12:18 AM, Jon Zeppieri wrote:
> Should that be:
>
> MemberExpression [no LineTerminator here] BlockArguments
>
> instead? This may just be the sleepiness talking, but it looks like a
> CallExpression always starts with
>
> MemberExpression Arguments
>
> which would requ
On 23 May 2011 19:48, Mark S. Miller wrote:
> On Mon, May 23, 2011 at 7:22 AM, Andreas Rossberg
> wrote:
>> On 20 May 2011 15:42, Mark S. Miller wrote:
>> > Modules aren't generative.
>>
>> If you mean that you cannot create several objects from them, then
>> yes, but see my reply to Dave.
>>
>>
On 23 May 2011 19:42, Mark S. Miller wrote:
> On Mon, May 23, 2011 at 2:16 PM, Andreas Rossberg
> wrote:
>> Compare:
>>
>> class Point {
>> private x, y
>> constructor(x0, y0) { x = x0; y = y0 }
>> public function move(dx, dy) { x += dx; y += dy }
>> public function abs() { return Ma
On Fri, May 20, 2011 at 8:54 PM, Brendan Eich wrote:
> As promised/threatened:
> http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival
>
Sorry to take a step back here. After reading Waldemar's comments, I
took a closer look at the formal grammar, and I'm puzzled by the
production
14 matches
Mail list logo
