Email list hosting service & mailing list manager

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)

Re: Portable S-expressions Lassi Kortela 20 Apr 2021 13:09 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.