Running Lisp in Production (2015)

Re:Running Lisp in Production (2015) by jlarocco on Sunday May 24, 2020 @04:33PM (#23294462)

For the benefit of everybody else, #+ does feature checking.

The Common Lisp standard defines a standard "special variable" (kind of like a global) named * features * (shouldn't be spaces, but HN italicizes it otherwise), and #+ (and #-) take a "feature expression" and conditionally execute the expression that immediately follows it when the feature expression is true. If the feature check is false, the next expression is ignored.

For example:

    #+freebsd(print "This is FreeBSD")
    #+(not (and 64-bit linux))(print "This is not 64-bit Linux.")
    #+quicklisp (ql:quickload :some-library)

The CL standard lists a few standard features (:common-lisp, :ieee-floating-point, etc.) but for the most part implementations and libraries define their own.

It's not perfect, but works well enough in practice.

[ Parent | on HN ]

Re:Running Lisp in Production (2015) by TeMPOraL on Sunday May 24, 2020 @05:49PM (#23295142)

The common thing done with it is:

  #+nil(this expression (won't be read))

(Also done with #+and, and #+or.)

This is an unofficial Common Lisp s-expression level comment. One of these incredibly nice things that's missing in most programming languages. It comments out a single s-expression, no matter how complex. It's like a #|block comment|# in that it can span multiple lines, and like ; line comment in that you only put something at the beginning. Have a complex expression within a function, that you need to temporarily shut down? Just shove #+nil in front of it.

(The #+nil version is discouragd because there's a remote chance somebody will define a * feature * called :nil for some reason.)

A less-common thing done with it is library interop. Many libraries tend to add a tag to * features * to indicate they've been loaded, so in your library, you can use #+library_tag to detect that another library is a part of the same project, and conditionally compile-in some extensions or interoperability code.

(@dang, I think HN could use a way to escape the * * formatting marks. For a site and community that has a soft spot for Lisp, not being able to type in the "earmuffs" is something that always bewildered me.)

[ Parent | on HN ]

Re:Running Lisp in Production (2015) by rjsw on Sunday May 24, 2020 @08:17PM (#23296248)

I would guess that there was a feature :nil defined in the NIL [1] system.

[1] https://en.wikipedia.org/wiki/NIL_(programming_language)

[ Parent | on HN ]

Re:Running Lisp in Production (2015) by TeMPOraL on Monday May 25, 2020 @04:16AM (#23299124)

That must be it, thanks!

[ Parent | on HN ]