Re: Rename Number.prototype.clz to Math.clz

[Qantas 94 Heavy]

My bad, should have replied to all. Thanks for clarifying though.


On Fri, Jan 31, 2014 at 11:14 AM, Brendan Eich  wrote:

> Yes, that's right -- for type-inference-based JITs and AOT compilers that
> use a type-checked subset (asm.js, e.g.) this is not an issue. And as you
> noted up-thread, it matches other Math.* methods.
>
> Did you mean to reply only to me, or to reply-all?
>
> /be
>
>  Qantas 94 Heavy 
>> January 30, 2014 at 7:13 PM
>>
>> Sorry if this is stupid, but does that mean that it's been decided that
>> Math.clz32 will be generic (in that it won't throw a TypeError if it is not
>> a number object)?
>>
>>
>>
>> Brendan Eich 
>> January 30, 2014 at 6:43 PM
>>
>>
>>
>> ToUint32 does ToNumber in its first step (http://people.mozilla.org/~
>> jorendorff/es6-draft.html#sec-touint32).
>>
>> /be
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> Qantas 94 Heavy 
>> January 30, 2014 at 6:26 PM
>>
>>
>> Would Math.clz32 still throw a TypeError if the argument is not a number,
>> nor an object with the [[NumberData]] internal slot? Currently all math
>> functions perform ToNumber on their arguments, unlike what
>> Number.prototype.clz is currently specified to do.
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Rename Number.prototype.clz to Math.clz

[Brendan Eich]

Qantas 94 Heavy wrote:
Would Math.clz32 still throw a TypeError if the argument is not a 
number, nor an object with the [[NumberData]] internal slot? Currently 
all math functions perform ToNumber on their arguments, unlike what 
Number.prototype.clz is currently specified to do.


ToUint32 does ToNumber in its first step 
(http://people.mozilla.org/~jorendorff/es6-draft.html#sec-touint32).


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Rename Number.prototype.clz to Math.clz

[Qantas 94 Heavy]

Would Math.clz32 still throw a TypeError if the argument is not a number,
nor an object with the [[NumberData]] internal slot? Currently all math
functions perform ToNumber on their arguments, unlike what
Number.prototype.clz is currently specified to do.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Brendan Eich]

Thaddee Tyl wrote:

By the way, even in the current specification of let, we can still
construct a useless let:

 for (let x = 42;false;) console.log(x);

(which is the same as the example you gave, using "if").


Yes, this falls out of the JS (and Dart, convergent evolution, 
coincidental as far as I can tell) design, but so what? OMG LETS MAKE 
USELESS LETS EVERYWHERE LOLJSSUXZ0RZ! Um, no.


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Thaddee Tyl]

On Thu, Jan 30, 2014 at 8:27 PM, John Lenz  wrote:
> I don't argue that it isn't a useless "let".

For the sake of argument, can you construct a non-block-scoped `if (…)
…` which is actually any useful, assuming your mental model of

if (…) … <==> if (…) { … }

(which must be removed from teaching material) applies?

By the way, even in the current specification of let, we can still
construct a useless let:

for (let x = 42;false;) console.log(x);

(which is the same as the example you gave, using "if").
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Specification styles

[Boris Zbarsky]

On 1/30/14 11:52 AM, Forrest L Norvell wrote:

I agree with this entirely, with the caveat that "partially obscured"
and even "boilerplate" are in this case subjective factors.


Absolutely.  In fact, it sounds like we agree on most of this stuff in 
general. ;)



It's interesting that you raise this issue, because all of the aspects
involving asynchronicity and callbacks in Domenic's spec do so in the
context of ES promises, and unless I'm missing something


Hmm...  It's hard to tell.  I'm looking at things like [[callPull]](), 
which say:


  When/if this.[[startedPromise]] is fulfilled, call
  this.[[onPull]](this.[[push]], this.[[close]], this.[[error]]).

I don't think this is explicitly defining what the script settings stack 
looks like when the [[onPull]] function is called, because the "When/if 
this.[[startedPromise]] is fulfilled" wording doesn't tell me exactly 
how this interacts with the promise specification and its manipulation 
of that stack.  Is this supposed to have equivalent behavior to doing:


 this.[[startedPromise]].then(
   this.[[onPull]].bind(undefined, this.[[push]],
this.[[close]], this.[[error]]))

or something else?  If this is supposed to be like a then() call, then I 
agree that promises would completely define the behavior here.  But if 
this is just saying that at some point after the promise is fulfilled 
the [[onPull]] needs to be called, then the behavior is not defined by 
Promises.


Unfortunately, the promise specification doesn't handle incumbent/entry 
settings objects either, so the behavior is undefined no matter what. 
:(  It needs to.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Specification styles

[Allen Wirfs-Brock]

On Jan 30, 2014, at 11:52 AM, Forrest L Norvell wrote:

> On Thu, Jan 30, 2014 at 11:07 AM, Boris Zbarsky  wrote:
> ...
> I think we all agree that ES-style specifications are in fact more 
> straightforward to transcribe into an ES implementation.
> 
> What is harder, in my experience, is understanding whether the specification 
> actually says what it means to say and determining whether there are bugs in 
> the specification.  This arises to some extent from the core functionality 
> being partially obscured by a fair amount of boilerplate.
> 
> I agree with this entirely, with the caveat that "partially obscured" and 
> even "boilerplate" are in this case subjective factors. Once you split 
> Domenic's streams documentation into two pieces -- a narrative, informal 
> piece explaining the design and its motivation, and the specification proper, 
> which is still informal but more organized -- the specification itself seems 
> neither particularly verbose nor overdetermined. Again, this is my subjective 
> interpretation, but I've spent a fair amount of time dealing with 
> specifications (and, just to be clear, mostly not in the JavaScript world).
> 

Some of the boiler plate is just a legacy (go look at the ES3 spec) and I'm 
slowly eliminating some of the verbosity. But it is a fairly low priority task 
in the overall effort of finishing ES6.

> Neither WebIDL nor the style of ES-262 are formal specification languages, 
> nor do they specify any kind of rigorous operational semantics. This isn't a 
> problem, as that's not their purpose. Their purpose, as I understand it, is 
> to facilitate the specification of behavior in such a way that a consensus 
> can be formed as to whether a given implementation is congruent with a given 
> design (and, more nebulously, the designers' intent).
> 
> Now I agree this is somewhat subjective.  Some people prefer to have all the 
> complications explicitly written out, both in specifications and in code, 
> while others prefer reusable tested black boxes that have certain defined 
> behavior.  The former approach is much more verbose and can thus hinder 
> understanding of the big picture.  The latter approach involves in-depth 
> understanding of the black boxes to understand the details.  In practice, 
> both the WebIDL and ES styles use some mixture of the two; what differs is 
> the exact set of black boxes used.  The ES style black boxes are mostly more 
> fine-grained than the WebIDL ones.
> 
> I agree with this description, and I wish there were a way to support both 
> approaches. Neither the declarative style of WebIDL nor the imperative style 
> of ES-262 are good at capturing both at the same time. As designers and 
> researchers we want to be able to point to the formal model and, if not 
> prove, at least attempt to make strong assertions about particular behaviors 
> or abstractions. As implementors, it's much easier to work from imperative 
> descriptions of behavior, and the process of resolving the ambiguities during 
> implementation will surface aspects of the design that are not obvious when 
> looking at a declarative model.

The ES6 spec. is much more detailed and prescriptive than any other language 
specification I've ever been involved with. This is intentional and motivated 
by the fact that the interoperability expectations across multiple 
independently developed implementations of the language are much high than any 
other language I've ever encountered.  In addition, the collective experience 
in TC39 is that if something (for example various edge cases) is under 
specified in an ES spec. then implementations will inevitably  have observable 
differences and that some JS programmers will write code that is sensitive to 
the differences. Hence, ES6 tries to specify the handling of all edge cases and 
the ordering of all observable side-effects.   

Other standards might choose to use common test cases or other techniques to 
ensure interoperability. That isn't the path TC39 has taken.

Allen

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Brendan Eich]

John Lenz wrote:
I don't argue that it isn't a useless "let".  I do point out that in 
"sloppy" mode, that other declaration are allow in practices by 
browsers.  Chrome allows function, const, and var in the body of an if 
without block.


But those aren't useless.

They are quirky, but they do not bind in the consequent only, which is 
exactly what you and John said you wanted for if(x)let y=z.


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Rick Waldron]

On Thu, Jan 30, 2014 at 2:59 PM, John Lenz  wrote:

> Yes, that was my point, that is has to be allowed currently and this is a
> change.
>

But let and const aren't the same as var and function, they have different
syntax with different static and runtime semantics. New forms are allowed
to have new rules, especially ones that make writing code with the new
forms more intuitive and less error prone.

Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[John Lenz]

Yes, that was my point, that is has to be allowed currently and this is a
change.  Using what incorrectly? Existing "const" and "function"
implementations?  Or if "scoped" declarations?


On Thu, Jan 30, 2014 at 11:35 AM, Oliver Hunt  wrote:

>
> On Jan 30, 2014, at 11:27 AM, John Lenz  wrote:
>
> I don't argue that it isn't a useless "let".  I do point out that in
> "sloppy" mode, that other declaration are allow in practices by browsers.
>  Chrome allows function, const, and var in the body of an if without block.
>
>
> That's because they _have_ to be allowed as these constructs are used on
> millions (billions?) of web pages.  Disallowing that behaviour would break
> the web and we can't do that.
>
> Introducing new constructs that expose the same coding problems is not
> worth it - maybe we would want to change something in the future but we
> would already have been burned by existing content using this code
> incorrectly.
>
> --Oliver
>
>
> It does seems like an unnecessary restriction, and with it I'll need to
> make sure that Closure Compiler doesn't introduce these when stripping
> blocks, not a big deal just one more thing to deal with.
>
> I was just hoping that the restriction was enabling something and not just
> noise.
>
>
> On Thu, Jan 30, 2014 at 11:00 AM, Brendan Eich wrote:
>
>> John Barton wrote:
>>
>>>  Not silly. Can you suggest any on-line that most JS developers can
>>> understand discussing how these two forms differ?
>>>
>>> Here are some that describe them as equivalent:
>>>
>>> http://en.wikipedia.org/wiki/JavaScript_syntax#If_..._else
>>> http://msdn.microsoft.com/en-us/library/kw1tezhk(v=vs.94).aspx <
>>> http://msdn.microsoft.com/en-us/library/kw1tezhk%28v=vs.94%29.aspx>
>>>
>>> http://programmers.stackexchange.com/questions/
>>> 16528/single-statement-if-block-braces-or-no
>>> http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/
>>> index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Flanguage%2Fref%2Fclrc08csor.htm
>>> http://msdn.microsoft.com/en-us/library/ms173143.aspx
>>>
>>> and so on across multiple languages.  Whether or not you think these
>>> forms should be different, programmers don't expect them to differ.
>>>
>>
>> This is all beside the point, since the unbraced let as consequent of if
>> cannot make a useful binding (if you use comma-separated multiple
>> declarators, you still can't use any of the values that initialize the
>> bindings except in later useless-outside-the-single-declaration
>> consequent).
>>
>> /be
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Specification styles

[Forrest L Norvell]

On Thu, Jan 30, 2014 at 11:07 AM, Boris Zbarsky  wrote:

> On 1/30/14 10:20 AM, Forrest L Norvell wrote:
>
>> So far, this has been a very straightforward spec to implement.
>>
>
> Forrest,
>
> I think I may have been a bit unclear, my apologies.
>
> I think we all agree that ES-style specifications are in fact more
> straightforward to transcribe into an ES implementation.
>
> What is harder, in my experience, is understanding whether the
> specification actually says what it means to say and determining whether
> there are bugs in the specification.  This arises to some extent from the
> core functionality being partially obscured by a fair amount of boilerplate.
>

I agree with this entirely, with the caveat that "partially obscured" and
even "boilerplate" are in this case subjective factors. Once you split
Domenic's streams documentation into two pieces -- a narrative, informal
piece explaining the design and its motivation, and the specification
proper, which is still informal but more organized -- the specification
itself seems neither particularly verbose nor overdetermined. Again, this
is my subjective interpretation, but I've spent a fair amount of time
dealing with specifications (and, just to be clear, mostly not in the
JavaScript world).

Neither WebIDL nor the style of ES-262 are formal specification languages,
nor do they specify any kind of rigorous operational semantics. This isn't
a problem, as that's not their purpose. Their purpose, as I understand it,
is to facilitate the specification of behavior in such a way that a
consensus can be formed as to whether a given implementation is congruent
with a given design (and, more nebulously, the designers' intent).

Now I agree this is somewhat subjective.  Some people prefer to have all
> the complications explicitly written out, both in specifications and in
> code, while others prefer reusable tested black boxes that have certain
> defined behavior.  The former approach is much more verbose and can thus
> hinder understanding of the big picture.  The latter approach involves
> in-depth understanding of the black boxes to understand the details.  In
> practice, both the WebIDL and ES styles use some mixture of the two; what
> differs is the exact set of black boxes used.  The ES style black boxes are
> mostly more fine-grained than the WebIDL ones.
>

I agree with this description, and I wish there were a way to support both
approaches. Neither the declarative style of WebIDL nor the imperative
style of ES-262 are good at capturing both at the same time. As designers
and researchers we want to be able to point to the formal model and, if not
prove, at least attempt to make strong assertions about particular
behaviors or abstractions. As implementors, it's much easier to work from
imperative descriptions of behavior, and the process of resolving the
ambiguities during implementation will surface aspects of the design that
are not obvious when looking at a declarative model.

I spoke up in this thread because my primary purpose in taking on the
effort of implementing Domenic's spec was to figure out how I feel about it
(spoiler: so far I feel pretty good!). The easiest way for me to get up to
speed was to write some code (and tests) to see what gotchas popped up in
the real world (as streams have historically been probably the most fertile
source of edge cases in Node). For this purpose, Domenic's choice of
specification style has been ideal, for me.


> I wish I had a good way to combine the strengths of the two approaches
> more than existing specification formalisms do right now.  In some ways,
> something that allows looking at higher-level definition in terms of black
> boxes and then on-demand (e.g. a "expand this" or "expand all in this
> section" link) allows the reader to inline the black boxes to see all the
> details might be a possibility.  That would involve creating some tooling,
> obviously.


I think the underlying problem is that neither of these are truly formal,
at least not in the sense that I understand it. There's structure and some
essays at rigor, but nothing like, say, the recent implementation of ES5 in
Coq (which is awesome) or a Robert Harper-style operational semantics
rooted in axiomatic logic. On the other hand, I don't think formalism is
really what WebIDL is after.

As an implementor, I find this all a refreshing contrast to trying to
>> wrap my head around WebIDL
>>
>
> I honestly think that this (just like other people's experiences with
> trying to wrap their heads around ECMASpeak) is at least partially due to
> familiarity, or lack thereof, with the black boxes being used as
> specification primitives...  Partially it may be due to the wrong
> primitives being used, of course, which is a real problem in both styles I
> believe.


I'm fine with black boxes, and referring to standards documents when
decrypting specifications (I've had to work with ASN.1, I did a fair amount
of CORBA development with its IDL on

Re: restrictions on let declarations

[Rick Waldron]

On Thu, Jan 30, 2014 at 2:27 PM, John Lenz  wrote:

> I don't argue that it isn't a useless "let".  I do point out that in
> "sloppy" mode, that other declaration are allow in practices by browsers.
>  Chrome allows function, const, and var in the body of an if without block.
>
>

Did you mean to include const? Only IE11 has implemented const and let with
the proper semantics (with the exception of the for loop let binding
mistake, which will be corrected).

Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Oliver Hunt]

On Jan 30, 2014, at 11:27 AM, John Lenz  wrote:

> I don't argue that it isn't a useless "let".  I do point out that in "sloppy" 
> mode, that other declaration are allow in practices by browsers.  Chrome 
> allows function, const, and var in the body of an if without block.  
That’s because they _have_ to be allowed as these constructs are used on 
millions (billions?) of web pages.  Disallowing that behaviour would break the 
web and we can’t do that.

Introducing new constructs that expose the same coding problems is not worth it 
- maybe we would want to change something in the future but we would already 
have been burned by existing content using this code incorrectly.

—Oliver

> 
> It does seems like an unnecessary restriction, and with it I'll need to make 
> sure that Closure Compiler doesn't introduce these when stripping blocks, not 
> a big deal just one more thing to deal with.
> 
> I was just hoping that the restriction was enabling something and not just 
> noise.
> 
> 
> On Thu, Jan 30, 2014 at 11:00 AM, Brendan Eich  wrote:
> John Barton wrote:
>  Not silly. Can you suggest any on-line that most JS developers can 
> understand discussing how these two forms differ?
> 
> Here are some that describe them as equivalent:
> 
> http://en.wikipedia.org/wiki/JavaScript_syntax#If_..._else
> http://msdn.microsoft.com/en-us/library/kw1tezhk(v=vs.94).aspx 
> 
> 
> http://programmers.stackexchange.com/questions/16528/single-statement-if-block-braces-or-no
> http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Flanguage%2Fref%2Fclrc08csor.htm
> http://msdn.microsoft.com/en-us/library/ms173143.aspx
> 
> and so on across multiple languages.  Whether or not you think these forms 
> should be different, programmers don't expect them to differ.
> 
> This is all beside the point, since the unbraced let as consequent of if 
> cannot make a useful binding (if you use comma-separated multiple 
> declarators, you still can't use any of the values that initialize the 
> bindings except in later useless-outside-the-single-declaration consequent).
> 
> /be
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[John Lenz]

I don't argue that it isn't a useless "let".  I do point out that in
"sloppy" mode, that other declaration are allow in practices by browsers.
 Chrome allows function, const, and var in the body of an if without block.


It does seems like an unnecessary restriction, and with it I'll need to
make sure that Closure Compiler doesn't introduce these when stripping
blocks, not a big deal just one more thing to deal with.

I was just hoping that the restriction was enabling something and not just
noise.


On Thu, Jan 30, 2014 at 11:00 AM, Brendan Eich  wrote:

> John Barton wrote:
>
>>  Not silly. Can you suggest any on-line that most JS developers can
>> understand discussing how these two forms differ?
>>
>> Here are some that describe them as equivalent:
>>
>> http://en.wikipedia.org/wiki/JavaScript_syntax#If_..._else
>> http://msdn.microsoft.com/en-us/library/kw1tezhk(v=vs.94).aspx <
>> http://msdn.microsoft.com/en-us/library/kw1tezhk%28v=vs.94%29.aspx>
>>
>> http://programmers.stackexchange.com/questions/16528/single-statement-if-
>> block-braces-or-no
>> http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/
>> index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Flanguage%2Fref%2Fclrc08csor.htm
>> http://msdn.microsoft.com/en-us/library/ms173143.aspx
>>
>> and so on across multiple languages.  Whether or not you think these
>> forms should be different, programmers don't expect them to differ.
>>
>
> This is all beside the point, since the unbraced let as consequent of if
> cannot make a useful binding (if you use comma-separated multiple
> declarators, you still can't use any of the values that initialize the
> bindings except in later useless-outside-the-single-declaration
> consequent).
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Specification styles

[Boris Zbarsky]

On 1/30/14 10:20 AM, Forrest L Norvell wrote:

So far, this has been a very straightforward spec to implement.


Forrest,

I think I may have been a bit unclear, my apologies.

I think we all agree that ES-style specifications are in fact more 
straightforward to transcribe into an ES implementation.


What is harder, in my experience, is understanding whether the 
specification actually says what it means to say and determining whether 
there are bugs in the specification.  This arises to some extent from 
the core functionality being partially obscured by a fair amount of 
boilerplate.


Now I agree this is somewhat subjective.  Some people prefer to have all 
the complications explicitly written out, both in specifications and in 
code, while others prefer reusable tested black boxes that have certain 
defined behavior.  The former approach is much more verbose and can thus 
hinder understanding of the big picture.  The latter approach involves 
in-depth understanding of the black boxes to understand the details.  In 
practice, both the WebIDL and ES styles use some mixture of the two; 
what differs is the exact set of black boxes used.  The ES style black 
boxes are mostly more fine-grained than the WebIDL ones.


I wish I had a good way to combine the strengths of the two approaches 
more than existing specification formalisms do right now.  In some ways, 
something that allows looking at higher-level definition in terms of 
black boxes and then on-demand (e.g. a "expand this" or "expand all in 
this section" link) allows the reader to inline the black boxes to see 
all the details might be a possibility.  That would involve creating 
some tooling, obviously.



As an implementor, I find this all a refreshing contrast to trying to
wrap my head around WebIDL


I honestly think that this (just like other people's experiences with 
trying to wrap their heads around ECMASpeak) is at least partially due 
to familiarity, or lack thereof, with the black boxes being used as 
specification primitives...  Partially it may be due to the wrong 
primitives being used, of course, which is a real problem in both styles 
I believe.



I have nothing against formal specification methods per se, but, at least for 
things
that are implementable in pure JavaScript (as Domenic's proposal is)


It's not, actually, since it requires asynchronous callbacks which do 
not currently exist in pure JavaScript.  This is not quite a nitpick, 
since properly defining asynchronous callbacks is a fairly nontrivial 
matter with security implications, as I already pointed out in this thread.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Brendan Eich]

John Barton wrote:
 Not silly. Can you suggest any on-line that most JS developers can 
understand discussing how these two forms differ?


Here are some that describe them as equivalent:

http://en.wikipedia.org/wiki/JavaScript_syntax#If_..._else
http://msdn.microsoft.com/en-us/library/kw1tezhk(v=vs.94).aspx 


http://programmers.stackexchange.com/questions/16528/single-statement-if-block-braces-or-no
http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Flanguage%2Fref%2Fclrc08csor.htm
http://msdn.microsoft.com/en-us/library/ms173143.aspx

and so on across multiple languages.  Whether or not you think these 
forms should be different, programmers don't expect them to differ.


This is all beside the point, since the unbraced let as consequent of if 
cannot make a useful binding (if you use comma-separated multiple 
declarators, you still can't use any of the values that initialize the 
bindings except in later useless-outside-the-single-declaration consequent).


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Specification styles

[Rick Waldron]

On Thu, Jan 30, 2014 at 1:20 PM, Forrest L Norvell wrote:

> On Thu, Jan 30, 2014 at 9:40 AM, Boris Zbarsky  wrote:
>
>> On 1/30/14 8:25 AM, Domenic Denicola wrote:
>>
>>> since I find that style more precise and idiomatic
>>>
>>
>> It's not clear to me that the former is true (and in fact, making sure
>> that an ES-style spec is not fundamentally buggy in the "doesn't have the
>> desired behavior" sense is _much_ harder than doing it for a WebIDL spec,
>> in my experience).
>>
>> It's also _much_ harder to read and understand in my experience, and the
>> experience of many other people I've talked to.
>>
>
> I am going through the process of implementing Domenic's spec in ES5 for
> Node as a way of validating my understanding of the spec (in reality, the
> only Nodeisms in my implementation is my use of CommonJS modules), so maybe
> I can shed a little light on this.
>
> So far, this has been a very straightforward spec to implement. The spec
> language is imperative and concrete, so it is easy both to turn into
> JavaScript and to point to the correspondences between the implementation
> code and the relevant line items in the spec. So far, it has also been easy
> to use the code to illuminate inconsistencies or identify problems with the
> spec,
>

This is excellent, please be sure to file any spec bugs of any nature here:
http://bugs.ecmascript.org Feedback based on implementation experience is
critical to ES6 success :)

Rick


> and using the nomenclature of ES-262 makes very clear from context how to
> distinguish between the public interface of the API and its internal
> properties and methods.
>
> I've been surprised (and pleased) by how easy it has been to implement the
> spec thus far, and most of the issues I've raised with Domenic have been
> down to either minor misunderstandings on my part or judgment calls without
> objectively right or wrong answers. To me, this feels like the appropriate
> sort of issues to be coming out of working with a draft specification. Much
> of the credit for that goes to Domenic and his collaborators (and probably
> also to my familiarity with other JavaScript streams implementations), but
> I appreciate not having to spend a lot of time translating between WebIDL's
> abstract hybrid of C++, Java and JavaScript type models and the code I'm
> working on.
>
> As an implementor, I find this all a refreshing contrast to trying to wrap
> my head around WebIDL, which, in my blunt opinion, does a poor job of
> capturing any real operational model used on the web. I have nothing
> against formal specification methods per se, but, at least for things that
> are implementable in pure JavaScript (as Domenic's proposal is), I think
> ECMASpeak is preferable to WebIDL.
>
> F
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Specification styles

[Boris Zbarsky]

On 1/30/14 9:52 AM, Domenic Denicola wrote:

The lack of data properties


That's fair.


the fact that all argument coercion and type-checking happens up-front (verus 
just-in-time checking if a callable property exists and throwing if it does 
not, for example)


This is a philosophical disagreement, agreed.


the inability to change return types based on the input


WebIDL has this ability.  Either union types or object/any, depending on 
how much you want to change it.



the lack of care in handling abrupt completions


Uh...  WebIDL does in fact define the handling of those if you operate 
on WebIDL objects.


Obviously if you want to operate on "object" or "any" you have to do it 
yourself as now.



the lack of formalization around internal slots


This would look the same way in a WebIDL spec as in yours.


the inability to support the ES6 inheritance and constructor model


WebIDL is supposed to support this.  If it doesn't, please file bugs.


the constant appeal to vague prose phrases


Can you give an example?


the lack of support for iterators


See discussion about sequence<>?


I was referring in particular to the contents of the referenced thread, wherein 
we discussed ways in which TextDecoder/TextEncoder didn't align with the 
ECMAScript model, e.g. exception type usage.


Exception type usage is the issue you're having in your ES version as 
well, right?   Seems like that's something that just needs to be fixed 
as needed and doesn't depend so much on the specification formalism.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Specification styles

[Boris Zbarsky]

On 1/30/14 9:40 AM, Boris Zbarsky wrote:

It's not clear to me that the former is true (and in fact, making sure
that an ES-style spec is not fundamentally buggy in the "doesn't have
the desired behavior" sense is _much_ harder than doing it for a WebIDL
spec, in my experience).


Let me give a concrete example, actually.  Any web specification that 
involves asynchronously invoking callbacks from the event loop needs to 
define the incumbent and entry script settings object used when the 
callback is invoked.  If you use WebIDL callbacks, you get this for 
free, since those define the behavior for you.  I don't see the spec 
under discussion here defining anything like that; presumably it was 
just overlooked.  Preventing that sort of "overlooked" mistake is one of 
the major goals we had with WebIDL.


I'm not going to make the absurd claim that WebIDL is perfect.  I _will_ 
claim that we want to make it easier to write web specs that don't make 
basic mistakes like that.  And we want to make it easier to write web 
specs that use the ES capabilities you describe.  A desirable property 
is that even people who are not intimately familiar with the edge cases 
of ES and the web platform can write specifications describing some sort 
of basic functionality without tripping up in all sorts of ways.


The question is how we get there.  Constructive ideas are very much welcome.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exception type for "invalid operations"?

[Joshua Bell]

On Thu, Jan 30, 2014 at 8:25 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> I'm trying to design the [whatwg/streams spec][1] in the style of
> ECMAScript primitives, since I find that style more precise and idiomatic,
> and potentially in the future streams could become a language-level
> feature. Basically, I want to get ahead of the situation
> `TextEncoder`/`TextDecoder` find themselves in, as per [recent
> discussions][2].
>

Even following the link, I'm unsure if you're referring to the use of
DOMException with name "EncodingError", or something else in that thread.
(If something else, can you ping me directly?)


> One thing I'm stuck on is what exception type to use for invalid
> operations. For example, trying to read from or write to a closed stream.
> None of the ECMAScript standard types---`EvalError`, `RangeError`,
> `ReferenceError`, `SyntaxError`, `TypeError`, and `URIError`---seem to
> match. Do I just give up and use `TypeError`, which seems to be the
> catch-all in most situations?
>
>
Distinct DOMException types used to be defined with a numeric enum. That's
changed to distinct strings (hence the DOMException w/ name
"EncodingError", for example), and specs can add new types without
requiring additions to an enum tracked in the DOM spec.

Even with the ability to have feature-specific names error names, the
specific types don't communicate enough detail for developers to know
what's going on (e.g. "InvalidStateError" - uh, why?). In Chromium we're
trying to update the messages to indicate e.g. the method being called
("Failed to execute 'put' on 'IDBObjectStore': ...") in addition to the
specific details ("The transaction is not active."). But at least with the
flexibility for a feature to define a specific error, you can point to the
line in the spec that explains why it's being thrown. Which argues for
allowing feature-specific error types and against an explosion of types
that need defining in ES where strings would be sufficient.

So... can we simply use Error() with documented |name| (for code to reason
about) and detailed |message| (for developers to log/debug) ?



> Or would it make sense to open ourselves up beyond the existing set, and
> define some kind of `InvalidOperationError`? The idea being that, *if*
> streams were to become an ECMAScript primitive, so would
> `InvalidOperationError`. (*If*, not when! Please don't read too much
> presumptuousness into my API design predilections.)
>
> Other languages seem to have something similar: [.NET's
> `InvalidOperationException`][3] and [Java's `IllegalStateException`][4]
> come to mind. But of course they have much deeper exception hierarchies,
> which I don't think we want to emulate.
>
> [1]: https://github.com/whatwg/streams
> [2]:
> http://esdiscuss.org/topic/need-a-champion-stringview-strawman#content-17
> [3]:
> http://msdn.microsoft.com/en-us/library/system.invalidoperationexception%28v=vs.110%29.aspx
> [4]:
> http://docs.oracle.com/javase/7/docs/api/java/lang/IllegalStateException.html
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Specification styles

[Forrest L Norvell]

On Thu, Jan 30, 2014 at 9:40 AM, Boris Zbarsky  wrote:

> On 1/30/14 8:25 AM, Domenic Denicola wrote:
>
>> since I find that style more precise and idiomatic
>>
>
> It's not clear to me that the former is true (and in fact, making sure
> that an ES-style spec is not fundamentally buggy in the "doesn't have the
> desired behavior" sense is _much_ harder than doing it for a WebIDL spec,
> in my experience).
>
> It's also _much_ harder to read and understand in my experience, and the
> experience of many other people I've talked to.
>

I am going through the process of implementing Domenic's spec in ES5 for
Node as a way of validating my understanding of the spec (in reality, the
only Nodeisms in my implementation is my use of CommonJS modules), so maybe
I can shed a little light on this.

So far, this has been a very straightforward spec to implement. The spec
language is imperative and concrete, so it is easy both to turn into
JavaScript and to point to the correspondences between the implementation
code and the relevant line items in the spec. So far, it has also been easy
to use the code to illuminate inconsistencies or identify problems with the
spec, and using the nomenclature of ES-262 makes very clear from context
how to distinguish between the public interface of the API and its internal
properties and methods.

I've been surprised (and pleased) by how easy it has been to implement the
spec thus far, and most of the issues I've raised with Domenic have been
down to either minor misunderstandings on my part or judgment calls without
objectively right or wrong answers. To me, this feels like the appropriate
sort of issues to be coming out of working with a draft specification. Much
of the credit for that goes to Domenic and his collaborators (and probably
also to my familiarity with other JavaScript streams implementations), but
I appreciate not having to spend a lot of time translating between WebIDL's
abstract hybrid of C++, Java and JavaScript type models and the code I'm
working on.

As an implementor, I find this all a refreshing contrast to trying to wrap
my head around WebIDL, which, in my blunt opinion, does a poor job of
capturing any real operational model used on the web. I have nothing
against formal specification methods per se, but, at least for things that
are implementable in pure JavaScript (as Domenic's proposal is), I think
ECMASpeak is preferable to WebIDL.

F
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Specification styles

[Domenic Denicola]

From: es-discuss  on behalf of Boris Zbarsky 


> I would be interested in knowing what aspects of what you want to specify 
> cannot be expressed in WebIDL + normal DOM spec style.

Well, there's a lot of issues. The lack of data properties; the fact that all 
argument coercion and type-checking happens up-front (verus just-in-time 
checking if a callable property exists and throwing if it does not, for 
example); the inability to change return types based on the input (e.g. `return 
new this.constructor(...)` or `return firstArg`); the lack of care in handling 
abrupt completions; the lack of formalization around internal slots; the 
inability to support the ES6 inheritance and constructor model; the constant 
appeal to vague prose phrases; the lack of support for iterators; ...

Some of the type-related stuff could be handled within a WebIDL-using 
specification, by simply using `optional any` liberally and doing the work 
manually. Other issues are areas where WebIDL simply hasn't kept up with 
ECMAScript, and I imagine it will evolve to do so in the future. But the bottom 
line is, I want to be able to use the capabilities that JavaScript gives me, 
and second to writing JavaScript itself, ECMASpeak is a much better language 
for doing so than WebIDL + web-spec-style prose.

> What "situation" is that, exactly?

I was referring in particular to the contents of the referenced thread, wherein 
we discussed ways in which TextDecoder/TextEncoder didn't align with the 
ECMAScript model, e.g. exception type usage.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Specification styles

[Boris Zbarsky]

On 1/30/14 8:25 AM, Domenic Denicola wrote:

since I find that style more precise and idiomatic


It's not clear to me that the former is true (and in fact, making sure 
that an ES-style spec is not fundamentally buggy in the "doesn't have 
the desired behavior" sense is _much_ harder than doing it for a WebIDL 
spec, in my experience).


It's also _much_ harder to read and understand in my experience, and the 
experience of many other people I've talked to.


I would be interested in knowing what aspects of what you want to 
specify cannot be expressed in WebIDL + normal DOM spec style.



and potentially in the future streams could become a language-level feature.


Quite honestly, I would appreciate it if language-level features in ES 
were not defined with as much error-prone and hard-to-read boilerplate 
as they are now.



Basically, I want to get ahead of the situation `TextEncoder`/`TextDecoder` 
find themselves in


What "situation" is that, exactly?

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Rick Waldron]

On Thu, Jan 30, 2014 at 12:24 PM, Brendan Eich  wrote:

> Rick Waldron wrote:
>
>>
>> It is -- special forms that have heads can bind in bodies. We see
>> this with formal parameters to functions, also with the defunct
>> let blocks and let expressions of ES4. ML has similar forms.
>>
>> We made this block scoping, and how! Turns out Dart did the same.
>> Each iteration gets a fresh binding. If there's a closure in the
>> first part of the for(;;) head that captures the loop variable, it
>> gets a "0th iteration" binding.
>>
>>
>> Also, there was very positive interest in Waldemar's proposed if-scoped
>> let, here: https://mail.mozilla.org/pipermail/es-discuss/2013-
>> December/035077.html
>>
>
> Nick Krempel  proposed that upthread, just for the record.
>

Yes, my mistake--I had looked in December archives and found what I thought
was the OP. This is the correct OP from November:

https://mail.mozilla.org/pipermail/es-discuss/2013-November/035060.html


Rick


>
> Yeah, it's good. It comes from C++ but goes back to Algol, IIRC. Another
> precedent for block-scoped bindings that are declared in heads.
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[John Barton]

On Thu, Jan 30, 2014 at 8:59 AM, Brendan Eich  wrote:

> John Lenz wrote:
>
>> In my model
>>
>> if (y) let x = 42
>>
>> is equivalent to
>>
>> if (y) {
>>   let x = 42
>> }
>>
>> and it is clear "x" in "alert(x)" is 0;
>>
>
> It is as clear as those invisible braces in your model's input :-P.
>
> Come on, this is silly.


Not silly. Can you suggest any on-line that most JS developers can
understand discussing how these two forms differ?

Here are some that describe them as equivalent:

http://en.wikipedia.org/wiki/JavaScript_syntax#If_..._else
http://msdn.microsoft.com/en-us/library/kw1tezhk(v=vs.94).aspx
http://programmers.stackexchange.com/questions/16528/single-statement-if-block-braces-or-no
http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Flanguage%2Fref%2Fclrc08csor.htm
http://msdn.microsoft.com/en-us/library/ms173143.aspx

and so on across multiple languages.  Whether or not you think these forms
should be different, programmers don't expect them to differ.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Brendan Eich]

Rick Waldron wrote:


It is -- special forms that have heads can bind in bodies. We see
this with formal parameters to functions, also with the defunct
let blocks and let expressions of ES4. ML has similar forms.

We made this block scoping, and how! Turns out Dart did the same.
Each iteration gets a fresh binding. If there's a closure in the
first part of the for(;;) head that captures the loop variable, it
gets a "0th iteration" binding.


Also, there was very positive interest in Waldemar's proposed 
if-scoped let, here: 
https://mail.mozilla.org/pipermail/es-discuss/2013-December/035077.html


Nick Krempel  proposed that upthread, just for the record.

Yeah, it's good. It comes from C++ but goes back to Algol, IIRC. Another 
precedent for block-scoped bindings that are declared in heads.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Rick Waldron]

On Thu, Jan 30, 2014 at 12:10 PM, Brendan Eich  wrote:

> John Lenz wrote:
>
>> How did "let x" in for-loops land:
>>
>> for (let x = 1; x < 10 ; i++) {
>>   // is "x" a fresh binding for every iteration?
>> }
>>
>> This wouldn't be "block" scoping either.
>>
>
> It is -- special forms that have heads can bind in bodies. We see this
> with formal parameters to functions, also with the defunct let blocks and
> let expressions of ES4. ML has similar forms.
>
> We made this block scoping, and how! Turns out Dart did the same. Each
> iteration gets a fresh binding. If there's a closure in the first part of
> the for(;;) head that captures the loop variable, it gets a "0th iteration"
> binding.


Also, there was very positive interest in Waldemar's proposed if-scoped
let, here:
https://mail.mozilla.org/pipermail/es-discuss/2013-December/035077.html


Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Brendan Eich]

John Lenz wrote:

How did "let x" in for-loops land:

for (let x = 1; x < 10 ; i++) {
  // is "x" a fresh binding for every iteration?
}

This wouldn't be "block" scoping either.


It is -- special forms that have heads can bind in bodies. We see this 
with formal parameters to functions, also with the defunct let blocks 
and let expressions of ES4. ML has similar forms.


We made this block scoping, and how! Turns out Dart did the same. Each 
iteration gets a fresh binding. If there's a closure in the first part 
of the for(;;) head that captures the loop variable, it gets a "0th 
iteration" binding.


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exception type for "invalid operations"?

[Allen Wirfs-Brock]

On Jan 30, 2014, at 8:49 AM, Domenic Denicola wrote:

> From: Allen Wirfs-Brock 
> 
>> If you invert things you can think of "invalid operation" as trying to apply 
>> a valid operation upon the "wrong kind of object" so TypeError is a 
>> plausible.
> 
> This seems like a stretch :P. Are there existing instances in the ES spec of 
> this kind of use? I guess maybe trying to write to a non-writable property in 
> strict mode and the like.

Sure, all over the place.  For example, trying to apply a built-in constructor 
to an object that doesn't have the expected set of internal slots.

> 
>> In practice, where would throwing OperationError instead of TypeError 
>> actually make any difference.  How would you handle one differently from the 
>> other?
> 
> In practice it makes almost no difference, just like all other ECMAScript 
> error type discrimination. It just seems that when a user sees `TypeError` in 
> a stack trace, they expect to find some kind of argument validation problem.
> 
> (Maybe once we get pattern-matching `catch` clauses it would matter more. 
> E.g. people could purposefully try to catch `OperationError`s from such 
> operations, and handle them differently, leaving `TypeError`s etc. to bubble 
> outward and hit a top-level exception handler as "truly unexpected." But 
> that's a ways off.)
> 
> ---
> 
> Sounds like `TypeError` is probably the way to go, even if it feels a bit off.

We work with the tools that are available...

> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Brendan Eich]

John Lenz wrote:

In my model

if (y) let x = 42

is equivalent to

if (y) {
  let x = 42
}

and it is clear "x" in "alert(x)" is 0;


It is as clear as those invisible braces in your model's input :-P.

Come on, this is silly. "var" has quirks, but we are not propagating 
them to other forms, making implicit blocks where no braces exist, etc.


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Rick Waldron]

On Thu, Jan 30, 2014 at 11:39 AM, John Lenz  wrote:

> How did "let x" in for-loops land:
>
> for (let x = 1; x < 10 ; i++) {
>   // is "x" a fresh binding for every iteration?
>

Yes.


> }
>
> This wouldn't be "block" scoping either.
>

See:
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-11/nov-20.md#consensusresolution-6


Rick



>
> On Thu, Jan 30, 2014 at 8:13 AM, Brendan Eich  wrote:
>
>> John Barton wrote:
>>
>>
>>> On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich >> bren...@mozilla.com>> wrote:
>>>
>>> John Lenz wrote:
>>>
>>> Generally, I've always thought of:
>>>
>>> "if (x) ..." as equivalent to "if (x) { ... }"
>>>
>>>
>>> let and const (and class) are block-scoped. {...} in your "if (x)
>>> {...}" is a block. An unbraced consequent is not a block, and you
>>> can't have a "conditional let binding".
>>>
>>> The restriction avoids nonsense such as
>>>
>>> let x = 0; { if (y) let x = 42; alert(x); }
>>>
>>> What pray tell is going on here, in your model?
>>>
>>>
>>> I'm with John: the alert should say 0 and I can't see why that is not
>>> obvious.
>>>
>>
>> Interesting!
>>
>> You don't want the alert to show undefined, so the extent of the inner
>> binding in your model is the unbraced consequent of the  "if".
>>
>> That is not "block scope" in any plain sense.
>>
>> /be
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Exception type for "invalid operations"?

[Domenic Denicola]

From: Allen Wirfs-Brock 

> If you invert things you can think of "invalid operation" as trying to apply 
> a valid operation upon the "wrong kind of object" so TypeError is a plausible.

This seems like a stretch :P. Are there existing instances in the ES spec of 
this kind of use? I guess maybe trying to write to a non-writable property in 
strict mode and the like.

> In practice, where would throwing OperationError instead of TypeError 
> actually make any difference.  How would you handle one differently from the 
> other?

In practice it makes almost no difference, just like all other ECMAScript error 
type discrimination. It just seems that when a user sees `TypeError` in a stack 
trace, they expect to find some kind of argument validation problem.

(Maybe once we get pattern-matching `catch` clauses it would matter more. E.g. 
people could purposefully try to catch `OperationError`s from such operations, 
and handle them differently, leaving `TypeError`s etc. to bubble outward and 
hit a top-level exception handler as "truly unexpected." But that's a ways off.)

---

Sounds like `TypeError` is probably the way to go, even if it feels a bit off.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exception type for "invalid operations"?

[Allen Wirfs-Brock]

On Jan 30, 2014, at 8:25 AM, Domenic Denicola wrote:

> I'm trying to design the [whatwg/streams spec][1] in the style of ECMAScript 
> primitives, since I find that style more precise and idiomatic, and 
> potentially in the future streams could become a language-level feature. 
> Basically, I want to get ahead of the situation `TextEncoder`/`TextDecoder` 
> find themselves in, as per [recent discussions][2].
> 
> One thing I'm stuck on is what exception type to use for invalid operations. 
> For example, trying to read from or write to a closed stream. None of the 
> ECMAScript standard types---`EvalError`, `RangeError`, `ReferenceError`, 
> `SyntaxError`, `TypeError`, and `URIError`---seem to match. Do I just give up 
> and use `TypeError`, which seems to be the catch-all in most situations?
> 
> Or would it make sense to open ourselves up beyond the existing set, and 
> define some kind of `InvalidOperationError`? The idea being that, *if* 
> streams were to become an ECMAScript primitive, so would 
> `InvalidOperationError`. (*If*, not when! Please don't read too much 
> presumptuousness into my API design predilections.)
> 
> Other languages seem to have something similar: [.NET's 
> `InvalidOperationException`][3] and [Java's `IllegalStateException`][4] come 
> to mind. But of course they have much deeper exception hierarchies, which I 
> don't think we want to emulate.

So far we've avoiding adding any new built-in exceptions.  Perhaps, we could 
add another but I think it would take some time to build consensus around that.

In practice new library functions in ES6 restrict themselves to using either 
TypeError or RangeError with TypeError being by far the most common.  Range 
error is used when a parameter or other value is (likely) of the correct 
primitive type (number, string, etc.) but the specific value is not 
contextually valid.  Pretty much everything else is treated as a TypeError.  
Note that in this context we interpret "Type"  more like "kind" than 
corresponding the ECMAScript types. You can think about this usage of TypeError 
as "the wrong kind of thing was directly or indirectly passed to the function". 
 If you invert things you can think of "invalid operation" as trying to apply a 
valid operation upon the "wrong kind of object" so TypeError is a plausible.

In practice, where would throwing OperationError instead of TypeError actually 
make any difference.  How would you handle one differently from the other?

Allen
> 
> [1]: https://github.com/whatwg/streams
> [2]: http://esdiscuss.org/topic/need-a-champion-stringview-strawman#content-17
> [3]: 
> http://msdn.microsoft.com/en-us/library/system.invalidoperationexception%28v=vs.110%29.aspx
> [4]: 
> http://docs.oracle.com/javase/7/docs/api/java/lang/IllegalStateException.html
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Jason Orendorff]

On Thu, Jan 30, 2014 at 8:26 AM, John Lenz  wrote:
> In my model
>
> if (y) let x = 42
>
> is equivalent to
>
> if (y) {
>   let x = 42
> }

Yes, everyone here understands your model. This is a question of
taste. There are competing senses of what is intuitive at play.

-j
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[John Lenz]

How did "let x" in for-loops land:

for (let x = 1; x < 10 ; i++) {
  // is "x" a fresh binding for every iteration?
}

This wouldn't be "block" scoping either.


On Thu, Jan 30, 2014 at 8:13 AM, Brendan Eich  wrote:

> John Barton wrote:
>
>
>> On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich > bren...@mozilla.com>> wrote:
>>
>> John Lenz wrote:
>>
>> Generally, I've always thought of:
>>
>> "if (x) ..." as equivalent to "if (x) { ... }"
>>
>>
>> let and const (and class) are block-scoped. {...} in your "if (x)
>> {...}" is a block. An unbraced consequent is not a block, and you
>> can't have a "conditional let binding".
>>
>> The restriction avoids nonsense such as
>>
>> let x = 0; { if (y) let x = 42; alert(x); }
>>
>> What pray tell is going on here, in your model?
>>
>>
>> I'm with John: the alert should say 0 and I can't see why that is not
>> obvious.
>>
>
> Interesting!
>
> You don't want the alert to show undefined, so the extent of the inner
> binding in your model is the unbraced consequent of the  "if".
>
> That is not "block scope" in any plain sense.
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[John Barton]

> On Thu, Jan 30, 2014 at 10:59 AM, John Barton
>
> That craziness is the whole point of block scoping let.  ...
>
> Give that this is the behaviour of every other block scoped language i
> don’t see why this is confusing.
>

It's not `let` vs `var` that concerns us, it's that the statement following
an if condition is not equivalent to a block.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[John Lenz]

In my model

if (y) let x = 42

is equivalent to

if (y) {
  let x = 42
}

and it is clear "x" in "alert(x)" is 0;


On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich  wrote:

> John Lenz wrote:
>
>> Generally, I've always thought of:
>>
>> "if (x) ..." as equivalent to "if (x) { ... }"
>>
>
> let and const (and class) are block-scoped. {...} in your "if (x) {...}"
> is a block. An unbraced consequent is not a block, and you can't have a
> "conditional let binding".
>
> The restriction avoids nonsense such as
>
> let x = 0; { if (y) let x = 42; alert(x); }
>
> What pray tell is going on here, in your model?
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Exception type for "invalid operations"?

[Domenic Denicola]

I'm trying to design the [whatwg/streams spec][1] in the style of ECMAScript 
primitives, since I find that style more precise and idiomatic, and potentially 
in the future streams could become a language-level feature. Basically, I want 
to get ahead of the situation `TextEncoder`/`TextDecoder` find themselves in, 
as per [recent discussions][2].

One thing I'm stuck on is what exception type to use for invalid operations. 
For example, trying to read from or write to a closed stream. None of the 
ECMAScript standard types---`EvalError`, `RangeError`, `ReferenceError`, 
`SyntaxError`, `TypeError`, and `URIError`---seem to match. Do I just give up 
and use `TypeError`, which seems to be the catch-all in most situations?

Or would it make sense to open ourselves up beyond the existing set, and define 
some kind of `InvalidOperationError`? The idea being that, *if* streams were to 
become an ECMAScript primitive, so would `InvalidOperationError`. (*If*, not 
when! Please don't read too much presumptuousness into my API design 
predilections.)

Other languages seem to have something similar: [.NET's 
`InvalidOperationException`][3] and [Java's `IllegalStateException`][4] come to 
mind. But of course they have much deeper exception hierarchies, which I don't 
think we want to emulate.

[1]: https://github.com/whatwg/streams
[2]: http://esdiscuss.org/topic/need-a-champion-stringview-strawman#content-17
[3]: 
http://msdn.microsoft.com/en-us/library/system.invalidoperationexception%28v=vs.110%29.aspx
[4]: 
http://docs.oracle.com/javase/7/docs/api/java/lang/IllegalStateException.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Oliver Hunt]

On Jan 30, 2014, at 8:07 AM, Dean Landolt  wrote:

> 
> 
> 
> On Thu, Jan 30, 2014 at 10:59 AM, John Barton  wrote:
> 
> 
> 
> On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich  wrote:
> John Lenz wrote:
> Generally, I've always thought of:
> 
> "if (x) ..." as equivalent to "if (x) { ... }"
> 
> let and const (and class) are block-scoped. {...} in your "if (x) {...}" is a 
> block. An unbraced consequent is not a block, and you can't have a 
> "conditional let binding".
> 
> The restriction avoids nonsense such as
> 
> let x = 0; { if (y) let x = 42; alert(x); }
> 
> What pray tell is going on here, in your model?
> 
> I'm with John: the alert should say 0 and I can't see why that is not obvious.
> 
> 
> It's not obvious at all -- what happens when you drop the initial `let x = 
> 0;` and you just have `{ if (y) let x = 42; alert(x); }` -- now what happens? 
> Is x declared or not?
> 
> To my mind `if (y) let x = 42;` reads like it's own 1-line noop block -- at 
> least, that's what I'd expect of the scope. So while it could be allowed in 
> that sense, it'd only serve as a footgun when y is true.

This is exactly foot gun the language restriction is intended to avoid.

Most modern [Obj-]C[++] will warn on this (well, s/let/int/)

You might be getting confused because of the bizarro var hoisting semantics of 
var

if (y) let x = “nope"; alert(x)

Results in an unusable binding of x, and so this would throw (the foot gun 
occurs if you’re shadowing x, that’s another shadow that i think C compilers 
will warn on), e.g..
y = true; let x = “whoops”; if (y) let x = “nope"; alert(x) // “whoops"

The var case

y = true; var x = “whoops”; if (y) var x = “nope"; alert(x); // “nope"

is actually interpreted as

var x; y= true; x = “whoops”; if (y) x = “nope”; alert(x); // “nope"

That craziness is the whole point of block scoping let.  More interestingly

if (window.SomeCrazyDomFeature) var foo = true;

is a common web idiom as it brings foo into scope for everything, so makes 
later "if (foo) “ statements safe.  Anyone trying to do this with a |let| would 
get incorrect (from their PoV) behaviour.  Again that’s why we error out.

Give that this is the behaviour of every other block scoped language i don’t 
see why this is confusing.

—Oliver

> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Brendan Eich]

John Barton wrote:


On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich > wrote:


John Lenz wrote:

Generally, I've always thought of:

"if (x) ..." as equivalent to "if (x) { ... }"


let and const (and class) are block-scoped. {...} in your "if (x)
{...}" is a block. An unbraced consequent is not a block, and you
can't have a "conditional let binding".

The restriction avoids nonsense such as

let x = 0; { if (y) let x = 42; alert(x); }

What pray tell is going on here, in your model?


I'm with John: the alert should say 0 and I can't see why that is not 
obvious.


Interesting!

You don't want the alert to show undefined, so the extent of the inner 
binding in your model is the unbraced consequent of the  "if".


That is not "block scope" in any plain sense.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Dean Landolt]

On Thu, Jan 30, 2014 at 10:59 AM, John Barton wrote:

>
>
>
> On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich  wrote:
>
>> John Lenz wrote:
>>
>>> Generally, I've always thought of:
>>>
>>> "if (x) ..." as equivalent to "if (x) { ... }"
>>>
>>
>> let and const (and class) are block-scoped. {...} in your "if (x) {...}"
>> is a block. An unbraced consequent is not a block, and you can't have a
>> "conditional let binding".
>>
>> The restriction avoids nonsense such as
>>
>> let x = 0; { if (y) let x = 42; alert(x); }
>>
>> What pray tell is going on here, in your model?
>
>
> I'm with John: the alert should say 0 and I can't see why that is not
> obvious.
>


It's not obvious at all -- what happens when you drop the initial `let x =
0;` and you just have `{ if (y) let x = 42; alert(x); }` -- now what
happens? Is x declared or not?

To my mind `if (y) let x = 42;` reads like it's own 1-line noop block -- at
least, that's what I'd expect of the scope. So while it could be allowed in
that sense, it'd only serve as a footgun when y is true.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Allen Wirfs-Brock]

On Jan 30, 2014, at 7:43 AM, John Lenz wrote:

> It seems unfortunate that "let" and "const" have different usage rules from 
> "var".  It seem strange  that "var" is considered a statement and not 
> declaration as per:
> 
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-statements-and-declarations
> 
> Generally, I've always thought of:
> 
> "if (x) ..." as equivalent to "if (x) { ... }"
> 
> Does this restriction on let/const enable anything?
> 

The anomaly is that 'var' was considered a statement in ES1. But note that the 
only other declaration in the language ('function') at that time was not a 
statement. See http://www.wirfs-brock.com/allen/draft-ES5.1/#sec-14 

Declarations have global static impact within their containing scope (function 
or block). It generally doesn't make any sense to use them in a conditional 
context without an explicitly surrounding block that constrains their scope.

So all new declarative forms in ES6 are treated similarly to function.  They 
are declarations but not statements.  Var must remain a statement for legacy 
compatability.

Allen




___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[John Barton]

On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich  wrote:

> John Lenz wrote:
>
>> Generally, I've always thought of:
>>
>> "if (x) ..." as equivalent to "if (x) { ... }"
>>
>
> let and const (and class) are block-scoped. {...} in your "if (x) {...}"
> is a block. An unbraced consequent is not a block, and you can't have a
> "conditional let binding".
>
> The restriction avoids nonsense such as
>
> let x = 0; { if (y) let x = 42; alert(x); }
>
> What pray tell is going on here, in your model?


I'm with John: the alert should say 0 and I can't see why that is not
obvious.


>
>
> /be
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Brendan Eich]

John Lenz wrote:

Generally, I've always thought of:

"if (x) ..." as equivalent to "if (x) { ... }"


let and const (and class) are block-scoped. {...} in your "if (x) {...}" 
is a block. An unbraced consequent is not a block, and you can't have a 
"conditional let binding".


The restriction avoids nonsense such as

let x = 0; { if (y) let x = 42; alert(x); }

What pray tell is going on here, in your model?

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on module import export names

[Calvin Metcalf]

forgot to hit replay all

On Thu, Jan 30, 2014 at 10:25 AM, Kevin Smith  wrote:

> [Did you mean to reply all?]
>
> ```js
>> var projs = [
>> import "./projections/merc",
>> import "./projections/longlat"
>> ];
>> ```
>>
>
> That idea was last discussed on the list two or three years ago.  The
> problem is that you are placing strange and novel placement restrictions on
> expression forms, which is sure to cause more confusion than it's worth.
>  What about cases like:
>
> var x = f || import "blah";
>
> Should that be different than this?
>
> var x = import "blah" || f;
>
> The current module design is straightforward and clean.  Have you tried
> doing any coding with them?
>

yes I've coded with them via ember app kit's grunt es6 module transpiler
thingy, the syntax was significantly more complex and verbose than commonjs
and we ended up switching over to browserify/commonjs.

var x = f || import "blah";
> Should that be different than this?
> var x = import "blah" || f;

if we have static linking (which imho is great, not complaining about it,
seriously good work guys) then those should act in the same way, what I'm
really suggesting is probably more like sugar for,

```js
var x = f || import "blah";
//becomes ->
import "blah" as _temp;
var x = f || _temp;
```

similar to export default which didn't change anything behind the scenes.


On Thu, Jan 30, 2014 at 9:28 AM, Kevin Smith  wrote:

> var projs = [
>>   require('./projections/merc'),
>>
>>
>>   require('./projections/longlat')
>> ];
>>
>>
> With ES6 modules, you might do something like this:
>
> import merc from "./projections/merc";
> import longlat from "./projections/longlat";
>
> var projs = [merc, longlat];
>
> Or if you're importing the modules themselves:
>
> module merc from "./projectsions/merc";
> module longlat from "./projectsions/longlat";
>
> var projs = [merc, longlat];
>
>
>> is there a reason [import] can't be an expression which evaluates to
>> either an object with all the [exports] or the default export when it's
>> used as an AssignmentExpression (I think I'm using that one right).
>>
>>
> Yes.  ES6 modules are "statically linked", meaning that all of the
> non-local (imported) bindings are resolved *before the module begins
> executing*.  It's an important distinction.
>
> Because of this difference, you can expect usage patterns to turn out
> somewhat different from the "require" patterns we are used to seeing in
> node.
>
>


-- 
-Calvin W. Metcalf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[John Lenz]

It seems unfortunate that "let" and "const" have different usage rules from
"var".  It seem strange  that "var" is considered a statement and not
declaration as per:

http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-statements-and-declarations

Generally, I've always thought of:

"if (x) ..." as equivalent to "if (x) { ... }"

Does this restriction on let/const enable anything?





On Wed, Jan 29, 2014 at 10:31 PM, Erik Arvidsson
wrote:

> It falls out of the grammar.
>
> IfStatement can only contain Statement which does not include Declaration
> without going through a BlockStatement.
>
>
> On Wed, Jan 29, 2014 at 9:57 PM, John Lenz  wrote:
>
>>  I have some old notes that says that "let" can't be used in some
>> context where a var could like:
>>
>>   if (a) let x = 2;
>>
>> In my perusal of the spec I don't see that this is the case now.  Can
>> someone confirm that for me?
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> erik
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on module import export names

[Kevin Smith]

>
> var projs = [
>   require('./projections/merc'),
>
>   require('./projections/longlat')
> ];
>
>
With ES6 modules, you might do something like this:

import merc from "./projections/merc";
import longlat from "./projections/longlat";

var projs = [merc, longlat];

Or if you're importing the modules themselves:

module merc from "./projectsions/merc";
module longlat from "./projectsions/longlat";

var projs = [merc, longlat];


> is there a reason [import] can't be an expression which evaluates to
> either an object with all the [exports] or the default export when it's
> used as an AssignmentExpression (I think I'm using that one right).
>
>
Yes.  ES6 modules are "statically linked", meaning that all of the
non-local (imported) bindings are resolved *before the module begins
executing*.  It's an important distinction.

Because of this difference, you can expect usage patterns to turn out
somewhat different from the "require" patterns we are used to seeing in
node.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on module import export names

[Calvin Metcalf]

sorry guys, was getting confused on VariableStatement vs
AssignmentExpression, gist is updated with correct examples, I guess it
seems somewhat overly complicated having 4 different ways to export things
each with their own arbitrary restrictions which leads to weirdness, e.g.
if you want to export an array as `foo` you could do

```js
export let foo = [stuff];
```

but if foo was already defined you probably wouldn't want to do that, but
you wouldn't be able to do this (I believe).

```js
//bad
export { [stuff] as foo}
```

as you can only use identifierNames or identifierReferences here even
though they are going to be discarded, so

```js
let _foo = [stuff];
export { _foo as foo };
```

would be the only way


the other thing is on second thought more of an issue with imports not
being expressions,  yes this code might be an edge case

 ```js
let app = module.exports = require('express')();
```

but it's from in the wild code, slightly less ridicules example would be

```js

var projs = [
  require('./projections/merc'),
  require('./projections/longlat')
];

```

is there a reason import ModuleSpecifier can't be an expression which
evaluates to either an object with all the imports or the default export
when it's used as an AssignmentExpression (I think I'm using that one
right).


On Wed, Jan 29, 2014 at 9:55 PM, Kevin Smith  wrote:

>
>> ```js
>> let app = module.exports = require('express')();
>> ```
>>
>
> Not impossible.  Possibly:
>
> import express from "express";
> let app = express();
> export { app as default };
>
> I think you're attempting to optimize edge cases.
>
> Also, I agree with Domenic.  Read the grammar for the current spec and try
> not to post syntax errors that might lead others astray  : )
>
>


-- 
-Calvin W. Metcalf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss