Hacker News Reader

Comment by dreamcompiler | Hacker News Reader

It can be a problem in advanced Lisp programming where you'll end up reinventing things like maybe monads. But it's never a problem in simple Lisp programs. (After all, C has the same issue with booleans.) Can you be more specific about your concerns?

View on HN

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.

In that situation you could simply represent `null` as a keyword :NULL, `false` as NIL and `[]` as a vector (or some other non-list datastructure).

Exactly. 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.

This 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.

Reply on news.ycombinator.com