From ... From: Erik Naggum Subject: Re: ANSI spec brain damaged wrt case in dispatch macro char Date: 2000/12/03 Message-ID: <3184871207489902@naggum.net> X-Deja-AN: 700740564 References: <3A268F3E.5F4CA36A@cs.berkeley.edu> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 975885422 26675 195.0.192.66 (3 Dec 2000 23:17:02 GMT) Organization: Naggum Software; vox: +47 800 35477; gsm: +47 93 256 360; fax: +47 93 270 868; http://naggum.no; http://naggum.net User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 Mime-Version: 1.0 NNTP-Posting-Date: 3 Dec 2000 23:17:02 GMT Newsgroups: comp.lang.lisp * Richard Fateman | At the risk of tossing gasoline on a fire that has | almost burned out... I think using "braindamaged" about a technical decision like this is indicative of a lack of interest in solving a problem and a desire to toss gasoline on the embers to start a new fire aflaming. | I thought what a great application for read table hacking. Really? That doesn't look awfully smart to me, but OK, let's assume it's a possible application of read tables, not contrived gasoline. | Clearly I should make [ into a dispatch character, and I should use | set-dispatch-macro-character to do the processing of the next | modifier character, e.g. F or s in the examples above, and collect | the arguments. I'd think it would be a lot smarter to read the "list" in as a whole since you would have to read up to the enclosing ] in every "macro", associate functions with the characters, strings, or symbols that make up the first object, and call the function associated with the first object when you hit that final ]. | This clear win turns into a sour taste, when debugging since lisp | forbids you from separately doing | | (set-dispatch-macro-character #\[ #\s .... ) | (set-dispatch-macro-character #\[ #\S .... ) | | from the ANSI spec. | set-dispatch-macro-character causes new-function to be called | when disp-char followed by sub-char is read. If sub-char is a | lowercase letter, it is converted to its uppercase equivalent. | It is an error if sub-char is one of the ten decimal digits. This is a valid _complaint_, of course, even though the application still seems contrived to cause an unnecessary problem and conflict. A proposal that should be both backward compatible and easy to implement: The _standard_ dispatch macro characters are defined for the standard-case letters ("standard-case" being defined in a proposal yet to be published, pretend it reads "uppercase" if you really have to) and the case of the character _read_ should be adjusted according to the readtable-case of the readtable prior to dispatching. That is, it was a design flaw to introduce case knowledge in the function that sets up the dispatch tables. The problem of case gets bigger according as the character sets get bigger. Since modern languages should support Unicode natively and efficiently and this is hard to accomplish if you want to maintain a case-insensitivity throughout the entire character set and system, we need to rethink our character sensitivity needs a little bit. It is _not_ hard to implement case-insensitivity in the Lisp reader as we read character by character and already have to do a number of costly conversions, anyway. E.g., a character object could easily contain information about the case and the distance in the code space to the corresponding character of the other case. (This holds for everything but three _stupidly_ transliterated characters from Cyrillic to Latin or whatever, but people who actually _use_ those should just be shot, anyway, so I'll pull a Foderaro and say that "in practice" it is not a problem, with nigh a thought for the doofuses who wanted those wacky "characters" in the first place.) | Thus the ANSI spec insists on changing #\s into #\S. That's an amazingly inaccurate statement. | This seems totally brain-damaged to me. It requires that I dispatch | to #\S and then look again at the sub-char to see if it was #\s or | #\S, in effect dispatching AGAIN. (defun macro-case-dispatch (uppercase lowercase) (lambda (stream char infix) (let ((call (if (upper-case-p char) uppercase lowercase))) (if call (funcall call stream char arg) #+allegro (excl::dispatch-char-error stream char arg))))) Now you can do straightforward stuff like this: (set-dispatch-macro-character #\# #\Z (macro-case-dispatch #'FOOBAR #'foobar)) I don't think this seems brain-damaged at all, but it probably still seems "totally brain-damaged" to you, since you aren't going to accept any other solution than "the standard is broken because upper-case is insane", isn't that right? | I wonder if there are other places that the ANSI standard specifies | that --even though you wrote the backslashed character in lower case-- | that it will change it to upper case. Well, char-upcase is a rather obvious candidate. :) | While I suppose there is some theological argument defending this | decision, (and, by the way, Franz seems to abide by ANSI in this | instance), I think it would be nice to have a | set-dispatch-macro-character-retaining-case function, which could | trivially be used to implement the brain-damaged version by | upper-casing its 2nd argument. The reverse transformation is not | trivial. However dubious your "braindamage" label about the case problems in general, _that_ is a truly braindamaged solution to your "problem". After having watched not one, but two, astonishingly stupid ways _not_ to deal with the upper-case issue in ANSI Common Lisp, I must wonder whether the desire to be _annoyed_ by upper-case issues has caused a few old Lispers to go slightly bananas, making them miss some obvious technical solutions to their problems in preference to broken, stupid non-solutions that do nothing but show people how irrationally annoyed _they_ are with the upper-case decision. This is more than bitterness at having to deal with a standard and people who voted them down in a committee, which probably would never have happened if they had been only _somewhat_ less antagonistic to upper-case to begin with, How can you _fail_ to get the majority of a committee to agree with you that lower-case is better than upper-case, when that clearly is the simplest, best, most obvious solution? My take: Accuse your opponents of suffering braindamaged _before_ you have even presented your case, and prefer to continue to call them braindamaged while you utterly fail to present a better technical solution to _their_ concerns. _I'm_ annoyed with the proponents of a lower-case Common Lisp that had a chance to affect the standard, because if _they_ had not been so braindamaged, maybe we would've had a lower-case symbol names today. #:Erik -- "When you are having a bad day and it seems like everybody is trying to piss you off, remember that it takes 42 muscles to produce a frown, but only 4 muscles to work the trigger of a good sniper rifle." -- Unknown