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

Alexander Schmolck a.schmolck at gmail.com
Sat May 13 01:42:40 CEST 2006

Duane Rettig <duane at franz.com> writes:

> My reason for responding to you in the first place was due to your poor use
> of the often misused term "bug".  You could have used many other words or
> phrases to describe the situation, and I would have left any of those alone.

I'm happy to accept your terminology of bug (not conforming to a certain
specification) for the remainder of this discussion so that we can stop
quibbling over words.

> > 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).
> Well, OK, let's change the conversation away from "bug"-ness and toward any of
> the other negatives we discussed above.  I actually doubt that I can provide
> a justification in a small space without first understanding who you are
> and from what background you are coming, so let me turn it around and ask
> you instead to knock down a straw-man:
> You seem to be saying that pure lexical transparency is always preferable
> to statefulness (e.g. context).


> Can we make that leap? If not, set me straight. 

I think that in most contexts lexical transparency is desirable so that
deviations from lexical transparency ought to be well motivated. I also
believe that a construct that is usually used to establish a lexically
transparent binding shouldn't be equally used for dynamic bindings so that it
isn't syntactically obvious what's going on. I've already provided some
reasons why CL's design wrt. binding special and lexical variables seems bad
to me. I don't think these reasons were terribly forceful but as I'm not aware
of any strong motivation why the current behaviour would be useful I'm
currently considering it a minor wart.

To make things more concrete: What would be the downside of, instead of doing
something like:

(let ((*x* ...)) [(declare (special *x*))] ...) ; where [X] denotes maybe X

doing any of the below:

a) using a different construct e.g. (fluid-let ((*x* ...)) ...) for binding
   special variables
b) having to use *...* (or some other syntax) for special variables
c) using (let ((q (special *x*) (,a ,b , at c)) (values 1 2 '(3 4 5 6)))
              (list q ((lambda () (incf *x*))) a b c)) ; => (1 3 3 4 (5 6))

(It's getting late, but hopefully this makes some vague sense)

> If so, tell me: how do we programmatically model those situations in life
> which are inherently contextual in nature, where you might get a small piece
> of information and must make sense of it by drawing on information that is
> _not_ given in that information, but is (globally, if you will) "just known"
> by you? How about conversations in English? And, by the way, how do you
> really know I'm writing to you in English, and not some coded language that
> means something entirely different?

We can skip that part.


More information about the Python-list mailing list