>> 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 [...] could return
> one or two artificial objects, but the result would just be an
> annoyance to the CL programmer.

I don't see a way to escape the problem either. The phrase "lost in
translation" comes to mind.

What the reader CL can have is a parameter to pick which representations
of ()/NIL/false/null will returned at each call to (read). Since we ship
the reader in our own library, it's not much effort to add options.

> What's wrong with the symbol cluser:foobar on the wire?

It's fine with me :) I thought you didn't like it. Any symbol notation
is probably fine with me, so long as some equivalent of vertical-bar
notation is available even in the simplest syntax so arbitrary symbol
names can be sent.

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

Yes. The reader might also need user choice for what to do upon
encountering a non-existent package.

> There is an issue that cluser:foobar, |cluser:foobar|, |cluser|:foobar,
> cluser:|foobar|, and |cluser|:|foobar| all mean different things.

IMHO we should dictate that symbols are always case-sensitive.
Converting bare symbols to uppercase is anachronisic, and converting
them to lowercase is not really necessary.

Case-sensitive symbols mean |cluser|:foobar and cluser:|foobar| and
|cluser|:|foobar| are equal.

I would read |cluser:foobar| as a symbol named "cluser:foobar" in the
default package (i.e. the symbol has no package prefix).

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

I still visit CL regularly and try hard to reduce unnecessary
divergence. Lisp needs people who go the extra mile to reach across
dialect boundaries.

Separately from that issue, a practical serialization of all CL data is
probably an intractable problem even with the best of intentions. But we
can provide enough extensibility that people can try, and gradually add
more types. Those should be identical to Scheme types where it makes sense.

> In any case, anyone who quotes : or uses
> packages that differ only in case deserves to lose.

Case-sensitive symbols and/or vertical-bar notation (or equivalent, e.g.
symbol name as double-quoted string with a special # prefix) should
solve that problem easily.

Even CL symbols are case-sensitive under the hood, as you know, so the
only thing that folds case is the CL reader with its default settings
(and a diminishing number of Scheme readers).

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

Again, I'll argue that Lisp can simply give you uninterned symbol from
somewhere. It's easier to support them as an extension than have people
filter them out from all data they ever write.

If you want to banish these weird symbols behind a # extension instead
of convoluting the format's basic lexical syntax: enthusiastically agreed.

>>> 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][-])*\]/.

All of that is good.

What about using underscore as the digit separator? Dash brings to mind
subtraction and Lisp symbols / Scheme identifiers, though there is
probably no serious risk of confusion.

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

Well, I hate to admit this but base64 is still convenient. One of the
latest examples is storing image files in data: URIs.

Still no strong opinion on whether base64 or only hex. I'll defer to others.

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

Ah, ok. I'll wait for your #name syntax before evaluating the #u8"".

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

OK, maybe loss of float precision is fine. Caring about bit-identical
floats is an anti-pattern (though I expect there are some fringe
applications where that kind of expediency is needed).

Then it's probably also fine to convert freely between binary floats
(for the binary format) and decimal floats (for the text format).

The big concern is representing exact quantities of money. Databases
have had to deal with this problem for ages; what do they do?

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

Interesting.

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

Sure. I meant something like #u8"1234abcd", i.e. a string prefixed by a
tag. But I'll wait for your bytevectors in #names.