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