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"
}