> 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.

Good call. The colon gives similar trouble in all Lisp implementations
that use it for keywords. In CL symbols it separates the package name
from the symbol name (e.g. COMMON-LISP:NIL and COMMON-LISP::NIL -- one
colon means to access expoerted symbols only, two colons means to play
dirty and ignore export rules).

Dots are weird too: typing '... into GNU CLISP says "a token consisting
only of dots cannot be meaningfully read in".

However, '|...| works fine, giving a symbol whose name is "...".
Likewise, :foo gives a keyword whereas '|:foo| gives a non-keyword
symbol. CL also permits ':|foo| which gives a keyword whose name is "..."

One of the main selling points of vertical-bar notation is that the
special meaning of things like slash and colon can be unambiguously
avoided. We could simply make / and : illegal in bare symbols, but if we
permit vertical-bar symbols to contain any characters that double-quoted
strings do, it's no problem to type / and : in them.

> 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.

This matches what I hear from everyone who has delved into it. One of
the problems with languages that don't have a spec is that no-one
reviews this stuff before it becomes de facto standard.

For POSE, I would prefer symbols and strings to be able to represent all
characters so the range of encodeable data is logical and easy to
understand.

> 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.

Agreed. They could have taken the opportunity to drop some of the
questionable parts.

>> 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.

It's almost certainly not possible to do if we want full compatibility
with most of the existing Lisp dialects. Like elf, I'd prefer to
prioritize a clean representation of all datatypes over absolute compat
with existing stuff. It seems a good balance can be struck quite easily.