I value these discussions a lot. They take a lot of time and energy, but
few complex inventions bear fruit without getting a number of people in
agreement. It's just not possible to do much for the world by oneself.
Hearty agreement.
Perhaps the CL writer should write out NIL and T as something like
#!cl:nil and #!cl:t.
The CL writer isn't the problem: it's the CL reader that will blur the distinction between |NIL|, false and empty list no matter what we do. It could return one or two artificial objects, but the result would just be an annoyance to the CL programmer. I guess this simply comes under the heading of "C will treat lists and improper lists as vectors."
As we discussed, CL symbols also have packages. I think they should be
representable on "throw some code into the format at the end of a tired
workday" grounds. But again it can be a special field:
#package-symbol{"CL-USER" FOOBAR}.
What's wrong with the symbol cluser:foobar on the wire? The CL reader can either boot if it finds an unknown package, as CL's native reader does, or create it on the fly with make-package.
There is an issue that cluser:foobar, |cluser:foobar|, |cluser|:foobar, cluser:|foobar|, and |cluser|:|foobar| all mean different things. My personal attitude to that problem is "Who cares?" AFAIK we are not trying to provide serializations for all possible CL data structures. Let the CL community do that work, and if it fits into our framework (very unlikely, politically), so much the better. In any case, anyone who quotes : or uses packages that differ only in case deserves to lose.
Uninterned symbols could be #package-symbol{#!null FOOBAR} or
#uninterned-symbol{FOOBAR}. Some Schemes also have uninterned symbols so
a common solution needs to be found.
We'll discuss that, but I am not a fan of it. Most Schemes won't have any such thing, and anyway, different instances of #:foo are all different, so they might as well be strings.
> First of all, I want a more compact syntax for bytevectors. My current
> notion is for them to match/\[([0-9A-Fa-f][0-9A-Fa-f][-])*\]/. That is,
> hex digits with optional hyphens between each byte so you can group things
> as you like, and then wrapped in square brackets. I'm not particular about
> the square brackets.
I like the hex digits thing. I might even go with the base64; quite
neutral on it.
Base64 fails on both human-readability and bit compactness. The *only* reason it exists at all is because email channels were originally 7-bit only. Indeed, they still are unless both ends negotiate otherwise.
What's your opinion of simply using strings for the hex? #u8"abcdef1234"
I want a stand-alone way to do bytevectors that doesn't involve #name prefixes, because I want to use is as part of #name notations.
One natural name would be "Lisp ASN.1".
No objection.
Both binary and decimal floats would be nice to have. It's good to have
binary floats in the text format too, since the binary format has them.
Likewise, people are going to write 123.45 in the text format, so it's
good to have decimal floats in the binary format.
ASN.1 standard floats (nobody uses them AFAIK) can handle exponent bases of 2, 8, 10, or 16. But the normal textual notaton of floats, like "3.1415", should correspond to the normal binary notation, IEEE binary64. I'll worry about a specialized type for decimal floats when some Lisp provides them.
There are libraries for Python, R, C/C++, and a few other languages, but no one has the integrated into the language's numeric tower (Python comes closest, but not very close). Hardware support is caught in a chicken-and-egg problem: langages don't support them, so chips don't implement them (except for the IBM POWER and the z/Series mainframes), so languages don't support them. They have been characterized as a solution in search of a problem.
The problem with the [0000-0000] encodings is that we need to introduce
extra square-bracket lexical syntax for something that could already be
represented as a string: "0000-0000".
I want to distinguish in the text format between ASN.1 types that are basically ASCII and those that are basically binary. Bytevectors vs. strings is the natural way to do that.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgThis great college [Trinity], of this ancient university [Cambridge],
has seen some strange sights. It has seen Wordsworth drunk and Porson
sober. And here am I, a better poet than Porson, and a better scholar
than Wordsworth, somewhere betwixt and between. --A.E. Housman