Re: Let Over Lambda chapter 4
- From: Rainer Joswig <joswig@xxxxxxx>
- Date: Sat, 28 Jun 2008 02:31:54 +0200
In article
<34e7da66-0b73-4f36-9cf7-196e2f52df5c@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Doug Hoyte <doug@xxxxxxxx> wrote:
....
Why I don't put asterisks on special variables
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Several people have asked me to clarify why I don't use the
*earmuff* convention for special variables, so here goes.
First of all, I'm not convinced that unexpected collisions
are unconditionally bad. The way I look at it, you always
learn something when you encounter a collision and you
never learn anything when you don't.
My instinct tells me that the earmuff convention is
dangerous, or at least that it isn't nearly as open-shut
an issue as everyone seems to think. For example, what
sort of binding is this?
(let (*hello*)
...)
It is a lexical binding because I haven't declared *hello*
to be special yet. But that's not what you thought when
you first looked at it, was it?
Naming conventions are not enforced. But they
mark intentions. *hello* tells us that it
was supposed to be a special variable and if it
isn't, it better be fixed in the source.
Naming special variables like that should give
the reader (remember the quote that code is
not just for computers to execute, but also for human
readers) some additional hints.
Or consider this: If you are dogmatic about the earmuffs,
why stop there?
Right, the are lots of naming conventions you find in Lisp
software. %foo for internal definitions or non-portable
definitions. fooF for macros that take a place
like INCF. predicate-p for predicates that return a
boolean value. +foo+ for constants. make-something
for functions that create some kind of object.
using-foo for something that uses some object
in its scope. Plus many more.
How about a print-name convention for
distinguishing between macros and functions? Instead of
with-open-file, we could call it ^with-open-file^ so that
we wouldn't need to remember that it is a macro instead of
a function. This convention would also reduce collisions
like accidentally trying to funcall a macro.
the prefix with- is already the convention that
tells us that it is a macro creating some kind of
scope. There are other conventions used for special
types of macros like
* DEFsomething or DEFINE-SOMETHING
* doING
* DOsomething
Would you use this convention? No, of course you wouldn't.
I already use the with- convention.
It's stupid. Instead of relying on a semantically meaningless
print-name convention, it is a better idea to just name
your macros and functions appropriately in the first place.
I guess I'm trying to say that I consider the following fact
to be a feature, not a flaw of Common Lisp: Functions and
macros, along with lexical and special bindings, look the
same in Common Lisp.
They don't look the same in code I read. Pick any
Lisp application, look at the main files and
count the different naming conventions used.
There are lots of naming conventions.
For macros there are also lots of structure conventions.
IMHO naming conventions are extremely important and
can be very helpful. My goal is not to make everything
to look the same (foo bar baz). My goal would be to
use appropriate naming for the program structure at
hand. Personally I like special variables to stand out.
There are some other conventions I'm not so interested
in - like everywhere encoding type information
in identifiers.
Hope this helps clarify my reasoning,
Doug Hoyte
Strategic Lead API Designer, HCSW
PS. Come to think of it, not even the standard is dogmatic
about the earmuffs. There are at least 6 special variables
defined by ANSI that don't begin and end with asterisks.
Most special variables in ANSI CL that are intended to be bound are
following the *foo* convention.
--
http://lispm.dyndns.org/
.
- Follow-Ups:
- Re: Let Over Lambda chapter 4
- From: Doug Hoyte
- Re: Let Over Lambda chapter 4
- References:
- Let Over Lambda chapter 4
- From: Doug Hoyte
- Let Over Lambda chapter 4
- Prev by Date: Let Over Lambda chapter 4
- Next by Date: Re: Let Over Lambda chapter 4
- Previous by thread: Let Over Lambda chapter 4
- Next by thread: Re: Let Over Lambda chapter 4
- Index(es):
Relevant Pages
|
