Alexander Schmolck wrote: > Duane Rettig <[EMAIL PROTECTED]> writes: > > >>Alexander Schmolck <[EMAIL PROTECTED]> writes: >> >> >>>Ken Tilton <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list