Replying as a separate subthread:

> A very very rough sketch of my idea for extending S-expressions smoothly:
>
> On input, a list whose car is a symbol beginning with "." is mapped through
> a procedure associated with that symbol by the caller, and whatever the
> procedure returns replaces that part of the input.  This is effectively
> macroexpansion at the lexical level.  On output, you need a mapping from
> type predicates to such lists.  The virtue of this design is that it works
> *on top of* `read` and `write`, and therefore is portable, except to people
> who use symbols with dots in front (hopefully few to none, but substitute
> another symbol character if you want, just not colon).  Yes, it's a kludge.
>
> The alternative is to use SRFI-10 syntax:  #.(list).  This is safe,
> requires modifications to read and write, and is inherently unportable.
> (The associated predicate set-reader-ctor! is inappropriately global and
> shouldn't be used.)

Both seem like reasonable ideas to me. I don't have much of an opinion
on this.

Common Lisp's, and to some extent Racket's, approach is to sprout all
syntax extensions by tacking new characters onto sharpsign (#). That may
be reasonable but in our case it's not enough to tack on new characters
- we need new words :)

I think compatibility (beyond the Platonic ideal of S-expressions) is
ultimately unattainable and will limit our imagination if we strive for
it. It's good for lists, symbols, strings and numbers to have familiar
syntax but beyond that there are going to be incompatibilities with soem
dialects no matter what we do.