Spawn proposal strawman

[Eugene Lazutkin]

I think JsonML (with []) is perfect:

- it doesn't introduce new concepts like the other proposal
- working with it doesn't require new APIs
- it is simple but not more restrictive than the other proposal
- we can add new "tokens" if we need to without introducing new objects/APIs

Given these positives and the lack of notable negatives I give +1 for
JsonML. If we need more user-friendly facade we can always implement it
with a library that uses JsonML-based facilities under the hood.

Eugene Lazutkin
Dojo Toolkit, Committer
http://lazutkin.com/

On 05/12/2009 02:31 AM, Brendan Eich wrote:
> On May 12, 2009, at 12:24 AM, kevin curtis wrote:
> 
>> JsonML looks good for for an AST handling:
>>
>> ["||",
>>   ["||",
>>     ["Id", "X"],
>>     ["Id", "Y"]],
>>   ["Id", "Z"]]
> 
> Yes.
> 
> 
>> 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.
> 
> JsonML wouldn't be used to build object graphs -- the JSON decoder would
> do that given JsonML in a string, from the AST encoder. That's the point
> I made in the words you bottom-cite about not mandating a big fat object
> graph if the use-case doesn't need the graph, just the string containing
> the AST serialization.
> 
> 
>> The benefit is that a scheme-y format could help the thinking on the
>> semantics for es6/harmony.
> 
> That seems like no benefit in memory use or cycles, only in thinking. If
> you squint, don't the []s turn into ()s? :-P
> 
> 
>> (Downside compared to a JSON  canonical format is that with JSON the
>> parsing/stringifying is free via the JSON api in es5).
> 
> This is a big downside.
> 
> 
>> For convenience JSON could remain JSON in this scheme-y format:
>> var x = [1,4,5]
>> becomes:
>> (var x [1,4,5])
> 
> I don't see why we'd invent a third language.
> 
> /be