Thoughts on Canonical S-Expressions (2019)

We changed the url from https://en.wikipedia.org/wiki/Canonical_S-expressions to a non-Wikipedia article. (Wikipedia submissions are fine but if there's a good third-party source, those are usually preferred because they're less generic.)

Readers may want to look at both of course!

Re: Thoughts on Canonical S-Expressions (2019)

#5

Post by amiga386 » Thu, Aug 08, 2024, 9:58 PM UTC

Canonical S-expressions seem remarkably similar to bencoding as used in BitTorrent files. They both use length prefixes written in ASCII digits followed by a colon.

    Canonical S-Expression: (9:groceries(4:milk5:bread))
    Bencoding:              l9:groceriesl4:milk5:breadee

Bencoding also manages to specify dictionaries, and yet still have a canonical encoding, by requiring dictionaries be sorted by key (and keys be unique).

It doesn't have the option for arbitrary type names, it just has actual types: integer, bytestring, list and dictionary.

FTA:

> Bencoding offers many of the same benefits of CSEXP, but because it also supports types, is a bit easier to work with.

Hmm, well there you go.

Re: Thoughts on Canonical S-Expressions (2019)

#6

Post by Jtsummers » Thu, Aug 08, 2024, 9:58 PM UTC

djaouen wrote: post #3

Imagine if we had this instead of shitty ass C or asm lol

Canonical S-Expressions aren't meant to replace something like C or assembly, they're for data serialization. It's meant to be compared against things like JSON, XML, ASN.1, or any other serialization format.

Re: Thoughts on Canonical S-Expressions (2019)

#7

Post by [deleted] » Thu, Aug 08, 2024, 10:09 PM UTC

amiga386 wrote: post #5

Canonical S-expressions seem remarkably similar to bencoding as used in BitTorrent files. They both use length prefixes written in ASCII digits followed by a colon. Canonical S-Expression: (9:groceries(4:milk5:bread)) Bencoding: l9:groceriesl4:milk5:breadee Bencoding also manages to specify dictionaries, and yet still have a canonical encoding, by requiring dictionaries be sorted by key (and keys be unique). It doesn…

[deleted]

Re: Thoughts on Canonical S-Expressions (2019)

#8

Post by shalabhc » Thu, Aug 08, 2024, 10:29 PM UTC

I would suggest the author also look at Amazon Ion:

* It can be used as schema-less

* allows attaching metadata tags to values (which can serve as type hints[1]), and

* encodes blobs efficiently

I have not used it, but in the space of flexible formats it appears to have other interesting properties. For instance it can encode a symbol table making symbols really compact in the rest of the message. Symbol tables can be shared out of band.

[1] https://amazon-ion.github.io/ion-docs/docs/spec.html#annot

Re: Thoughts on Canonical S-Expressions (2019)

#9

Post by emacsen » Thu, Aug 08, 2024, 11:26 PM UTC

dang wrote: post #4

We changed the url from https://en.wikipedia.org/wiki/Canonical_S-expressions to a non-Wikipedia article. (Wikipedia submissions are fine but if there's a good third-party source, those are usually preferred because they're less generic.) Readers may want to look at both of course!

Thanks for the plug on this very old article/topic.

Re: Thoughts on Canonical S-Expressions (2019)

#10

Post by bsima » Fri, Aug 09, 2024, 1:10 AM UTC

> One thought that I keep having while I'm using csexp is to use the type hints to store information such as the data type.

This is exactly what edn does. Seems like the author would like edn but doesn’t mention it

https://github.com/edn-format/edn