Email list hosting service & mailing list manager

Full S-expression syntax Lassi Kortela (25 Sep 2019 09:16 UTC)
Re: Full S-expression syntax rain1@xxxxxx (26 Sep 2019 18:44 UTC)

Full S-expression syntax Lassi Kortela 25 Sep 2019 09:16 UTC

Extending John's core S-expression spec in the other thread, here's a
quick proposal to cover his whole spreadsheet of datatypes at
<https://docs.google.com/spreadsheets/d/1V-7E5d3fLON5DrVeHkVvp9h5SRgcteOgnPl8KvWTA3M>:

Fixed integer           1234 -123
Fraction                12/34
Symbol                  foo |:foo \| bar|
Keyword                 :foo (Common Lisp)
(Public symbol)         my-package:my-symbol (Common Lisp)
(Private symbol)        my-package::my-symbol (Common Lisp)
String                  "foo"
List                    (1 2 3)
Improper list           (1 2 . 3)

End-of-file object      #!eof
Null                    #!null
Boolean                 #!true #!false

Character               #\foo
Vector                  #{...}

Complex number          #c{1 1}
Mapping                 #map{k1 v1 k2 v2 k3 v3}
Record/structure        #record{k1 v1 k2 v3 k3 v3}
Bag                     #bag{1 2 3}
Set                     #set{1 2 3}

Bit string              #bits{101010101010101010101010}

Bytevector              #u8{1 2 3}
s8vector                #s8{1 2 3}
u16vector               #u16{1 2 3}
s16vector               #s16{1 2 3}
u32vector               #u32{1 2 3}
s32vector               #s32{1 2 3}
u64vector               #u64{1 2 3}
s64vector               #s64{1 2 3}

f32vector               #f32{1 2 3}
f64vector               #f64{1 2 3

c64vector               #c64{...}
c128vector              #c128{...}

IEEE binary float       #binfloat64{"4bd5c8047eefd0"}
Binary string           #binstring{shift_jis
"82b182f182c982bf82cd90a28a450a"}

8601 datetime           #datetime{"2016-06-12"}
8601 duration           #duration{"P3Y6M4DT12H30M5S"}
Column table            #column-table{...}
Range                   #range{...}

For the sake of consistency, I made some quite unusual changes above:

Parentheses (...) are only used for lists. Vectors and all other stuff
use curly braces {...}. The rationale is that Lisp lists can be improper
lists, whereas vectors cannot. So a (...) parser has to handle a consing
dot, whereas a {...} parser should ban the consing dot altogether.

Also I changed #t and #f to #!true and #!false for consistency with the
other special objects #!eof and #!null. So sharpsign-bang (#!) is always
followed by a single symbol denoting a special object, and nothing else.

On the contrary, #foo{...} i.e. sharpsign followed immediately by a
symbol is a complex custom datatype. The symbol is always followed by
curly braces, and zero or more Lisp objects are read recursively inside
those braces. Their interpretation depends on the symbol after the
sharpsign. Readers who don't understand that symbol can skip past the
braces.

I like the simplicity of the above proposal considering how many
datatypes and extensions it can handle. I'm happy to argue about the
details; I don't have a strong opinion that this is the one true way,
just an idea that came to mind.