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