Uppercasing symbols
William Paul Vrotney
In article <yWF52.7055$Sz4.3...@news.teleport.com> "David B. Lamkins"
<dlam...@teleport.com> writes:
>
> In article <vrotneyF...@netcom.com> , vro...@netcom.com (William Paul
> Vrotney) wrote:
>
> >I find having to specify the symbol "Bill" in Common Lisp as "|Bill|" not
> >only awkward but find it non-symmetric in having to specify it differently
> >than the symbol "bill". The fact that the former prints as |Bill| makes it
> >difficult to read and parse in general.
> >
>
> I'm not sure I understand the cause for your objection. Obviously, the Lisp
> printer and reader have no problems with this. So what is it you're doing
> that absolutely requires you to have case-sensitive names? Is there
> something intrinsic to your Lisp program that depends on case distinctions,
> or are you having a problem interfacing to external libraries with
> case-sensitive names?
>
>
> *PRINT-CASE* lets you change this for normal output. Some implementations
> also have a way of specifying print case separately for certain tools
> (debugger, inspector, ...) -- a quick trip to the documentation or apropos
> should help you find these.
>
Apparently you have not been reading this new thread carefully enough, I was
talking about default behaviors in Common Lisp,
From my original post:
I would like to see here some more discussion on the rational for doing this
in CL. This is one of the more embarrassing things that I have to explain
to new people that I am introducing to Common Lisp. I can see no reason why
case sensitive symbols by default would not be superior.
^
|
--
William P. Vrotney - vro...@netcom.com
David B. Lamkins
>
>In article <yWF52.7055$Sz4.3...@news.teleport.com> "David B. Lamkins"
><dlam...@teleport.com> writes:
>
>>
>> In article <vrotneyF...@netcom.com> , vro...@netcom.com (William Paul
>> Vrotney) wrote:
>>
>> >I find having to specify the symbol "Bill" in Common Lisp as "|Bill|" not
>> >only awkward but find it non-symmetric in having to specify it differently
>> >than the symbol "bill". The fact that the former prints as |Bill| makes it
>> >difficult to read and parse in general.
>> >
>>
>> I'm not sure I understand the cause for your objection. Obviously, the Lisp
>> printer and reader have no problems with this. So what is it you're doing
>> that absolutely requires you to have case-sensitive names? Is there
>> something intrinsic to your Lisp program that depends on case distinctions,
>> or are you having a problem interfacing to external libraries with
>> case-sensitive names?
>>
[NOTE: There was a change of topic at this point in the original post. The
following reply is unrelated to what appears above.]
>>
>> *PRINT-CASE* lets you change this for normal output. Some implementations
>> also have a way of specifying print case separately for certain tools
>> (debugger, inspector, ...) -- a quick trip to the documentation or apropos
>> should help you find these.
>>
>
>Apparently you have not been reading this new thread carefully enough, I was
>talking about default behaviors in Common Lisp,
Actually, I did go back to the beginning of the thread: note that the
remarks you chose to clip out when quoting my reply went into some detail on
the subject which was under discussion when you split this thread.
>
>From my original post:
>
> I would like to see here some more discussion on the rational for doing this
> in CL. This is one of the more embarrassing things that I have to explain
> to new people that I am introducing to Common Lisp. I can see no reason why
> case sensitive symbols by default would not be superior.
> ^
> |
I'm also talking about default behaviors in CL. But I prefer to take the
viewpoint that the user gets a choice (as pointed out in the second sections
of my reply, which you did quote), instead of setting up a strawman to knock
down...
Earlier, I asked what problem it is that you're trying to solve that so
strongly depends on having case preservation be the out-of-the-box default
behavior for CL. Your response (above) is that you find it embarassing to
have to explain to newbies that it just ain't so.
Your assertion that case sensitivity is "superior" remains unsupported,
unless we are to take your embarassment as cause for action.
Respondents to this thread have offered historical explanation, rationale,
and _two_ reminders that the defaults are _configurable_. So far, as
support for your position, you have invoked (1) the practices and behaviors
of the C and C++ communities, (2) personal preference (vis, you assertion of
"superiority"), and (3) efficiency of certain compile-time mechanisms
(answered in part elsewhere in this thread).
You've stated that it is "awkward" for you to have to write case-preserving
symbols in a manner different from the default (perhaps I should say
"different from the default default".) Since you did not offer a concrete
example for our consideration -- something that would illustrate _why_ it
might be necessary to write a CL program which uses the default case folding
read and print behavior _and_ at the same time require a distinction
between, e.g. the symbols BILL and |Bill| -- I went back to the parent
thread to find an example of why such a situation might arise, then offered
three possible solutions to that particular problem. In so doing, I was
hoping to elicit from you a response more like "Well, that's OK, but here's
an example of a problem that won't yield to that kind of solution."
So, the question remains: are we discussing personal preference, or is there
a compelling example (i.e., a problem that you're attempting to solve using
CL) which would offer support to your expressed desire to have the CL reader
and printer preserve case _by default_?
---
David B. Lamkins <http://www.teleport.com/~dlamkins/>
Marco Antoniotti
> In article <yWF52.7055$Sz4.3...@news.teleport.com> "David B. Lamkins"
> <dlam...@teleport.com> writes:
>
> From my original post:
>
> I would like to see here some more discussion on the rational for doing this
> in CL. This is one of the more embarrassing things that I have to explain
> to new people that I am introducing to Common Lisp. I can see no reason why
> case sensitive symbols by default would not be superior.
> ^
> |
I think Barry Margolin's post confirmed what I thought
happened. Common Lisp derives from Maclisp. Maclisp was
"uppercasing". End of the story. The rest are rationalizations of
"what it was". Personally I see no reasons not to adopt the
conventions widely used in most other "mainstream" languages. But I
think we'll have to live with this state of affairs.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
William Paul Vrotney
In article <YDP52.7499$Sz4.3...@news.teleport.com> "David B. Lamkins"
<dlam...@teleport.com> writes:
>
> In article <vrotneyF...@netcom.com> , vro...@netcom.com (William Paul
> Vrotney) wrote:
>
> >
> >From my original post:
> >
> > I would like to see here some more discussion on the rational for doing this
> > in CL. This is one of the more embarrassing things that I have to explain
> > to new people that I am introducing to Common Lisp. I can see no reason why
> > case sensitive symbols by default would not be superior.
> > ^
> > |
>
...
> I'm also talking about default behaviors in CL. But I prefer to take the
> viewpoint that the user gets a choice (as pointed out in the second sections
> of my reply, which you did quote), instead of setting up a strawman to knock
> down...
>
I prefer to take that viewpoint also, but that is irrelevant to the
discussion of the rational of sticking with the old for the default. If it
turns out that a case sensitive default is better for various reasons, then
in the next generation of Lisp dialect, if there is one, these reasons will
have served as a lesson learned.
> Earlier, I asked what problem it is that you're trying to solve that so
> strongly depends on having case preservation be the out-of-the-box default
> behavior for CL. Your response (above) is that you find it embarassing to
> have to explain to newbies that it just ain't so.
>
> Your assertion that case sensitivity is "superior" remains unsupported,
> unless we are to take your embarassment as cause for action.
Note that I said "I can see no reason why case sensitive symbols by default
would not be superior." This was not meant as an assertion that "Case
sensitive symbols by default *is* superior". I was just fishing for a
discussion and other peoples viewpoints. I appreciate your comments, but
most of your comments sounded to me like you were concentrating on how to
override the defaults, or how to solve some sort of problem that I was
having, which I am not. Yes, I do admit, it is a peronal preference to me
now (it didn't used to be).
Now that you say it that way, embarrassment in having to explain a language
feature to beginners, does in fact sound like a good cause for action.
...
>
> So, the question remains: are we discussing personal preference, or is there
> a compelling example (i.e., a problem that you're attempting to solve using
> CL) which would offer support to your expressed desire to have the CL reader
> and printer preserve case _by default_?
>
Ok, this is good. I admit that personal preference is not a good enough
argument in itself. So here is a summary from reasons I gave and the
responses I got
Non-personal-preferences arguments for case sensitive by default:
1. It is embarrassing for an advanced Common Lisp user to explain to
beginners why case-insensitive-upper-case-conversion is the default. To say
that it is based on some historical evolution having to do with uppercase
keyboards doesn't bode well for Common Lisp.
2. Elisp uses case sensitive.
3. A big part of the world outside of Lisp uses case sensitive
symbols, so translation from and two such systems, by default becomes
more difficult.
4. By default, Lisp users would have a richer set of symbols.
5. Point (4.) would be achieved by default, without the awkward bar
notation, as in '|Bill| instead of just 'Bill. The bar notation is good for
including reader special parsing characters such as escaping, quoting and
white space.
6. It is convenient, by default, to represent symbolic abstractions as
different abstractions that differ only in case. Some examples are: "Bill"
for a name and "bill" for a common noun, as in (BILL HASA BILL).
"A" for one type of mathematical symbol and "a" for another. Convienient
month designators such as "Dec" for December.
William Paul Vrotney
In article <lw90h4y...@copernico.parades.rm.cnr.it> Marco Antoniotti
<mar...@copernico.parades.rm.cnr.it> writes:
>
> vro...@netcom.com (William Paul Vrotney) writes:
>
> > In article <yWF52.7055$Sz4.3...@news.teleport.com> "David B. Lamkins"
> > <dlam...@teleport.com> writes:
> >
> > From my original post:
> >
> > I would like to see here some more discussion on the rational for doing this
> > in CL. This is one of the more embarrassing things that I have to explain
> > to new people that I am introducing to Common Lisp. I can see no reason why
> > case sensitive symbols by default would not be superior.
> > ^
> > |
>
> I think Barry Margolin's post confirmed what I thought
> happened. Common Lisp derives from Maclisp. Maclisp was
> "uppercasing". End of the story. The rest are rationalizations of
> "what it was".
Yes, this is consistent with what I thought happened also. I would be
surprised if someone in the CL team did not veto the chosen decision for
some of the reasons that have been cited.
> Personally I see no reasons not to adopt the
> conventions widely used in most other "mainstream" languages. But I
> think we'll have to live with this state of affairs.
>
I am glad that others agree with my preference. I also should add that I
did not always have this preference until I started using Lisp for more
"mainstream" world problems.
If I was stuck having to live with something, Common Lisp would not be a bad
choice. I prefer Common Lisp to Elisp for general purpose programming, for
example, despite the fact that Elisp uses case sensitive symbols. Although
I do like Elisp also for the pursose that it's been serving.
I think it is wise to track where Common Lisp may have potential problems in
any case. Who knows, there may be yet another even better dialect of Lisp
developed in the future based on lessons learned from Common Lisp.
Mike McDonald
vro...@netcom.com (William Paul Vrotney) writes:
> Ok, this is good. I admit that personal preference is not a good enough
> argument in itself. So here is a summary from reasons I gave and the
> responses I got
>
> Non-personal-preferences arguments for case sensitive by default:
>
> 1. It is embarrassing for an advanced Common Lisp user to explain to
> beginners why case-insensitive-upper-case-conversion is the default. To say
> that it is based on some historical evolution having to do with uppercase
> keyboards doesn't bode well for Common Lisp.
Just because you find it embarassing doesn't mean the rest of us do. I've
never ran into this problem when introducing CL to newbies. They have bigger
problems understanding things like quoting than the default case of symbols.
My experience has been that newbies adapt to the default case rules rather
quickly. But "embarassment" is a personal issue.
> 2. Elisp uses case sensitive.
Yah, so what? CL isn't Elisp. And I PERSONALLY find it repulsive that (eq
NIL nil) is false.
> 3. A big part of the world outside of Lisp uses case sensitive
> symbols, so translation from and two such systems, by default becomes
> more difficult.
Yes, that true. But every language out there uses a different set of
characters to make up identifier names. Should we also change all of the
dashes to underscores while we're at it? Are we going to follow C, Pascal,
Java, or Fortran naming conventions?
> 4. By default, Lisp users would have a richer set of symbols.
By default, they do. They can have all of the C identifiers plus they can
use dashes, plus signs, equal signs, ...
> 5. Point (4.) would be achieved by default, without the awkward bar
> notation, as in '|Bill| instead of just 'Bill. The bar notation is good for
> including reader special parsing characters such as escaping, quoting and
> white space.
I prefer (find-person "Bill") myself. See 6.
> 6. It is convenient, by default, to represent symbolic abstractions as
> different abstractions that differ only in case. Some examples are: "Bill"
> for a name and "bill" for a common noun, as in (BILL HASA BILL).
> "A" for one type of mathematical symbol and "a" for another. Convienient
> month designators such as "Dec" for December.
Symbols are different from strings, formal names, nouns, and relationships.
Trying to use symbols to represent all of these other things is a mistake, in
my opinion.
While we're on personal preferences, I personally like the current defaults.
I like typing in expressions in lowercase and having the system print the
results in uppercase. It makes it easier for me to scroll back thru the output
and know where this expression came from.
Mike McDonald
mik...@mikemac.com
Kelly Murray
always filenames). This is a big source of confusion
if some creative? person doesn't use all lowercase.
(I note that my webserver can be made to operate in case-insensitive
mode -- all webpage names are lowercased)
It ends up being a Bug, not a Feature (or was it a bug
and not a feature, or a BUG and not a FEATURE?)
Consider if internet hostnames were case sensitive.
Then we could have http://www.netscape.com
and http://www.Netscape.com and http://www.NetScape.com
and http://WWW.netscape.com
refer to different websites. What a wonderfully modern way
of doing things...NOT (or is that Not or not ?)
-Kelly Murray k...@intellimarket.com
William Paul Vrotney
In article <365A2541...@IntelliMarket.Com> Kelly Murray
<k...@IntelliMarket.Com> writes:
Actually, I must admit this is an excellent point. I'm not sure its sense
translates to programming language symbols. But in the past to Internet
newbies that asked me whether a specific URL domain name was upper or lower
case I have said, "They did that the right way so that you don't have to
worry about it." Sigh.
In reality we are more apt to represent URLs as strings and not as symbols.
Note that in Lisps, textual file path names are represented as strings and
not as symbols. And URLs are more like file path names than symbolic
abstractions.
Let me ask you (and others) this, would you like file names to be case
insensitive? I guess that the answer would be different coming from a
Windows person versus a Unix person. Personally I find having something
like a README file to be distinguishable from other lowercase files quite
handy and not at all confusing. And personally I find the Windows
preference *very* confusing. Also I think that many of us would agree that
case in natural language prose is sometimes a useful thing to have. It is
pretty hard to argue that case distinction of symbols in mathematics is not
useful.
On the surface, to me, your point does not translate to symbols. However in
my original post on this thread my guess as to the original thinking of
symbol representations was that RED, red (and Red, rEd, ...) were all to
represent the same concept "the color red". In this sense your point
applies. So, it may be that in our brains a symbol does not want to be case
sensitive for some reason. On the other hand when someone says "two", I
see: two, oo, II, 2 and a few other symbols, which seems to put case
sensitivity in another category. The utility of something in a programming
language may not nicely map to the human symbolic abstraction. Recall for
example that, at least in Common Lisp, we find t and nil or non-nil and nil
to be more utility than true and false. Of course this distinction is
semantical as well as syntactical, but I just wanted to point out the
differences between the human and computer program. Something like the
convenience of typing functionp versus function-p or function-predicate may
be more to the point.
My preference for case sensitive symbols in Lisp is mostly based in utility,
but maybe the above psychological preference is somehow more important than
utility. It certainly seems to be for some people.
William Paul Vrotney
>
> In article <vrotneyF...@netcom.com>,
> vro...@netcom.com (William Paul Vrotney) writes:
>
> > Ok, this is good. I admit that personal preference is not a good enough
> > argument in itself. So here is a summary from reasons I gave and the
> > responses I got
> >
> > Non-personal-preferences arguments for case sensitive by default:
> >
> > 1. It is embarrassing for an advanced Common Lisp user to explain to
> > beginners why case-insensitive-upper-case-conversion is the default. To say
> > that it is based on some historical evolution having to do with uppercase
> > keyboards doesn't bode well for Common Lisp.
>
> Just because you find it embarassing doesn't mean the rest of us do. I've
> never ran into this problem when introducing CL to newbies. They have bigger
> problems understanding things like quoting than the default case of symbols.
> My experience has been that newbies adapt to the default case rules rather
> quickly. But "embarassment" is a personal issue.
>
Yes, the embarrassment is internal and personal, because I do not have a
*good* explanation for it. I was hoping that someone in the Lisp news
group would give me one. I certainly am not going to tell the newbie that
it is that way because we used to have uppercase only keyboards. Would you
if asked?
> > 2. Elisp uses case sensitive.
>
> Yah, so what? CL isn't Elisp. And I PERSONALLY find it repulsive that (eq
> NIL nil) is false.
>
Actually in Elisp (eq NIL nil) would probably complain about the unquoted
symbol NIL not having a value or something. But that supports your
argument, you probably find that even *more* repulsive! :-)
Frankly I think this is just one of those things that we (yes me too) have
gotten used to as Lisp programmers and are unwilling to see another way.
Instead of your excellent example, allow me to use a less problematical one.
I suspect that most people in the world outside of Lisp programmers would
find (eq 'A 'a) => false (or nil) to make more sense by far.
> > 3. A big part of the world outside of Lisp uses case sensitive
> > symbols, so translation from and two such systems, by default becomes
> > more difficult.
>
> Yes, that true. But every language out there uses a different set of
> characters to make up identifier names. Should we also change all of the
> dashes to underscores while we're at it? Are we going to follow C, Pascal,
> Java, or Fortran naming conventions?
>
Oh please, I was not alluding to C programming symbol conventions as being
good, I was just using that as an example of where programmers do not seem
to have confusion using case sensitive symbols.
The world of case sensitive symbols extends to far more than just
programming language symbols.
> > 4. By default, Lisp users would have a richer set of symbols.
>
> By default, they do. They can have all of the C identifiers plus they can
> use dashes, plus signs, equal signs, ...
>
Agreed, but by default they do not have a distinction between A and a, and
as I've already pointed out this distinction is important in mathematical
symbol systems.
> > 5. Point (4.) would be achieved by default, without the awkward bar
> > notation, as in '|Bill| instead of just 'Bill. The bar notation is good for
> > including reader special parsing characters such as escaping, quoting and
> > white space.
>
> I prefer (find-person "Bill") myself. See 6.
>
> > 6. It is convenient, by default, to represent symbolic abstractions as
> > different abstractions that differ only in case. Some examples are: "Bill"
> > for a name and "bill" for a common noun, as in (BILL HASA BILL).
> > "A" for one type of mathematical symbol and "a" for another. Convienient
> > month designators such as "Dec" for December.
>
> Symbols are different from strings, formal names, nouns, and relationships.
> Trying to use symbols to represent all of these other things is a mistake, in
> my opinion.
>
Of course symbols are different from strings, but not necessarily from
names, nouns and relationships. Now, unless I don't understand your point,
it sounds to me like a C programmer's opinion. I agree that something like
a file pathname is better repersented as a string in Lisp, but by far a
close examination of Lisp archives would show that Lisp programmers would
represent logical relationships using symbols as in
(bill isa case-freak) :-)
as opposed to
("bill" "isa" "case-freak") :-(
This is an important property of symbols and why they are much more
efficient than using strings for representations such as this, both in terms
of storage and search speed.
> While we're on personal preferences, I personally like the current defaults.
> I like typing in expressions in lowercase and having the system print the
> results in uppercase. It makes it easier for me to scroll back thru the output
> and know where this expression came from.
>
Well ok, I'll give you that one.
Kelly Murray
> to be case insensitive?
Yes, I think it would be better if they were not case sensitive.
The difference between makefile and Makefile is not a
particularly welcomed distinction.
Nor is README, Readme, ReadMe, readme.
I believe logical pathnames are a way to have case-insensitive
filenames.
Certainly anytime distinctions can be made, someone will find
a use for them. It just becomes further removed from normal
experience and something that must be learned.
I'm reminded of the painful Hayes Modem experience:
AT works, but lowercase at doesn't
(or didn't, they fixed that bug in later modems)
-Kelly Murray k...@intellimarket.com
$500 reward offered for CommonLisp JPEG encoder/decoder
Mike McDonald
>> > 2. Elisp uses case sensitive.
>>
>> Yah, so what? CL isn't Elisp. And I PERSONALLY find it repulsive that (eq
>> NIL nil) is false.
>>
>
> Actually in Elisp (eq NIL nil) would probably complain about the unquoted
> symbol NIL not having a value or something. But that supports your
> argument, you probably find that even *more* repulsive! :-)
Actually, it didn't complain. I ran into this when I was hooking up Franz's
Emacs CL mode to CMUCL. I'd return NIL from CMUCL and Xemacs would see it as
(not nil). Scratched my head on that for a while!
>
> Frankly I think this is just one of those things that we (yes me too) have
> gotten used to as Lisp programmers and are unwilling to see another way.
To me, lisp symbols are more than just the equivalent of a C identifier. C
programmer have to use case to distinguish between the various uses of
indentifiers because the language basicly forces them to. C gets real upset if
a type, function, and variable all have the same name with the same case.
(Doesn't ANSI C now allow the type and identifier names to be the same?) CL
doesn't force this on you.
> The world of case sensitive symbols extends to far more than just
> programming language symbols.
> Agreed, but by default they do not have a distinction between A and a, and
> as I've already pointed out this distinction is important in mathematical
> symbol systems.
But lisp symbols are not the same as mathematical symbols, written words, ...
They are different beasts with different properties. Don't try to mix them up.
> Of course symbols are different from strings, but not necessarily from
> names, nouns and relationships. Now, unless I don't understand your point,
> it sounds to me like a C programmer's opinion. I agree that something like
> a file pathname is better repersented as a string in Lisp, but by far a
> close examination of Lisp archives would show that Lisp programmers would
> represent logical relationships using symbols as in
>
> (bill isa case-freak) :-)
>
> as opposed to
>
> ("bill" "isa" "case-freak") :-(
Arghhh!!!!!! "Intro to AI" brain damage again! Yes, lots of intro texts do
simple examples like this. In a real system, you'd need to be able to
distinguish between the multitude of bills. Symbols themselves aren't meant to
encompass all of those subtleties.
Mike McDonald
mik...@mikemac.com
Erik Naggum
| From my original post:
|
| I would like to see here some more discussion on the rational for doing this
| in CL. This is one of the more embarrassing things that I have to explain
| to new people that I am introducing to Common Lisp. I can see no reason why
| case sensitive symbols by default would not be superior.
| ^
| |
since you accuse people of not reading carefully, you yourself should
have understood by now that _symbols_ in Common Lisp are case sensitive.
the reader, on the other hand, is case-folding. you know this, right?
#:Erik
--
The Microsoft Dating Program -- where do you want to crash tonight?