[clisp-list] symbol cases

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

Thread view

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

On Mon, 23 Dec 2002, Pascal Bourguignon wrote:
> Date: Mon, 23 Dec 2002 21:29:29 +0100 (CET)
> From: Pascal Bourguignon <pjb@...>
> To: clisp-list@...
> 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. ;)

Sam Steingold writes:
> Pascal Bourguignon <pjb@...> wrote:
> >
> > Did I miss something?
>
> the manual? :-) <http://clisp.cons.org/impnotes/pack-dict.html&gt;
> 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

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

> * In message <15879.51535.944428.986251@...>
> * On the subject of "[clisp-list] Re: symbol cases"
> * Sent on Tue, 24 Dec 2002 03:41:19 +0100
> * Honorable Pascal Bourguignon <pjb@...> 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&gt; <http://www.iris.org.il&gt; <http://www.memri.org/&gt;
<http://www.mideasttruth.com/&gt; <http://www.palestine-central.com/links.html&gt;
MS DOS: Keyboard not found. Press F1 to continue.

Sam Steingold writes:
> > * In message <15879.51535.944428.986251@...>
> > * On the subject of "[clisp-list] Re: symbol cases"
> > * Sent on Tue, 24 Dec 2002 03:41:19 +0100
> > * Honorable Pascal Bourguignon <pjb@...> 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