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

[Duane Rettig]

Alexander Schmolck <a.schmolck at gmail.com> writes:

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

It wouldn't be a bug in Allegro CL, because it would never happen in an Allegro CL
that hasn't been enhanced with some kind of program.  And although that program
itself could have a bug whereby such a threat were accidental, I would tend not
to call it accidental, I would tend to call it expicit, and thus not a bug but
an intended consequence of such explicit programming.

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.

For example:

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

Whether it is preferable is a matter of opinion, and whether Kenny meant it
to infer preferability (I suspect so) or not has nothing to due with whether
it is a bug.  Instead, you should call it a "design misfeature", which would
set the stage for a more cogent argumentation on the point, rather than on the
hyperbole.  By the way, if you do call it a design misfeature, I would be
arguing against you, but that is another conversation.

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

Then call it "misdesigned" or "inelegant".

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

Then call it a "bad 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)).

Then call it "not fully standardized or normative".

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

Then call it "inherently inferior".

> But I might be wrong -- which is why was asking for the rationale of Kenny's
> preference.

But you _didn't_ ask him what rationale he had for his _preference_, you
asked him his rationale for considering it not a _bug_.

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

-- 
Duane Rettig    duane at franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182