Spawn proposal strawman

[kevin curtis]

JsonML looks good for for an AST handling:

["||",
   ["||",
     ["Id", "X"],
     ["Id", "Y"]],
   ["Id", "Z"]]

Maybe the 'canonical' AST serialized string format could actually be
more scheme-y:

(or (or X Y) Z)

JsonML could be used for building pure js in-memory AST graphs which
could then be easily stringified to the 'canonical' format.

The benefit is that a scheme-y format could help the thinking on the
semantics for es6/harmony.
(Downside compared to a JSON  canonical format is that with JSON the
parsing/stringifying is free via the JSON api in es5).

For convenience JSON could remain JSON in this scheme-y format:
var x = [1,4,5]
becomes:
(var x [1,4,5])

On Mon, May 11, 2009 at 5:26 PM, Brendan Eich <brendan at mozilla.com> wrote:
> (Targeted replies below, too much to digest in one pass. :-P)
>
> On May 8, 2009, at 8:49 PM, Kris Kowal wrote:
>
>> "(function (require, exports) {" + text + "/**/\n}"
>
> Nit-picking a bit on names: require : provide :: import : export -- so
> mixing require and export mixes metaphors. Never stopped me ;-).
>
>
>> This doesn't enforce the "program" construction, and some of the
>> JavaScript language semantics suffer for it.  For example, function
>> statements aren't defined and do not necessarily get bound to the
>> module scope in some implementations.
>
> What makes functions eval'ed hermetically by the module function occur in a
> statement context? They should be nested function declarations, not
> (sub-)statements. Or I'm missing something.
>
>
>>  To address the latter problem, the engine would need to
>> provide a program evaluator that begins with two scopes, one with
>> globals, the other for module locals, wherein top-level declarations
>> (and potentially free assignment, if that can't simply be culled from
>> modules) are bound to the locals instead of the globals.
>
> This is a language change. ES1-5 put free variables created by assignment in
> the object at the bottom of the scope chain.
>
>
>>  I believe
>> this addresses issues with Mark's idea:
>>
>>> eval.hermetic() does an indirect eval of the program in the current
>>> global context, but, as in
>>> <http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope>,
>>> without the global object at the bottom of the scope chain.
>>
>
> Mark is citing a proposal that *removes* the global object from the scope
> chain; that proposal does not fiddle with where declared and free vars go.
>
>
>> Implementations would need to decouple the top of the scope chain and
>> the global object.
>
> Implementations can do this easily, but the issue is language-level: is the
> global object at the bottom of the scope chain? So far, it is.
>
>
>> With the addition of a "eval.parse(text):AST", we could recover some
>> performance lost with this method, by sharing AST's among sandboxes.
>
> I've considered exposing the AST encoder as eval.parse. It's a cute trick to
> use eval as a namespace, tempting in order to minimize compatibility hits in
> adding to the global object. But it feels a little "off" here.
>
> Also, the AST codec I'm writing produces and consumes strings of JsonML.
> It's up to the user to invoke the JSON codec (or not), taking the hit of
> building a big array/object graph only as needed. This should not be a
> mandatory consequence of parsing from source to an AST form that can be
> consumed by the engine. You shouldn't have to go from
>
> source string -> object graph -> JsonML string
>
> in the language itself, since the middle step can chew up a fair amount of
> memory compared to an incremental (top-level-declaration-or-statement at a
> time or better), native parser that feeds its internal AST into a native
> stringifier.
>
> /be
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>