Portable S-expressions
Lassi Kortela
(16 Apr 2021 09:40 UTC)
|
Re: Portable S-expressions
John Cowan
(20 Apr 2021 12:09 UTC)
|
Re: Portable S-expressions
elf
(20 Apr 2021 12:14 UTC)
|
Re: Portable S-expressions
Lassi Kortela
(20 Apr 2021 12:49 UTC)
|
Re: Portable S-expressions
elf
(20 Apr 2021 12:59 UTC)
|
Re: Portable S-expressions Lassi Kortela (20 Apr 2021 13:09 UTC)
|
Re: Portable S-expressions
John Cowan
(20 Apr 2021 19:29 UTC)
|
Re: Portable S-expressions
Lassi Kortela
(20 Apr 2021 20:55 UTC)
|
Re: Portable S-expressions
Peter Bex
(20 Apr 2021 12:22 UTC)
|
Re: Portable S-expressions
Lassi Kortela
(20 Apr 2021 13:03 UTC)
|
Re: Portable S-expressions
Peter Bex
(20 Apr 2021 13:15 UTC)
|
Re: Portable S-expressions
Lassi Kortela
(20 Apr 2021 13:27 UTC)
|
Re: Portable S-expressions
Lassi Kortela
(20 Apr 2021 13:33 UTC)
|
> As a thought... define a compat-symbol/number as the first entry in the > file, which will determine specific variations. A format signature is a good idea, but I'd leave it for more complex syntaxes. The idea of POSE is to establish an extremely simple baseline - similar to JSON, which also decided to be so simple that it doesn't require a version number. > Or define a new symbol for things like booleans, that are not used by > any implementation or language, and that can be trivially parsed into a > local representation. Scheme's #t and #f (or #true and #false) are a good representation for unambiguous booleans IMHO. A syntax supporting booleans could simply use those. > In other words, it may be useful to define a sub-or-super-language which > can be trivially parsed by all extant languages, instead of trying to > find a subset of all languages that can be parsed identically by all > languages. I think that any such subset will be too small to be useful, > and will eventually result in either of the two options above, if the > idea continues at all. Fully agreed on all points. I can say from personal experience that a syntax with only lists, numbers, symbols, and strings is very useful. Probably not for serious code, but certainly for data, and for simple domain-specific languages.