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 Peter Bex 20 Apr 2021 13:15 UTC
On Tue, Apr 20, 2021 at 04:03:17PM +0300, Lassi Kortela wrote:
> The angle brackets < and > should be symbol-constituent characters since
> they are that way in most/all Lisp dialects.

Speaking of which, in EDN (as in Clojure), a slash is only valid when it
occurs bare, or when it occurs as a separator between a "namespace" and
the symbol itself.  A symbol cannot contain multiple slashes.

I've experimented a little bit with Clojure's reader/writer and it's a
total mess: it basically doesn't care about read/write invariance
*at all*.  It is trivial to construct symbols that can be printed but
not read back.

> EDN is like the YAML of Lisp -- the quest for convenience went so far that
> the complexity is starting to be too much of a burden. Apart from being
> confusing, complex parsers are now security hazards as well.

Yeah, and also EDN isn't really a specification IMHO.  It's pretending
to be an interchange format, but it's basically just trying to describe
"whatever the Clojure reader accepts", warts and all.

> Nothing also prevents us from specifying a tower of S-expression notations
> of increasing complexity, such that each notation is a fully compatible
> superset of all the less complex ones.

I doubt that's achievable or even useful; there are overlaps between what
the various Lisp readers accept which are mutually incompatible in
different ways and trying to do all of it would result in a fractal of
complexity.  Just look at pre-R7RS numeric syntax in Scheme alone.

Cheers,
Peter