6 ms·
in at least Common Lisp world slinging s-expressions is considered to be a hack, at best something you do in a development environment, like swank/slime wire pr
by g9550684 2mo ago
in at least Common Lisp world slinging s-expressions is considered to be a hack, at best something you do in a development environment, like swank/slime wire protocol. one of the reasons is that a readtable is both powerful, user extendable, and has all kinds of default ways in which a malicious input would be detrimental. you can remove all kinds of reader macros like #.(xyzzy), but to make a truly bulletproof s-expression reader you'd have to build a json like subset from first principles. even things like colons in symbol name package:symbol will trip you up. it's been understood since long time ago, that common internet standards, like RFCs, are the preferred method. in which case the fact that it's an s-expression versus a json is pretty much irrelevant. it's a kind of reader/writer anyway.
- groundzeros2015 2mo agoYou can configure (read) to be safe for this purpose. It’s not a hack.
- pfdietz 2mo agoYes, there's a specific standard special variable controlling it, *read-eval*.
- groundzeros2015 2mo agoYou can also configure a read table to disable any other data structure features you want. inb4 DoS attack. That is a universal parsing problem and should be solved by configuring OS limits for your process.
- pfdietz 2mo agoI'm of two minds about read tables. Yes, it's nice we have control over it. This is a lisp thing, where features that are used to implement standard things (like the standard reader) are exposed so the user can play with them also. But code written with custom read tables has some problems. Different code with different read tables may not be composable. If I have two packages that use incompatible read tables I can't import them into a third package and expect to be able to use their readtables there. Also, it makes treating code as an object to be inspected, modified, and written out again difficult. This is similar to the problem of code rewriting systems on preprocessed languages like C or C++. A different branch of Lisp put everything into S expressions. Interlisp, for example, had comments in the code as forms, so the code could be editted as S-expressions. But that was dropped from Common Lisp, which took the surface syntax more from Maclisp.
- groundzeros2015 2mo agoGood points. I sometimes see it as “easy and clean json” rather than code as data.