A critic of Guido's blog on Python's lambda

[Ken Tilton]

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
> languages.

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[1]) is handled in common lisp is particularly well designed or
> elegant.

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[2] 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
> anyone? 

Sh*t, you don't respond to compiler warnings? Don't blame CL for your 
problems. :)

> 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?

:)


kenny