Attempt at a stack of data formats to make everyone happy Lassi Kortela (19 Sep 2019 17:28 UTC)
Sketching the format stack Lassi Kortela (19 Sep 2019 18:07 UTC)
Re: Attempt at a stack of data formats to make everyone happy Arthur A. Gleckler (20 Sep 2019 22:19 UTC)
Re: Attempt at a stack of data formats to make everyone happy Alaric Snell-Pym (24 Sep 2019 09:02 UTC)
Core S-expression and binary formats John Cowan (24 Sep 2019 14:49 UTC)
Re: Core S-expression and binary formats John Cowan (25 Sep 2019 02:14 UTC)
Sharpsign syntax for hashtables, sets, bytevectors, etc. Lassi Kortela (25 Sep 2019 08:26 UTC)
Bytevector literals Lassi Kortela (25 Sep 2019 08:38 UTC)
Re: Sharpsign syntax for hashtables, sets, bytevectors, etc. Alaric Snell-Pym (25 Sep 2019 09:33 UTC)
Re: Sharpsign syntax for hashtables, sets, bytevectors, etc. Lassi Kortela (25 Sep 2019 09:53 UTC)
Re: Sharpsign syntax for hashtables, sets, bytevectors, etc. Alaric Snell-Pym (25 Sep 2019 10:32 UTC)
String literals inside bytevector literals Lassi Kortela (25 Sep 2019 10:46 UTC)
A S-expression syntax that can carry all this stuff Lassi Kortela (19 Sep 2019 20:01 UTC)

Sharpsign syntax for hashtables, sets, bytevectors, etc. Lassi Kortela 25 Sep 2019 08:25 UTC

> This syntax is quite nice, but I'd think about it some more. In
>>> particular, Racket already has a different read syntax for hash-tables,
>>> as does Clojure's EDN.

> In Racket it's "#hash" followed by an alist, so we are back to the idea of
> alists.

Right, I thought you meant some readers/writers would have implicit
magic behavior on ordinary lists that happen to have the structure of an
alist. If there's an explicit "#hash" prefix first, then it's all good
and doesn't much matter if the remaining syntax resembles an alist or
something else.

> Clojure uses the same syntax I threw together, except starting
> with "{" instead of "#{".  Of the two, I prefer Clojure's.  How do you feel
> about it?

I also think Clojure's looks much nicer. But it's completely different
from normal alist syntax, and what will we use for sets? Well, we could
have:

#hash{key1 val1 key2 val2}
#set{elt1 elt2 elt3}

#ordered-hash{key1 val1 key2 val2}
#ordered-set{elt1 elt2 elt3}

It might be nice if the hash syntax is always #symbol{...} which is a
mash-up of all our suggestions so far. And if the symbol could
optionally be reverse-DNS, so I could make #io.lassi.whizbang{...} for
my own syntax extensions without disturbing others, and the {...}
wrapping would guarantee an easy way for uninterested (machine and
human) readers to skip it.

> As for bytevectors, I'll add them using R7RS syntax.  Should we require
> hex?  It's easier to read, if wasteful.  Chibi outputs every value in hex
> except 0, which is exceedingly common.

Do you mean this: #u8(1 2 3 4 5). I find it very nice. However, the bit
density is low and as you say, decimal numbers cause concern.

Would this be a terrible idea: #u8"0123456789abcdef". So it's a string
but its contents must be an even number of hex digits.

The trouble with that is splitting up long strings. Is this baroque:

#u8{
"000089f809d08b1d483e00004489e683"
"ce0809d8448a15f13c0000410f45f445"
"31c944380de73c0000410f45f44584d2"
"410f45f44584c0410f45f48a05bb3c00"
}