A critic of Guido's blog on Python's lambda
kentilton at gmail.com
Sat May 13 02:06:32 CEST 2006
Alexander Schmolck wrote:
> Duane Rettig <duane at franz.com> writes:
>>Alexander Schmolck <a.schmolck at gmail.com> writes:
>>>Ken Tilton <kentilton at gmail.com> writes:
>>>>In Common Lisp we would have:
>>>> (defvar *x*) ;; makes it special
>>>> (setf *x* 1)
>>>> (print *x*) ;;-> 1
>>>> (let ((*x* 2))
>>>> (print *x*)) ;; -> 2
>>>> (print *x*) ;; -> 1
>>>You seem to think that conflating special variable binding and lexical
>>>variable binding is a feature and not a bug. What's your rationale?
I will expand on my earlier "transparency" rationale with a further
rationale for transparency: I do not need no stinkin' rationale. A
special variable is still a variable. They should be set, read, and
bound (say, by "let") the same way as any other variable.
You need a rationale. It sounds as if you want some noisey syntax to
advertise the specialness. I do not think the Python community will
appreciate you messing up their pretty code.
You are right about one thing: specialness needs advertising. You know
what we do in Lisp? We obediently name special variables with bracketing
*s, like *this*. Too simple?
>>A bug is a non-conformance to spec.
> There is a world beyond specs, you know. If copies of allegro CL accidently
> sent out death-threats to the US president on a weekly basis, because someone
> at franz accidently or purposefully left in some pranky debugging code the
> fact that this behaviour would likely neither violate the ansi spec nor any
> other specs that ACL officially purports to adhere to wouldn't make it any
> less of a bug (or help to pacify your customers).
>>Kenny's statement was specifically about Common Lisp
> No Kenny's statement was about contrasting the way something is done in python
> and the way something is done in common lisp (with the implication that the
> latter is preferable).
Close, but no. The question I was weighing in was "has Michele
replicated special variables?". My implication was, "Not yet -- can you
match the transparency?", and it was an honest question, I do not know.
Again, transparency is a qualitative difference.
I liked your solution better, btw, because it does minimize the noise.
For fun, you should call the class ** instead of special, so we end up
with: **.b = 42
We'll understand. :)
> Of course the way something is done in common lisp is
> almost tautologically in closer agreement with the ansi common lisp spec than
> the way it is done in python, so agreement with the clhs is not a useful
> criterion when talking about design features and misfeatures when contrasting
Again, no, it is not the spec, it is the highly-valued Python quality of
clean code. Also, the consistency of treating variables as variables,
regardless of some special/dynamic quality.
Some background. Lisp is a big language, and I am self taught and do not
like to read, grew up in Lisp in isolation. Not many Lispers in the
exercise yard. Discovered special variables only when we hired an old
hand who gently corrected a howler:
(let* ((old-x *x*))
(setf *x* 42)
(setf *x* old-x))
I still laugh at that. Anyway, as soon as I learned that, I was able to
make Cells syntax infinitely more transparent. And guess what? It also
made dependency identification automatic instead of cooperative, and
when I rebuilt a huge Cells-based app I discovered two or three cases
where I had neglected to publish a dependency.
It's a mystery, but somehow simpler syntax... oh, wait, this is
c.l.python, I am preaching to the choir.
> I just don't think the way special variable binding (or variable binding in
> general) is handled in common lisp is particularly well designed or
See above. There is nothing like a concrete experience of implementing a
hairy library like Cells /without/ leveraging specials and then
converting to specials. Talk about an Aha! experience. I mean, bugs ran
screaming from their nests simply because of the implementation change--
we call that A Message From God that the design has taken a correct turn.
> Special variables and lexical variables have different semantics and using
> convention and abusing the declaration mechanism to differentiate between
> special and lexical variables doesn't strike me as a great idea.
I know what you mean, but I like reading tea leaves, and I find it
fascinating that *this* somehow eliminates all ambiguity. Background:
don't know where I might find it, but I once saw a thread demonstrating
the astonishing confusion one could create with a special variable such
as a plain X (no *s). Absolutely mind-bogglingly confusing. Go back and
rename the special version *x*, and use *x* where you want to rebind it.
Result? Utterly lucid code. Scary, right?
> I can certainly think of problems that can occur because of it (E.g. ignoring
> or messing up a special declaration somewhere; setf on a non-declared variable
Sh*t, you don't respond to compiler warnings? Don't blame CL for your
> There are also inconsistent conventions for naming (local) special
> variables within the community (I've seen %x%, *x* and x)).
OK, you are in flamewar mode, now you are just making things up.
> Thus I don't see having to use syntactically different binding and assignment
> forms for special and lexical variables as inherently inferior.
DUDE! They are both variables! Why the hell /should/ the syntax be
different? "Oh, these are /cross-training/ sneakers. I'll wear them on
my hands." Hunh?
More information about the Python-list