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

[Alexander Schmolck]

Ken Tilton <kentilton at gmail.com> writes:

> Alexander Schmolck wrote:
> > 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?
> 
> Transparency. 

That's is circular. You might be right, but you failed to provide a rationale
and not just a restatement.

> That is where power comes from. I did the same things with Cells. Reading a
> slot with the usual Lisp reader method transparently creates a dependency on
> the variable. 

Let me see if I understand it right -- if an instance of class A has a ruled
slot a that reads an instance of class B's slot b then it is noted somewhere
that A's a depends on b?

> To change a variable and have it propagate throughout the datamodel, Just
> Change It.
> 
> 
> Exposed wiring means more work and agonizing refactoring.

Well, you claim that in that instance python suffers from exposed wiring and I
claim that CL suffers from a (minor) booby trap. You can't typically safely
ignore whether a variable is special as a mere wiring detail or your code
won't work reliably (just as you can't typically safely ignore whether
something is rigged or not even if booby-trapness is pretty transparent) --
it's as simple as that (actually its a bit worse because the bug can be hard
to detect as lexical and special variables will result in the same behaviour
in many contexts).

So in the case of booby traps and special variables, I generally prefer some
exposed wiring (or strong visual clues) to transparency.

I'd like to see a demonstration that using the same binding syntax for special
and lexical variables buys you something apart from bugs.

'as