Minor questions on new module BNF

Jeff Morrison lbljeffmo at gmail.com
Tue Jun 4 09:37:29 PDT 2013

I still kinda like the idea of allowing ImportDeclarations to be 
expressed anywhere inside a ScriptElement (including in its children), 
and then hoisting the declaration for compilation/linking, but only 
executing the dependency when the statement is reached at runtime. It is 
then a parse error if an ImportDeclaration is outside of a ScriptElement 

The System.get() paradigm is kind of awkward and indistinguishable from 
the import syntax in terms of its expressive relation.
If its all we can get, so be it -- but it feels pretty unpolished.


On 6/4/13 8:11 AM, Jason Orendorff wrote:
> On Mon, Jun 3, 2013 at 11:33 AM, Yehuda Katz <wycats at gmail.com 
> <mailto:wycats at gmail.com>> wrote:
>     I've advocated for this in the past. I believe it should be allowed.
>     Separately, I would like this form to be specified as deferring
>     execution until bindings are explicitly imported (from another
>     module), or a synchronous `System.get` call is made.
> It makes the static import language a bit more expressive, but why is 
> it necessary?
> For performance? The alternative, if a module has expensive 
> initialization, would be to have it initialize itself more lazily.
>     This would make it possible to guarantee that a synchronous
>     `System.get` will succeed, without being forced to execute the
>     module first.
> It would definitely make that possible, but what `System.get()` use 
> case are you looking to support? To my mind `System.get()` is like 
> examining `$LOADED_FEATURES` in Ruby or `sys.modules` in Python; those 
> use cases exist, but the kind of code you're writing when you touch 
> those is typically either an egregious hack or it's generic across all 
> modules, right? They don't need or merit syntactic support.
> I want to understand the motivation, because Domenic asked for syntax 
> that just loads and runs a module, without bindings. It seems like we 
> could support that feature with a tweak of the grammar, but you're 
> proposing taking that exact syntax and using it for something else. I 
> expect people trying to load and run a module will greatly outnumber 
> people trying to load and *not* run a module.  Wouldn't we be 
> astonishing more people by doing it your way?
> -j
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130604/ffe66f00/attachment.html>

More information about the es-discuss mailing list