Live data from Hacker News

Thoughts on Canonical S-Expressions (2019)

write.emacsen.net

11–15 of 15 posts

Re: Thoughts on Canonical S-Expressions (2019)

#11
The primary intended use case of this in contrast to say Extensible Data Notation (EDN) seems to be for faster machine processing. The necessitating of prefixing datums with their lengths (Pascal string style) alone is the clue. So an advantage here is it is much easier to place a hard bound on memory and CPU for reading this format, and confers security properties like systemically reduced possibility of buffer overflows. Good for hard real-time, for example guidance systems that do all allocation only at startup.

Beyond lists and string atoms (or whatever the actual list is), this format also makes an affordance for custom types, but as TFA points out, you still have to roll your own other / higher order data types. Data types that you almost definitely have on hand. Now we are talking about needing to do additional processing on the decoded output, just to interpret common data structures like associative arrays and sets. And as a machine-first serialization format, if you are interchanging with other people or with yourself in the future, sure hope you have full agreement on those custom types.

So what do you do: Add libs? Roll your own? Well, competing alternatives already offer that complete picture as mature, battle-tested solutions. So I'm inclined to view Canonical S-Expressions merely as a way-point on our path of technological evolution, worthy of fleeting, mild curiosity.

Re: Thoughts on Canonical S-Expressions (2019)

#13
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…

How would you encode a bencode where the list doesn’t end in a list ? Or is that the purpose of the letter ‘e’ ?

Re: Thoughts on Canonical S-Expressions (2019)

#14
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.

Maybe they meant writing C in an s expression syntax? Would certainly make macros nicer.

Re: Thoughts on Canonical S-Expressions (2019)

#15
post #13
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…

How would you encode a bencode where the list doesn’t end in a list ? Or is that the purpose of the letter ‘e’ ?

Yes, that's the purpose of "e". https://en.wikipedia.org/wiki/Bencode#Encoding_algorithm
Post reply on HN