45f150f813d7

PUSH
[view raw] [browse files]
author Steve Losh <steve@stevelosh.com>
date Sun, 12 Aug 2018 15:35:27 +0000
parents 63c2a02ed78c
children 2a1c58e03bc2
branches/tags (none)
files content/blog/2018/08/a-road-to-common-lisp.markdown

Changes

--- a/content/blog/2018/08/a-road-to-common-lisp.markdown	Sat Aug 04 13:28:40 2018 -0700
+++ b/content/blog/2018/08/a-road-to-common-lisp.markdown	Sun Aug 12 15:35:27 2018 +0000
@@ -665,18 +665,20 @@
 well-written grab bag that will teach you a lot of things you won't find in
 other books.
 
-### Patterns
+### Final Patterns
 
 If you've gotten this far you're pretty invested in Common Lisp, and I want to
-recommend one non-technical book that I think you'll really enjoy: [Patterns of
-Software][] by Richard Gabriel.  Unfortunately I don't think it's available as
-an eBook and it's out of print, so you'll need to track down a used copy.
+recommend one not-strictly-technical book that I think you'll really enjoy:
+Patterns of Software by Richard Gabriel.  It's available as a PDF on [the
+author's site][], and you can still find used print copies online if you prefer.
 
 This is *not* the "Gang of Four"/"Design Patterns" book that you might have
-already read or heard about, but is a set of essays by one of the original
-designers of Common Lisps on a variety of topics.  It's the best book I've read
-so far this year.  I don't want to spoil anything in it for you, so I'll just
-say that I think you'll find it well worth the effort of finding and reading it.
+already read or heard about, but is a set of essays on a variety of
+loosely-related topics.  It's the best book I've read so far this year.  I don't
+want to spoil anything in it for you, so I'll just say that I think you'll find
+it well worth your time.
+
+[pos]: https://www.dreamsongs.com/Books.html
 
 ## Where to Go From Here
 
@@ -1020,64 +1022,6 @@
 * ASDF adds systems.
 * Quicklisp adds the internet.
 
-#### Naming Conventions
-
-One more small thing we should talk about before moving on is how to name
-things.  This section is only my personal opinion, so some other folks will
-probably disagree.  You should consider their arguments and your own needs and
-decide for yourself.
-
-You can name your packages anything you want, but your users will thank you if
-you follow a couple of simple rules.  First, don't do the overly-verbose style
-of naming packages like `com.stevelosh.cl-digraph.digraph`.  Unfortunately
-Common Lisp doesn't have a portable way to add package-local nicknames, so
-naming your packages like this means that users will have to type that entire
-giant name whenever they wanted to refer to a symbol without importing it, like
-`(com.stevelosh.cl-digraph.digraph:successors graph vertex)` instead of
-`(digraph:successors graph vertex)`.  This is just as miserable to read as it is
-to write.
-
-On the flip side: don't try to be overly clever and use a one or two letter name
-for your packages.  Common Lisp's packages are in a global namespace, and if
-more than one library tries to claim the same two-letter name it causes
-problems.  An example of this is Bordeaux Threads which has a package called
-`bt`.  It's too late to change this now, but try to avoid such easily-clashing
-names when making new packages.  I'd even try to avoid three or four letter
-names, but I'll admit I've broken this rule myself a couple of times.
-
-Another question that comes up is: "I see a lot of projects called `cl-whatever`
-— should I name my projects with the `cl-` prefix?".  Some Common Lispers hate
-the `cl-` prefix and never use it.  I personally prefer this style for two
-specific cases:
-
-* A Common Lisp wrapper around something else, like `cl-cudd` (not written by
-  me), which is a set of bindings to the TODO C++ CUDD library.
-* A Common Lisp implementation of a well-known data structure or protocol like
-  `cl-digraph`.
-
-Not using the `cl-` prefix in this case would feel confusing to me, because
-you'd just be calling the project `cudd` which would be easy to confuse with the
-actual library itself.
-
-For anything that's not one of these two cases I prefer to come up with a unique
-name instead.  Sometimes it's a pun or just something that sounds unique — the
-critical part is that it doesn't conflict with anything already in Quicklisp.
-
-When you *do* use the prefix, the next question is what parts of the project get
-the prefix.  This comes down to personal preference.  Here are my personal
-rules:
-
-* The project, Mercurial/Git repository, etc have the `cl-` prefix (e.g.
-  `https://github.com/sjl/cl-digraph`).
-* The system(s) should have the same name as the project, so it also gets the
-  prefix (e.g. `cl-digraph`).
-* The packages are going to be typed frequently, and we're *firmly* in Common
-  Lisp territory at the point where we're defining packages, so it's safe to
-  drop the prefix for packages (e.g. `digraph`).
-
-Other people (including my past and future selves) might disagree on some of
-these conventions.  Feel free to take them with a large grain of salt.
-
 ### Common Libraries
 
 Common Lisp doesn't have a *large* of a community as some newer languages, but