@lizzy@social.vlhl.dev @ada@zoner.work snac deals with a lot of JSON strings, all data is stored in JSON files on disk, sent as JSON over network, etc. Handling the data as loosely typed strings most of the time is likely cheaper than marshaling everything into well-typed "objects" and then serializing them back again on I/O. I haven't delved much into the implementation of xs myself, but I used it when I wrote a few patches for snac, and it was acceptable to use. I've been using snac for a few months, and it's much better on resources than any other major AP software I've seen, so I don't have complaints about the performance of parsing doubles :)

I still see snac as "worse-is-better" software, which I don't like much, but at least it's simple enough to start doing meaningful patches within a couple of hours of diving into it, and definitely cheaper for me than having to write a whole AP server from scratch, which I was tempted to do before.

Hi, #snac author here. The xs code is specially crafted to parse the JSON files in use in the ActivityPub protocol, which are a) mostly small, and b) they have very few numbers, so the string to double conversion happens almost never.

Regarding the enum numbers: they are surely arbitrary, but the rationale there is that they are all ASCII control codes (so: less than 32) that should never happen in a JSON file (and, if they occasionally appear, they are converted to their Unicode representations). The correspondence is:

XS_TYPE_STRING 0x02 ASCII: STX (start of text)
XS_TYPE_TRUE 0x06 ASCII: ACK (acknowledge)
XS_TYPE_FALSE 0x15 ASCII: NAK (negative ack.)
XS_TYPE_LIST 0x1d ASCII: GS  (group separator)
XS_TYPE_LITEM 0x1f US  (unit separator)
XS_TYPE_DICT 0x1c ASCII: FS  (file separator)