4 ms·

You parse the s-exprs and execute them in the context of a namespace of data constructors. Then you can have whatever data structures in memory that are defined

You parse the s-exprs and execute them in the context of a namespace of data constructors. Then you can have whatever data structures in memory that are defined by the constructors. This is NOT equivalent to having one data structure to cover both as Lua does. It is having one text format that can construct any kind of data structure in memory for which you have constructors defined.

iainmerrick 5y ago
Okay, but we’re talking about a lingua franca for exchanging plain old data between different programs. You would have to pick your data constructors in advance. I’m saying that arrays and maps give good bang for the buck, so you don’t really need to define anything beyond those. And if you accept that, having special syntax for arrays and maps is more convenient and readable than S-exprs.
- eadmund 5y ago
  > And if you accept that, having special syntax for arrays and maps is more convenient and readable than S-exprs. S-expressions are arrays, and maps are really just degenerate unsorted arrays of key-value pairs. Taking a look at https://json.org/example.html https://json.org/example.html, I think this is easily more readable: (menu (id file) (value File) (popup (item (value New) (onclick "CreateNewDoc()")) (item (value Open) (onclick "OpenDoc")) (item (value Close) (onclick "CloseDoc()")))) than: {"menu": { "id": "file", "value": "File", "popup": { "menuitem": [ {"value": "New", "onclick": "CreateNewDoc()"}, {"value": "Open", "onclick": "OpenDoc()"}, {"value": "Close", "onclick": "CloseDoc()"} ] } }}
  - iainmerrick 5y ago
    Each to their own! A big part of the difference is that all the JSON keys are quoted, which I agree is ugly (I like JSON5 myself). You’ve also omitted the “menuitem” from the S-expr version. That could have been omitted from the JSON too but I assume it’s meant to be there for some good reason.

iainmerrick 5y ago

Okay, but we’re talking about a lingua franca for exchanging plain old data between different programs. You would have to pick your data constructors in advance. I’m saying that arrays and maps give good bang for the buck, so you don’t really need to define anything beyond those. And if you accept that, having special syntax for arrays and maps is more convenient and readable than S-exprs.

eadmund 5y ago
> And if you accept that, having special syntax for arrays and maps is more convenient and readable than S-exprs. S-expressions are arrays, and maps are really just degenerate unsorted arrays of key-value pairs. Taking a look at https://json.org/example.html https://json.org/example.html, I think this is easily more readable: (menu (id file) (value File) (popup (item (value New) (onclick "CreateNewDoc()")) (item (value Open) (onclick "OpenDoc")) (item (value Close) (onclick "CloseDoc()")))) than: {"menu": { "id": "file", "value": "File", "popup": { "menuitem": [ {"value": "New", "onclick": "CreateNewDoc()"}, {"value": "Open", "onclick": "OpenDoc()"}, {"value": "Close", "onclick": "CloseDoc()"} ] } }}
- iainmerrick 5y ago
  Each to their own! A big part of the difference is that all the JSON keys are quoted, which I agree is ugly (I like JSON5 myself). You’ve also omitted the “menuitem” from the S-expr version. That could have been omitted from the JSON too but I assume it’s meant to be there for some good reason.