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.<p>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.<p>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.
I would suggest the author also look at Amazon Ion:<p>* It can be used as schema-less<p>* allows attaching metadata tags to values (which can serve as type hints[1]), and<p>* encodes blobs efficiently<p>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.<p>[1] <a href="https://amazon-ion.github.io/ion-docs/docs/spec.html#annot" rel="nofollow">https://amazon-ion.github.io/ion-docs/docs/spec.html#annot</a>
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.<p><pre><code> Canonical S-Expression: (9:groceries(4:milk5:bread))
Bencoding: l9:groceriesl4:milk5:breadee
</code></pre>
Bencoding also manages to specify dictionaries, and yet still have a canonical encoding, by requiring dictionaries be sorted by key (and keys be unique).<p>It doesn't have the option for arbitrary type names, it just has actual types: integer, bytestring, list and dictionary.<p>FTA:<p>> Bencoding offers many of the same benefits of CSEXP, but because it also supports types, is a bit easier to work with.<p>Hmm, well there you go.
> 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.<p>This is exactly what edn does. Seems like the author would like edn but doesn’t mention it<p><a href="https://github.com/edn-format/edn">https://github.com/edn-format/edn</a>
We changed the url from <a href="https://en.wikipedia.org/wiki/Canonical_S-expressions" rel="nofollow">https://en.wikipedia.org/wiki/Canonical_S-expressions</a> 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.)<p>Readers may want to look at both of course!
> In some cases this conversion is easy, 3:100 becomes the integer 100.<p>Huh, I'd have said it should become the string "100", based on earlier examples such as 5:hello