35 ms·
I'm most concerned about interacting with other systems, like databases, http services, whatever, where the data that's being worked on includes such values as
by s_kilk 9y ago
I'm most concerned about interacting with other systems, like databases, http services, whatever, where the data that's being worked on includes such values as `false`, `null`, and `[]`.
In that context it's hard not to simply conclude that CL would be at a disadvantage.
- juki 9y agoIn that situation you could simply represent `null` as a keyword :NULL, `false` as NIL and `[]` as a vector (or some other non-list datastructure).
- dreamcompiler 9y agoExactly. Symbols are first-class runtime objects in CL, so just make up a symbol name for the various null-like values. Keywords are the easiest symbols for this purpose since they're package-agnostic.
- diogofranco 9y agoThis is a legitimate concern - I've built some production lisp services that handled JSON back and forth, and you need to address this specifically. My solution was to hook custom encoders and decoders to `cl-json`, converting null to :null, false to :false, and [] to nil. Other conversions are possible of course. This scheme has the advantage of allowing you to naturally iterate over JSON arrays as lists in application code, but you have to take care of the fact that :false evaluates to T, by for example writing your own macros for "if". This might read like a nightmare, but Lisp makes it really easy to customize everything about it self, which can be beautiful, if you're into that.