> In article <vrotneyF2rwBt....@netcom.com> , vrot...@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. ^ | --
>In article <yWF52.7055$Sz4.3642...@news.teleport.com> "David B. Lamkins" ><dlamk...@teleport.com> writes:
>> In article <vrotneyF2rwBt....@netcom.com> , vrot...@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_?
> In article <yWF52.7055$Sz4.3642...@news.teleport.com> "David B. Lamkins" > <dlamk...@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.
> In article <vrotneyF2t95w....@netcom.com> , vrot...@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.
> vrot...@netcom.com (William Paul Vrotney) writes:
> > In article <yWF52.7055$Sz4.3642...@news.teleport.com> "David B. Lamkins" > > <dlamk...@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.
In article <vrotneyF2ur8o....@netcom.com>, vrot...@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.
Most webpage "names" are case-sensitive (since they're almost 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?)
> Most webpage "names" are case-sensitive (since they're almost > 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?)
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.
In article <73cedb$48...@spitting-spider.aracnet.com> mike...@mikemac.com (Mike McDonald) writes:
> In article <vrotneyF2ur8o....@netcom.com>, > vrot...@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.
> Let me ask you (and others) this, would you like file names > 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
In article <vrotneyF2x1I4....@netcom.com>, vrot...@netcom.com (William Paul Vrotney) writes:
>> > 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.
* vrot...@netcom.com (William Paul Vrotney) | 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?
