<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Times New Roman" size="3"><span style="font-size:12pt;">
<div> </div>
<div style="padding-left:36pt;">Well, I think I understand what you're getting at: there's a sense in which generators don't add the ability to do something that's *absolutely impossible* to express in ES5.</div>
<div style="padding-left:36pt;"> </div>
<div style="padding-left:36pt;">OTOH, generators make it possible to express something that otherwise -- in general -- requires a deep translation (in particular, a CPS transformation of the entire function). This is more than syntactic sugar. This is a new
expressiveness that wasn't there before. The slope between Felleisen-expressiveness ("is it possible to do X without a deep transformation?") and Turing-expressiveness ("is it possible to do X at all?") is a slippery one.</div>
<div style="padding-left:36pt;"> </div>
<div style="padding-left:36pt;">I don't want to quibble about philosophical pedantry, but that's really all I mean by my shyness about General Principles. They're strictly *harder* to decide on than the problem at hand. It's too easy to lose focus and waste
time arguing abstractions. And then even when we agree on general principles, when we get into concrete situations it's too easy to start quibbling about exactly how to interpret and apply the principles for the problem at hand.</div>
<div style="padding-left:36pt;"> </div>
<div style="padding-left:36pt;">I prefer to work out from the middle of the maze, learning and refining principles as I go, rather than trying to decide on them all up front.</div>
<div><font color="#1F497D"> </font></div>
<div><font face="Calibri" size="2" color="#1F497D"><span style="font-size:11pt;">Agreed.  The principle itself is not really the primary point.  But I do think there is a fairly crisp line that can be drawn at the level of “any observable behaviour of an object
that can be created with extended code can also be provided by an object created without using extended code”.   Ultimately though, the goal is just to provide the most value to the most users.</span></font></div>
<div><font color="#1F497D"> </font></div>
<div> </div>
<div style="padding-left:36pt;"> </div>
<div style="padding-left:36pt;">But it should not be necessary to have a callbacky version for builtin modules like "@name" -- the API should include a simple, synchronous way to test for the presence of modules in a loader. So it should be possible to do something
like SystemLoader.getLoaded("@name").</div>
<div> </div>
<div><font face="Calibri" size="2" color="#1F497D"><span style="font-size:11pt;">That’s good to hear.  I do hope we can ultimately make this API even simpler – both for convenient feature-detection and for authoring modular code in normal syntax.  “require(‘@name’)”
is a pleasantly simple primitive for modularity – while it may not be possible to be quite so terse in the ES.next API, I hope we can move in that direction.</span></font></div>
<div><font color="#1F497D"> </font></div>
<div><font face="Calibri" size="2" color="#1F497D"><span style="font-size:11pt;">(1) why is a child loader needed?</span></font></div>
<div> </div>
<div style="padding-left:36pt;">Not needed, just the point of the example. Let me make the example more concrete:</div>
<div style="padding-left:36pt;"> </div>
<div style="padding-left:36pt;">You're writing an online code editor like CodeMirror or ACE, and you want to support the programmer running JS code from within the editor. So you want to run that code in a sandbox, so that it doesn't see the data structures
that are implementing the IDE itself. So you create a child loader. Now, within that child loader, you might want the ability to construct some initial modules that make up the initial global environment that the user's code is running in. So you use buildModule
to dynamically construct those modules.</div>
<div><br>

</div>
<div style="padding-left:36pt;"><font face="Calibri" size="2" color="#1F497D"><span style="font-size:11pt;">(2) any particular reason why the buildModule and registerModule are separated?</span></font></div>
<div style="padding-left:36pt;"> </div>
<div style="padding-left:36pt;">Because you might want to build a single shared module instance that you register in multiple loaders. These are orthogonal primitives that can be composed. It may also make sense to have conveniences for common operations, layered
on top of the primitives.</div>
<div> </div>
<div><font face="Calibri" size="2" color="#1F497D"><span style="font-size:11pt;">This use case makes sense.  Though generally the use of child loaders does feel like a <10% case for modules.  I’ll be interested in discussing the conveniences for common operations
here, once there are more details on the primitives to provide feedback on.<br>

<br>

</span></font></div>
<div style="padding-left:36pt;"><font face="Calibri" size="2" color="#1F497D"><span style="font-size:11pt;">(3) Would this allow declaring module dependencies for the new module?  As one comparison, the require.js module definition syntax is simpler in terms
of APIs, but also requires an extra closure due to module dependencies, which may also be needed in the model above:</span></font></div>
<div style="padding-left:36pt;"><font face="Calibri" size="2" color="#1F497D"><span style="font-size:11pt;"> </span></font></div>
<div style="padding-left:36pt;"><font face="Calibri" size="2" color="#1F497D"><span style="font-size:11pt;">    define("m", [], function() {</span></font></div>
<div style="padding-left:36pt;"><font face="Calibri" size="2" color="#1F497D"><span style="font-size:11pt;">        return {</span></font></div>
<div style="padding-left:36pt;"><font face="Calibri" size="2" color="#1F497D"><span style="font-size:11pt;">            x: 42,</span></font></div>
<div style="padding-left:36pt;"><font face="Calibri" size="2" color="#1F497D"><span style="font-size:11pt;">            f: function() { …  }</span></font></div>
<div style="padding-left:36pt;"><font face="Calibri" size="2" color="#1F497D"><span style="font-size:11pt;">        }</span></font></div>
<div style="padding-left:36pt;"><font face="Calibri" size="2" color="#1F497D"><span style="font-size:11pt;">    });</span></font></div>
<div style="padding-left:36pt;"> </div>
<div style="padding-left:36pt;">I think the more straightforward approach is just to pre-load (and pre-register in the loader, if appropriate) whatever dependencies are needed.</div>
<div> </div>
<div><font face="Calibri" size="2" color="#1F497D"><span style="font-size:11pt;">I’m not sure I follow what this would look like.  Why would I need a new loader at all in this case?  I  think I just need to see some more examples to grok how this API is intended
to be used.</span></font></div>
<div><font color="#1F497D"> </font></div>
<div><font face="Calibri" size="2" color="#1F497D"><span style="font-size:11pt;">Luke</span></font></div>
<div> </div>
</span></font>
</body>
</html>