Subject: Re: a problem with Franz's case suggestions From: Erik Naggum <erik@naggum.net> Date: 14 Nov 2000 04:55:06 +0000 Newsgroups: comp.lang.lisp Message-ID: <3183166506151217@naggum.net> * John Foderaro <jkf@unspamx.franz.com> | So in practice what we've suggested isn't a problem but of course | it can't hurt to bind *print-case* around format call just | to be sure (or to use (symbol-name :make-) to get *print-case* | out of it entirely). You're big on "no problem in practice", but I am _very_ negative to that general attitude towards solving problems. I want correctness and adherence to specifications, not some justification that most of the time, most of the carefully worked-out specification does not matter, while the safe, general case applies. There are a number of bugs in Allegro CL that have to be coded around by funny bindings and fixes because you don't do your job correctly and according to the full specification, but assume all sorts of simplifying short-cuts for yourself. That's the New Jersey approach, not what we want in the Common Lisp world. Now, I'm not sure this is you only, but I have seen the code of many engineers at Franz Inc, and I have the greatest respect for their work, normally written with visible traces of painstaking attention to detail. I have seen some more of your work and I am not consistently impressed, to put it that way. Yes, it works, most of the time. Yes, it does useful stuff, most of the time. Yes, it is speedily written and satisfies that "we deliver" reuirement. But it is not _correct_. Like, I have been asking for fixes to the code that reads and prints symbols for a _very_ long time, only to find some fixes in ACL 6.0, but this is _still_ broken: (2) cl-user *print-base* => 10 (3) cl-user (let ((*print-base* 16)) (prin1 (list 'DEAD (intern "FACE")))) (DEAD |FACE|) => (DEAD |FACE|) It should print (|DEAD| |FACE|) and return (DEAD FACE) in Modern mode, but it prints what it does because the first time the escaped print name is cached, the base is honored, but it is not _stored_ with the optimization, so when it is different, the cache is not invalidated. You know about all this, John, since we have discussed it at great length. I argued that until the caching was fixed, it should not be enabled and that keeping the base and other parameters with the cache was crucial to _correctness_. The _impression_ I got was that this was not veryimportant because "in practice" people didn't fiddle with these special variables, but that only means it won't be a problem "in practice" either because people who try to use Allegro CL will get burned and never try to use the specification to the fullest. By a careful process of introducing such bugs, you lower the value of the standard as a tool for good programmers (never mind the mediocre ones who epitomize the "in practice" excuse) as a repository of knowledge about the language and a treasure of understanding what the language _should_ be like. To imagine that you can destroy all that important trust in a community reference simply by optimizing the printing of symbols incorrectly! You'd have to be phenomenally careless about other people's time, money, and other values _not_ to think about the _consequences_ of making such an optimization. So, rather than _defending_ the buggy code in your documentation, the responsible thing to do is to admit to the bug and fix it in the next release. I still get these really bad vibes from someone who relies on other people to "remember" something that they shouldn't have to know about, which is not part of the specification, such as which assumptions somebody else made about what the "common crowd" would or would not "normally" do, so the "most of the time" could apply. It breaks the simple and elegant and attractive ideas of abstraction and encapsulation, too, so we are left with a product that we have to know in _much_ more detail than we would need to if you had just done it right the first time. Finally, I'd like to draw people's attention to what I wrote back on 2000-11-08 in <3182670171755106@naggum.net>: * John Foderaro | If you want to see the "ferociously detailed specs", they are slightly | more than one page of html. Don't blink or you might miss it. | | http://www.franz.com/support/documentation/6.0/doc/case.htm#portability-1 Your code examples break if *print-case* is not :upcase. This is just too shoddy work to publish, John. It gets worse the more you defend it. #:Erik -- ALGORITHM: a procedure for solving a mathematical problem in a finite number of steps that frequently involves repetition of an operation. ALGOREISM: a procedure for solving an electoral problem in a finite number of steps that frequently involves repetition of an operation.