3 ms·
S-Expressions are missing. Language support is poor (except if you're programming in a Lisp dialect in which case it's built-in), but I do believe they are the
by linschn 8y ago
S-Expressions are missing. Language support is poor (except if you're programming in a Lisp dialect in which case it's built-in), but I do believe they are the best serialization format out there:
http://wiki.c2.com/?XmlIsaPoorCopyOfEssExpressions http://wiki.c2.com/?XmlIsaPoorCopyOfEssExpressions
They have a canonical representation
https://en.wikipedia.org/wiki/Canonical_S-expressions https://en.wikipedia.org/wiki/Canonical_S-expressions
I swear I have seen a proposal for an efficient binary representation somewhere but I can't find it.
- wodenokoto 8y agoAs far as I understand S-expressions are completely code-as-data, so how do you protect yourself from malicious code execution when loading S-expressions?
- kazinator 8y agoSimply not passing any of these parsed expressions to your eval function. ANSI Common Lisp presents a pitfall here in that it features read-time evaluation via the #. (hash dot) syntax. For instance #.(+ 2 2) produces the object 4. After seeing #., he reader scans the (+ 2 2) expression, evaluates it immediately, and substitutes the result. When reading untrusted data in Common Lisp, the * read-eval * variable must be set to nil to disable hash-dot. Lisps that don't have a read-time-eval escape mechanism don't require anything.