> Mini-rant about the horrible awfulness of text-with-counted-strings,
True for sure. I don't suppose anyone intends such formats to be edited
nowadays. I imagine the dusty decks are not a mere figure of speech :)
Well, they aren't actually punch cards any more. But programs that date from punch-card days are definitely still around and in use.
I was being imprecise; if the simple formats can be a straight subset of
the complex uber-format, so much the better. They shouldn't be
gratuitously different.
Good.
So if the simple format is a subset of ASN.1 we should still write a
separate spec for it, with a maximum of 5 easy-to-read pages and a
promise that "this is all there is".
I can't guarantee to be that compact, but there definitely will be a SRFI that doesn't just defer to the X.690 docs. If people can understand, say, SRFI 160, they should be able to understand this.
I'd also like everything to be S-expression-based, though I'll listen to
counterarguments.
What do you think about my dotted-symbol protocol and/or SRFI 10? One problem with SRFI 10 is that (very unfortunately) the "#." syntax can't be safely used in interchange in CL, because the following list is *evaluated* in the current global environment at read time. This is equally true of interchange between two CL programs.
There's no hope of specifying a widely compatible subset of
S-expressions for intricate stuff, but we can ship read/write libraries
for every popular Lisp dialect. That's almost as good.
And people don't have to use them, which is good. They can use native read and write in trusted communication, which is a very important use case.
Here are my suggestions for rock-bottom S-expressions:
Proper lists as we know them. They might turn into vectors in non-Lisp systems.
Alists as we know them. They might turn into hashtables or dictionaries in non-Lisp systems. We always format an alist element (1 2 3) as (1 . (2 3)).
Symbols without escapes. NIL is not a symbol. Users should not rely on the case of symbols to distinguish meaning.
Possibly-signed decimal integers. Users should not rely on transmitting numbers outside the 64-bit range.
Possibly-signed decimal floats, but without +inf.0 -inf.0 +nan.0. Users should not rely on 0.0 and -0.0 being distinct. Users should not rely on transmitting numbers outside the float64 range.
Strings, with only \\ and \" supported. I'd like \n as well, but CL doesn't understand it and some older Schemes might not either.
I use to think for years that using a standard solution where available
is the most important thing. A couple years ago I had some
transformative programming experiences (can't remember which, sadly)
that showed that simplicity is more important than standardization.
Following complex standards, apart from the immediate practical problems
that stem from complexity, also perpetuate the spread of complexity.
Agreed. But if complex models are well-designed, they don't need complex standards, because hierarchy and extensibility.
By the way, Ron Rivest's S-expressions (someone linked to them here) include textual counted strings, in 1997! Smart does not mean wise.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.org "Mr. Lane, if you ever wish anything that I can do, all you will have
to do will be to send me a telegram asking and it will be done."
"Mr. Hearst, if you ever get a telegram from me asking you to do
anything, you can put the telegram down as a forgery."