Log in

Zach Beane's Blog

Survey results: Lisp-2-ness is used by many

Thanks to the many who responded to my survey
on comp.lang.lisp
and on my
blog. It seems like more than 80% of the more than 60 people who responded
do not avoid using the same names for variables and
functions.

The original statement that inspired the survey was posted
to the arc forum a
few days ago.

Comments

I suppose this makes me a total lame-ass, but I really dislike this habit. Anything that makes symbol bindings less obvious -- even by a tiny amount -- seems to be a net loss of comprehensibility for maintenance programmers. I mean, I feel the same way about dynamic binding in OO languages so this is not really a lisp-critique per se. It just seems gratuitous.

My experience with lisp is limited to two professional gigs maintaining and extending someone else's scheme code, and some side-project toys I've written in CL and/or scheme. I enjoyed many aspects of writing lisp and would probably bite if another such job came along. But nothing ever motivated me to want to try using the lisp-2-ness of CL in my own code. I've always hated the random-guess-at-symbol-binding that comes into play in the homebrew OO systems and macrology of scheme code, and wouldn't want to make matters worse.

In general though, lisp-2-ness doesn't seem any different to me than type/type-parameter/macro/function/operator/field-name/tag/constructor/value namespace disjointness that appears in various languages, or in fact just the simpler facility of block-structured variable shadowing. And in all such cases -- everywhere outside of this "lisp-1/lisp-2" thing that seems to have stuck in lisp culture as being historically meaningful -- the outcome has more or less been "don't recycle names from legally-different namespaces". Doing so would get a patch rejected from most projects I've ever contributed to. Indeed, most language cultures I've seen wind up adopting some typographic conventions to further visually differentiate names of different "meanings", beyond what the language requires, such as UPPER_CASE_MACROS or <type-names> or *special-variables* or such. And I think that's generally a good thing. Helps the reader. Even just pragmatically, it helps dumb "readers" like grep or font-lock-mode.

Maybe I've missed something that makes functions and non-functions an especially-tasty case of shadowing or disjoint-naming?

Sampling bias?

I know you were trying to get a sense for how many people that program Lisp-2s pretend like they're Lisp-1s, but it might have been beneficial to also try to get a feel for how many use Lisp-1s because they don't like the separate-but-equal treatment of variable names found in Lisp-2s.

Perhaps my preference won't count because I have yet to do any substantial software development in either a Lisp-2 or Lisp-1, but I think that the perceived need to reuse the names of variables and functions stems from a habit of poor variable naming. Instead of calling a variable or parameter "list" or something equally nondescript, try to more accurately describe what it is. This may create some slightly longer names, but ultimately creates more readable, maintainable code.

Re: Sampling bias?

Instead of calling a variable or parameter "list" or something equally nondescript, try to more accurately describe what it is. This may create some slightly longer names, but ultimately creates more readable, maintainable code

And sometimes a name "list" is the most descriptive one you can have, if the function you are writing is general enough (and Common Lisp programmers create quite a lot of these) functons. Look for instance at the signature of MEMBER function. Or even COPY-LIST. Same goes for strings -- if I write a function that does something to any string passed in, then there's no more descriptive name for the parameter as "string".

Re: Sampling bias?

"And sometimes a name "list" is the most descriptive one you can have, if the function you are writing is general enough (and Common Lisp programmers create quite a lot of these) functons. Look for instance at the signature of MEMBER function. Or even COPY-LIST."

I disagree. The hyperspec describes it as "copy-list list => copy". But why "list"? Wouldn't "original" be both more descriptive and consistent?

I think this is another aspect of what Kent Pitman points out in his "The Best of Intentions: EQUAL Rights - and Wrongs - in Lisp" essay. Other languages conflate physical meaning and semantic meaning, but much of Lisp's power comes from not doing this: almost everything is a list, so the semantics of "a list" exist only in context, in the programmer's head and in the names of the variables. If I were to call something simply "list", it would imply I think that the physical type is its most important aspect.

After all, I know from the name "COPY-LIST" that it's a list. The important part of the arg is that it's the original. Well, in this case it's trivial, so even calling it "x" would suffice.

another note

Hi Zach,

I used to wonder why people would want separate namespaces. Then a couple things made it clear:

1) Having a separate namespace for functions means that all values in that space are functions. Thus you can avoid typechecks. I understand that Chez Scheme uses this as an implementation detail, though it is not exposed to the language.

2) Having a separate function namespace makes hygiene less of a problem. In Guile Scheme I used to unquote in values into macro expansions -- function values -- to ensure hygiene. Of course once we started to compile, that didn't work, which finally made me wary of the defmacros I used and loved for many years. Of course having modules made that problem much more acute. But in a system without modules, having functions be in there own namespace reduces hygiene problems because functions are rarely rebound lexically.