> The core S-expression and its corresponding binary format
> are for communication between Lisps, but more importantly between Lisps and
> non-Lisps, and simplicity is everything.  I'm talking here about a JSON
> data model plus integers, symbols, and bytevectdors.

I like that set of data types for the simple version of the format.

I'd just like to avoid arbitrary limits on the range of values within
each data type. Things like numerical limits, or limits on what
characters can appear in symbols. In order for the text format to have a
simple correspondence with its dual binary format, it should do a little
extra work to be able to represent things like symbols with weird chars.

And the reason the text and binary formats should have 100% equal data
models, is simplicity for users - the proper aim of abstraction. Rich
Hickey had a point about Clojure, that it often sits between external
systems, and users should be able to get some data from an external
system, frob only part of it, and pass on the rest to some other system.
Without being concerned about the contents of the data they are not
frobbing. He said that he doesn't like static typing because it's
obsessed with dictating the type of all data, including data that's just
along for the ride and that his code doesn't care about.

I'd like to have 100% text/binary equivalence and a rich set of data
types for the same reason. Just simple (read) and (write) with a choice
of text and binary, no need to be concerned with other options, and
being able to trust that towards end of a long workday, I can just toss
some data to them without keeping in mind idiosyncrasies like what kinds
of symbols can be represented as text and what kind can be represented
as binary, or whether improper lists can be represented or not. The
point of much of Lisp culture is to obviate concerns like that.

So I would like the formats to provide "mechanism, not policy". I don't
care about guiding people to use particular kinds of data by restricting
the format. That can be an important goal, but I don't see a reasonable
way of tackling it. Empirically, when you try to restrict the range of
data types, people do even stupider workarounds, or switch to richer
formats (which often have baroque syntax and other problems).

A simple format in the ballpark of JSON is supremely useful for
implementation reasons: it makes little sense to demand that a Scheme
sitting on a little IoT device relaying sensor readings should support
arbitrary-precision floats or ordered sets or something. But other than
that, I would work a little extra to avoid restrictions and dictating
policy to users. Not because policy sucks an I'm unsympathetic to it,
but because it seems like an intractable problem, and attempted
solutions are likely to be a hassle without fixing things.

> The binary format I'm developing, of which the core binary format is a
> small subset, is for serialization and Lisp-to-Lisp communication (though
> of course other languages can implement it, and a subset of it can be used
> to talk to other ASN.1 implementations).  I'd like to leave full
> S-expressions for communication between identical or similar Lisp
> implementations (R5RS, R6RS, R7RS-small, CL) and not try to standardize
> them at this late date.  The binary format is probably simpler to implement
> anyway.

I like the range of your kithcen-sink binary format.

But why would it be particularly difficult to design an equivalent
S-expression format? I don't think the point is standardizing
S-expressions in general, but specifying _one_ flavor of S-expressions
that can carry everything. Preferably a simple and extensible one, with
most of the dodgy stuff implemented as extensions.

Would it appease you if we include all the dodgy stuff but using
sharpsign syntax so they act like third-party user extensions instead of
bloating up the lexical core of the syntax?

> technology was made for people, not people for technology.

It's not that simple :) But we can strive to act as if it is so.