Embed Notice

There is an old Common Lisp style guide written by Peter Norvig and @kentpitman that can be found here:

https://www.norvig.com/luv-slides.pdf

It's generally well written, and it parallels Grice's maxims of communcation.

However, it provides some examples that I, coming from the Scheme world, find hard to accept.

In particular, it explicitly recommends writing

(if (numberp x) (cos x) nil)

instead of

(and (numberp x) (cos x))

backing it up with the more general recommendation to use "and" and "or" for boolean values only.

In my understanding, this recommendation comes from the attempt to mimick the usages of natural language.

I already gave some consideration to this question (again, contrasting Scheme with Common Lisp) in one of the Quora answers that I once wrote: https://www.quora.com/What-are-the-pros-and-cons-of-functional-programming-compared-to-imperative-programming/answer/Panicz-Godek

The bottom line is that while there are some valuable traits of natural languages that should definitely be considered with care and attention, programming languages have a potential of being *better* than natural languages in some regards - especially if we take their compositionality to extreme with all due seriousness.

I remember asking a question on comp.lang.scheme about a function like "find" which - instead of an element satisfying a "predicate", would return the value of that "predicate". Someone replied that I can use the SRFI-1's "any" "quantifier" for this, and then I thought: of course! because it's a generalization of the "or" connective!

In the same vein, SRFI-2, written by Oleg Kiselyov, provides the and-let*, which is pretty much like Haskell's "do" notation over the Maybe monad (for those of you who haskel). And while the name "and-let*" is indeed a terrible one (although admittedly it does indicate that it's a combination of the "and" operator with the "let*" operator), the operator itself is very useful.

I devised its improved variant, described in the SRFI-202 document, which also has a capability of destructuring, and of receiving multiple values, and I use it a lot.

I don't have too much hands-on experience with Common Lisp to say anything significant about its coding style, but I remember how awkward it felt when I was working through Norvig's PAIP that he had to use '((t . t)) to represent empty bindings, because the empty list in Common Lisp is indistinguishable from the false value - and how much more natural it felt when I could use '() to represent empty bindings and #f to represent the match failure

#PlottingScheme