From 7e55d0998646666923cc31c5c86dd13be95fba87 Mon Sep 17 00:00:00 2001 From: Mark Wooding Date: Tue, 15 Dec 2015 19:15:23 +0000 Subject: [PATCH] STYLE: Some minor wording fixes. * Some actual typos. * Punt on the issue of `a ~flet~' versus `an ~flet~' and how I'm pronouncing `flet' today. --- STYLE | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/STYLE b/STYLE index c138615..c1eb705 100644 --- a/STYLE +++ b/STYLE @@ -40,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. @@ -79,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 @@ -133,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: @@ -207,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 -- 2.11.0