Re: The generator.next() method

[Forbes Lindesay]

I'd rather be corrected when I'm right than ignored when I'm wrong, and at the 
moment I'm still pretty new to the specifics of ES6 APIs :)

On 23 Aug 2013, at 19:44, "Brendan Eich"  wrote:

> André Bargull wrote:
>> `g.next()` returns `{value: [1, 2, 3], done: false}` for me, so .value is 
>> needed here. Or do you mean something else?
> 
> Sorry (to Forbes), I was thinking of when for-of orchestrates.
> 
> /be
> 
>> 
>> Thanks,
>> André
>> 
>>> No .value anywhere, though.
>>> 
>>> /be
>>> 
>>> Forbes Lindesay wrote:
>>> >/  It already is dealt with via destructuring assignments:
>>> />/
>>> />/  ```js
>>> />/  function* gen() {
>>> />/ var {x, y, z} = yield [1, 2, 3]
>>> />/ return x&&   y || z
>>> />/  }
>>> />/  var g = gen()
>>> />/  var [a, b, c] = g.next().value
>>> />/  assert(a === 1)
>>> />/  assert(b === 2)
>>> />/  assert(c === 3)
>>> />/  var res = g.send({x: true, y: false, z: true}).value
>>> />/  assert(res === true)
>>> />/  ```/
>> ___
>> 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: Optional Strong Typing

[Brendan Eich]

Brendan Eich wrote:

The Chrome dev tools (Firefox devtools, etc.) can cope -- but the burning


question

is: will we have more type confusion bugs or fewer if we standardize 
warning annotations.


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

Re: Optional Strong Typing

[Brendan Eich]

On Aug 23, 2013, at 1:20 PM, J B  wrote:

> On Fri, Aug 23, 2013 at 2:50 PM, J B  wrote:
>> @Brendan "Those are warnings, but WarnScript was a bad name" --you mean the 
>> tools (IDEs, closure compiler, etc) throw warnings, but not the Chrome 
>> debugger, for instance, right?


The Chrome dev tools (Firefox devtools, etc.) can cope -- but the burning is: 
will we have more type confusion bugs or fewer if we standardize warning 
annotations.

Here it pays to recall the benefit of soundness. A type system (sound by 
definition) will stop code cold, at compile time. Anything like what you 
propose will possibly let bugs out into the wild.

Whether more or same/fewer that without, I do not know. But I suspect "more", 
because programmers will have a false sense of security from the "strong 
typing".

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

Re: Optional Strong Typing

[J B]

"That said, note that your sentiment has been graciously heard. What you
are asking for is well-represented by rigorous research going into
TypeScript, which is very closely aligned with work and proposals that came
out of these discussions. I believe it is fair to interpret Brendan’s last
sentiment, “This again puts unsound warning "types" outside of the
standards track for a while. But carry on with TypeScript etc. — TC39 is
tracking”, not as “no”, but as “not yet”."

Thanks Kris, That's all I wanted to know; I don't have anything remaining
to say on the subject.

Thank you.


On Fri, Aug 23, 2013 at 3:39 PM, Kris Kowal  wrote:

> On Fri, Aug 23, 2013 at 1:20 PM, J B  wrote:
>
>> https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html This
>> is depressing.
>>
>
> J B,
>
> You’re entitled to a dissenting opinion. However, this archives one of the
> best moments for the evolution of the language. It was a commitment to
> focus on deliberate, consistent, incremental change. We are realizing the
> rewards for the Harmony agenda today with property descriptors (which
> formalized and exposed an existing concept), new collections, and Proxies.
> The cesura on namespaces have provided an opportunity for much much more
> deliberately designed modules. Innovation has returned and the pace is
> good, neither hasty nor stagnant.
>
> That said, note that your sentiment has been graciously heard. What you
> are asking for is well-represented by rigorous research going into
> TypeScript, which is very closely aligned with work and proposals that came
> out of these discussions. I believe it is fair to interpret Brendan’s last
> sentiment, “This again puts unsound warning "types" outside of the
> standards track for a while. But carry on with TypeScript etc. — TC39 is
> tracking”, not as “no”, but as “not yet”.
>
> Kris Kowal
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

[Kris Kowal]

On Fri, Aug 23, 2013 at 1:20 PM, J B  wrote:

> https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html This
> is depressing.
>

J B,

You’re entitled to a dissenting opinion. However, this archives one of the
best moments for the evolution of the language. It was a commitment to
focus on deliberate, consistent, incremental change. We are realizing the
rewards for the Harmony agenda today with property descriptors (which
formalized and exposed an existing concept), new collections, and Proxies.
The cesura on namespaces have provided an opportunity for much much more
deliberately designed modules. Innovation has returned and the pace is
good, neither hasty nor stagnant.

That said, note that your sentiment has been graciously heard. What you are
asking for is well-represented by rigorous research going into TypeScript,
which is very closely aligned with work and proposals that came out of
these discussions. I believe it is fair to interpret Brendan’s last
sentiment, “This again puts unsound warning "types" outside of the
standards track for a while. But carry on with TypeScript etc. — TC39 is
tracking”, not as “no”, but as “not yet”.

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

Re: Optional Strong Typing

[Angel Java Lopez]

TypeScript are a move from Microsoft to become JavaScript more friendly to
VisualStudio developers. And to try typed scenarios.

I'm a VisualStudio-developer, and for years, I didn't need typed JavaScript
(as I didn't need type Python or Ruby). I feel that is the case with many
developers.

I guess the point is:

- Some developers prefer or feel more comfortable with typed system

But the point:

- Typed language allows large systems or something alike

is more debatable. I don't think so, and tons of JavaScript, Ruby, Python
programs, libraries, and complete system go against that point.

Having no typing, sometimes is easy to implement some features. In my
experience, I had more work and time in writing the same system in typed
language than in not-typed ones. And code complexity and refactor, can be
managed without pain.

I'm apologize bad English, but I hope I wrote an "clear" argument

Angel "Java" Lopez
@ajlopez


On Fri, Aug 23, 2013 at 5:20 PM, J B  wrote:

> https://brendaneich.com/2007/11/my-media-ajax-keynote/ I liked reading
> this...
>
> https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html This
> is depressing.
>
>
> On Fri, Aug 23, 2013 at 2:50 PM, J B  wrote:
>
>> @Brendan "Those are warnings, but WarnScript was a bad name" --you mean
>> the tools (IDEs, closure compiler, etc) throw warnings, but not the Chrome
>> debugger, for instance, right?
>>
>>
>> On Fri, Aug 23, 2013 at 2:37 PM, Brendan Eich wrote:
>>
>>> J B wrote:
>>>
 @Brendan - The typing wouldn't be used at all during run-time. So,
 unlike AS3, it wouldn't check if types were valid, and it wouldn't try an
 kind of implicit coercion.


>>> Ok, that's not "typing" (I mean not a type system).
>>>
>>> "Those are warnings, but WarnScript was a bad name" - me at JSConf.au
>>> last November.
>>>
>>> The unsoundness means you have something that needs strong tool support,
>>> not just an error or JS console in which to spew. TypeScript got this right.
>>>
>>> This again puts unsound warning "types" outside of the standards track
>>> for a while. But carry on with TypeScript etc. -- TC39 is tracking.
>>>
>>> /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: Optional Strong Typing

[J B]

https://brendaneich.com/2007/11/my-media-ajax-keynote/ I liked reading
this...

https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html This
is depressing.


On Fri, Aug 23, 2013 at 2:50 PM, J B  wrote:

> @Brendan "Those are warnings, but WarnScript was a bad name" --you mean
> the tools (IDEs, closure compiler, etc) throw warnings, but not the Chrome
> debugger, for instance, right?
>
>
> On Fri, Aug 23, 2013 at 2:37 PM, Brendan Eich  wrote:
>
>> J B wrote:
>>
>>> @Brendan - The typing wouldn't be used at all during run-time. So,
>>> unlike AS3, it wouldn't check if types were valid, and it wouldn't try an
>>> kind of implicit coercion.
>>>
>>>
>> Ok, that's not "typing" (I mean not a type system).
>>
>> "Those are warnings, but WarnScript was a bad name" - me at JSConf.au
>> last November.
>>
>> The unsoundness means you have something that needs strong tool support,
>> not just an error or JS console in which to spew. TypeScript got this right.
>>
>> This again puts unsound warning "types" outside of the standards track
>> for a while. But carry on with TypeScript etc. -- TC39 is tracking.
>>
>> /be
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

[J B]

@Brendan "Those are warnings, but WarnScript was a bad name" --you mean the
tools (IDEs, closure compiler, etc) throw warnings, but not the Chrome
debugger, for instance, right?


On Fri, Aug 23, 2013 at 2:37 PM, Brendan Eich  wrote:

> J B wrote:
>
>> @Brendan - The typing wouldn't be used at all during run-time. So, unlike
>> AS3, it wouldn't check if types were valid, and it wouldn't try an kind of
>> implicit coercion.
>>
>>
> Ok, that's not "typing" (I mean not a type system).
>
> "Those are warnings, but WarnScript was a bad name" - me at JSConf.au last
> November.
>
> The unsoundness means you have something that needs strong tool support,
> not just an error or JS console in which to spew. TypeScript got this right.
>
> This again puts unsound warning "types" outside of the standards track for
> a while. But carry on with TypeScript etc. -- TC39 is tracking.
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

[Brendan Eich]

J B wrote:
@Brendan - The typing wouldn't be used at all during run-time. So, 
unlike AS3, it wouldn't check if types were valid, and it wouldn't try 
an kind of implicit coercion.




Ok, that's not "typing" (I mean not a type system).

"Those are warnings, but WarnScript was a bad name" - me at JSConf.au 
last November.


The unsoundness means you have something that needs strong tool support, 
not just an error or JS console in which to spew. TypeScript got this right.


This again puts unsound warning "types" outside of the standards track 
for a while. But carry on with TypeScript etc. -- TC39 is tracking.


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

Re: Optional Strong Typing

[J B]

@Brendan - The typing wouldn't be used at all during run-time. So, unlike
AS3, it wouldn't check if types were valid, and it wouldn't try an kind of
implicit coercion.

@Jeremy - "The implication being that implementors start shipping static
compilers where this parsing/stripping takes place (i.e., as a precursory
step to being interpreted)?"  --You would probably know better than me. I'm
not too sure how the various implementations work, but the idea is to
simply ignore all the special typing code.

"The problem with this statement is that "key features" is open for
interpretation." --You're right in that it's open for interpretation, but I
think we can both agree that there are things that most devs would agree
are key features, and most would not, and there are some where it would be
a coin flip; but, as there is a JS extension called "TypeScript" (the key
feature is in the very name), and there is a section in that list I linked
to dedicated to this key feature, I think it's a bit more important than...
generics... for instance.

"The fact is that devs already are building "large scale" projects using
plain ol' JS" --I prefer to have the option of static typing, because there
are definite benefits that are hard to ignore, especially when it's code
refactoring time. I'm not saying building large scale projects with untyped
code can't be done, or even that loose typing is a bad thing (it's not),
but static typing can often make things a whole hell of a lot easier for
larger projects with large amounts of developers.

"I'd be interested in seeing data that the de facto standard is to use
compile-to-JavaScript languages.  My own experience has been quite the
opposite." --For large scale/professional development? I think it's the
very reason why TypeScript exists, and why Visual Studio supports it. Also,
a description given for TypeScript is [1]: "TypeScript is a language for
application-scale JavaScript development."


[1] http://www.microsoft.com/en-us/download/details.aspx?id=34790




On Fri, Aug 23, 2013 at 2:03 PM, Jeremy Martin  wrote:

> > I mean the parser will strip all of the typing info out before it's
> compiled/interpreted.
>
> The implication being that implementors start shipping static compilers
> where this parsing/stripping takes place (i.e., as a precursory step to
> being interpreted)?
>
> > but it's been made worse by ECMAScript's lack of key features
>
> The problem with this statement is that "key features" is open for
> interpretation.
>
> > if JS was a little more large scale development friendly (like
> TypeScript), devs could just use plain ol' JS
>
> The fact is that devs already are building "large scale" projects using
> plain ol' JS (I myself have worked on JS projects with 100k+ loc without
> feeling the need for static typing).  The same goes for Python, PHP, Ruby,
> etc. - this isn't an attack against static typing, but it's hardly
> necessary for a language to be "friendly" for "large scale development".
>
> > Sure, some would still use language extensions like TypeScript, but at
> least it wouldn't be the defacto standard because of core inadequacies in
> base language.
>
> I'd be interested in seeing data that the de facto standard is to use
> compile-to-JavaScript languages.  My own experience has been quite the
> opposite.
>
>
> On Fri, Aug 23, 2013 at 2:24 PM, J B  wrote:
>
>> @Jeremy: I mean the parser will strip all of the typing info out before
>> it's compiled/interpreted.
>>
>> @Axel: "Evolving a language standard used as broadly as ECMAScript takes
>> time" -- I agree.
>> "You can see TypeScript as exploring future options for ECMAScript." --
>> Wasn't AS3 already doing this?
>> "Guards" -- Looks good...
>> "TypeScript tracks JavaScript very closely, I would not consider it a
>> different language." It's compiled, and it's one of many options available,
>> which presents a problem in that if one code base is written in TypeScript,
>> and another in JavaScript++ will they be compatible? Even if the resulting
>> JS is, devs will be required to learn several variants of JS. It's not that
>> this isn't happening elsewhere (libraries written in Java vs C#), but it's
>> been made worse by ECMAScript's lack of key features, which has caused a
>> good many of these languages to appear, and to be used. My point is, if JS
>> was a little more large scale development friendly (like TypeScript), devs
>> could just use plain ol' JS! Sure, some would still use language extensions
>> like TypeScript, but at least it wouldn't be the defacto standard because
>> of core inadequacies in base language.
>>
>>
>> On Fri, Aug 23, 2013 at 1:06 PM, Jeremy Martin  wrote:
>>
>>> I mean it's a parse error that will throw prior to attempting to execute
>>> it.  For example, consider:
>>>
>>> (function() { var foo:String; })
>>>
>>> This will throw an error, despite the fact that the function hasn't been
>>> invoked.  I replied in haste, though... your point is obviously valid for
>>> o

Re: Optional Strong Typing

[J B]

Also, unlike other language features, static typing has it's own section in
that list; and they're not all in that section: "Some of the ones listed
below are also statically typed, such as mobl, GWT, JSIL, NS Basic, and
Haxe."

So, yeah, I don't think it qualifies as a "pet feature".

None of this was a problem when plugins were the norm, but now that they
appear to be going away, more and more devs have been transitioning over to
JS for serious development (games, frameworks, engines..), but JS wasn't
ready for this, so all of these other JavaScript like languages crept in to
fill the gaps... That's good, but shouldn't that be a short term solution?
Also, maybe this was part of the reason why ES4 got a little carried away,
but come on, that doesn't mean ECMAScript shouldn't be extended so that it
can also support larger scale development.


On Fri, Aug 23, 2013 at 1:24 PM, J B  wrote:

> @Jeremy: I mean the parser will strip all of the typing info out before
> it's compiled/interpreted.
>
> @Axel: "Evolving a language standard used as broadly as ECMAScript takes
> time" -- I agree.
> "You can see TypeScript as exploring future options for ECMAScript." --
> Wasn't AS3 already doing this?
> "Guards" -- Looks good...
> "TypeScript tracks JavaScript very closely, I would not consider it a
> different language." It's compiled, and it's one of many options available,
> which presents a problem in that if one code base is written in TypeScript,
> and another in JavaScript++ will they be compatible? Even if the resulting
> JS is, devs will be required to learn several variants of JS. It's not that
> this isn't happening elsewhere (libraries written in Java vs C#), but it's
> been made worse by ECMAScript's lack of key features, which has caused a
> good many of these languages to appear, and to be used. My point is, if JS
> was a little more large scale development friendly (like TypeScript), devs
> could just use plain ol' JS! Sure, some would still use language extensions
> like TypeScript, but at least it wouldn't be the defacto standard because
> of core inadequacies in base language.
>
>
> On Fri, Aug 23, 2013 at 1:06 PM, Jeremy Martin  wrote:
>
>> I mean it's a parse error that will throw prior to attempting to execute
>> it.  For example, consider:
>>
>> (function() { var foo:String; })
>>
>> This will throw an error, despite the fact that the function hasn't been
>> invoked.  I replied in haste, though... your point is obviously valid for
>> other scenarios.  Nonetheless, as a non-authoritative response, you're
>> going to need an argument far more compelling than I can think of to see
>> static typing seriously considered.
>>
>>
>> On Fri, Aug 23, 2013 at 2:00 PM, J B  wrote:
>>
>>> Are you referring to browsers like Chrome that compile the JS first?
>>> Then, yeah, I mean it shouldn't throw an error at compile time.
>>>
>>>
>>> On Fri, Aug 23, 2013 at 12:59 PM, Jeremy Martin wrote:
>>>
 > var foo:String;

 That's already a compile-time error (as opposed to runtime not sure
 if that's what you meant by the interpreter throwing an error).


 On Fri, Aug 23, 2013 at 1:56 PM, J B  wrote:

> And just to be clear, I'm not asking for run-time type checking or
> coercion; I'm simply asking that the interpreter not to thrown an error
> when it encounters something like this: var foo:String;
>
>
> On Fri, Aug 23, 2013 at 12:45 PM, J B  wrote:
>
>> For one, I wouldn't describe strong typing as a "pet feature". Two,
>> no, as far as I know, most of those languages in that list don't offer
>> macros or lots of parentheses; and, if they did, then, yeah, maybe it 
>> does
>> say something.
>>
>>
>> On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola <
>> dome...@domenicdenicola.com> wrote:
>>
>>> In general ECMAScript lacks lots of features. You may well ask why
>>> it doesn't have any other pet feature, and you can often point to
>>> compile-to-JS languages that add those. This doesn't imply that the 
>>> feature
>>> should be added to the language.
>>>
>>> Here, let me try:
>>>
>>> ---
>>>
>>> I'm aware of LispyScript, as well as all of these:
>>> https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
>>> .
>>>
>>> But those languages appear to have been created precisely because
>>> ECMAScript lacks features like lots of parentheses or macros. How many 
>>> of
>>> those languages offer lots of parentheses? I count quite a few... 
>>> Doesn't
>>> that say something?
>>>
>>> ---
>>>
>>> The existence of a feature in other languages does not imply it
>>> should be added to ECMAScript. You'll have to justify better than that 
>>> why
>>> you think strong typing would be valuable to a language that has
>>> historically rejected it. (I'll wait for one of the old timers to chi

Re: Optional Strong Typing

[Jeremy Martin]

> I mean the parser will strip all of the typing info out before it's
compiled/interpreted.

The implication being that implementors start shipping static compilers
where this parsing/stripping takes place (i.e., as a precursory step to
being interpreted)?

> but it's been made worse by ECMAScript's lack of key features

The problem with this statement is that "key features" is open for
interpretation.

> if JS was a little more large scale development friendly (like
TypeScript), devs could just use plain ol' JS

The fact is that devs already are building "large scale" projects using
plain ol' JS (I myself have worked on JS projects with 100k+ loc without
feeling the need for static typing).  The same goes for Python, PHP, Ruby,
etc. - this isn't an attack against static typing, but it's hardly
necessary for a language to be "friendly" for "large scale development".

> Sure, some would still use language extensions like TypeScript, but at
least it wouldn't be the defacto standard because of core inadequacies in
base language.

I'd be interested in seeing data that the de facto standard is to use
compile-to-JavaScript languages.  My own experience has been quite the
opposite.


On Fri, Aug 23, 2013 at 2:24 PM, J B  wrote:

> @Jeremy: I mean the parser will strip all of the typing info out before
> it's compiled/interpreted.
>
> @Axel: "Evolving a language standard used as broadly as ECMAScript takes
> time" -- I agree.
> "You can see TypeScript as exploring future options for ECMAScript." --
> Wasn't AS3 already doing this?
> "Guards" -- Looks good...
> "TypeScript tracks JavaScript very closely, I would not consider it a
> different language." It's compiled, and it's one of many options available,
> which presents a problem in that if one code base is written in TypeScript,
> and another in JavaScript++ will they be compatible? Even if the resulting
> JS is, devs will be required to learn several variants of JS. It's not that
> this isn't happening elsewhere (libraries written in Java vs C#), but it's
> been made worse by ECMAScript's lack of key features, which has caused a
> good many of these languages to appear, and to be used. My point is, if JS
> was a little more large scale development friendly (like TypeScript), devs
> could just use plain ol' JS! Sure, some would still use language extensions
> like TypeScript, but at least it wouldn't be the defacto standard because
> of core inadequacies in base language.
>
>
> On Fri, Aug 23, 2013 at 1:06 PM, Jeremy Martin  wrote:
>
>> I mean it's a parse error that will throw prior to attempting to execute
>> it.  For example, consider:
>>
>> (function() { var foo:String; })
>>
>> This will throw an error, despite the fact that the function hasn't been
>> invoked.  I replied in haste, though... your point is obviously valid for
>> other scenarios.  Nonetheless, as a non-authoritative response, you're
>> going to need an argument far more compelling than I can think of to see
>> static typing seriously considered.
>>
>>
>> On Fri, Aug 23, 2013 at 2:00 PM, J B  wrote:
>>
>>> Are you referring to browsers like Chrome that compile the JS first?
>>> Then, yeah, I mean it shouldn't throw an error at compile time.
>>>
>>>
>>> On Fri, Aug 23, 2013 at 12:59 PM, Jeremy Martin wrote:
>>>
 > var foo:String;

 That's already a compile-time error (as opposed to runtime not sure
 if that's what you meant by the interpreter throwing an error).


 On Fri, Aug 23, 2013 at 1:56 PM, J B  wrote:

> And just to be clear, I'm not asking for run-time type checking or
> coercion; I'm simply asking that the interpreter not to thrown an error
> when it encounters something like this: var foo:String;
>
>
> On Fri, Aug 23, 2013 at 12:45 PM, J B  wrote:
>
>> For one, I wouldn't describe strong typing as a "pet feature". Two,
>> no, as far as I know, most of those languages in that list don't offer
>> macros or lots of parentheses; and, if they did, then, yeah, maybe it 
>> does
>> say something.
>>
>>
>> On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola <
>> dome...@domenicdenicola.com> wrote:
>>
>>> In general ECMAScript lacks lots of features. You may well ask why
>>> it doesn't have any other pet feature, and you can often point to
>>> compile-to-JS languages that add those. This doesn't imply that the 
>>> feature
>>> should be added to the language.
>>>
>>> Here, let me try:
>>>
>>> ---
>>>
>>> I'm aware of LispyScript, as well as all of these:
>>> https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
>>> .
>>>
>>> But those languages appear to have been created precisely because
>>> ECMAScript lacks features like lots of parentheses or macros. How many 
>>> of
>>> those languages offer lots of parentheses? I count quite a few... 
>>> Doesn't
>>> that say something?
>

Re: Optional Strong Typing

[Brendan Eich]

Has everyone forgotten ES4? Blasts from the past:

https://brendaneich.com/2007/11/my-media-ajax-keynote/

and then

https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html

ES4 failed in part because of AS3 namespaces (from original JS2/ES4 
namespaces in 1999, also in JScript.NET in 2000, IIRC; inspired by 
Common Lisp symbol packages), but also because on the Web it's very hard 
to know *when* to typecheck. Code loads all the time. Judgments may be 
invalidated down the road. The "any" type requires runtime checking.


So "strong typing" if it means "what AS3 does" bounced, hard.

The best we have in its place are the compile-to-JS langauges with 
optional and unsound type

If you want warnings, use WarnScript (er, TypeScript or Dart or ...).

If you want standardized warnings, we need lots more developer 
experience from TypeScript and other languages to get anywhere near a 
standard. ES8 at the earliest, given our move toward more rapid releases.


If you want a static type system -- which means soundness -- then there 
are big open research problems to solve.


/be


J B wrote:
@Jeremy: I mean the parser will strip all of the typing info out 
before it's compiled/interpreted.


@Axel: "Evolving a language standard used as broadly as ECMAScript 
takes time" -- I agree.
"You can see TypeScript as exploring future options for ECMAScript." 
-- Wasn't AS3 already doing this?

"Guards" -- Looks good...
"TypeScript tracks JavaScript very closely, I would not consider it a 
different language." It's compiled, and it's one of many options 
available, which presents a problem in that if one code base is 
written in TypeScript, and another in JavaScript++ will they be 
compatible? Even if the resulting JS is, devs will be required to 
learn several variants of JS. It's not that this isn't happening 
elsewhere (libraries written in Java vs C#), but it's been made worse 
by ECMAScript's lack of key features, which has caused a good many of 
these languages to appear, and to be used. My point is, if JS was a 
little more large scale development friendly (like TypeScript), devs 
could just use plain ol' JS! Sure, some would still use language 
extensions like TypeScript, but at least it wouldn't be the defacto 
standard because of core inadequacies in base language.



On Fri, Aug 23, 2013 at 1:06 PM, Jeremy Martin > wrote:


I mean it's a parse error that will throw prior to attempting to
execute it.  For example, consider:

(function() { var foo:String; })

This will throw an error, despite the fact that the function
hasn't been invoked.  I replied in haste, though... your point is
obviously valid for other scenarios.  Nonetheless, as a
non-authoritative response, you're going to need an argument far
more compelling than I can think of to see static typing seriously
considered.


On Fri, Aug 23, 2013 at 2:00 PM, J B mailto:por...@gmail.com>> wrote:

Are you referring to browsers like Chrome that compile the JS
first? Then, yeah, I mean it shouldn't throw an error at
compile time.


On Fri, Aug 23, 2013 at 12:59 PM, Jeremy Martin
mailto:jmar...@gmail.com>> wrote:

> var foo:String;

That's already a compile-time error (as opposed to
runtime not sure if that's what you meant by the
interpreter throwing an error).


On Fri, Aug 23, 2013 at 1:56 PM, J B mailto:por...@gmail.com>> wrote:

And just to be clear, I'm not asking for run-time type
checking or coercion; I'm simply asking that the
interpreter not to thrown an error when it encounters
something like this: var foo:String;


On Fri, Aug 23, 2013 at 12:45 PM, J B
mailto:por...@gmail.com>> wrote:

For one, I wouldn't describe strong typing as a
"pet feature". Two, no, as far as I know, most of
those languages in that list don't offer macros or
lots of parentheses; and, if they did, then, yeah,
maybe it does say something.


On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola
mailto:dome...@domenicdenicola.com>> wrote:

In general ECMAScript lacks lots of features.
You may well ask why it doesn't have any other
pet feature, and you can often point to
compile-to-JS languages that add those. This
doesn't imply that the feature should be added
to the language.

Here, let me try:

---

I'm aware of LispyScript, as well as all of
these:

https://github.com/jashkenas/coffee-script/wiki/List-of-la

Re: The generator.next() method

[Brendan Eich]

André Bargull wrote:
`g.next()` returns `{value: [1, 2, 3], done: false}` for me, so .value 
is needed here. Or do you mean something else?


Sorry (to Forbes), I was thinking of when for-of orchestrates.

/be



Thanks,
André


No .value anywhere, though.

/be

Forbes Lindesay wrote:
>/  It already is dealt with via destructuring assignments:
/>/
/>/  ```js
/>/  function* gen() {
/>/ var {x, y, z} = yield [1, 2, 3]
/>/ return x&&   y || z
/>/  }
/>/  var g = gen()
/>/  var [a, b, c] = g.next().value
/>/  assert(a === 1)
/>/  assert(b === 2)
/>/  assert(c === 3)
/>/  var res = g.send({x: true, y: false, z: true}).value
/>/  assert(res === true)
/>/  ```/

___
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: The generator.next() method

[Brendan Eich]

Domenic Denicola wrote:

[Working example in Traceur][1] (this is fun!)


Yes, +lots for Traceur.

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

Re: Optional Strong Typing

[J B]

@Jeremy: I mean the parser will strip all of the typing info out before
it's compiled/interpreted.

@Axel: "Evolving a language standard used as broadly as ECMAScript takes
time" -- I agree.
"You can see TypeScript as exploring future options for ECMAScript." --
Wasn't AS3 already doing this?
"Guards" -- Looks good...
"TypeScript tracks JavaScript very closely, I would not consider it a
different language." It's compiled, and it's one of many options available,
which presents a problem in that if one code base is written in TypeScript,
and another in JavaScript++ will they be compatible? Even if the resulting
JS is, devs will be required to learn several variants of JS. It's not that
this isn't happening elsewhere (libraries written in Java vs C#), but it's
been made worse by ECMAScript's lack of key features, which has caused a
good many of these languages to appear, and to be used. My point is, if JS
was a little more large scale development friendly (like TypeScript), devs
could just use plain ol' JS! Sure, some would still use language extensions
like TypeScript, but at least it wouldn't be the defacto standard because
of core inadequacies in base language.


On Fri, Aug 23, 2013 at 1:06 PM, Jeremy Martin  wrote:

> I mean it's a parse error that will throw prior to attempting to execute
> it.  For example, consider:
>
> (function() { var foo:String; })
>
> This will throw an error, despite the fact that the function hasn't been
> invoked.  I replied in haste, though... your point is obviously valid for
> other scenarios.  Nonetheless, as a non-authoritative response, you're
> going to need an argument far more compelling than I can think of to see
> static typing seriously considered.
>
>
> On Fri, Aug 23, 2013 at 2:00 PM, J B  wrote:
>
>> Are you referring to browsers like Chrome that compile the JS first?
>> Then, yeah, I mean it shouldn't throw an error at compile time.
>>
>>
>> On Fri, Aug 23, 2013 at 12:59 PM, Jeremy Martin wrote:
>>
>>> > var foo:String;
>>>
>>> That's already a compile-time error (as opposed to runtime not sure
>>> if that's what you meant by the interpreter throwing an error).
>>>
>>>
>>> On Fri, Aug 23, 2013 at 1:56 PM, J B  wrote:
>>>
 And just to be clear, I'm not asking for run-time type checking or
 coercion; I'm simply asking that the interpreter not to thrown an error
 when it encounters something like this: var foo:String;


 On Fri, Aug 23, 2013 at 12:45 PM, J B  wrote:

> For one, I wouldn't describe strong typing as a "pet feature". Two,
> no, as far as I know, most of those languages in that list don't offer
> macros or lots of parentheses; and, if they did, then, yeah, maybe it does
> say something.
>
>
> On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola <
> dome...@domenicdenicola.com> wrote:
>
>> In general ECMAScript lacks lots of features. You may well ask why it
>> doesn't have any other pet feature, and you can often point to
>> compile-to-JS languages that add those. This doesn't imply that the 
>> feature
>> should be added to the language.
>>
>> Here, let me try:
>>
>> ---
>>
>> I'm aware of LispyScript, as well as all of these:
>> https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
>> .
>>
>> But those languages appear to have been created precisely because
>> ECMAScript lacks features like lots of parentheses or macros. How many of
>> those languages offer lots of parentheses? I count quite a few... Doesn't
>> that say something?
>>
>> ---
>>
>> The existence of a feature in other languages does not imply it
>> should be added to ECMAScript. You'll have to justify better than that 
>> why
>> you think strong typing would be valuable to a language that has
>> historically rejected it. (I'll wait for one of the old timers to chime 
>> in
>> about the ES4 days here.)
>>
>>
>

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


>>>
>>>
>>> --
>>> Jeremy Martin
>>> 661.312.3853
>>> http://devsmash.com
>>> @jmar777
>>>
>>
>>
>
>
> --
> Jeremy Martin
> 661.312.3853
> http://devsmash.com
> @jmar777
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

[Jeremy Martin]

I mean it's a parse error that will throw prior to attempting to execute
it.  For example, consider:

(function() { var foo:String; })

This will throw an error, despite the fact that the function hasn't been
invoked.  I replied in haste, though... your point is obviously valid for
other scenarios.  Nonetheless, as a non-authoritative response, you're
going to need an argument far more compelling than I can think of to see
static typing seriously considered.


On Fri, Aug 23, 2013 at 2:00 PM, J B  wrote:

> Are you referring to browsers like Chrome that compile the JS first? Then,
> yeah, I mean it shouldn't throw an error at compile time.
>
>
> On Fri, Aug 23, 2013 at 12:59 PM, Jeremy Martin  wrote:
>
>> > var foo:String;
>>
>> That's already a compile-time error (as opposed to runtime not sure
>> if that's what you meant by the interpreter throwing an error).
>>
>>
>> On Fri, Aug 23, 2013 at 1:56 PM, J B  wrote:
>>
>>> And just to be clear, I'm not asking for run-time type checking or
>>> coercion; I'm simply asking that the interpreter not to thrown an error
>>> when it encounters something like this: var foo:String;
>>>
>>>
>>> On Fri, Aug 23, 2013 at 12:45 PM, J B  wrote:
>>>
 For one, I wouldn't describe strong typing as a "pet feature". Two, no,
 as far as I know, most of those languages in that list don't offer macros
 or lots of parentheses; and, if they did, then, yeah, maybe it does say
 something.


 On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola <
 dome...@domenicdenicola.com> wrote:

> In general ECMAScript lacks lots of features. You may well ask why it
> doesn't have any other pet feature, and you can often point to
> compile-to-JS languages that add those. This doesn't imply that the 
> feature
> should be added to the language.
>
> Here, let me try:
>
> ---
>
> I'm aware of LispyScript, as well as all of these:
> https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
> .
>
> But those languages appear to have been created precisely because
> ECMAScript lacks features like lots of parentheses or macros. How many of
> those languages offer lots of parentheses? I count quite a few... Doesn't
> that say something?
>
> ---
>
> The existence of a feature in other languages does not imply it should
> be added to ECMAScript. You'll have to justify better than that why you
> think strong typing would be valuable to a language that has historically
> rejected it. (I'll wait for one of the old timers to chime in about the 
> ES4
> days here.)
>
>

>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>>
>> --
>> Jeremy Martin
>> 661.312.3853
>> http://devsmash.com
>> @jmar777
>>
>
>


-- 
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

[Axel Rauschmayer]

Evolving a language standard used as broadly as ECMAScript takes time. You can 
see TypeScript as exploring future options for ECMAScript.

Guards [1] may still be added to ECMAScript, I don’t know what the current TC39 
opinion is on them.

Lastly, TypeScript tracks JavaScript very closely, I would not consider it a 
different language.

[1] http://wiki.ecmascript.org/doku.php?id=strawman:guards

On Aug 23, 2013, at 19:38 , J B  wrote:

> So the defacto response for large scale JS development will always be: Use X?
> 
> 
> On Fri, Aug 23, 2013 at 12:35 PM, Jeremy Martin  wrote:
> I haven't personally used it, but you may find that TypeScript provides what 
> you're looking for: http://www.typescriptlang.org/
> 
> 
> On Fri, Aug 23, 2013 at 1:26 PM, J B  wrote:
> Is there any particular reason my JS doesn't support (optional) AS3 style 
> strong typing? All the typing info would be ignored at run-time, but it would 
> be helpful for compile-time checking, code hinting, and general readability 
> of code. Tools like the closure compiler could even strip out all the typing 
> info, and it wouldn't make any difference at run-time. I'm probably beating a 
> dead horse here, but why?
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> 
> -- 
> Jeremy Martin
> 661.312.3853
> http://devsmash.com
> @jmar777
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

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

Re: Optional Strong Typing

[J B]

Are you referring to browsers like Chrome that compile the JS first? Then,
yeah, I mean it shouldn't throw an error at compile time.


On Fri, Aug 23, 2013 at 12:59 PM, Jeremy Martin  wrote:

> > var foo:String;
>
> That's already a compile-time error (as opposed to runtime not sure if
> that's what you meant by the interpreter throwing an error).
>
>
> On Fri, Aug 23, 2013 at 1:56 PM, J B  wrote:
>
>> And just to be clear, I'm not asking for run-time type checking or
>> coercion; I'm simply asking that the interpreter not to thrown an error
>> when it encounters something like this: var foo:String;
>>
>>
>> On Fri, Aug 23, 2013 at 12:45 PM, J B  wrote:
>>
>>> For one, I wouldn't describe strong typing as a "pet feature". Two, no,
>>> as far as I know, most of those languages in that list don't offer macros
>>> or lots of parentheses; and, if they did, then, yeah, maybe it does say
>>> something.
>>>
>>>
>>> On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola <
>>> dome...@domenicdenicola.com> wrote:
>>>
 In general ECMAScript lacks lots of features. You may well ask why it
 doesn't have any other pet feature, and you can often point to
 compile-to-JS languages that add those. This doesn't imply that the feature
 should be added to the language.

 Here, let me try:

 ---

 I'm aware of LispyScript, as well as all of these:
 https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
 .

 But those languages appear to have been created precisely because
 ECMAScript lacks features like lots of parentheses or macros. How many of
 those languages offer lots of parentheses? I count quite a few... Doesn't
 that say something?

 ---

 The existence of a feature in other languages does not imply it should
 be added to ECMAScript. You'll have to justify better than that why you
 think strong typing would be valuable to a language that has historically
 rejected it. (I'll wait for one of the old timers to chime in about the ES4
 days here.)


>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Jeremy Martin
> 661.312.3853
> http://devsmash.com
> @jmar777
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

[Jeremy Martin]

> var foo:String;

That's already a compile-time error (as opposed to runtime not sure if
that's what you meant by the interpreter throwing an error).


On Fri, Aug 23, 2013 at 1:56 PM, J B  wrote:

> And just to be clear, I'm not asking for run-time type checking or
> coercion; I'm simply asking that the interpreter not to thrown an error
> when it encounters something like this: var foo:String;
>
>
> On Fri, Aug 23, 2013 at 12:45 PM, J B  wrote:
>
>> For one, I wouldn't describe strong typing as a "pet feature". Two, no,
>> as far as I know, most of those languages in that list don't offer macros
>> or lots of parentheses; and, if they did, then, yeah, maybe it does say
>> something.
>>
>>
>> On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola <
>> dome...@domenicdenicola.com> wrote:
>>
>>> In general ECMAScript lacks lots of features. You may well ask why it
>>> doesn't have any other pet feature, and you can often point to
>>> compile-to-JS languages that add those. This doesn't imply that the feature
>>> should be added to the language.
>>>
>>> Here, let me try:
>>>
>>> ---
>>>
>>> I'm aware of LispyScript, as well as all of these:
>>> https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
>>> .
>>>
>>> But those languages appear to have been created precisely because
>>> ECMAScript lacks features like lots of parentheses or macros. How many of
>>> those languages offer lots of parentheses? I count quite a few... Doesn't
>>> that say something?
>>>
>>> ---
>>>
>>> The existence of a feature in other languages does not imply it should
>>> be added to ECMAScript. You'll have to justify better than that why you
>>> think strong typing would be valuable to a language that has historically
>>> rejected it. (I'll wait for one of the old timers to chime in about the ES4
>>> days here.)
>>>
>>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

[J B]

And just to be clear, I'm not asking for run-time type checking or
coercion; I'm simply asking that the interpreter not to thrown an error
when it encounters something like this: var foo:String;


On Fri, Aug 23, 2013 at 12:45 PM, J B  wrote:

> For one, I wouldn't describe strong typing as a "pet feature". Two, no, as
> far as I know, most of those languages in that list don't offer macros or
> lots of parentheses; and, if they did, then, yeah, maybe it does say
> something.
>
>
> On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola <
> dome...@domenicdenicola.com> wrote:
>
>> In general ECMAScript lacks lots of features. You may well ask why it
>> doesn't have any other pet feature, and you can often point to
>> compile-to-JS languages that add those. This doesn't imply that the feature
>> should be added to the language.
>>
>> Here, let me try:
>>
>> ---
>>
>> I'm aware of LispyScript, as well as all of these:
>> https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
>> .
>>
>> But those languages appear to have been created precisely because
>> ECMAScript lacks features like lots of parentheses or macros. How many of
>> those languages offer lots of parentheses? I count quite a few... Doesn't
>> that say something?
>>
>> ---
>>
>> The existence of a feature in other languages does not imply it should be
>> added to ECMAScript. You'll have to justify better than that why you think
>> strong typing would be valuable to a language that has historically
>> rejected it. (I'll wait for one of the old timers to chime in about the ES4
>> days here.)
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

[J B]

For one, I wouldn't describe strong typing as a "pet feature". Two, no, as
far as I know, most of those languages in that list don't offer macros or
lots of parentheses; and, if they did, then, yeah, maybe it does say
something.


On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> In general ECMAScript lacks lots of features. You may well ask why it
> doesn't have any other pet feature, and you can often point to
> compile-to-JS languages that add those. This doesn't imply that the feature
> should be added to the language.
>
> Here, let me try:
>
> ---
>
> I'm aware of LispyScript, as well as all of these:
> https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
> .
>
> But those languages appear to have been created precisely because
> ECMAScript lacks features like lots of parentheses or macros. How many of
> those languages offer lots of parentheses? I count quite a few... Doesn't
> that say something?
>
> ---
>
> The existence of a feature in other languages does not imply it should be
> added to ECMAScript. You'll have to justify better than that why you think
> strong typing would be valuable to a language that has historically
> rejected it. (I'll wait for one of the old timers to chime in about the ES4
> days here.)
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Optional Strong Typing

[Domenic Denicola]

In general ECMAScript lacks lots of features. You may well ask why it doesn't 
have any other pet feature, and you can often point to compile-to-JS languages 
that add those. This doesn't imply that the feature should be added to the 
language.

Here, let me try:

---

I'm aware of LispyScript, as well as all of these: 
https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS.

But those languages appear to have been created precisely because ECMAScript 
lacks features like lots of parentheses or macros. How many of those languages 
offer lots of parentheses? I count quite a few... Doesn't that say something?

---

The existence of a feature in other languages does not imply it should be added 
to ECMAScript. You'll have to justify better than that why you think strong 
typing would be valuable to a language that has historically rejected it. (I'll 
wait for one of the old timers to chime in about the ES4 days here.)

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

Re: Optional Strong Typing

[J B]

So the defacto response for large scale JS development will always be: Use
X?


On Fri, Aug 23, 2013 at 12:35 PM, Jeremy Martin  wrote:

> I haven't personally used it, but you may find that TypeScript provides
> what you're looking for: http://www.typescriptlang.org/
>
>
> On Fri, Aug 23, 2013 at 1:26 PM, J B  wrote:
>
>> Is there any particular reason my JS doesn't support (optional) AS3 style
>> strong typing? All the typing info would be ignored at run-time, but it
>> would be helpful for compile-time checking, code hinting, and general
>> readability of code. Tools like the closure compiler could even strip out
>> all the typing info, and it wouldn't make any difference at run-time. I'm
>> probably beating a dead horse here, but why?
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Jeremy Martin
> 661.312.3853
> http://devsmash.com
> @jmar777
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

[J B]

I'm aware of TypeScript, as well as all of these:
https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS

But those languages appear to have been created precisely because
ECMAScript lacks features like typing. How many of those languages offer
strong typing? I count quite a few... Doesn't that say something?



On Fri, Aug 23, 2013 at 12:29 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> You may be interested in [TypeScript](http://typescript.codeplex.com/).
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

[Jeremy Martin]

I haven't personally used it, but you may find that TypeScript provides
what you're looking for: http://www.typescriptlang.org/


On Fri, Aug 23, 2013 at 1:26 PM, J B  wrote:

> Is there any particular reason my JS doesn't support (optional) AS3 style
> strong typing? All the typing info would be ignored at run-time, but it
> would be helpful for compile-time checking, code hinting, and general
> readability of code. Tools like the closure compiler could even strip out
> all the typing info, and it wouldn't make any difference at run-time. I'm
> probably beating a dead horse here, but why?
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: new ES6 spec. draft now available

[Jason Orendorff]

On Fri, Aug 23, 2013 at 10:51 AM, Allen Wirfs-Brock
 wrote:
> http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#august_23_2013_draft

The HTML version is now available:
https://people.mozilla.com/~jorendorff/es6-draft.html

As always, bug reports are greatly appreciated. Send me email, or
better yet, file them here:
https://github.com/jorendorff/es-spec-html/issues

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

Re: new ES6 spec. draft now available

[Michael Dyck]

On 13-08-23 08:51 AM, Allen Wirfs-Brock wrote:


http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#august_23_2013_draft


When I view the PDFs in Adobe Reader, most of the body text is rendered 
in Adobe Sans MM, which is what it substitutes when it can't locate the 
original font.


Original fonts appear to be:
Arial
Arial,Bold
Arial,BoldItalic
Arial,Italic
Helvetica
Helvetica,Bold
Helvetica,Italic
Times New Roman
Times New Roman,Bold
Times New Roman,Italic

Actually, it looks like there versions of these fonts embedded in the 
PDF, but I guess Reader can't use them? They're marked:

Type: TrueType (CID)
Encoding: Identity-H

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

Optional Strong Typing

[J B]

Is there any particular reason my JS doesn't support (optional) AS3 style
strong typing? All the typing info would be ignored at run-time, but it
would be helpful for compile-time checking, code hinting, and general
readability of code. Tools like the closure compiler could even strip out
all the typing info, and it wouldn't make any difference at run-time. I'm
probably beating a dead horse here, but why?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

new ES6 spec. draft now available

[Allen Wirfs-Brock]

http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#august_23_2013_draft
 

Changes include:

Added Number.isSafeInteger
Added Number.MAX_SAFE_INTEGER
Removed: Number.MAX_INTEGER
Removed: Number.toInteger
Define all parts of a class definition to be strict code
‘length’ property of program defined functions have the attributes { 
[[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true }.
Computed property names in object literals and class definitions can be strings 
or symbols
TypedArray objects are made non-extensible when they are allocated.
Added ToLength abstract operation. Generic Array methods use ToLength and are 
not limited to Uint32 lengths.
keys, and entries interators over Arrays and Typed Arrays return numbers for 
their key values.
Map/WeakMap constructor no longer explicitly looks for an ‘entires’ method on 
iterable arg. Always uses @@iterator.Throws if an iteration item is not an 
object.
Added with blacklist (@@unscopable) support to withStatement and Object 
Environment Records
Added Array.prototype[@@unscopable) with value [”find”, “findIndex”, “fill”, 
copyWithin”, “entries”, “keys”, “values”]
Destructuring to a object/array pattern throws if the value/default value is 
not an object
Destructuring throws if a corresponding source property does not exist and a 
default value is not provided
Eliminated NoIn alternative expression grammar because they are unnecessary 
after eliminating for-in binding initializer expression
Added Array.prototype.fill, Array.prototype.copyWithin, 
%TypedArray%.prototype.fill, %TypedArray%.prototype.copyWithin
Updated definition of Function.prototype.toString
Added Math.roundFloat32 (formerly aka Math.toFloat32)
Updated Array.prototype.splice to match web reality when called with 1 argument 
(see bug 429)
{[”__proto__“]: obj defines a data property named “proto” rather than setting 
the object’s [[Prototype]] internal data property
Using a computed property name in a strict mode object literal or class 
definition to define a property that already exists is a runtime error
Made DataView buffer, byteLength, byteOffset prototype accessor properties just 
like they are for Typed Array
Specified all %TypedArray%.prototype methods
Array.prototype.map, filter, slice, splice when used iwth array subclasses 
creates results arrays of the same subclass
foo.__proto__ = 1234, etc. and {__proto__: 123} no longer throws.
Resolved Bugs: 1800, 1796, 1794, 178-1783, 1779, 1777-1771, 1769, 1767-1763, 
1761-1752, 1750-1735, 1733, 1731, 1729, 1727-1717, 1715, 1713-1705, 1703-1661, 
1659-1634, 1632-1626, 1624, 1622-1620, 1618, 1616-1609, 1607, 1605-1602, 1599, 
1596, 1594, 1592, 1590, 1588-1586, 1583-1581, 1579, 1575, 1560, 1464, 1257, 
788, 733, 716, 701, 429, 224, 175, 146

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

RE: The generator.next() method

[Domenic Denicola]

I believe .value is indeed correct, although as André alludes to, .send() has 
been replaced by .next().

[Working example in Traceur][1] (this is fun!)

[1]: 
http://traceur-compiler.googlecode.com/git/demo/repl.html#function*%20gen%28%29%20{%0A%20%20var%20{x%2C%20y%2C%20z}%20%3D%20yield%20[1%2C%202%2C%203]%0A%20%20return%20x%20%26%26%20y%20||%20z%0A}%0Avar%20g%20%3D%20gen%28%29%0Avar%20[a%2C%20b%2C%20c]%20%3D%20g.next%28%29.value%0Aconsole.log%28%27a%20%3D%3D%3D%201%27%2C%20a%20%3D%3D%3D%201%29%0Aconsole.log%28%27b%20%3D%3D%3D%202%27%2C%20b%20%3D%3D%3D%202%29%0Aconsole.log%28%27c%20%3D%3D%3D%203%27%2C%20c%20%3D%3D%3D%203%29%0Avar%20res%20%3D%20g.next%28{x%3A%20true%2C%20y%3A%20false%2C%20z%3A%20true}%29.value%0Aconsole.log%28%27res%20%3D%3D%3D%20true%27%2C%20res%20%3D%3D%3D%20true%29
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional named arguments

[Forbes Lindesay]

The `=` operator in the object declaration is defining defaults for the 
destructuring.  If the object being destructured doesn't have that property, 
the value on the right hand side of the `=` operator is used.

The `= {}` provides a default object to de-structure, making the entire 
argument optional.  Without that you would be trying to de-structure 
`undefined` when you call `postToMailingList()` which would be an error.

If you don't pass an object, `{}` is used because it is the default.  If you 
pass an empty object then that empty object is used (i.e. still `{}`).

P.S. please just inline your code samples and use something like GitHub 
flavoured markdown to format your posts (i.e. code blocks begin and end with 
three back-tick characters)  That way they will be quick and easy to read on 
http://esdiscuss.org/topic/optional-named-arguments  You can see plenty of 
examples by clicking on "View Original" (e.g. I re-formatted your last post for 
you)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The generator.next() method

[Forbes Lindesay]

I just wanted to demonstrate the point, I couldn't remember what the exact API 
agreed upon for `gen.send` is.

On 23 Aug 2013, at 10:07, "Andr? Bargull" 
mailto:andre.barg...@udo.edu>> wrote:

`g.next()` returns `{value: [1, 2, 3], done: false}` for me, so .value is 
needed here. Or do you mean something else?

Thanks,
Andr?


No .value anywhere, though.

/be

Forbes Lindesay wrote:
> It already is dealt with via destructuring assignments:
>
> ```js
> function* gen() {
>var {x, y, z} = yield [1, 2, 3]
>return x&&  y || z
> }
> var g = gen()
> var [a, b, c] = g.next().value
> assert(a === 1)
> assert(b === 2)
> assert(c === 3)
> var res = g.send({x: true, y: false, z: true}).value
> assert(res === true)
> ```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The generator.next() method

[André Bargull]

`g.next()` returns `{value: [1, 2, 3], done: false}` for me, so .value 
is needed here. Or do you mean something else?


Thanks,
André


No .value anywhere, though.

/be

Forbes Lindesay wrote:
>/  It already is dealt with via destructuring assignments:
/>/
/>/  ```js
/>/  function* gen() {
/>/ var {x, y, z} = yield [1, 2, 3]
/>/ return x&&  y || z
/>/  }
/>/  var g = gen()
/>/  var [a, b, c] = g.next().value
/>/  assert(a === 1)
/>/  assert(b === 2)
/>/  assert(c === 3)
/>/  var res = g.send({x: true, y: false, z: true}).value
/>/  assert(res === true)
/>/  ```/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The generator.next() method

[Brendan Eich]

No .value anywhere, though.

/be

Forbes Lindesay wrote:

It already is dealt with via destructuring assignments:

```js
function* gen() {
   var {x, y, z} = yield [1, 2, 3]
   return x&&  y || z
}
var g = gen()
var [a, b, c] = g.next().value
assert(a === 1)
assert(b === 2)
assert(c === 3)
var res = g.send({x: true, y: false, z: true}).value
assert(res === true)
```
___
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: The generator.next() method

[Forbes Lindesay]

It already is dealt with via destructuring assignments:

```js
function* gen() {
  var {x, y, z} = yield [1, 2, 3]
  return x && y || z
}
var g = gen()
var [a, b, c] = g.next().value
assert(a === 1)
assert(b === 2)
assert(c === 3)
var res = g.send({x: true, y: false, z: true}).value
assert(res === true)
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

The generator.next() method

[Michaël Rouges]

Hello everyone,

I wondered why it would be possible to send only one variable via this
method?

Knowing that we will have the opportunity to use destructuring assignments, why
can't we deal on this "problem"?

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

Re: Re: Optional named arguments

[Michaël Rouges]

Hi all,

Thanks for your answers.

Domenic Denicola sent me an example by email, but I don't understand it all.

I waited for his response, but seemed busy, I turn back to you.

The sample :

http://traceur-compiler.googlecode.com/git/demo/repl.html#function%20postToMailingList%28{%0A%20%20%20%20email%20%3D%20%22es-discuss%40mozilla.org%22%2C%0A%20%20%20%20subject%20%3D%20%22Optional%20named%20arguments%22%2C%0A%20%20%20%20from%20%3D%20%22michael.rouges%40gmail.com%22}%20%3D%20{}%29%20{%0A%20%20console.log%28email%2C%20subject%2C%20from%29%3B%0A}%0A%0ApostToMailingList%28%29%3B%20%2F%2F%20uses%20all%20the%20defaults%0ApostToMailingList%28{}%29%3B%20%2F%2F%20same%0ApostToMailingList%28{%20email%3A%20%22public-script-coord%40w3.org%22%20}%29%3B%20%2F%2F%20overrides%20the%20default%20email

Several points seems obscure:

   - the *=* operator in the option object declaration
   - the role of *= {}* inside the parentheses of the function declaration
   - and the fact that you can decide to have an empty object, despite
   defaults *(line 9)*

Could you enlighten me, please? or advise me of an article on this subject?

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