None of ANSI Common Lisp is off-limits.
+I think my Lisp style is rather more imperative in flavour than most
+modern Lisp programmers. It's probably closer to historical Lisp
+practice in that regard, even though I wasn't writing Lisp back then.
+
I make extensive use of CLOS, and macros. On a couple of occasions I've
made macros which use CLOS generic function dispatch to compute their
expansions. The parser language is probably the best example of this in
-the codebase. I like hairy ~format~ strings.
+the codebase.
+
+I like hairy ~format~ strings.
I've avoided hairy ~loop~ for the most part, not because I dislike it
strongly but because others do and I don't find that it wins big enough
implementation: specifically, MOP introspection, and Gray streams.
There's intentionally no MOP intercession.
-The frontend additionally ~cl-launch~, but the dependency is actually
-quite weak, and it could be replaced with a different, maybe
+The frontend additionally makes use of ~cl-launch~, but the dependency
+is actually quite weak, and it could be replaced with a different, maybe
implementation-specific, mechanism fairly easily. I'm keen to take
patches which improve frontend portability.
fixing. Since I don't use hairy ~loop~ much, this isn't a major
problem.
+ + Emacs indents lambda lists really badly. I often prefer to put the
+ entire lambda list on its own line than to split it. If I have to
+ split a simple lambda list, without lambda-list keywords, I just
+ align the start of each subsequent line with the start of the first
+ argument. I break hairy lambda lists before lambda-list keywords,
+ and the start of a subsequent line aligns with the first argument
+ name following the lambda-list keyword which begins the group, so
+ that the lambda-list keyword stands out.
+
+ : (defun many-arguments (first second third
+ : fourth fifth)
+ : ...)
+
+ : (defun hairy-arguments (first second third
+ : &optional fourth fifth
+ : sixth
+ : &rest others)
+ : ...)
+
+ I don't know what I'd do if I had a hairy lambda list with so many
+ mandatory positional arguments that I had to split them. So far,
+ this situation hasn't come up.
+
Lines are 77 characters at most, except for strange special effects.
Don't ask. This is not negotiable, though. Don't try to tell me that
your monitor is very wide so you can read longer lines. My monitor is
+ Break a long nested calculation into pieces, giving names to the
intermediate results, in a ~let*~ form.
- + Hoist deeply nested complex computations out into an ~flet~ or
- ~labels~, and then invoke it from inside whatever complicated
+ + Hoist deeply nested complex computations out into ~flet~ or
+ ~labels~, and then invoke them from inside whatever complicated
conditional mess was needed to decide what to do.
+ Shrug my shoulders and let code dribble down the right hand side for
Then there's ~cl:in-package~. Like ~defpackage~, I use a gensym to name
the package. I can't think offhand of a good reason to have a file with
-sections `in' more than one package. So, in the ~in-package~ form goes
-at the top of the file, before the first section header. If sections
-are going to end up in separate packages, I think I'd put a
-~cl:in-package~ at the top of each section in case I wanted to reorder
-them.
+sections `in' more than one package. So, the ~in-package~ form goes at
+the top of the file, before the first section header. If sections are
+going to end up in separate packages, I think I'd put a ~cl:in-package~
+at the top of each section in case I wanted to reorder them.
The rest of the file consists of Lisp code. I don't use page boundaries
~^L~ to split files up. Instead, I use big banner comments for this:
implementations aggressively optimize ~defstruct~ accessor
functions.
- + Have I subclasses my class? While I can move over a
+ + Have I subclassed my class? While I can move over a
single-inheritance tree using ~:include~, it seems wrong to do this
most of the time. Also, I'd be precluding subclasses from multiple
inheritance, and I'd either have to prohibit subclassing by
+ The default predicate always has ~-p~ appended. If the class name
is a single word, then I'll explicitly name the predicate with a
simple ~p~ suffix. For example, ~ship~ would have the predicate
- ~shipp~, rather than ~ship-p~.
+ ~shipp~, rather than ~ship-p~.
+ If there are slots I can't default then I'll usually provide a BOA
constructor which sets them from required parameters; other slots
from the CLOS MOP. While I mourn the loss of whimsical names like
~haulong~ and ~haipart~, I've tried to avoid inventing more of them.
-There's a convention, which I think comes from ML, of using ~_~ in a
-where a binding occurrence of a variable name is expected, to signify
-that that the corresponding value is to be discarded. Common Lisp,
-alas, doesn't have such a convention. Instead, there's a sequence of
-silly names used with the same intention, and the bindings are then
-explicitly ignored with a declaration. The names begin ~hunoz~,
-~hukairz~, and (I think) ~huaskt~.
+There's a convention, which I think comes from ML, of using ~_~ where a
+binding occurrence of a variable name is expected, to signify that that
+the corresponding value is to be discarded. Common Lisp, alas, doesn't
+have such a convention. Instead, there's a sequence of silly names used
+with the same intention, and the bindings are then explicitly ignored
+with a declaration. The names begin ~hunoz~, ~hukairz~, and (I think)
+~huaskt~.
* Declarations
up into a number of different parts of the expansion, which in turn
requires figuring out what the declarations mean and which bindings
they're referring to. That's not completely impossible, assuming that
-there aren't implementation-specific declarations which crazy syntax
+there aren't implementation-specific declarations with crazy syntax
mixed in there, but it's more work than seems worthwhile.
~mdw / sod / blobdiff