Spawn proposal strawman
eugene.lazutkin at gmail.com
Fri May 15 14:14:19 PDT 2009
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.
Dojo Toolkit, Committer
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"]]
>> 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]
>> (var x [1,4,5])
> I don't see why we'd invent a third language.
More information about the es-discuss