src/method-impl.lisp: Initialize `suppliedp' flags properly.

[sod] / STYLE

diff --git a/STYLE b/STYLE
index 12e848a302798437704c934fb065b5a915af2bb5..c1eb705597029ea137ba8716760cdca923e82cb8 100644 (file)
--- a/STYLE
+++ b/STYLE
@@ -4,10 +4,16 @@ Notes on Lisp style
 
 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
@@ -34,8 +40,8 @@ beyond ANSI Common Lisp and what's included in just about every serious
 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.
 
@@ -73,8 +79,8 @@ this.
   + 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
@@ -127,11 +133,10 @@ package definition file.
 
 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:
@@ -201,7 +206,7 @@ questions influence my decision.
     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
@@ -217,7 +222,7 @@ making a new structure type.  I tend to tidy up a few rough edges.
   + 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