From: Pascal B. <pj...@in...> - 2002-12-23 20:29:42
|
Did I miss something? With the default behavior of the reader, all symbols are converted to uppercase, aren't they. When you do (describe (find-package "COMMON-LISP")), you get a list of exported symbols all in upper case, and you can type: (car (Car (cAR (CAR '(((((a b ) c) d) e) f))))) to get (A B). Ok. But (describe (find-package "LINUX")) shows that all the symbols def-call-out'ed are in low case, so up to now, I've been typing LINUX:|access| and so on. But it seems that LINUX:access works too (while LINUX:ACCESS does not. Is that correct? How comes in that case the reader does not uppercase LINUX:access? Isn't that a dirty hack? [15]> (linux:|access| "/tmp" 1) ;; Works as expexted. 0 [16]> (linux:access "/tmp" 1) ;; Works too, surprisingly! 0 [17]> (linux:ACCESS "/tmp" 1) ;; Does not work as expected. *** - READ from #<INPUT CONCATENATED-STREAM #<INPUT STRING-INPUT-STREAM> #<IO SYNONYM-STREAM *TERMINAL-IO*>>: #<PACKAGE LINUX> has no external symbol with name "ACCESS" 1. Break [18]> And finally, shouldn't we lispify the symbols in LINUX and have all of them in upper case? (Personal taste: while I understand that this upper case orientation of LISP comes from its long history, I prefer case sensitivity, for example as implemented in emacs lisp (ie. with standard symbols in lower case) ; too bad standadizers of Common-Lisp choosed historical behavior). -- __Pascal_Bourguignon__ http://www.informatimago.com/ ---------------------------------------------------------------------- There is a fault in reality. do not adjust your minds. -- Salman Rushdie |
From: Kaz K. <ka...@as...> - 2002-12-23 21:04:31
|
On Mon, 23 Dec 2002, Pascal Bourguignon wrote: > Date: Mon, 23 Dec 2002 21:29:29 +0100 (CET) > From: Pascal Bourguignon <pj...@in...> > To: cli...@li... > Subject: [clisp-list] symbol cases > > > Did I miss something? > > With the default behavior of the reader, all symbols are converted to > uppercase, aren't they. Yes; this is controlled by the readtable-case property of the read-table. > When you do (describe (find-package "COMMON-LISP")), you get a list of > exported symbols all in upper case, and you can type: > (car (Car (cAR (CAR '(((((a b ) c) d) e) f))))) > to get (A B). Ok. > > But (describe (find-package "LINUX")) shows that all the symbols > def-call-out'ed are in low case, so up to now, I've been typing > LINUX:|access| and so on. Yes; that's because the symbols in that package are simply defined that way. It's horribly inconvenient. For that reason, and its nonportability, I don't use that package any longer. > [15]> (linux:|access| "/tmp" 1) ;; Works as expexted. > 0 > [16]> (linux:access "/tmp" 1) ;; Works too, surprisingly! > 0 > [17]> (linux:ACCESS "/tmp" 1) ;; Does not work as expected. > > *** - READ from > #<INPUT CONCATENATED-STREAM #<INPUT STRING-INPUT-STREAM> > #<IO SYNONYM-STREAM *TERMINAL-IO*>>: #<PACKAGE LINUX> has no external symbol with name "ACCESS" Strange. What does (readtable-case *readtable*) say at that point? > And finally, shouldn't we lispify the symbols in LINUX and have all of > them in upper case? It would be far more convenient, indeed. > (Personal taste: while I understand that this upper case orientation > of LISP comes from its long history, I prefer case sensitivity, for > example as implemented in emacs lisp (ie. with standard symbols in > lower case) ; too bad standadizers of Common-Lisp choosed historical > behavior). This is not a matter of personal taste at all. The way Lisp does it is more useful than naive case sensitivity, but more technically correct than case insensitivity. The standardizers did the right thing by keeping the best possible design, which accomodates the useful qualities of both. Lisp symbol names *are* in fact case sensitive, and can be arbitrary strings. This is a necessity, which allows Lisp to interface with arbitrary languages; symbols from another language can be represented directly as Lisp symbols without having to undergo some name translation. If you ever write a compiler in Lisp for some other language, you will be glad. On the other hand, transforming case on input in the reader or output in the formatter is quite useful. One benefit is that in an interactive session, the stuff printed by the machine is all caps. So if you type in all lowercase, you can easily separate the conversation without the need to resort to a different font or color. I have been psychologically conditioned into accepting and preferring the case sensitivity by Unix and C; but I'm not jaded enough to fail to remember that I indeed had problems with it once upon a time. My perspective does not represent the norm. ;) |
From: Sam S. <sd...@gn...> - 2002-12-23 22:42:14
|
> * In message <200...@th...> > * On the subject of "[clisp-list] symbol cases" > * Sent on Mon, 23 Dec 2002 21:29:29 +0100 (CET) > * Honorable Pascal Bourguignon <pj...@in...> writes: > > Did I miss something? the manual? :-) <http://clisp.cons.org/impnotes/pack-dict.html> or maybe the sources? :-) <modules/bindings/linuxlibc6/linux.lisp> > But (describe (find-package "LINUX")) shows that all the symbols > def-call-out'ed are in low case, so up to now, I've been typing > LINUX:|access| and so on. But it seems that LINUX:access works too > (while LINUX:ACCESS does not. Is that correct? How comes in that case > the reader does not uppercase LINUX:access? Isn't that a dirty hack? "LINUX" is a case-sensitive package. -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> Sinners can repent, but stupid is forever. |
From: Pascal B. <pj...@in...> - 2002-12-24 02:12:44
|
Sam Steingold writes: > Pascal Bourguignon <pj...@in...> wrote: > > > > Did I miss something? > > the manual? :-) <http://clisp.cons.org/impnotes/pack-dict.html> > or maybe the sources? :-) <modules/bindings/linuxlibc6/linux.lisp> > > > But (describe (find-package "LINUX")) shows that all the symbols > > def-call-out'ed are in low case, so up to now, I've been typing > > LINUX:|access| and so on. But it seems that LINUX:access works too > > (while LINUX:ACCESS does not. Is that correct? How comes in that case > > the reader does not uppercase LINUX:access? Isn't that a dirty hack? > > "LINUX" is a case-sensitive package. That's it. Clearly not a standard feature... Thank you. -- __Pascal_Bourguignon__ http://www.informatimago.com/ ---------------------------------------------------------------------- There is a fault in reality. do not adjust your minds. -- Salman Rushdie |
From: Pascal B. <pj...@in...> - 2002-12-24 02:41:49
|
Kaz Kylheku writes: > > [15]> (linux:|access| "/tmp" 1) ;; Works as expexted. > > 0 > > [16]> (linux:access "/tmp" 1) ;; Works too, surprisingly! > > 0 > > [17]> (linux:ACCESS "/tmp" 1) ;; Does not work as expected. > > > > *** - READ from > > #<INPUT CONCATENATED-STREAM #<INPUT STRING-INPUT-STREAM> > > #<IO SYNONYM-STREAM *TERMINAL-IO*>>: #<PACKAGE LINUX> has no external symbol with name "ACCESS" > > Strange. What does (readtable-case *readtable*) say at that point? The default: [1]> (readtable-case *readtable*) :UPCASE [2]> (linux:access "/tmp" 1) 0 As Sam said, it's because LINUX is a case-sensitive package (clisp incompatible stuff). > > And finally, shouldn't we lispify the symbols in LINUX and have all of > > them in upper case? > > It would be far more convenient, indeed. > > (Personal taste: while I understand that this upper case orientation > > of LISP comes from its long history, I prefer case sensitivity, for > > example as implemented in emacs lisp (ie. with standard symbols in > > lower case) ; too bad standadizers of Common-Lisp choosed historical > > behavior). > > This is not a matter of personal taste at all. The way Lisp does it is > more useful than naive case sensitivity, but more technically correct > than case insensitivity. The standardizers did the right thing by > keeping the best possible design, which accomodates the useful > qualities of both. > > Lisp symbol names *are* in fact case sensitive, and can be arbitrary > strings. This is a necessity, which allows Lisp to interface with > arbitrary languages; symbols from another language can be represented > directly as Lisp symbols without having to undergo some name > translation. If you ever write a compiler in Lisp for some other > language, you will be glad. > > On the other hand, transforming case on input in the reader or output > in the formatter is quite useful. One benefit is that in an > interactive session, the stuff printed by the machine is all caps. So > if you type in all lowercase, you can easily separate the conversation > without the need to resort to a different font or color. As I said: "history". That is, more than 30 years old. Well do you still run LISP code 30 years old? Not much here. I would even bet that more new common-lisp code will written this year than what has been from the origins to 10 years ago. Now, let's see, when was the last time I had to read a listing printed on a teletype where the distinction with low case/up case would have been handy? Something like 25 years ago. And then, the tty only printed upper case! Since then, all the computers have had color or distinct fonts (mind it, Lisa is 21 years old and Macintosh is 19 years old!). Clearly, if I don't (setf (readtable-case *readtable*) :preserve) right now, it's because I may have to use other common-lisp code that I don't want to have to edit first. It would be better if the standard specified :preserve... Since it does not, you find sources that are either in low case, in up case or mixed, and you cannot change it. If the standard was :preserve, you could set :upcase anytime if it was necessary for "user interface" reasons. > I have been psychologically conditioned into accepting and > preferring the case sensitivity by Unix and C; but I'm not jaded > enough to fail to remember that I indeed had problems with it once > upon a time. My perspective does not represent the norm. ;) Yes, me too. Mine too. Unfortunately. -- __Pascal_Bourguignon__ http://www.informatimago.com/ ---------------------------------------------------------------------- There is a fault in reality. do not adjust your minds. -- Salman Rushdie |
From: Sam S. <sd...@gn...> - 2002-12-24 04:38:43
|
> * In message <158...@th...> > * On the subject of "[clisp-list] Re: symbol cases" > * Sent on Tue, 24 Dec 2002 03:41:19 +0100 > * Honorable Pascal Bourguignon <pj...@in...> writes: > > As Sam said, it's because LINUX is a case-sensitive package (clisp > incompatible stuff). this is a _perfectly_ _compatible_ _extension_. it does not break any "conforming programs". yes, case-sensitive packages are not a "standard feature", but neither are sockets, weak hash tables &c &c. if you do not like this feature (case-sensitive packages), you do not have to use it. if you prefer that "LINUX" is a case-insensitive package, you may ask Bruno why he made it case-sensitive and try to convince him that he made a mistake. -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> MS DOS: Keyboard not found. Press F1 to continue. |
From: Pascal B. <pj...@in...> - 2002-12-24 07:23:40
|
Sam Steingold writes: > > * In message <158...@th...> > > * On the subject of "[clisp-list] Re: symbol cases" > > * Sent on Tue, 24 Dec 2002 03:41:19 +0100 > > * Honorable Pascal Bourguignon <pj...@in...> writes: > > > > As Sam said, it's because LINUX is a case-sensitive package (clisp > > incompatible stuff). > > this is a _perfectly_ _compatible_ _extension_. > it does not break any "conforming programs". > yes, case-sensitive packages are not a "standard feature", > but neither are sockets, weak hash tables &c &c. True. I looked at make-package instead of defpackage. Sorry. > if you do not like this feature (case-sensitive packages), > you do not have to use it. > > if you prefer that "LINUX" is a case-insensitive package, you may ask > Bruno why he made it case-sensitive and try to convince him that he made > a mistake. Well, if we take that it's a CLISP on linux specific package, it does not matter. It was just surprising to see that the reader behaved specially for the LINUX package. -- __Pascal_Bourguignon__ http://www.informatimago.com/ ---------------------------------------------------------------------- There is a fault in reality. do not adjust your minds. -- Salman Rushdie |