> we need an API standard as well as a format standard

Good idea.

> Which is why it's a restartable exception in CL.

I never thought of that. Restartable exceptions could be used for our CL
reader too.

>> I would read |cluser:foobar| as a symbol named "cluser:foobar" in the
>> default package (i.e. the symbol has no package prefix).
>
> The trouble now is that ||s are now semantic instead of just syntactic.
> cluser:foobar and |cluser:foobar| are the same on all systems except CL,
> but different on CL.

I thought cluser:foobar would cause an error when being read into Scheme
(unless the user gives a reader option for what to do about symbols with
packages).

> Maybe we do need a separate type for
> package-qualified symbols, but I'm not personally interested in spending
> time on it, as they mostly appear just in code, never in general data.

Yes, only in code. It's fine by me to have "symbol" and "fancy-symbol"
types. fancy-symbol would grok things like keywords, packages and
uninterned symbols.

>> Again, I'll argue that Lisp can simply give you uninterned symbol
>
> Can you give examples of data that contain them

Just code. CL has read syntax for them.
<http://www.lispworks.com/documentation/HyperSpec/Body/02_dh.htm> lists
"uninterned symbol" and:

[1]> '#:foo
#:FOO
[2]> (symbol-name '#:foo)
"FOO"
[3]> (symbol-package '#:foo)
NIL
[4]> (equal '#:foo '#:foo)
NIL

> I was thinking of UUIDs, but I don't care that much.  Overall I think
> hyphens are more human-readable.

OK, no strong opinion on this one. Let's wait and see.

>> Well, I hate to admit this but base64 is still convenient.
>
> Again because URIs were ASCII-only until fairly recently and are still not
> 8-bit clean.

These "one last holdout of ASCII-dom" instances keep popping up year
after year :)

>> Ah, ok. I'll wait for your #name syntax before evaluating the #u8"".
>
> I talked about this above and you LGTMed it.  The format is # followed by
> name or hexcode, followed by list, string, or bytevector.

I missed that, unless you somehow mean the bytevector syntax.

> Actually there is no loss.  Scheme guarantees that when you read and write
> binary floats as text you don't lose precision, much less get incorrect
> results.  Many libraries now guarantee the same properties (I believe glibc
> does).  There is no exact representation of 1.1 in binary32 floats, but
> there is a particular float that is closer to mathematical 1.1 than any
> other float is, and it may be safely printed as "1.1"

Cool, I didn't know that.

>> The big concern is representing exact quantities of money. Databases
>> have had to deal with this problem for ages; what do they do?
>
> They use integers with decimal scaling factors.  We can do that by
> representing 1.1 as 11/10.  It gets lengthy if the scaling factor is big,
> but not that lengthy.

Ah yes, ratios. I've always just dealt with money as integer cents, but
it's not all that convenient.