date:20140127

Thanks for the explanation.

Given all of the costs, perhaps it is worth reconsidering the benefit.
 Many issues affect the load timing of web pages, will this one change make
such an improvement that it's worth the disruption it causes?


On Sat, Jan 25, 2014 at 3:31 PM, Brendan Eich bren...@mozilla.com wrote:

 John Barton wrote:

 The Script goal disallows 'import' and 'export' specifically to ensure
 that the Script goal is inconvenient for developers and thus they are
 encouraged to shift to the Module goal.


 No, that's not the rationale. The reason is to avoid enabling more
 synchronous script src=-style jank. We have enough of that already with
 the existing attractive nuisance (script src= w/o async), per Steve Souders.

 /be

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

Re: detecting JS language mode for tools

2014-01-27 Thread David Bruant


Le 27/01/2014 19:41, David Herman a écrit :

On Jan 27, 2014, at 2:07 AM, David Bruant bruan...@gmail.com wrote:


Indeed. I'm wondering why we need inline script for modules.

Because people write inline scripts all the time. It's unacceptably 
inconvenient not to be able to bootstrap your app with inline code. It also 
allows you to control for when the scripts resource is there, in particular to 
be sure that necessary bootstrapping/kernel code has loaded before you need to 
do some wiring up of your app.
Agreed. Note that I didn't suggest to stop writing inline scripts and 
proposed an alternative to script@module that can work today.
Granted, it's somewhat hacky, but I think it can work during the period 
during which there'll be both ES6 and non-ES6 browsers to support.


I was sloppy in my phrasing. What we don't need is the current inline 
script execute right now and block everything else semantics, 
specifically for modules which order of execution shouldn't block things.



But it's not even worth overthinking. It's so obviously, obscenely anti-usable 
not to be able to write

 script module
 import $ from jquery;
 import go from myapp;
 $(go);
 /script

inline that I'm surprised this is even a discussion.
If the snippet is only targetting ES6 browser, it can work without the 
module attribute (I think?). This snippet doesn't work on non-ES6 
browsers, though.


I feel two different problems are being discussed in this thread? One 
about inline modules, one about compatibility, (both a bit away from the 
original topic ;-)). I was on the compatibility track.


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

Re: Reason why generators do not have references to themselves?

I'd like to suggest another sense in which you may have gone down a bad path: 
you're assuming that await is paired with function*, but it could instead be 
(like C#) paired with its own async-function syntactic form. Let's say for the 
sake of argument that async is just a keyword that takes a function form:

  async function sizeOfZombocom() {
let all = await download(http://zombo.com;);
return all.length;
  }

Imagine we were designing this with a macro system like sweet.js. The 
temptation is for `async` to unhygienically bind `await` to a macro within its 
body, but Racket has developed a cleaner mechanism for thinking about paired 
forms like this, which they call syntax parameters (kind of a confusingly 
generic sounding name) [1] [2]. The basic idea is that you bind both `async` 
and `await` at the same time, so `await` is always bound, even outside of an 
async function, but the two collaborate so that `async` informs `await` of its 
syntactic context. So it would look something like this:

Example 1:

  import { async, await } from async;

  await 1; // syntax error: await used outside of async function

Example 2:

  import { async, await } from async;

  function* sizeOfZombocom() {
let all = await download(http://zombo.com;); // syntax error: await used 
outside of async function
return all.length;
  }

Example 3:

  import { async, await } from async;

  async function sizeOfZombocom() {
let all = await download(http://zombo.com;); // great success
return all.length;
  }

This makes your abstraction airtight: `await` is a concept that belongs to 
`async` functions, not generator functions; generator functions are merely the 
internal implementation technique.

Currently, sweet.js doesn't have syntax parameters, but it'd be a good 
experiment to add them them and try implementing async/await as I've sketched 
here.

Dave

[1] http://www.greghendershott.com/fear-of-macros/Syntax_parameters.html
[2] http://docs.racket-lang.org/reference/stxparam.html

On Jan 23, 2014, at 2:14 PM, Bradley Meck bradley.m...@gmail.com wrote:

 I was playing around with generators / looking at await for promises and 
 notices a very difficult thing revolving around generators not having a 
 reference to themselves.
 
 See: 
 
 https://gist.github.com/bmeck/72a0f4f448f20cf00f8c
 
 I have to end up wrapping the generator function to get a reference to the 
 generator for passing to nested functions.
 
 Is there a reason the execution context is not a generator / there is no 
 reference back to the generator during [[call]]?
 ___
 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: detecting JS language mode for tools

On Jan 27, 2014, at 10:58 AM, David Bruant bruan...@gmail.com wrote:

 Agreed. Note that I didn't suggest to stop writing inline scripts and 
 proposed an alternative to script@module that can work today.
 Granted, it's somewhat hacky, but I think it can work during the period 
 during which there'll be both ES6 and non-ES6 browsers to support.
 
 I was sloppy in my phrasing. What we don't need is the current inline script 
 execute right now and block everything else semantics, specifically for 
 modules which order of execution shouldn't block things.

OK, sorry I jumped in the middle of things missing some context. In fact, I 
think what we've been planning on proposing is not too far -- I think -- from 
what you're talking about. The plan is *not* a module attribute (that was a 
think-o on my part, and maybe some misinformation that crept into this 
discussion earlier?) but type=module. That way on old browsers it's ignored 
and you can add shims to load it. Shims can be made future-proof via feature 
detection, so type=module can obtain new semantics.

Moreover, the type=module should not actually mean execute right now and 
block everything else, but rather executing asynchronously once all my module 
dependencies are loaded and linked.

Does that make more sense? I realize part of the issue here is there isn't a 
concrete plan or proposal that's been spelled out, it's just been informal 
discussions. That's on us, the modules champions, to put forward a proposal for 
web (i.e. non-Ecma) standardization ASAP. Yehuda's going to be in town for TC39 
this week, so he and I will sit down and do an informal write-up so people can 
see the plan more clearly, while we work on a fuller proposal for 
standardization.

Dave

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

Re: detecting JS language mode for tools

On Jan 27, 2014, at 2:07 AM, David Bruant bruan...@gmail.com wrote:

 Indeed. I'm wondering why we need inline script for modules.

Because people write inline scripts all the time. It's unacceptably 
inconvenient not to be able to bootstrap your app with inline code. It also 
allows you to control for when the scripts resource is there, in particular to 
be sure that necessary bootstrapping/kernel code has loaded before you need to 
do some wiring up of your app.

But it's not even worth overthinking. It's so obviously, obscenely anti-usable 
not to be able to write

script module
import $ from jquery;
import go from myapp;
$(go);
/script

inline that I'm surprised this is even a discussion.

Dave

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

Re: detecting JS language mode for tools

[Resending, not sure why it's not getting through to the list...]

On Jan 27, 2014, at 10:41 AM, David Herman dher...@mozilla.com wrote:

 On Jan 27, 2014, at 2:07 AM, David Bruant bruan...@gmail.com wrote:
 
 Indeed. I'm wondering why we need inline script for modules.
 
 Because people write inline scripts all the time. It's unacceptably 
 inconvenient not to be able to bootstrap your app with inline code. It also 
 allows you to control for when the scripts resource is there, in particular 
 to be sure that necessary bootstrapping/kernel code has loaded before you 
 need to do some wiring up of your app.
 
 But it's not even worth overthinking. It's so obviously, obscenely 
 anti-usable not to be able to write
 
script module
import $ from jquery;
import go from myapp;
$(go);
/script
 
 inline that I'm surprised this is even a discussion.
 
 Dave
 

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

ES6 timetable and current status

2014-01-27 Thread Maciej Jaros


Hi.

I'm trying to figure out what is the current status of ES6 especially 
that next draft was released. As I understand this is not yet a 
Candidate Draft this presentation mentions 
http://slid.es/rafaelweinstein/tc39-process? So my question is - is 
there some timetable/roadmap for the ES6? Also is it still possible that 
new things like Symbols and Modules will be dropped or work very 
differently then in current draft? Or is it just a matter of maturing 
stuff and any other changes will be pushed to ES7 (like this slides seem 
to suggest http://www.slideshare.net/BrendanEich/js-resp)?


Also what is the status of strawman/harmony pages on ES wiki? They all 
are proposals for ES6, right? Or can I just assume that all/most things 
in strawman won't make it to ES6 and will be pushed to ES7? Or should 
they all be treated as loose notes? I'm just not sure what to follow and 
to what extent.


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

Re: detecting JS language mode for tools

2014-01-27 Thread Allen Wirfs-Brock


On Jan 24, 2014, at 6:33 PM, Brendan Eich wrote:

 John Barton wrote:
 On Fri, Jan 24, 2014 at 12:17 PM, Allen Wirfs-Brock al...@wirfs-brock.com 
 mailto:al...@wirfs-brock.com wrote:
 
I should have also included:
 
2A) Hopefully, overtime, the old script syntactic goal will fade
from use, and the module goal will become the norm for new code.
 
 
 Now here is a reason, finally, for all the extra complexity the two goals 
 cause.
 
 If we want to kill script, let's not stab it with a dull pencil. Let's make 
 Loader and System be modules, not globals. Then you cannot load modules with 
 script, only with module.
 
 We are not killing script Dream on!

Right, that's why I said script syntactic goal.  In 2A script refers to the 
ES6 Script grammar production, not the HTML script tag.

Allen


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

JSCert: a JavaScript formalisation in the Coq theorem prover

2014-01-27 Thread Gareth Smith

We are pleased to announce JSCert, a formalisation of Chapters 8-14 of
the ES5 standard. 

We've built JSCert using the Coq proof assistant, using the same
metaphors and data structures as the ES5 standard, and following ES5
algorithm listings line-by-line. This means we can evolve our formalism
along with ECMAScript: local changes to the standard should mean
similarly local changes to JSCert. At the same time, we've structured
JSCert to make it as easy as possible to build analysis and verification
tools on top.

We also provide JSRef, an interpreter for ES5, which we have verified in
Coq to correctly implement JSCert. We have also tested JSRef using
test262. Since each line of JSRef has a close correspondence with a
given line of JSCert and the ES5 algorithms we will be able to use code
coverage tools to begin to evaluate how much of ES5 is covered by
test262.

We very much hope that people will be interested in using JSCert and
JSRef for investigating, for example, semantics-preserving compilation
to ECMAScript, or other language analyses.

You can find papers, code, talks and docs all at our website:

http://jscert.org

The code is here:

http://github.com/jscert/jscert

And our recent paper describing the project is here:

http://www.doc.ic.ac.uk/~gds/jscert_popl14.pdf

Thanks,

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

Re: detecting JS language mode for tools

David Herman mailto:dher...@mozilla.com
January 27, 2014 at 12:03 PM

OK, sorry I jumped in the middle of things missing some context. In
fact, I think what we've been planning on proposing is not too far --
I think -- from what you're talking about. The plan is *not* a module
attribute (that was a think-o on my part, and maybe some
misinformation that crept into this discussion earlier?) but
type=module. That way on old browsers it's ignored and you can add
shims to load it. Shims can be made future-proof via feature
detection, so type=module can obtain new semantics.

The shims word suggests that old-browser-targeted script must DOM-scrape
the script type=module text and interpret it with Esprima or similar.
This may not perform well enough compared to an AOT compiler, which is
another option. Just weighing these.

Moreover, the type=module should not actually mean execute right
now and block everything else, but rather executing asynchronously
once all my module dependencies are loaded and linked.

The detail I mentioned 1:1 of type= requiring IANA media types suggests
something other than module. Detail? Not to standardistas (Hi, Bjoern!).

Whatever the bootstrap inline script compatibility story, I agree having
an inline bootstrap module-script is desirable.

/be
Does that make more sense? I realize part of the issue here is there
isn't a concrete plan or proposal that's been spelled out, it's just
been informal discussions. That's on us, the modules champions, to put
forward a proposal for web (i.e. non-Ecma) standardization ASAP.
Yehuda's going to be in town for TC39 this week, so he and I will sit
down and do an informal write-up so people can see the plan more
clearly, while we work on a fuller proposal for standardization.

Dave

David Bruant mailto:bruan...@gmail.com
January 27, 2014 at 10:58 AM
Le 27/01/2014 19:41, David Herman a écrit :

On Jan 27, 2014, at 2:07 AM, David Bruant bruan...@gmail.com wrote:

Indeed. I'm wondering why we need inline script for modules.
Because people write inline scripts all the time. It's unacceptably
inconvenient not to be able to bootstrap your app with inline code.
It also allows you to control for when the scripts resource is there,
in particular to be sure that necessary bootstrapping/kernel code has
loaded before you need to do some wiring up of your app.
Agreed. Note that I didn't suggest to stop writing inline scripts and
proposed an alternative to script@module that can work today.
Granted, it's somewhat hacky, but I think it can work during the
period during which there'll be both ES6 and non-ES6 browsers to support.

I was sloppy in my phrasing. What we don't need is the current inline
script execute right now and block everything else semantics,
specifically for modules which order of execution shouldn't block things.

But it's not even worth overthinking. It's so obviously, obscenely
anti-usable not to be able to write

script module
import $ from jquery;
import go from myapp;
$(go);
/script

inline that I'm surprised this is even a discussion.
If the snippet is only targetting ES6 browser, it can work without the
module attribute (I think?). This snippet doesn't work on non-ES6
browsers, though.

I feel two different problems are being discussed in this thread? One
about inline modules, one about compatibility, (both a bit away from
the original topic ;-)). I was on the compatibility track.

David

David Herman mailto:dher...@mozilla.com
January 27, 2014 at 10:41 AM

Because people write inline scripts all the time. It's unacceptably
inconvenient not to be able to bootstrap your app with inline code. It
also allows you to control for when the scripts resource is there, in
particular to be sure that necessary bootstrapping/kernel code has
loaded before you need to do some wiring up of your app.

But it's not even worth overthinking. It's so obviously, obscenely
anti-usable not to be able to write

script module
import $ from jquery;
import go from myapp;
$(go);
/script

inline that I'm surprised this is even a discussion.

Dave

David Bruant mailto:bruan...@gmail.com
January 27, 2014 at 2:07 AM
Le 27/01/2014 06:45, Brendan Eich a écrit :

Kevin Smith wrote:

Is a new attribute necessary? What about using @type?

Old browsers will ignore unknown types, losing the two-way
fallback option.

Two-way fallback? Why is that important? Since modules are
implicitly strict, there is little intersection between scripts and
modules.

One can write strict code that runs fine in old browsers!
Yes. For transition from non-strict to strict and advice on writing
strictness-neutral code, there is
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions_and_function_scope/Strict_mode/Transitioning_to_strict_mode?redirectlocale=en-USredirectslug=JavaScript%2FReference%2FFunctions_and_function_scope%2FStrict_mode%2FTransitioning_to_strict_mode

(reviews

Re: Reason why generators do not have references to themselves?

2014-01-27 Thread Erik Arvidsson

On Jan 27, 2014 2:09 PM, David Herman dher...@mozilla.com wrote:

 I'd like to suggest another sense in which you may have gone down a bad
path: you're assuming that await is paired with function*, but it could
instead be (like C#) paired with its own async-function syntactic form.
Let's say for the sake of argument that async is just a keyword that takes
a function form:

   async function sizeOfZombocom() {
 let all = await download(http://zombo.com;);
 return all.length;
   }

This is similar to way we implemented async in Traceur a few years ago
(time flies). A lot of code can be be shared between generators and async
functions but you do not want to implement async using generators.

 Imagine we were designing this with a macro system like sweet.js. The
temptation is for `async` to unhygienically bind `await` to a macro within
its body, but Racket has developed a cleaner mechanism for thinking about
paired forms like this, which they call syntax parameters (kind of a
confusingly generic sounding name) [1] [2]. The basic idea is that you bind
both `async` and `await` at the same time, so `await` is always bound, even
outside of an async function, but the two collaborate so that `async`
informs `await` of its syntactic context. So it would look something like
this:

 Example 1:

   import { async, await } from async;

   await 1; // syntax error: await used outside of async function

 Example 2:

   import { async, await } from async;

   function* sizeOfZombocom() {
 let all = await download(http://zombo.com;); // syntax error: await
used outside of async function
 return all.length;
   }

 Example 3:

   import { async, await } from async;

   async function sizeOfZombocom() {
 let all = await download(http://zombo.com;); // great success
 return all.length;
   }

 This makes your abstraction airtight: `await` is a concept that belongs
to `async` functions, not generator functions; generator functions are
merely the internal implementation technique.

 Currently, sweet.js doesn't have syntax parameters, but it'd be a good
experiment to add them them and try implementing async/await as I've
sketched here.

 Dave

 [1] http://www.greghendershott.com/fear-of-macros/Syntax_parameters.html
 [2] http://docs.racket-lang.org/reference/stxparam.html

 On Jan 23, 2014, at 2:14 PM, Bradley Meck bradley.m...@gmail.com wrote:

  I was playing around with generators / looking at await for promises
and notices a very difficult thing revolving around generators not having a
reference to themselves.
 
  See:
 
  https://gist.github.com/bmeck/72a0f4f448f20cf00f8c
 
  I have to end up wrapping the generator function to get a reference to
the generator for passing to nested functions.
 
  Is there a reason the execution context is not a generator / there is
no reference back to the generator during [[call]]?
  ___
  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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Reason why generators do not have references to themselves?

2014-01-27 Thread Bradley Meck

Could not get the example deferred function to work with traceur from the
wiki page to see what it generates.
https://github.com/google/traceur-compiler/wiki/LanguageFeatures

Been talking off list since this is off topic, but keeps coming up. I ended
up following Brendan's advice. I have a sweet.js that works well, but still
requires a wrapper.

https://gist.github.com/bmeck/5146e40d71bbd57ec9ec

Tests seem to pass, yielding promises without awaiting, direct eval
(without regenerator), usage in regenerator, etc.

My macro does no match the semantics of what is in the wiki, but would be
interested in how traceur does function returns from deferred functions /
if I can use yield.

Unsure on how new syntax features like await should deal w/ multiple
operands though, like if await wanted to turn multiple promises into an
array. Comma operator takes comma separated list out of the equation.


On Mon, Jan 27, 2014 at 3:17 PM, Erik Arvidsson erik.arvids...@gmail.comwrote:


 On Jan 27, 2014 2:09 PM, David Herman dher...@mozilla.com wrote:
 
  I'd like to suggest another sense in which you may have gone down a bad
 path: you're assuming that await is paired with function*, but it could
 instead be (like C#) paired with its own async-function syntactic form.
 Let's say for the sake of argument that async is just a keyword that takes
 a function form:
 
async function sizeOfZombocom() {
  let all = await download(http://zombo.com;);
  return all.length;
}

 This is similar to way we implemented async in Traceur a few years ago
 (time flies). A lot of code can be be shared between generators and async
 functions but you do not want to implement async using generators.

  Imagine we were designing this with a macro system like sweet.js. The
 temptation is for `async` to unhygienically bind `await` to a macro within
 its body, but Racket has developed a cleaner mechanism for thinking about
 paired forms like this, which they call syntax parameters (kind of a
 confusingly generic sounding name) [1] [2]. The basic idea is that you bind
 both `async` and `await` at the same time, so `await` is always bound, even
 outside of an async function, but the two collaborate so that `async`
 informs `await` of its syntactic context. So it would look something like
 this:
 
  Example 1:
 
import { async, await } from async;
 
await 1; // syntax error: await used outside of async function
 
  Example 2:
 
import { async, await } from async;
 
function* sizeOfZombocom() {
  let all = await download(http://zombo.com;); // syntax error:
 await used outside of async function
  return all.length;
}
 
  Example 3:
 
import { async, await } from async;
 
async function sizeOfZombocom() {
  let all = await download(http://zombo.com;); // great success
  return all.length;
}
 
  This makes your abstraction airtight: `await` is a concept that belongs
 to `async` functions, not generator functions; generator functions are
 merely the internal implementation technique.
 
  Currently, sweet.js doesn't have syntax parameters, but it'd be a good
 experiment to add them them and try implementing async/await as I've
 sketched here.
 
  Dave
 
  [1] http://www.greghendershott.com/fear-of-macros/Syntax_parameters.html
  [2] http://docs.racket-lang.org/reference/stxparam.html
 
  On Jan 23, 2014, at 2:14 PM, Bradley Meck bradley.m...@gmail.com
 wrote:
 
   I was playing around with generators / looking at await for promises
 and notices a very difficult thing revolving around generators not having a
 reference to themselves.
  
   See:
  
   https://gist.github.com/bmeck/72a0f4f448f20cf00f8c
  
   I have to end up wrapping the generator function to get a reference to
 the generator for passing to nested functions.
  
   Is there a reason the execution context is not a generator / there is
 no reference back to the generator during [[call]]?
   ___
   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

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

Re: ES6 timetable and current status

2014-01-27 Thread Allen Wirfs-Brock


On Jan 26, 2014, at 5:19 PM, Maciej Jaros wrote:

 Hi.
 
 I'm trying to figure out what is the current status of ES6 especially that 
 next draft was released. As I understand this is not yet a Candidate Draft 
 this presentation mentions? So my question is - is there some 
 timetable/roadmap for the ES6? Also is it still possible that new things like 
 Symbols and Modules will be dropped or work very differently then in current 
 draft? Or is it just a matter of maturing stuff and any other changes will be 
 pushed to ES7 (like this slides seem to suggest)?
 
 Also what is the status of strawman/harmony pages on ES wiki? They all are 
 proposals for ES6, right? Or can I just assume that all/most things in 
 strawman won't make it to ES6 and will be pushed to ES7? Or should they all 
 be treated as loose notes? I'm just not sure what to follow and to what 
 extent.


I can probably give a better update after this week's TC39 meeting.

The January 22 draft is very close to feature complete WRT public service area. 
There are only a few unresolved issues such as the public naming for %Realm% 
and %Loader%. Most of the semantic specification is in place except that the 
for(;;) and variable instantiation specs still need to be updated. Throughout 
the spec, some details may change over the next few months as the spec. is 
reviewed and implementation experience accumulates.  No major deletions or 
redos are contemplated unless something unexpected turns up.  It this point if 
anything requiring a major redesign would probably get deferred to ES7.

The harmony proposals and old ES6 strawman wiki pages are generally not being 
actively maintained. Look to the ES6 drafts as the definitive source.  Also you 
may want to check open issues on the ES6 spec at bugs.ecmascript.org . The 
current strawman page contains ideas for  post ES6.  However, TC39 has a new 
development process and staged development model we intend to follow for post 
ES6 work.  We will probably rollout new web infrastructure to support it.  Stay 
tuned for more details.

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

Re: detecting JS language mode for tools

2014-01-27 Thread John Lenz

On Sun, Jan 26, 2014 at 9:44 PM, Brendan Eich bren...@mozilla.com wrote:

 David Sheets wrote:

 There is no out-of-band metadata in a new script attribute. Attributes are
   data, not data-about-data, and in-band in HTML.


 The channel is the contents of the script element or the ES resource.
 The attribute is not transmitted in the contents of the script element
 or ES resource. This seems out-of-band from the perspective of the
 programming language you are specifying.


 Same argument applies to a novel media type. It'll get stripped just as
 much as the module attribute, but the latter has the advantage that old
 browsers will ignore just the attribute, while with an unknown type= value
 or version parameter (which we rejected with 1JS), the contents will be
 ignored.

   is it desirable to encourage? Is it worth
   creating a new attribute on the script element for what should be a
   parameter of the media type?

 
 
   Who says modules*should*  be a media type parameter?


 They can be annotated in a lot of ways. If you want to transmit a
 variation in interpretation of a media type, it would seem
 straightforward to do so either:

 1. in the content you are transmitting
 2. in the media type of the content you are transmitting
 3. in a parameter of the media type of the content you are transmitting


 This is all abstract and off target. We know what old browsers do, RFC
 4329 (https://www.ietf.org/rfc/rfc4329.txt) codified it. The concrete
 choice is between new script attribute and new script type or version
 parameter (other parameters than ;version would be ignored by old browsers,
 making them equivalent to a new attribute, but harder to detect).


Is there a reason that feature detection and a new media type or
 media
   type parameter would not suffice?

 
 
   I'm advocating feature detection based on a new attribute, not a new
 media
   type. I thought you were advocating the reverse.


 Is a new attribute to change interpretation behavior feature
 detection? Usually feature detection happens in the language using the
 features...

 I'm advocating introducing the smallest possible number of ways to
 indicate the same bit of information. It seems that there is a demand
 for:

 1. a file extension


 Talk here is not demand, and I bet we'll regret trying to add a new one.
 Extensions mapped by servers to media types require server configury, often
 missed or mangled. This has led in the past to clients hardcoding, e.g.
 text/javascript for missing content type / type= attribute /
 Content-Script-Type header in IE (older versions, not sure about 9 and up).


This is concerning, an new file extension affects build systems, editors,
servers, etc.  This moves use back to something in the source code:

// hey, I'm a module not a script
hey, I'm a module not a script;
?



  2. a media type mechanism


 Also a pain, easy to get lost as metadata, easy to mangle, easy to
 forget. IETF red tape is the least of it, but there's that too.

  3. an HTML attribute


 See my repeated points about fallback in old browsers, this is the way to
 win migration.


  4. in-language feature detection or declaration


 With module bodies in files in NPM and AMD, you don't need to detect
 anything. Clients require provided modules, there's no new suffix or MIME
 type.

 Why should ES6 be different?

 Now, say we add script module.../script support. The ... bits can use
 export, but need not. It could use the module loader API to do its deed,
 detecting that API and falling back on global or other properties in old
 browsers.

 Why shouldn't we support such two-way-compatible inline modules?


  Of these, the HTML attribute seems to be the least flexible and most
 coupled.


 We want most coupled between 3 and 4, because that's what enables two-way
 compatibility.


  Is there a use case for 3 that is not covered by some combination of
 1, 2,  and 4? If 1 is used or encouraged, will you not specify 2? If
 neither 1 nor 2 is specified,


 Do Not Want 1 or 2, as far as I can tell. Both new media type and new
 suffix face stiff adoption hurdles, hamper migration, add more typo and
 forgetfulness habitat, and smell bad. :-P


will you expect each carrier
 specification (HTML, HTTP, file system, etc) to specify their own
 special way to convey this bit of metadata?


 It's implicit in filesystem cases such as NPM today, and that wins.

 If you insist on treating it as meta- (or OOB, better, but same point
 here), please explain how filesystems convey media types today. Suffix
 conventions do not do it on Unixy systems. #! is in-band but not relevant
 to modules. Content sniffing considered harmful.

 HTML is the prize. We aren't going to generalize any useful module body
 here, not global code in- or out-of-band attribute across all containers.
 We don't need to for the out-of-line module case anyway. Only script is
 recognized usefully in browsers old and new. This leaves two-way
 compatibility winning, by

multiple modules with the same name

I didn't find anything in the spec on handling multiple modules with the
same name, or how to handle the redefinition of an existing module. At any
time a script type=module name=existing-nameexport default I just
replaced an exsting module;/script element could be added to the dom,
which would replace an existing module. This could also happen with pure
JavaScript, by calling any of the Loader.prototype.define,
Loader.prototype.import, Loader.prototype.load or Loader.prototype.set
methods. What should happen in such a scenario? Should existing modules be
replaced? Should an error be thrown? How would that work with the DOM?
Should it be a no-op, with no feedback to the user?

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

Re: multiple modules with the same name

2014-01-27 Thread Jason Orendorff

On Mon, Jan 27, 2014 at 1:54 PM, Marius Gundersen gunder...@gmail.com wrote:
 I didn't find anything in the spec on handling multiple modules with the
 same name [...]
 What should happen in such a scenario? Should existing modules be
 replaced? Should an error be thrown? How would that work with the DOM?
 Should it be a no-op, with no feedback to the user?

Before a module is ever exposed to scripts, before its module body
runs, it is first linked. This binds it permanently with the other
modules it imports.

After that, if you call loader.set(name, otherModule), that only
changes the loader's module registry. It affects future module loads.
It does not affect any modules already linked to the original module
that you replaced. It does not affect any functions from that original
module that are already on the stack.

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

Re: Proposal: Generator returning a value should throw SyntaxError

2014-01-27 Thread Adam Ahmed

In light of the recent thread discussing async and await keywords, I
thought it'd be appropriate to raise this point again, understanding it may
be too late to make a change.

As my original post details, the concept of `return` within a generator is
surprising in its difference in behavior from `yield`.

This does not do as 'expected' in a for-in:

function * threeCount() {
  yield 1;
  yield 2;
  return 3;
}

The argument for allowing return values was that usages in the vein of
task.js will use the return value as a real return value and the yields for
scheduling.

If we' re going to have async and await serve the scheduling purpose as
well, can we remove the 'return' foot gun from generators? It sounds like
it's just a stopgap until async-await, and a painful one, IMO. A syntax
error on a generator that returns values would make the scheduling
(async-await) vs iteration (generator) use cases much more clear. It'll be
much easier for new JS devs to understand generators.

Happy to be shutdown again, just thought it was worth reconsidering with
new async-await keywords in play.
On 27/09/2013 3:46 PM, Brandon Benvie bben...@mozilla.com wrote:

 On 9/26/2013 10:40 PM, Brandon Benvie wrote:

 ```js
 function* foo() {
   yield 'what';
   yield 'ever';
   return DONE;
 }

 function* bar() {
   console.log(yield* foo());
 }
 ```


 Err, this logs DONE when you do:

 ```js
 var gen = bar();
 gen.next();
 gen.next();
 gen.next();
 ```
 but you got the idea...
 ___
 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: multiple modules with the same name

On Mon, Jan 27, 2014 at 11:08 PM, Jason Orendorff jason.orendo...@gmail.com
 wrote:

 On Mon, Jan 27, 2014 at 1:54 PM, Marius Gundersen gunder...@gmail.com
 wrote:
  I didn't find anything in the spec on handling multiple modules with the
  same name [...]
  What should happen in such a scenario? Should existing modules be
  replaced? Should an error be thrown? How would that work with the DOM?
  Should it be a no-op, with no feedback to the user?

 Before a module is ever exposed to scripts, before its module body
 runs, it is first linked. This binds it permanently with the other
 modules it imports.

 After that, if you call loader.set(name, otherModule), that only
 changes the loader's module registry. It affects future module loads.
 It does not affect any modules already linked to the original module
 that you replaced. It does not affect any functions from that original
 module that are already on the stack.

 -j


So then there would be two versions of the same module, and a module could
get access to both these modules at the same time. For example, if ModuleB,
which depends on ModuleA is loaded and linked, and later ModuleA is
redefined, then ModuleC could depend on both ModuleB and ModueA, and would
get (indirect) access to two versions of ModuleA. Is this problem
preventable?

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

Re: Proposal: Generator returning a value should throw SyntaxError

Here are several ways to think about return:

- A generator function is like a normal function but it can be paused. The act 
of pausing can send an intermediate value out to the caller (yield's argument) 
and the caller can send an intermediate value back in when resuming (yield's 
result). None of this changes the fact that, like ordinary functions, there are 
still arguments passed into the function and a result passed out. Refusing 
return values just breaks down this generalization.

- A generator function produces an iterator object, which produces a record on 
each iteration that has a .value and a .done flag indicating whether the 
iteration is done. Refusing return values eliminates the .value field in this 
special case, making things less consistent.

Finally, task.js is just an example of building a control abstraction out of 
iterators. It happens that the for-of control flow form is imperative and 
doesn't have a use for a return value. That doesn't mean other control flow 
operations won't.

Dave

On Jan 27, 2014, at 2:18 PM, Adam Ahmed aah...@atlassian.com wrote:

 In light of the recent thread discussing async and await keywords, I thought 
 it'd be appropriate to raise this point again, understanding it may be too 
 late to make a change.
 
 As my original post details, the concept of `return` within a generator is 
 surprising in its difference in behavior from `yield`.
 
 This does not do as 'expected' in a for-in:
 
 function * threeCount() {
   yield 1;
   yield 2;
   return 3;
 }
 
 The argument for allowing return values was that usages in the vein of 
 task.js will use the return value as a real return value and the yields for 
 scheduling.
 
 If we' re going to have async and await serve the scheduling purpose as well, 
 can we remove the 'return' foot gun from generators? It sounds like it's just 
 a stopgap until async-await, and a painful one, IMO. A syntax error on a 
 generator that returns values would make the scheduling (async-await) vs 
 iteration (generator) use cases much more clear. It'll be much easier for new 
 JS devs to understand generators.
 
 Happy to be shutdown again, just thought it was worth reconsidering with new 
 async-await keywords in play.
 
 On 27/09/2013 3:46 PM, Brandon Benvie bben...@mozilla.com wrote:
 On 9/26/2013 10:40 PM, Brandon Benvie wrote:
 ```js
 function* foo() {
   yield 'what';
   yield 'ever';
   return DONE;
 }
 
 function* bar() {
   console.log(yield* foo());
 }
 ```
 
 Err, this logs DONE when you do:
 
 ```js
 var gen = bar();
 gen.next();
 gen.next();
 gen.next();
 ```
 but you got the idea...
 ___
 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

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

Re: multiple modules with the same name

On Jan 27, 2014, at 2:18 PM, Marius Gundersen gunder...@gmail.com wrote:

 So then there would be two versions of the same module, and a module could 
 get access to both these modules at the same time. For example, if ModuleB, 
 which depends on ModuleA is loaded and linked, and later ModuleA is 
 redefined, then ModuleC could depend on both ModuleB and ModueA, and would 
 get (indirect) access to two versions of ModuleA. Is this problem preventable?

It's important to be able to modify module registration for things like 
polyfilling. But that doesn't mean it's something people should do in general. 
Note that Jason only gave you an answer in the context of the basic module 
loader semantics; he didn't say what will happen in the HTML semantics. In 
particular, we can make it an error for there to be two definitions of the same 
module name in the same HTML, a la:

  script type=module name=jquery src=jquery1.js/script
  script type=module name=jquery src=jquery2.js/script

I'm inclined to call that an error, and require imperative modifications of 
existing module registrations to use imperative code.

Dave

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

Re: multiple modules with the same name

What is the use case for allowing registration different modules under the
same name? IMO should be an error.
jjb


On Mon, Jan 27, 2014 at 2:32 PM, David Herman dher...@mozilla.com wrote:

 On Jan 27, 2014, at 2:18 PM, Marius Gundersen gunder...@gmail.com wrote:

  So then there would be two versions of the same module, and a module
 could get access to both these modules at the same time. For example, if
 ModuleB, which depends on ModuleA is loaded and linked, and later ModuleA
 is redefined, then ModuleC could depend on both ModuleB and ModueA, and
 would get (indirect) access to two versions of ModuleA. Is this problem
 preventable?

 It's important to be able to modify module registration for things like
 polyfilling. But that doesn't mean it's something people should do in
 general. Note that Jason only gave you an answer in the context of the
 basic module loader semantics; he didn't say what will happen in the HTML
 semantics. In particular, we can make it an error for there to be two
 definitions of the same module name in the same HTML, a la:

   script type=module name=jquery src=jquery1.js/script
   script type=module name=jquery src=jquery2.js/script

 I'm inclined to call that an error, and require imperative modifications
 of existing module registrations to use imperative code.

 Dave

 ___
 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: Proposal: Generator returning a value should throw SyntaxError


David Herman wrote:

Finally, task.js is just an example of building a control abstraction out of 
iterators. It happens that the for-of control flow form is imperative and 
doesn't have a use for a return value. That doesn't mean other control flow 
operations won't.


+1. The need for an affordance for some use-cases and lack of need for 
others does not undermine the affordance's value.


PEP-380 is worth a read, IMHO, for anyone who values Python's 
experience. You have to grok some history and custom jargon.


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

Re: Reason why generators do not have references to themselves?


Bradley Meck wrote:
Unsure on how new syntax features like await should deal w/ multiple 
operands though, like if await wanted to turn multiple promises into 
an array. Comma operator takes comma separated list out of the equation.


No one proposed this. Do you have a use-case? Task.js and others provide 
combinators such as choose and join, this seems better (compositional, 
no magic/weird reinterpretation of comma).


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

Re: multiple modules with the same name

2014-01-27 Thread Sam Tobin-Hochstadt

This is absolutely necessary for polyfilling.

Imagine that some browser has an ok-but-not-complete implementation of
the X library, but you want to use jQuery 17, which requires a better
version.  You need to be able to replace X with a polyfilled update to
X, and then load jQuery on top of that.

Note that this involves indirect access in the same library (jQuery)
to two versions of X (the polyfill and the browser version), which is
why I don't think Marius's worry is fixable without throwing out the
baby with the bathwater.

Sam

On Mon, Jan 27, 2014 at 5:45 PM, John Barton johnjbar...@google.com wrote:
 What is the use case for allowing registration different modules under the
 same name? IMO should be an error.
 jjb


 On Mon, Jan 27, 2014 at 2:32 PM, David Herman dher...@mozilla.com wrote:

 On Jan 27, 2014, at 2:18 PM, Marius Gundersen gunder...@gmail.com wrote:

  So then there would be two versions of the same module, and a module
  could get access to both these modules at the same time. For example, if
  ModuleB, which depends on ModuleA is loaded and linked, and later ModuleA 
  is
  redefined, then ModuleC could depend on both ModuleB and ModueA, and would
  get (indirect) access to two versions of ModuleA. Is this problem
  preventable?

 It's important to be able to modify module registration for things like
 polyfilling. But that doesn't mean it's something people should do in
 general. Note that Jason only gave you an answer in the context of the basic
 module loader semantics; he didn't say what will happen in the HTML
 semantics. In particular, we can make it an error for there to be two
 definitions of the same module name in the same HTML, a la:

   script type=module name=jquery src=jquery1.js/script
   script type=module name=jquery src=jquery2.js/script

 I'm inclined to call that an error, and require imperative modifications
 of existing module registrations to use imperative code.

 Dave

 ___
 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

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

Re: detecting JS language mode for tools


John Lenz wrote:



1. a file extension


Talk here is not demand, and I bet we'll regret trying to add a
new one. Extensions mapped by servers to media types require
server configury, often missed or mangled. This has led in the
past to clients hardcoding, e.g. text/javascript for missing
content type / type= attribute / Content-Script-Type header in IE
(older versions, not sure about 9 and up).


This is concerning, an new file extension affects build systems, 
editors, servers, etc.  This moves use back to something in the source 
code:


// hey, I'm a module not a script
hey, I'm a module not a script;
?


It's pretty clear from NPM experience that a new suffix is not needed 
for out-of-line modules. Or are you suggesting that Node.js lacks 
tooling? I'm not offended, just trying to understand.


For NPM read AMD/require.js too.

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

Re: detecting JS language mode for tools


Brendan Eich wrote:
OK, sorry I jumped in the middle of things missing some context. In 
fact, I think what we've been planning on proposing is not too far -- 
I think -- from what you're talking about. The plan is *not* a module 
attribute (that was a think-o on my part, and maybe some 
misinformation that crept into this discussion earlier?) but 
type=module. That way on old browsers it's ignored and you can add 
shims to load it. Shims can be made future-proof via feature 
detection, so type=module can obtain new semantics.


The shims word suggests that old-browser-targeted script must 
DOM-scrape the script type=module text and interpret it with Esprima 
or similar. This may not perform well enough compared to an AOT 
compiler, which is another option. Just weighing these. 


And the other thing to weigh is script module, which could work two 
ways with enough care. Module loader API detected and used if present, 
else a named exports object used as fallback.


The performance would be better in pre-ES6 browsers than any scraping 
system, probably better than any AOT-compiled system. The ES6+ browsers 
would see API calls instead of declarative export and import forms, 
which might be slower -- or could perform within epsilon of declarative 
forms (fast engines these days).


We could take our time on this and do it via a CR-level HTML extension, 
which seems to be agreeable whether the attribute is type= or module. We 
wouldn't couple it to ES6 or its status, but we could implement and 
developer-test in nightly/canary rapid-release browsers.


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

Re: detecting JS language mode for tools

On Mon, Jan 27, 2014 at 2:51 PM, Brendan Eich bren...@mozilla.com wrote:

 John Lenz wrote:



 1. a file extension


 Talk here is not demand, and I bet we'll regret trying to add a
 new one. Extensions mapped by servers to media types require
 server configury, often missed or mangled. This has led in the
 past to clients hardcoding, e.g. text/javascript for missing
 content type / type= attribute / Content-Script-Type header in IE
 (older versions, not sure about 9 and up).


 This is concerning, an new file extension affects build systems, editors,
 servers, etc.  This moves use back to something in the source code:

 // hey, I'm a module not a script
 hey, I'm a module not a script;
 ?


 It's pretty clear from NPM experience that a new suffix is not needed for
 out-of-line modules. Or are you suggesting that Node.js lacks tooling? I'm
 not offended, just trying to understand.


What about the node experience helps? They have only one type of input,
modules, ergo only one suffix.



 For NPM read AMD/require.js too.


Ditto.




 /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: multiple modules with the same name

On Mon, Jan 27, 2014 at 2:50 PM, Sam Tobin-Hochstadt
sa...@cs.indiana.eduwrote:

 This is absolutely necessary for polyfilling.

 Imagine that some browser has an ok-but-not-complete implementation of
 the X library, but you want to use jQuery 17, which requires a better
 version.  You need to be able to replace X with a polyfilled update to
 X, and then load jQuery on top of that.

 Note that this involves indirect access in the same library (jQuery)
 to two versions of X (the polyfill and the browser version), which is
 why I don't think Marius's worry is fixable without throwing out the
 baby with the bathwater.


Guy Bedford, based on experiences within the requirejs and commonjs worlds,
has a much better solution for these scenarios. (It's also similar to how
npm works).

Your jQuery should depend upon the name X, but you Loader should map the
name X when loaded by jQuery to the new version in Loader.normalize(). The
table of name mappings can be configured at run time.

For example, if some other code depends on X@1.6 and jQuery needs X@1.7,
they each load exactly the version they need because the normalized module
names embed the version number.

This is the proper solution, not one based on overwriting the module
registry.   To be sure, because of the overhead loading code on slow
networks these kinds of multi-version scenarios are less attractive in the
browser, but the fix is the adapt the code.

Guy's project has a bit more: https://github.com/guybedford/systemjs

jjb



 Sam

 On Mon, Jan 27, 2014 at 5:45 PM, John Barton johnjbar...@google.com
 wrote:
  What is the use case for allowing registration different modules under
 the
  same name? IMO should be an error.
  jjb
 
 
  On Mon, Jan 27, 2014 at 2:32 PM, David Herman dher...@mozilla.com
 wrote:
 
  On Jan 27, 2014, at 2:18 PM, Marius Gundersen gunder...@gmail.com
 wrote:
 
   So then there would be two versions of the same module, and a module
   could get access to both these modules at the same time. For example,
 if
   ModuleB, which depends on ModuleA is loaded and linked, and later
 ModuleA is
   redefined, then ModuleC could depend on both ModuleB and ModueA, and
 would
   get (indirect) access to two versions of ModuleA. Is this problem
   preventable?
 
  It's important to be able to modify module registration for things like
  polyfilling. But that doesn't mean it's something people should do in
  general. Note that Jason only gave you an answer in the context of the
 basic
  module loader semantics; he didn't say what will happen in the HTML
  semantics. In particular, we can make it an error for there to be two
  definitions of the same module name in the same HTML, a la:
 
script type=module name=jquery src=jquery1.js/script
script type=module name=jquery src=jquery2.js/script
 
  I'm inclined to call that an error, and require imperative modifications
  of existing module registrations to use imperative code.
 
  Dave
 
  ___
  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


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

Re: multiple modules with the same name

On Jan 28, 2014 12:14 AM, John Barton johnjbar...@google.com wrote:




 On Mon, Jan 27, 2014 at 2:50 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
wrote:

 This is absolutely necessary for polyfilling.

 Imagine that some browser has an ok-but-not-complete implementation of
 the X library, but you want to use jQuery 17, which requires a better
 version.  You need to be able to replace X with a polyfilled update to
 X, and then load jQuery on top of that.

 Note that this involves indirect access in the same library (jQuery)
 to two versions of X (the polyfill and the browser version), which is
 why I don't think Marius's worry is fixable without throwing out the
 baby with the bathwater.


 Guy Bedford, based on experiences within the requirejs and commonjs
worlds, has a much better solution for these scenarios. (It's also similar
to how npm works).

 Your jQuery should depend upon the name X, but you Loader should map the
name X when loaded by jQuery to the new version in Loader.normalize(). The
table of name mappings can be configured at run time.

 For example, if some other code depends on X@1.6 and jQuery needs X@1.7,
they each load exactly the version they need because the normalized module
names embed the version number.

This seems to handle the scenario where two versions is wanted. This would
probably also work in the scenario where a unique instance of the same
version should be given to every module depending on it. This would be
useful for unit tests, where a clean world is required for each tests. Or
for unit test maybe a new realm should be used for each test.

If a module is redefined with imperative code then an error should probably
be thrown, or the promise could be rejected. But I don't think that would
be good for DOM manipulation. If innerHTML is used to add a lot of markup
and an existing module to the DOM, should an error be thrown? Should none
of the other markup be added to the DOM? What would the error message look
like to adequately indicate the source of the error?

Marius Gundersen


 This is the proper solution, not one based on overwriting the module
registry.   To be sure, because of the overhead loading code on slow
networks these kinds of multi-version scenarios are less attractive in the
browser, but the fix is the adapt the code.

 Guy's project has a bit more: https://github.com/guybedford/systemjs

 jjb



 Sam

 On Mon, Jan 27, 2014 at 5:45 PM, John Barton johnjbar...@google.com
wrote:
  What is the use case for allowing registration different modules under
the
  same name? IMO should be an error.
  jjb
 
 
  On Mon, Jan 27, 2014 at 2:32 PM, David Herman dher...@mozilla.com
wrote:
 
  On Jan 27, 2014, at 2:18 PM, Marius Gundersen gunder...@gmail.com
wrote:
 
   So then there would be two versions of the same module, and a module
   could get access to both these modules at the same time. For
example, if
   ModuleB, which depends on ModuleA is loaded and linked, and later
ModuleA is
   redefined, then ModuleC could depend on both ModuleB and ModueA,
and would
   get (indirect) access to two versions of ModuleA. Is this problem
   preventable?
 
  It's important to be able to modify module registration for things
like
  polyfilling. But that doesn't mean it's something people should do in
  general. Note that Jason only gave you an answer in the context of
the basic
  module loader semantics; he didn't say what will happen in the HTML
  semantics. In particular, we can make it an error for there to be two
  definitions of the same module name in the same HTML, a la:
 
script type=module name=jquery src=jquery1.js/script
script type=module name=jquery src=jquery2.js/script
 
  I'm inclined to call that an error, and require imperative
modifications
  of existing module registrations to use imperative code.
 
  Dave
 
  ___
  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


 ___
 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: multiple modules with the same name

On Mon, Jan 27, 2014 at 3:24 PM, Marius Gundersen gunder...@gmail.comwrote:


 On Jan 28, 2014 12:14 AM, John Barton johnjbar...@google.com wrote:
 
 
 
 
  On Mon, Jan 27, 2014 at 2:50 PM, Sam Tobin-Hochstadt 
 sa...@cs.indiana.edu wrote:
 
  This is absolutely necessary for polyfilling.
 
  Imagine that some browser has an ok-but-not-complete implementation of
  the X library, but you want to use jQuery 17, which requires a better
  version.  You need to be able to replace X with a polyfilled update to
  X, and then load jQuery on top of that.
 
  Note that this involves indirect access in the same library (jQuery)
  to two versions of X (the polyfill and the browser version), which is
  why I don't think Marius's worry is fixable without throwing out the
  baby with the bathwater.
 
 
  Guy Bedford, based on experiences within the requirejs and commonjs
 worlds, has a much better solution for these scenarios. (It's also similar
 to how npm works).
 
  Your jQuery should depend upon the name X, but you Loader should map the
 name X when loaded by jQuery to the new version in Loader.normalize(). The
 table of name mappings can be configured at run time.
 
  For example, if some other code depends on X@1.6 and jQuery needs X@1.7,
 they each load exactly the version they need because the normalized module
 names embed the version number.

 This seems to handle the scenario where two versions is wanted. This would
 probably also work in the scenario where a unique instance of the same
 version should be given to every module depending on it. This would be
 useful for unit tests, where a clean world is required for each tests. Or
 for unit test maybe a new realm should be used for each test.

 If a module is redefined with imperative code then an error should
 probably be thrown, or the promise could be rejected.



 But I don't think that would be good for DOM manipulation. If innerHTML is
 used to add a lot of markup and an existing module to the DOM, should an
 error be thrown?

In my opinion, attempting to overwrite a Loader's module entry would cause
an error yes.


 Should none of the other markup be added to the DOM?

Whatever DOM does is DOM's business.


 What would the error message look like to adequately indicate the source
 of the error?

`The module name ${moduleName} has already been defined.`

I don't suggest we try to issue an error message special to this
circumstance, such as Adding a module via innerHTML is craziness.  We'll
just let folks work that part out themselves.

jjb


  Marius Gundersen

 
  This is the proper solution, not one based on overwriting the module
 registry.   To be sure, because of the overhead loading code on slow
 networks these kinds of multi-version scenarios are less attractive in the
 browser, but the fix is the adapt the code.
 
  Guy's project has a bit more: https://github.com/guybedford/systemjs
 
  jjb
 
 
 
  Sam
 
  On Mon, Jan 27, 2014 at 5:45 PM, John Barton johnjbar...@google.com
 wrote:
   What is the use case for allowing registration different modules
 under the
   same name? IMO should be an error.
   jjb
  
  
   On Mon, Jan 27, 2014 at 2:32 PM, David Herman dher...@mozilla.com
 wrote:
  
   On Jan 27, 2014, at 2:18 PM, Marius Gundersen gunder...@gmail.com
 wrote:
  
So then there would be two versions of the same module, and a
 module
could get access to both these modules at the same time. For
 example, if
ModuleB, which depends on ModuleA is loaded and linked, and later
 ModuleA is
redefined, then ModuleC could depend on both ModuleB and ModueA,
 and would
get (indirect) access to two versions of ModuleA. Is this problem
preventable?
  
   It's important to be able to modify module registration for things
 like
   polyfilling. But that doesn't mean it's something people should do in
   general. Note that Jason only gave you an answer in the context of
 the basic
   module loader semantics; he didn't say what will happen in the HTML
   semantics. In particular, we can make it an error for there to be two
   definitions of the same module name in the same HTML, a la:
  
 script type=module name=jquery src=jquery1.js/script
 script type=module name=jquery src=jquery2.js/script
  
   I'm inclined to call that an error, and require imperative
 modifications
   of existing module registrations to use imperative code.
  
   Dave
  
   ___
   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
 
 
  ___
  es-discuss mailing list
  es-discuss@mozilla.org
  https://mail.mozilla.org/listinfo/es-discuss
 

___
es-discuss mailing list
es-discuss@mozilla.org

Re: detecting JS language mode for tools


John Barton wrote:



It's pretty clear from NPM experience that a new suffix is not
needed for out-of-line modules. Or are you suggesting that Node.js
lacks tooling? I'm not offended, just trying to understand.


What about the node experience helps? They have only one type of 
input, modules, ergo only one suffix.


No, their non-module main programs are in files with names ending in .js.


For NPM read AMD/require.js too.


Ditto.


No, script src=foo.js interops with AMD/require.js and the .js suffix 
is used everywhere.


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

Re: multiple modules with the same name

2014-01-27 Thread James Burke

On Mon, Jan 27, 2014 at 3:14 PM, John Barton johnjbar...@google.com wrote:
 On Mon, Jan 27, 2014 at 2:50 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
 wrote:
 Imagine that some browser has an ok-but-not-complete implementation of
 the X library, but you want to use jQuery 17, which requires a better
 version.  You need to be able to replace X with a polyfilled update to
 X, and then load jQuery on top of that.

 Note that this involves indirect access in the same library (jQuery)
 to two versions of X (the polyfill and the browser version), which is
 why I don't think Marius's worry is fixable without throwing out the
 baby with the bathwater.


 Guy Bedford, based on experiences within the requirejs and commonjs worlds,
 has a much better solution for these scenarios. (It's also similar to how
 npm works).

 Your jQuery should depend upon the name X, but you Loader should map the
 name X when loaded by jQuery to the new version in Loader.normalize(). The
 table of name mappings can be configured at run time.

 For example, if some other code depends on X@1.6 and jQuery needs X@1.7,
 they each load exactly the version they need because the normalized module
 names embed the version number.

In the AMD world, map config has been sufficient for these needs[1].

As a point of reference, requirejs only lets the first module
registration win, any subsequent registrations for the same module ID
are ignored. “ignore was chosen over “error because with multiple
module bundles, the same module ID/definition could show up in two
different bundles (think multi-page apps that have a “common” and
page-specific bundles).

I do not believe that case should trigger an error. It is just
inefficient, and tooling for bundles could offer to enforce finding
these inefficiencies vs the browser stopping the app from working by
throwing an error.

It is true that the errors introduced by “ignore” could be harder to
detect given that things may mostly work. The general guide in this
case for requirejs was to be flexible in the same spirit of HTML
parsing.

Redefinition seems to allow breaking the expectation that the module
value for a given normalized ID is always the same.

When the developer wants to explicitly orchestrate different module
values for specific module ID sets, something like AMD’s map config is
a good solution as it is a more declarative statement of intent vs
code in a module body deciding to redefine.

Also, code in module bodies do not have enough information to properly
redefine for a set of module IDs like map config can. Map config has
been really useful for supporting two different versions of a module
in an app, and for providing mocks to certain modules for unit
testing.

Given what has been said so far for use cases, I would prefer either
“ignore” or “error” over redefinition, with a preference of “ignore”
over “error based on the above.

[1] https://github.com/amdjs/amdjs-api/wiki/Common-Config#wiki-map

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

Re: Reason why generators do not have references to themselves?

2014-01-27 Thread Bradley Meck

This is more just a comment / thinking out loud about syntax. Not related
to a specific use case. The following is just what was starting to bring my
thoughts around to that though.

I am starting to build things with the constructs in this thread, so
building out things in a similar manner to Promise.[race|all] . Even with
the built ins, some things would just be interesting to have on hand:

I went the same route and made a:
mapPromises(Map?,Promise?)={rejections:Map?,?,resolutions:Map?:?},
while working out some example problems / speccing out a User lobby system.

I was trying to also figure out a way to dynamically add / remove Promises
while waiting on full resolution. Promises.all is useful, but when working
out people joining / removing themselves in a voting system it is a bit
tough. Ended up making my own function / plumbing for that:
mapDynamicallSpecifiedPromises =
{promise:PromiseMap?:?,setMappings(Map?,Promise?)}. This is
probably too much for stdlib though. Being able to dynamically change the
mappings makes for a much easier time if you have a constantly changing
list of users in a room for example.


On Mon, Jan 27, 2014 at 4:49 PM, Brendan Eich bren...@mozilla.com wrote:

 Bradley Meck wrote:

 Unsure on how new syntax features like await should deal w/ multiple
 operands though, like if await wanted to turn multiple promises into an
 array. Comma operator takes comma separated list out of the equation.


 No one proposed this. Do you have a use-case? Task.js and others provide
 combinators such as choose and join, this seems better (compositional, no
 magic/weird reinterpretation of comma).

 /be

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

Re: detecting JS language mode for tools

On Mon, Jan 27, 2014 at 4:57 PM, Brendan Eich bren...@mozilla.com wrote:

 John Barton wrote:



 It's pretty clear from NPM experience that a new suffix is not
 needed for out-of-line modules. Or are you suggesting that Node.js
 lacks tooling? I'm not offended, just trying to understand.


 What about the node experience helps? They have only one type of input,
 modules, ergo only one suffix.


 No, their non-module main programs are in files with names ending in .js.


Their non-module main programs don't fail if you issue require().




  For NPM read AMD/require.js too.


 Ditto.


 No, script src=foo.js interops with AMD/require.js and the .js suffix is
 used everywhere.


Because it is js everywhere. Pick any file in an AMD/require.js system and
you can parse it.

I think you are on the right track here: 1JS needs only one file suffix.
 If we have two languages, we need to suffixes.

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

Re: detecting JS language mode for tools


John Barton wrote:
On Mon, Jan 27, 2014 at 4:57 PM, Brendan Eich bren...@mozilla.com 
mailto:bren...@mozilla.com wrote:


John Barton wrote:



It's pretty clear from NPM experience that a new suffix is not
needed for out-of-line modules. Or are you suggesting that
Node.js
lacks tooling? I'm not offended, just trying to understand.


What about the node experience helps? They have only one type
of input, modules, ergo only one suffix.


No, their non-module main programs are in files with names ending
in .js.


Their non-module main programs don't fail if you issue require().


Nor do browserify'ed or properly-written require.js client main scripts.




For NPM read AMD/require.js too.


Ditto.


No, script src=foo.js interops with AMD/require.js and the .js
suffix is used everywhere.


Because it is js everywhere. Pick any file in an AMD/require.js system 
and you can parse it.


ES6 cannot support require as a function that synchronously loads from 
the filesystem, and I think you know this.


I think you are on the right track here: 1JS needs only one file 
suffix.  If we have two languages, we need to suffixes.


You do not have two languages, though. Two entry points to the grammar 
of the one language does not make two languages. HTML event handlers 
are FunctionBodies. I think you have no argument.


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

Re: multiple modules with the same name

2014-01-27 Thread Maciej Jaros


Sam Tobin-Hochstadt (2014-01-27 23:50):

This is absolutely necessary for polyfilling.

Imagine that some browser has an ok-but-not-complete implementation of
the X library, but you want to use jQuery 17, which requires a better
version.  You need to be able to replace X with a polyfilled update to
X, and then load jQuery on top of that.

Note that this involves indirect access in the same library (jQuery)
to two versions of X (the polyfill and the browser version), which is
why I don't think Marius's worry is fixable without throwing out the
baby with the bathwater.


Keeping your syntax you could declare:
script type=module name=jquery_1_17 src=jquery1.js/script
script type=module name=jquery_2_1 src=jquery2.js/script

Then the script that need 1.17 uses import:
import $ from jquery_1_17;
And script that need 2.1:
import $ from jquery_2_1;

But to my understanding a loader could be created that could 
automatically resolve something like (i.e. per some convention it would 
now where to find best CDN for each jQuery version):

import $ from cdn.jquery/2.1;

Or just a full URL:
import $ from http://code.jquery.com/jquery-2.1.0.min.js;

I actually like that syntax much more then declaring stuff in HTML. Not 
sure if that will be possible though.



Sam

On Mon, Jan 27, 2014 at 5:45 PM, John Barton johnjbar...@google.com wrote:

What is the use case for allowing registration different modules under the
same name? IMO should be an error.
jjb


On Mon, Jan 27, 2014 at 2:32 PM, David Herman dher...@mozilla.com wrote:

On Jan 27, 2014, at 2:18 PM, Marius Gundersen gunder...@gmail.com wrote:


So then there would be two versions of the same module, and a module
could get access to both these modules at the same time. For example, if
ModuleB, which depends on ModuleA is loaded and linked, and later ModuleA is
redefined, then ModuleC could depend on both ModuleB and ModueA, and would
get (indirect) access to two versions of ModuleA. Is this problem
preventable?

It's important to be able to modify module registration for things like
polyfilling. But that doesn't mean it's something people should do in
general. Note that Jason only gave you an answer in the context of the basic
module loader semantics; he didn't say what will happen in the HTML
semantics. In particular, we can make it an error for there to be two
definitions of the same module name in the same HTML, a la:

   script type=module name=jquery src=jquery1.js/script
   script type=module name=jquery src=jquery2.js/script

I'm inclined to call that an error, and require imperative modifications
of existing module registrations to use imperative code.

Dave

___
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


___
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: detecting JS language mode for tools

On Sat, Jan 25, 2014 at 3:31 PM, Brendan Eich bren...@mozilla.com wrote:

 John Barton wrote:

 The Script goal disallows 'import' and 'export' specifically to ensure
 that the Script goal is inconvenient for developers and thus they are
 encouraged to shift to the Module goal.


 No, that's not the rationale. The reason is to avoid enabling more
 synchronous script src=-style jank. We have enough of that already with
 the existing attractive nuisance (script src= w/o async), per Steve Souders.

 /be


Why can't script type='module' mean If we see import/export/module
statements then we will will not evaluate the body synchronously.? That
way we avoid the jank with new code just as we do with two parsing goals
and yet we don't need two parsing goals.

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

Re: ES6 timetable and current status


Allen Wirfs-Brock wrote:
The harmony proposals and old ES6 strawman wiki pages are generally 
not being actively maintained.


Any already in ES6 should be prefaced by a pointer to the spec draft. 
rwaldron helps with this, it is a duty we share as wiki curators, and 
it's easy to edit. Copy from existing such retired pages, e.g.,


http://wiki.ecmascript.org/doku.php?id=harmony:iterators

As for strawman, those are maintained for ES7 where not already in 
harmony (namely http://wiki.ecmascript.org/doku.php?id=harmony:observe).



Look to the ES6 drafts as the definitive source.


For ES6. For ES7, look at non-ES6 harmony and strawman, and we owe you 
edits to clarify things.


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

Re: detecting JS language mode for tools

2014-01-27 Thread Kevin Smith



 Because it is js everywhere. Pick any file in an AMD/require.js system
 and you can parse it.


 ES6 cannot support require as a function that synchronously loads from the
 filesystem, and I think you know this.


Without a new extension, you cannot import from an old-style module in
the browser or the server.  One must know a priori how to parse the file
before one parses the file.  Old-style modules cannot (in general) be
parsed as ES6 modules, and ES6 modules (in general) cannot be parsed as
old-style modules.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: detecting JS language mode for tools


Kevin Smith wrote:



Because it is js everywhere. Pick any file in an
AMD/require.js system and you can parse it.


ES6 cannot support require as a function that synchronously loads
from the filesystem, and I think you know this.


Without a new extension, you cannot import from an old-style module 
in the browser or the server.  One must know a priori how to parse the 
file before one parses the file.  Old-style modules cannot (in 
general) be parsed as ES6 modules, and ES6 modules (in general) cannot 
be parsed as old-style modules.


Yes, so?

My argument was that Node.js has both non-module and module files with a 
common suffix, .js.


You are mixing compatibility with consistency arguments.

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

Re: detecting JS language mode for tools


John Barton wrote:
Why can't script type='module' mean If we see import/export/module 
statements then we will will not evaluate the body synchronously.? 
That way we avoid the jank with new code just as we do with two 
parsing goals and yet we don't need two parsing goals.


We could do this, but then refactoring from no-exports to exports, or 
no-imports to imports, changes order of execution. Surprising, 
undesirable without good reason (having one entry point to the grammar, 
or two instead of three if you count HTML event handlers, is not a good 
reason).


Note also that type=module does not fly, the type attribute wants a 
media type value.


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

Re: detecting JS language mode for tools

2014-01-27 Thread Erik Arvidsson

All browsers support non media types. Can we change the specs to match
reality

On Monday, January 27, 2014 10:24:49 PM, Brendan Eich bren...@mozilla.com
wrote:

 John Barton wrote:
  Why can't script type='module' mean If we see import/export/module
  statements then we will will not evaluate the body synchronously.?
  That way we avoid the jank with new code just as we do with two
  parsing goals and yet we don't need two parsing goals.

 We could do this, but then refactoring from no-exports to exports, or
 no-imports to imports, changes order of execution. Surprising,
 undesirable without good reason (having one entry point to the grammar,
 or two instead of three if you count HTML event handlers, is not a good
 reason).

 Note also that type=module does not fly, the type attribute wants a
 media type value.

 /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: detecting JS language mode for tools

2014-01-27 Thread Kevin Smith



 My argument was that Node.js has both non-module and module files with a
 common suffix, .js.


Yes - but Node-modules and non-modules can be parsed the same way, so a
common extension makes sense.  But when a file needs to be parsed a
different way in Node, how's that's done?  By registered file extensions,
of course.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: detecting JS language mode for tools

On Jan 27, 2014, at 8:35 PM, Erik Arvidsson erik.arvids...@gmail.com wrote:
 
 All browsers support non media types. Can we change the specs to match reality

Examples? What is the specified grammar?

I hope you aren't thinking of language= here.

How about fallback for old browsers?

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

RE: detecting JS language mode for tools

2014-01-27 Thread Domenic Denicola

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan 
Eich

 Examples? What is the specified grammar?

From [the HTML spec][1]:

 The `type` attribute gives the language of the script or format of the data. 
 If the attribute is present, its value must be a [valid MIME type][2]. The 
 `charset` parameter must not be specified. The default, which is used if the 
 attribute is absent, is `text/javascript`.

Then there's a bunch of other text regarding how the `type` attribute 
translates into MIME types and how mime types end up translating to supported 
scripting languages, ending up at [3].

---

My understanding of what's been specified here, codified from legacy, is that 
browsers (since the dawn of time) always interpreted either missing `type` 
attribute or text/javascript as instructions to execute JavaScript code, and 
most other things as inert and ignored.

There's a bit of a gray area involving all the other aliases for 
text/javascript, e.g. some older browsers probably don't support 
text/livescript, while others probably don't support text/jscript.

The upside is that, as Arv says, you can put any string you want in there, and 
browsers will cope just fine by ignoring it unless it's one of the specific 
types that maps to JavaScript per [3]. The spec has authoring conformance 
criteria that it must be a MIME type. But the actual codified behavior is 
closer to if it's in this list of strings, or absent, you get JavaScript; 
otherwise it gets ignored, unless the browser wants to implement 
VBScript/Dart/etc. using some other magic string.

[1]: 
http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#the-script-element
[2]: 
http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#valid-mime-type
[3]: 
http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#support-the-scripting-language

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

Re: detecting JS language mode for tools


Domenic Denicola wrote:

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan 
Eich


  Examples? What is the specified grammar?


 From [the HTML spec][1]:


  The `type` attribute gives the language of the script or format of the data. If the 
attribute is present, its value must be a [valid MIME type][2]. The `charset` parameter must 
not be specified. The default, which is used if the attribute is absent, is 
`text/javascript`.


Then there's a bunch of other text regarding how the `type` attribute translates into 
MIME types and how mime types end up translating to supported scripting 
languages, ending up at [3].

---

My understanding of what's been specified here, codified from legacy, is that browsers 
(since the dawn of time) always interpreted either missing `type` attribute or 
text/javascript as instructions to execute JavaScript code, and most other 
things as inert and ignored.


Right, that doesn't mean the type can be any old string and have new 
meaning, though. More the reverse.



There's a bit of a gray area involving all the other aliases for 
text/javascript, e.g. some older browsers probably don't support text/livescript, while 
others probably don't support text/jscript.


Those are long dead. RFC 4329 defines properly registered IANA media 
types, application/javascript and application/ecmascript. The 
text/javascript misnomer was created without being registered by Dave 
Raggett for HTML4. It is shorter than application/javascript, so hard to 
kill now. But at least it's a media type.



The upside is that, as Arv says, you can put any string you want in there, and 
browsers will cope just fine by ignoring it unless it's one of the specific 
types that maps to JavaScript per [3].


Yes, this is part of the fail-soft nature of HTML. But it does not mean 
the HTML grammar allows anything for specified cases -- in fact for 
those as you say, it requires an IANA media type. Old content on the web 
could today use module and count on content being ignored (not that I 
know of any, or think this is likely).


Defining new types should follow the rules, not just extend the domain 
of type to random strings we think we can get away with.


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

Re: detecting JS language mode for tools

2014-01-27 Thread John Lenz

There  are three issues in my mind for tooling:
1) should the code be parsed as use strict
2) are import and export and module statements valid
3) should top level declarations be considered visible outside the file (no
can be inferred from the presence of import or exports)

It is my guess that it will be a common beginner mistake to load modules as
scripts or try to use import from scripts.  The first is the primary one
as keywords etc are different.


On Mon, Jan 27, 2014 at 8:43 PM, Kevin Smith zenpars...@gmail.com wrote:


 My argument was that Node.js has both non-module and module files with a
 common suffix, .js.


 Yes - but Node-modules and non-modules can be parsed the same way, so a
 common extension makes sense.  But when a file needs to be parsed a
 different way in Node, how's that's done?  By registered file extensions,
 of course.


 ___
 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: multiple modules with the same name