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

Alexander Schmolck a.schmolck at gmail.com
Fri May 12 23:10:58 CEST 2006


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

I thought it would have been pretty obvious that I was talking about language
design features and language design misfeatures (Indeed the infamously post
hoc, "It's a feature, not a bug" I was obviously alluding too doesn't make
much sense in a world were everything is tightly specified, because in it
nothing is post-hoc).

>, which has a spec.

Bah -- so does fortran. But scheme also has operational semantics.

> Now, what was your rationale for it _being_ a bug?

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.

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 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? There are also inconsistent conventions for naming (local) special
variables within the community (I've seen %x%, *x* and x)).

Thus I don't see having to use syntactically different binding and assignment
forms for special and lexical variables as inherently inferior.

But I might be wrong -- which is why was asking for the rationale of Kenny's
preference. I'd be even more interested in what you think (seriously; should
you consider it a design feature (for reasons other than backwards
compatiblity constraints), I'm pretty sure you would also give a justification
that would merrit consideration).

'as

Footnotes: 
[1] The space of what I see as orthogonal features (parallel vs. serial
    binding, single vs. multiple values and destructuring vs non-destructuring
    etc.) is sliced in what appear to me pretty arbitrary, non-orthogonal and
    annoying (esp. superfluous typing and indentation) ways in CL.

[2] Generally declarations don't change the meaning of an otherwise
    well-defined program. The special declaration does. It's also a potential
    source of errors as the declaration forces you to repeat yourself and to
    pay attention to two places rather than one.




More information about the Python-list mailing list