ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Marco Antoniotti
Hi
I just downloaded a trial version of ACL 6.0 (waiting for the
commercial upgrade) and found out, to my dismay, that ACL 6.0 ships in
non-ANSI mode when it comes to the reader behavior.
This has bit me very hard for a number of reasons.
In the file 'readme.txt' Franz explains how to generate an ANSI
'image' from the one available.
In the meantime, I would suggest Franz to start shipping a regular
ANSI image instead of the current incompatible one.
My understanding is that the commercial release will come with an ANSI
image available, however, the commercial version is not distributed
yet.
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Erik Naggum
| I just downloaded a trial version of ACL 6.0 (waiting for the
| commercial upgrade) and found out, to my dismay, that ACL 6.0 ships
| in non-ANSI mode when it comes to the reader behavior.
I'm intrigued to learn why that causes _your_ dismay.
| This has bit me very hard for a number of reasons.
Now, this is obviously silly, as you explain yourself: The readme
file does explain everything you need. What bit you was that you
did not read the readme file, right? Don't blame the wrong guy here.
| In the file 'readme.txt' Franz explains how to generate an ANSI
| 'image' from the one available.
Are these instructions insufficient for any reason?
Rather than build a new image, I prefer to stuff this in .clinit.cl.
(excl:set-case-mode :case-insensitive-upper)
(when (lep:lep-is-running)
(lep::eval-in-emacs "(setq fi::lisp-case-mode :upper)"))
| My understanding is that the commercial release will come with an
| ANSI image available, however, the commercial version is not
| distributed yet.
I think the readme file explains everything you need to do in order
to build the kinds of images you need. I am decidedly ambivalent on
the wisdom of shipping a lower-case image, myself, but I think the
painlessness of making your own image makes complaints seem silly.
Please note that for whatever reason, the Windows version seems to
be in ANSI "mode". This is probably because Franz feels that Unix
is already so deeply entrenched in the case-sensitive lower-case
world that it would be a pain to many non-old-timers to be exposed
to a Common Lisp where the case behavior of symbols is "unreasonable".
One of the first things I did in Allegro CL was (setq-default
*print-case* :downcase), just like I had figured out how to stop
CMUCL from shouting, simply because I think a computer that talks to
me in upper case is very rude and smells of age like some of the
things in my refrigerator that had to be shot before they attacked
Xyzzy, my lovely cat, but that does not _necessarily_ mean that I
think symbols should be in lower-cased and the reader case sensitive.
I have come to conclude that this case thing does not matter much to
me -- although it is a deeply religious issue to people I otherwise
respect. What matters to me is that I can know what to expect from
the environment, but if you query Allegro CL in "modern Lisp" mode,
it will lie to you about what it does. That bugs _me_ a helluva lot.
(5) cl-user
(readtable-case *readtable*)
=> :upcase
(6) cl-user
*print-case*
=> :upcase
At the very least, readtable-case should return :preserve, which
does have ANSI-defined semantics for the other printer variables and
is exactly what the reader is doing. I have complained about this
internally several times and it annoys me that I'm not heard on this
issue, so now I'm airing it in public. Moreover, it is impossible
to make a readtable in Modern Lisp that _does_ upcase when that's
what I actually want. These are bugs, not features. These are
breaking the standard and ignoring my needs.
If the Common Lisp community is going to accept lower-case symbols,
which is the crux of the matter, it must have a graceful upgrade
path, not a fork in the road like a T intersection with no way to
interoperate with the other decision.
I think Franz Inc is doing the Common Lisp community a service by
letting them know Common Lisp can have lower-case symbols and a case
sensitive reader, too, like so many other modern languages, and that
programming under a standard Common Lisp system which ignores case
issues is a good thing.
I think Franz Inc is doing the Common Lisp community a disservice by
forcing people to use the ANSI mode if they want to have only _some_
features of the standard behavior. That way, people will _not_ be
able to move to a more modern Lisp if they want to, but must stay
"behind". Wanting case-insensitive and/or upper-case _parts_ of a
system is not evil even if some think that upper-case symbols are or
that a case-insensitive reader is. If Franz Inc wants to succeed
with their modern Lisp, they must not force me to ignore them if I
do not accept the whole package deal. It is simply wrong to tell me
that I shall never need a readtable that _does_ upcase, and it is
simply wrong to _lie_ to me about the case behavior of the current
readtable. Stop that. Be nice to the upper-case people, and they
might follow you, in time. Offend them like you have, and they will
_have_ to antagonize you just to keep what they want to keep. Not
that I haven't said this before, but it is precisely because you
ignore me that I have to say it over and over.
Until the modern Lisp stops lying and breaking readtable-case, it
should not be published. When it has been fixed to work the right
way, meaning: lower-case symbols, corresponding printer variable
settings, and a default readtable-case value of :preserve, it should
be let out in public, again. The use of some hidden variable to
control the "case-mode" is bogus all the way.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
Christopher Browne
the artist formerly known as Erik Naggum said:
> One of the first things I did in Allegro CL was (setq-default
> *print-case* :downcase), just like I had figured out how to stop
> CMUCL from shouting, simply because I think a computer that talks to
> me in upper case is very rude and smells of age like some of the
> things in my refrigerator that had to be shot before they attacked
> Xyzzy, my lovely cat, but that does not _necessarily_ mean that I
> think symbols should be in lower-cased and the reader case sensitive.
Where does setq-default come from? That appears to be an "Allegro-ism;"
it's not in CMUCL or CLISP, nor is it in the HyperSpec.
[Fiddling with *print-case* _is_ a handy thing to know about; while
I've not agreed with some of your capitalization policies of the past,
I certainly _do_ agree that it is annoying to get SHOUTED AT, WHETHER
BY HUMANS THAT DON'T UNDERSTAND THE USE OF CAPS LOCK OR BY A LANGUAGE
ENVIRONMENT...]
--
cbbr...@ntlug.org - <http://www.ntlug.org/~cbbrowne/lsf.html>
Chad has brought us a brilliant new twist: "Nobody has ever been a bad
parent by buying Microsoft."
-- David Steinberg <stei...@interchange.ubc.ca>
Robert Monfera
> Please note that for whatever reason, the Windows version seems to
> be in ANSI "mode".
The beta Windows IDE version is modern (I haven't downloaded the trial
edition). It also says :upcase.
cg-user(24): (defun test () 1)
test
cg-user(25): (defun TEST () 2)
TEST
cg-user(26): (test)
1
cg-user(27): (TEST)
2
cg-user(28): (Test)
Error: attempt to call `Test' which is an undefined function.
[condition type: undefined-function]
> This is probably because Franz feels that Unix
> is already so deeply entrenched in the case-sensitive lower-case
> world that it would be a pain to many non-old-timers to be exposed
> to a Common Lisp where the case behavior of symbols is "unreasonable".
As newcomers are likely to expect case-sensitivity, it is a good policy
from Franz to ship the modern image as a default. Old-timers (and not
so old-timers) can easily build a new image if needed.
Robert
Erik Naggum
| One of the first things I did in Allegro CL was (setq-default
| *print-case* :downcase), just like I had figured out how to stop
| CMUCL from shouting, simply because I think a computer that talks to
| me in upper case is very rude and smells of age like some of the
| things in my refrigerator that had to be shot before they attacked
| Xyzzy, my lovely cat, but that does not _necessarily_ mean that I
| think symbols should be in lower-cased and the reader case sensitive.
* Christopher Browne
| Where does setq-default come from? That appears to be an
| "Allegro-ism;" it's not in CMUCL or CLISP, nor is it in the
| HyperSpec.
Jesus, Christopher, of course. But what can I say to this nonsense?
You need to think carefully about the purpose of standards and
portable code so you do not fall prey to a religious belief in them.
You should also think _very_ carefully about the purpose and means
of customization of a specific environment and why some environments
and languages are designed to be customized and others are not.
To achieve uniform external behavior, it is always necessary to
write some non-portable code in different environments. It is a
_luxury_ to be able to use such portable code, it does _not_ come
for free. If you are unwilling to work to create that luxury for
yourself, you will create _varying_ external behavior, instead.
Perl succeeded in the mish-mash of Unix differences because it
assumed the burden of unifying the behavior at a very high level, in
stark contrast to the morass of #ifdefs in C and the inability to
get shell scripts to work the same across the many implementations.
Perl did not deny the differences, it did not suggest that people
stick to some standard and hope they could do everything they wanted
with it, it did not live in the world of wishful thinking and the
irrational idiocy that only portable code is good code.
Perl did some things well: It transcended implementation differences
by staring them in the eye and fighting it out, not by giving up,
whining that something isn't standard and portable, etc. It gave
the bad standards and their nonsensical implementation differences
the finger and wrote its own standard. For the kinds of tasks Perl
does well, it is downright _impressively_ portable. You need the
ever expanding Perl book, but not the tens or hundreds of shelf-feet
of manuals that you used to have to deal with. Perl has created its
own operating system interface precisely by being an incredibly ugly
implementation, and I'll give Larry Wall this, but not much else: He
did fully understand the value of uniform external behavior of a
tool and he was willing to pay the price to get it. There is no
excuse for the _language_ he created in order to do this, however.
Now, some people try to compare Perl and Common Lisp, which I think
is an incredibly tasteless insult to the work of the Common Lisp
community to create Common Lisp, because it already _did_ the same
good things that Perl did. Some people do not appreciate this and
go ballistic over the complexity of pathnames, hailing Unix as the
simple and elegant solution, but Unix is only simple, not elegant:
That's why it needed Perl. Common Lisp doesn't need _its_ Perl: It
already _is_ everything that Perl aspired to be from the beginning.
What needs to be done is to _build_ on that environment in the same
vein: Uniform external behavior. That means only one thing: Ugly,
implementation-specific code that _exports_ simplicity and elegance,
transcends the silliness of operating system vendors with only their
own concerns to consider, transcends the incompetence of the Evil
Empire, and defines a virtual operating system on top of whatever
cruft people get for free on their fine computing machines. This
requires tons of code the equivalent of dirt under fingernails.
This requires tons of work that is never seen because its main value
is to hide and gloss over. Once upon a time, the Common Lisp
community was willing to do such work. These days, most are so
spoiled with the result of that prior work they are not even willing
to use implementation-specific features to get what they _want_.
People who go off to do their own thing need both policing and good
friends. Vendors cannot normally be trusted to do the right thing
on their own unless they have wise critics and co-conspirators alike
to guide them with input from the outside world at crucial times
before releases and during development. In much smaller capacity
than I would like, I try to help Franz Inc that way, and it's much
more work than I thought it would be, but it's rewarding most of the
time. Many people here favor some free software implementations
where everybody's an insider, destroying that customer-critic-friend
trichotomy, and brushing people aside by asking them to just supply
patches, but that is not what this is all about, and write access to
the source as in many Open Sores projects doesn't even work when you
want politicing and good friends who tell you what you shouldn't do.
Sharing code builds one type of community. Sharing visions for the
uniform external behavior builds another type of community. Perl
had the latter, but is moving towards the former. Lisp sort of
began with the former and is moving towards the latter. However, if
the "vision" is "don't use implementation-specific features; don't
write non-portable code", it's an accountant's vision of the future:
That of looking backwards in the books detailing the past. We don't
need that. We need implementation-specific code where people agree
on what matters: What other programmers will need to know and do to
use it, not agreement on the code and a laissez-faire attitude to
the interface.
What does this all mean? Respect the standard absolutely, but such
respect comes from realizing that it was made by people in a process
of much disagreement and pain. Reject the standard as a limitation:
It should never have been regarded that way if it were. Reject the
standard as the final vision: It isn't that, either. Step onto it
and use it as a higher vantage point. (This works in the literal
sense with ANSI Common Lisp, too.)
And above all: Shoot the anti-visionaries. They have kept Common
Lisp back for many years by refusing to use non-standard tools,
which has only led to a dearth of solutions to interesting problems
after the standard. Now, post-partum depression sets in with the
release of standards, but even though we had a prolonged birth with
that longish freeze time and final quibbles, it shouldn't still be a
problem. Especially not with people who weren't even there when the
standard was hammered out, but who act like it's _their_ baby. For
some reason mankind shall probably never fully understand given that
we _do_ understand what they go through, many women give birth to
more than one child, so maybe some have felt that after the standard
came out it was a good time to cut the wires and make like a raven
and go "nevermore". I don't see that in the people who are most
likely to be able to pull the locomotive, then push it before they
leave it running in its own. I see that in a lot of people who look
like they are fearful of being run over by _any_ moving object by
virtue of standing completely still, themselves. It's time to get
this baby rolling again, to mix this paragraph's metaphors badly.
Keke Abe
Robert Monfera <mon...@fisec.com> wrote:
> cg-user(24): (defun test () 1)
> test
> cg-user(25): (defun TEST () 2)
> TEST
> cg-user(26): (test)
> 1
> cg-user(27): (TEST)
> 2
> cg-user(28): (Test)
> Error: attempt to call `Test' which is an undefined function.
> [condition type: undefined-function]
Is this correct behavior? It seems that the reader preseves the
case for test and TEST while upcasing defun.
> As newcomers are likely to expect case-sensitivity, it is a good policy
> from Franz to ship the modern image as a default.
That sure encourages the use of mixed case symbol names. And
soon we will have to deal with mixed case CL codes. I don't
like that.
regards,
abe
John Foderaro
says...
>
> In the meantime, I would suggest Franz to start shipping a regular
> ANSI image instead of the current incompatible one.
>
The full product ships with 4 images due to two variables with two
values:
8 bit character, 16 bit character (aka International)
ANSI mode, Modern mode
We had to choose just one to ship with the trial version to keep
the size of what you had to download within reason.
The 16-bit Modern version is the most flexible in the sense that
it can run all the tools (in particular this is the XML parser's
perferred mode). Since the intention of the trial version is for
you to try things, it makes sense to distribute the most powerful
version.
The Modern image has slightly more information than the ANSI one.
You can generate the ANSI version from the Modern version but not
vice versa. Thus supplying the Modern version and asking you to
create the ANSI one if you need it saves you download time and
requires very little effort on your part.
- john foderaro
franz inc
Kevin Layer
wrote:
>My understanding is that the commercial release will come with an ANSI
>image available, however, the commercial version is not distributed
>yet.
You are correct, because it ships on a CD-ROM and is not available for
download.
Kevin Layer
Franz Inc.
Erik Naggum
| Is this correct behavior? It seems that the reader preseves the
| case for test and TEST while upcasing defun.
Try (symbol-name 'defun) and see the light.
| That sure encourages the use of mixed case symbol names. And soon
| we will have to deal with mixed case CL codes. I don't like that.
Do you feel encouraged to use mixed-case symbols? Do you know
anybody who are? Or did you think you were playing in Scary Movie
and had to make a stab at a charicature of something fearful?
Arguments from fear of what stupid people might do if not controlled
and punished is not the Lisp way. Learn to trust Lisp programmers.
Expect something from them. (And shoot the buggers who think they
are still in no-expectations-land.)
John Foderaro
the other side of the issue for the readers. We've talked
about this in person a few times so I doubt you'll find anything
new in here.
I've been dealing with reader case issues since 1980 when
I ported Macsyma written in an upper case lisp (MacLisp) to
Franz Lisp a lower case, case-sensitive lisp. One constraint
was that I couldn't change the source code (except for a line
here and there).
I learned quite a bit about what was needed to make lisp code
not just case independent, but independent of whether it
is case independent (meta-case-independent?).
All developers at Franz work in a case sensitive lower case Lisp
(i.e. now called a Modern mode lisp) yet all our code works in
an ANSI (upper case) lisp (except that just recently code to
interface with case sensitive things (e.g. XML
and Java) doesn't work well in ANSI mode, but that's off topic
for this discussion).
So the point is that whatever you may think of the features of ACL,
it does provide a system in which you can develop ANSI-only
code, Modern-only code, or you can develop code that will work
in either mode. Whenever possible we write code that works
in either mode.
Why don't we set readtable-case to :preserve in a Modern lisp?
It's because that would harm the ability to import ANSI code
and make it work in Modern mode as well. It would make it harder
to write code that works in ANSI and Modern modes.
The reason that it would cause problems is that it brings readtable-case
into play in Modern mode. ANSI code may create a readtable, and then set
its
case to :upcase so it can read in some data that it had written before.
This isn't going to work in Modern lisp since standard symbols are
in lower case. So when porting you're going to have
to search for all uses of readtable-case and insert conditional
code to make it work in ANSI and Modern mode. The conditional
code has to be runtime and not compile time conditional since
the decision as to which mode to run in is made at
runtime and a given fasl file can be compiled in one mode and
run in another.
So what we did with set-case-mode is akin to setting up a virtual
machine. If you run in Modern mode your program still sees *print-case*
set to :upcase and readtable-case set to :upcase and happily
goes on it way, thinking that it's running in a normal ANSI
lisp (unless it checks the value of *current-case-mode*).
I can only state that 20 years of experience has show that this
kind of thing works. I've yet to find a single ANSI program that
I can't import and make work in both ANSI and Modern modes. So
while what we have may not be pretty, it does the job that it was
designed to do.
If the decision hadn't been made to make Common Lisp case insensitive
upper (and I tried my best to stop it), then there wouldn't
be *print-case* or readtable-case in the language. They
are just kludges to fix a botch in the language.
If you really think that you want case transformations in the
reader in Modern mode then we have to do them in a different
way (i.e. a different function name would have to be involved
(e.g readtable-case-modern) so that it didn't ruin the virtual
machine effect we've got going.
And to implementors of other lisps: I encourage you to
add support for a Modern mode in your lisps as well.
If I can help you achieve this send me email.
-john foderaro
franz inc.
Marco Antoniotti
Erik Naggum <er...@naggum.net> writes:
> * Marco Antoniotti <mar...@cs.nyu.edu>
> | I just downloaded a trial version of ACL 6.0 (waiting for the
> | commercial upgrade) and found out, to my dismay, that ACL 6.0 ships
> | in non-ANSI mode when it comes to the reader behavior.
>
> I'm intrigued to learn why that causes _your_ dismay.
Because I hit "M-x allegro" and ILISP does not work. :) Ok. my fault.
MK:DEFSYSTEM does not work either. (This is my fault again.)
> | This has bit me very hard for a number of reasons.
>
> Now, this is obviously silly, as you explain yourself: The readme
> file does explain everything you need. What bit you was that you
> did not read the readme file, right? Don't blame the wrong guy here.
>
> | In the file 'readme.txt' Franz explains how to generate an ANSI
> | 'image' from the one available.
>
> Are these instructions insufficient for any reason?
>
> Rather than build a new image, I prefer to stuff this in .clinit.cl.
>
> (excl:set-case-mode :case-insensitive-upper)
> (when (lep:lep-is-running)
> (lep::eval-in-emacs "(setq fi::lisp-case-mode :upper)"))
Useful. Probably setting
(setf excl:*ignore-package-name-case* t)
is a good thing as well.
> | My understanding is that the commercial release will come with an
> | ANSI image available, however, the commercial version is not
> | distributed yet.
>
> I think the readme file explains everything you need to do in order
> to build the kinds of images you need. I am decidedly ambivalent on
> the wisdom of shipping a lower-case image, myself, but I think the
> painlessness of making your own image makes complaints seem silly.
>
Well, yes. It is rather painless to make an image, but there is
plenty of code that I wrote that assumes that
(readtable-case *readtable*) ==> :upcase
as the ANSI standard requires for the standard readtable.
Of course, I can go on and rewrite my code using the style described
in the document 'case.htm'. However.
1 - I do not expect code that I know to be ANSI compliant (to the best
of my abilities) to break on a new release of a new product.
2 - The style described is wasteful. You basically double the number
of symbols (interned or not) for any package you write.
> Please note that for whatever reason, the Windows version seems to
> be in ANSI "mode". This is probably because Franz feels that Unix
> is already so deeply entrenched in the case-sensitive lower-case
> world that it would be a pain to many non-old-timers to be exposed
> to a Common Lisp where the case behavior of symbols is
> "unreasonable".
This I understand. I just don't understand what was in the mind of
KMP and friends :) when they decided not to make the standard
readtable
(readtable-case *readtable*) ==> :preserve
and make the rest of CL case sensitive and lowercase biased. I am
sure, there are justifications.
> One of the first things I did in Allegro CL was (setq-default
> *print-case* :downcase), just like I had figured out how to stop
> CMUCL from shouting, simply because I think a computer that talks to
> me in upper case is very rude and smells of age like some of the
> things in my refrigerator that had to be shot before they attacked
> Xyzzy, my lovely cat, but that does not _necessarily_ mean that I
> think symbols should be in lower-cased and the reader case sensitive.
>
> I have come to conclude that this case thing does not matter much to
> me -- although it is a deeply religious issue to people I otherwise
> respect. What matters to me is that I can know what to expect from
> the environment, but if you query Allegro CL in "modern Lisp" mode,
> it will lie to you about what it does. That bugs _me_ a helluva lot.
>
> (5) cl-user
> (readtable-case *readtable*)
> => :upcase
> (6) cl-user
> *print-case*
> => :upcase
I was just about to complain about this. :)
> At the very least, readtable-case should return :preserve, which
> does have ANSI-defined semantics for the other printer variables and
> is exactly what the reader is doing. I have complained about this
> internally several times and it annoys me that I'm not heard on this
> issue, so now I'm airing it in public. Moreover, it is impossible
> to make a readtable in Modern Lisp that _does_ upcase when that's
> what I actually want. These are bugs, not features. These are
> breaking the standard and ignoring my needs.
>
....
>
> I think Franz Inc is doing the Common Lisp community a service by
> letting them know Common Lisp can have lower-case symbols and a case
> sensitive reader, too, like so many other modern languages,
....
>
> I think Franz Inc is doing the Common Lisp community a disservice by
> forcing people to use the ANSI mode if they want to have only _some_
> features of the standard behavior.
....
> Until the modern Lisp stops lying and breaking readtable-case, it
> should not be published. When it has been fixed to work the right
> way, meaning: lower-case symbols, corresponding printer variable
> settings, and a default readtable-case value of :preserve, it should
> be let out in public, again. The use of some hidden variable to
> control the "case-mode" is bogus all the way.
Thanks for having expressed my feelings in a much more eloquent and
to-the-point manner than I would have ever been able to.
I hope the Franz people here hear you.
Marco Antoniotti
Kevin Layer <la...@known.net> writes:
> On 04 Nov 2000 16:37:59 -0500, Marco Antoniotti <mar...@cs.nyu.edu>
> wrote:
>
> >My understanding is that the commercial release will come with an ANSI
> >image available, however, the commercial version is not distributed
> >yet.
>
> You are correct, because it ships on a CD-ROM and is not available
Yet at all.
> for download.
Your pages and the emails I got from you say mid-november.
John Foderaro
> That sure encourages the use of mixed case symbol names. And
> soon we will have to deal with mixed case CL codes. I don't
> like that.
>
Consider also that the trial lisp support 16 bit characters which
means you may encounter source code with symbols, strings and comments
in some language you don't understand. That's going to make using
those programs many times harder for you than a program with mixed
case symbols in a language you do understand.
But you would agree I'm sure that people should be able to write
code any way they wish in the privacy of their own home. So it's
right to give people the choice to program in whatever language
they choose.
If you write code that you wish to contribute to others you
as the author have to ensure that it will work on the target
platforms on which you wish it to run. If you want it to run
on a pure ANSI lisp then you must make sure that if you use
mixed-case symbols in your program then there are no symbol
name clashes if the code is read by an ANSI reader.
While Franz has never delivered a Modern image before the lisp has
always been capable of running in Modern mode. I haven't seen
any problems arise due to that. I think that Lisp people
prefer to use a hyphen to separate words in a symbol instead
of Capitalization. However if you want to refer to a Java
symbol MakeStringIOPort from lisp it's much clearer to me to refer
to it as MakeStringIOPort than make-string-i-o-port or MAKESTRINGIOPORT.
So I see people using mixed case when they need to denote
objects outside of lisp that are denoted by mixed case symbols.
Bottom line: Franz is not going to start introducing mixed case
APIs to normal lisp things. You can use mixed case if you want,
it's your choice. However when dealing with mixed case
objects (e.g. Java symbols, XML symbols) we will make use of ACL's mixed
case ability if the result is a cleaner interface.
- john foderaro
franz inc.
Erik Naggum
| All developers at Franz work in a case sensitive lower case Lisp
| (i.e. now called a Modern mode lisp) yet all our code works in an
| ANSI (upper case) lisp (except that just recently code to interface
| with case sensitive things (e.g. XML and Java) doesn't work well in
| ANSI mode, but that's off topic for this discussion).
There is nothing in the case sensitivity of these languages that
requires a that a case-insensitive reader be killed. We have been
able to work with case-sensitive readers for a very long time -- it
really is no big deal. When you lower-case all the symbol names,
you make that much, much easier for all of us and I thank you for
this, I really do, but I hate you for breaking the standard in the
process when that is so _obviously_ unnecessary and a hidden agenda
against the standard and the committee sticks out like a sore thumb.
| Why don't we set readtable-case to :preserve in a Modern lisp? It's
| because that would harm the ability to import ANSI code and make it
| work in Modern mode as well. It would make it harder to write code
| that works in ANSI and Modern modes.
*boggle* You have _broken_ readtable-case so it is hard-wired to
:preserve no matter what it reports or I set it to. If what you are
saying is true, then _you_ have harmed the ability to import ANSI
code and make it work in Modern mode as well by doing that. Except
you aren't telling anyone about it, which you would if you did make
that change.
What you're saying is pretty obviously false, but by now I realize
that I'll never get through to you, which means I shall have to
fight _against_ your Modern mode. Pretty stupid move, John. I want
lower-case symbol names. I want a case-sensitive reader by default.
I _don't_ want to have to get rid of the case-insensitive reader in
the process because I actually _need_ that functionality, but since
you force me to accept that package deal, I simply _cannot_ work
with the stuff I want, and I'll have to go back to the only mode in
which readtable-case actually works as standardized. What _are_ you
so bone-headed about this? What _would_ it cost you to keep within
the standard on the rest of these issues?
If you had set readtable-case to :preserve, which is its real value,
anyway, the standard says to ignore all the other case settings,
which is also precisely what you do, so the Modern behavior is all
_within_ the standard.
If people set the readtable-case directly, they know what they are
doing. If they want to read Lisp data in standard syntax, which is
but one _effect_ of choosing :upcase, they are supposed to use the
macro with-standard-io-syntax, not roll their own just because they
can. That would be a violation of intent, and Kent Pitman has made
a very good point about accidental truths and necessary truths. It
is a _necessary_ truth that if you use with-standard-io-syntax, you
will be able to read Lisp code in the standard syntax. It is an
_accidental_ truth that you may be able to do so if you set the
readtable case to :upcase. This is f*cking obvious. Why do you
fight this and refuse to get it? What do you gain by antagonizing
the standard and me and everybody else who would like to seee a Lisp
with lower-case symbol names, a case sensitive reader, but still
have the _choice_ we have come to love about Common Lisp? What _is_
it with you that makes you work so hard to remove that choice? It
really and truly does move the choice in a particular readtable with
case-insensitive upper-casing behavior to a choice in Modern or ANSI
Lisp, and that is not the choice I want to make just because I want
a simple, straightforward, well-defined functionality in ANSI CL
_with_ your new decisions, and there _is_ no technical reason you
don't want to give it to me. It's _political_, and although we have
one of those "choose the idiot with the nicest teeth in his grin"
contests right now, that doesn't mean I'm willing to buy any package
deals based on similarly irrelevant criteria.
| The reason that it would cause problems is that it brings
| readtable-case into play in Modern mode.
So you have created another, global, variable instead with exactly
the same semantics as the readtable setting, forcing people to fuck
with that instead of the standard interface to the reader for no
other reason that you historically hate the decisions that led to
their inclusions. Good stuff for religions. Bad engineering.
| ANSI code may create a readtable, and then set its case to :upcase
| so it can read in some data that it had written before.
It may _also_ create a readtable and set its case to :upcase because
it really wants the symbol names in upper-case. You disallow that.
I'm not objecting to what you have achieved. I object to the fact
that you force me to duplicate functionality with non-portable code
for no good reason only to achieve what I used to achieve: upcasing
symbol names in the reader. Because of your obnoxious and personal
dislike of the case stuff in ANSI Common Lisp, I have to redo what
is supposed to be in there for those uses where case-insensitivity
is well-defined and actually useful. I'm beginning to hate your
decisions on case for _that_ reason, not because you try to preserve
some other property of the environment that I disagree with.
If you have to break something to get something so fundamental and
relatively simple changed, you're guilty of bad engineering, as in:
Changing the world before you change your tools.
What kinds of written data would your claim actually work out on?
Because you have ripped out the case-translation in the reader, it
would have to be all lower-case in the _input_ to get the right
symbols, but that is _not_ the canonical case, so you end up with
all upper-case symbols, anyway, since that _is_ standard, as in:
produced within the body of a with-standard-io-syntax form.
What you could do is take this back to the drawing board, declare
yourself unfit to make technical decision because of too much
personal involvement, and let other people find ways to reach all of
your (technical) goals while breaking none of other people's goals
and needs. That is what mature standardization is all about, and
that's how mature people interact when they have conflicting needs.
You may think you won't find enough lower-case-friendly people to
get the committee around if you had to, but that is _irrelevant_.
You're already going ahead to implement something outside of the
standard, so you should _minimize_ (as in: _good_ engineering) the
effects upon the rest of the system with your change.
E.g., with-standard-io-syntax should print in lower-case, escape
upper-case letter in symbols (no harm done in case-sensitive mode)
and lower-case symbols on input. Just reverse the case in a fully
consistent, predictable way and you'll be surprised how little of
the language and environment actually _does_ change.
| This isn't going to work in Modern lisp since standard symbols are
| in lower case.
So the readtable-case has to be :lower, instead, because symbols are
now all lower-case. Big deal.
| So when porting you're going to have to search for all uses of
| readtable-case and insert conditional code to make it work in ANSI
| and Modern mode.
*boggle* What? Excuse me? You cannot possibly be serious, John!
We have with-standard-io-syntax to get standard syntax. If people
meddle with the readtable-case, they do that on purpose and must
accept full responsiblity for it. No need to look for anything.
Their settings correspond to their input requirements. If they set
:upcase, they will look for symbols with upper-case names and they
will have interned them with upper-case names, and if they are not
the complete morons you expect them to be, they will write code that
names them in all uppercase, too, simply because that is so much
less confusing to the reader of the code. (We agree fully that it's
a royal mess to deal with case translations in your head while
reading the code. Case sensitive makes maximal sense across the
board, but that's _code_, not input from the outside world. You are
_reversing_ the code-is-data paradigm of Lisp with this move, John!
You force me to treat external data as if it code, but it's really
the other way around: It is code that I may want to treat as data.)
| The conditional code has to be runtime and not compile time
| conditional since the decision as to which mode to run in is made at
| runtime and a given fasl file can be compiled in one mode and run in
| another.
I wonder who you think you're fooling with this joke of an argument.
I wonder if you realize how much you insult people's intelligence by
pretending that this is valid reasoning that they are supposed to
accept.
You have made a number of decisions that impact the effect of your
desire to change the symbol-names to lower-case and the reader to
case-sensitive. Those decisions are obviously not disconnected and
the effect upon the whole system that you detail so painstakingly
tell me one thing: They were made with blatant disregard for the
standard and the possibility of operating _within_ the it to the
extent this is possible with such a change. _Obviously_ you then
end up with a design that has disregard for the standard built-in
and fundamental to it. You could have made different decisions and
that is what I urge you to make. Go back and fix whatever it is
that you did that caused this important aspect of Common Lisp to
break for no good reason just because you want to switch the case of
the symbols. You're normally an excellent engineer, John, but this
stuff is as silly as it gets. I have seen your work and I'm truly
impressed with what you can do when you set your mind to it, but I'm
equally unimpressed with what you do when you set your mind not do
something. I can be a stubborn son-of-a-bitch myself, but at least
I can be shown to be mistaken or have my assumptions challenged and
then I'm a son-of-a-bitch with the new position, instead. I pride
myself with that combination of qualities. (We shall hear from Xah
Lee, shortly, of course.)
| So what we did with set-case-mode is akin to setting up a virtual
| machine. If you run in Modern mode your program still sees
| *print-case* set to :upcase and readtable-case set to :upcase and
| happily goes on it way, thinking that it's running in a normal ANSI
| lisp (unless it checks the value of *current-case-mode*).
Except that every time it looks at symbol-names as strings, it gets
the wrong results because you lied to it. Since people often make
the mistake of hard-wiring case into their code and do not follow
the fairly simple rules that Franz Inc has set for their code not to
_know_ the case, there is simply no way you can win with such people
and consequently it is irrational to try. The problem is that those
who do _not_ hardwire the case into their code might still want to
know what to expect from the reader by _querying_ it for what it
does, in that portable way that you hate and fight. And then you
lie to it, pretending to be something you aren't: in ANSI mode.
Really portable ANSI Common Lisp _will_ query and set the readtable-
case because it is a known factor of the language. That is what you
break, simply because you don't _want_ that factor to be there.
This is not only irrational, it is hostile to rational programmers.
This is just like that dumb-ass politician who tried to come off as
a Latino by changing his name in the campaign to get Hispanic votes.
Just how dumb does he think those people are? Just how dumb _do_
you think people who actually respect the standard on its case
issues are, John? Is that why you show no respect for them?
I'm telling you just how _unhappily_ my code goes on its way when
you broke readtable-case for me so case translation no longer works.
If you tell me to go fuck myself because I'm unhappy about this, I
have no choice but to be your worst enemy in this case business when
we have very similar goals, except I don't have an urgent personal
need to piss off the Common Lisp committee because I don't think
they did such a terribly evil thing as you think they did.
| I can only state that 20 years of experience has show that this kind
| of thing works. I've yet to find a single ANSI program that I can't
| import and make work in both ANSI and Modern modes.
Don't piss me off with bullshit like this! Damn it! If this is the
level of respect you have for me, you can go to hell, John. If you
think I'm making up this story about needing readtable-case :upcase
(or :lower, for that matter) because I'm processing Lisp data and
_want_ it to be case-insensitive and you're telling me that you have
never met an ANSI Common Lisp program that didn't want case not to
matter for its Common Lisp or Lisp-like input, _your_ credibility
has hit an all-time low, way below several presidentail candidates.
| So while what we have may not be pretty, it does the job that it
| was designed to do.
Really? So what I'm telling you that I need was explicity excluded
by design so I can't get those two nifty things you did that I want,
namely lower-case symbol names and the _choice_ of a case-sensitive
reader? I had the choice, I wanted the lower-case symbol names.
You gave me the lower-case symbol names but took away the choice.
As we had a choice with upper-case symbol names, how come we can't
have a choice with lower-case symbol names? You admit to the fact
that you can write code in all lower-case and have it compile in
both modes -- in fact you boast about this. What would change if
you only changed Common Lisp from upper-case to lower-case symbol
names and adjusted the relevant settings accordingly? _NOTHING!_
(Or probably "_nothing!_".) You would be able to do exactly what
you have been doing in a Lisp with upper-case symbols. The reason
you make a big stink about this is that your way of dealing with a
lower-case Lisp was _designed_ to piss off the people you still bear
a grudge against for what you see as a major screw-up in the
language standardization process. Get the hell _over_ it, John.
There is _no_ technical reason why we can't just flip the case and
make the necessary changes as they propagate through the standard to
get this right. Moreover, a position _in-between_ the two extremes
would work for far more people than your bone-headed, political
position: case-insensitive-lower, or just what a readtable-case
value of :lower instead of :upper would do in a Common Lisp with
lower-case symbol names.
| If the decision hadn't been made to make Common Lisp case
| insensitive upper (and I tried my best to stop it), then there
| wouldn't be *print-case* or readtable-case in the language. They
| are just kludges to fix a botch in the language.
Yes, this is definitely your real agenda. You _are_ breaking the
language on purpose because you think it has a kludge to fix a
botch. That's stupid of you, John, just plain stupid, and it's on
purpose, too. You have made up your mind to be stupid and annoying
and obnoxious about this issue instead of getting what you want:
Lower-case symbols and a consensus about it. I fear that the reason
is that you think the people you imagine yourself up against are
criminally insane and so you cannot use what they opened up for.
| If you really think that you want case transformations in the reader
| in Modern mode then we have to do them in a different way (i.e. a
| different function name would have to be involved (e.g
| readtable-case-modern) so that it didn't ruin the virtual machine
| effect we've got going.
This may come as a surprise to you, but you don't _have_ a virtual
machine effect. It works only as long as the input obeys the very
strict protocol that Franz Inc code obeys. What we actually need is
something that works _well_ for people who don't work at Franz Inc,
too, and they are more than very likely to think the standard ranks
higher than your/company coding standards. Sorry about that.
| And to implementors of other lisps: I encourage you to add support
| for a Modern mode in your lisps as well. If I can help you achieve
| this send me email.
Oh, God, please don't. Don't ask John. Get it right, instead.
Just flip the case, change all the corresponding references to
:upcase in the standard to :downcase, and let the abstraction
represented by with-standard-io-syntaxa work its magic with
lower-case symbols and a case-insensitive reader first, then add
case-sensitivity or let people make that choice as _they_ see fit
and have had time to work out the effects of the case change, if any
-- I doubt there will be many.
Let me wax political, too: I urge all Franz Inc customers to write
to them (on real paper) and request that they continue their work on
a Common Lisp with lower-case symbols and work to continue to make
Common Lisp case-sensitive about it over time, but in exactly the
same way Common Lisp has upper-case symbols today. Appeal to their
sense of evolution and bringing together a community, instead of the
splinter group revolutionary attitude that only threatens to bring
people into awareness of which "faction" they must belong to and
which to fight against.
Erik Naggum
| If you write code that you wish to contribute to others you as the
| author have to ensure that it will work on the target platforms on
| which you wish it to run. If you want it to run on a pure ANSI lisp
| then you must make sure that if you use mixed-case symbols in your
| program then there are no symbol name clashes if the code is read by
| an ANSI reader.
John, you _do_ know better than this, so I wonder why you completely
ignore the language as actually defined. The language you keep
arguing against is _not_ a full Common Lisp, but rather some stunted
version that displays all the flaws you would like people to believe
the full language suffers from, but that is simply not the case.
I'm positively _flabbergasted_ that you think you can get away with
such an obvious hoax in this forum, of all places. I could be mean
and say that you pit Modern Lisp against Ancient Lisp, not ANSI Lisp.
The "ANSI reader" can be told to preserve case. Except in Allegro
CL, where that functionality has been ripped out on purpose in order
to make code that wants to use this functionality break.
Symbol quoting has _always_ worked. In fact, it's in there because
people wanted an escape from the case-insensitivity. You can write
|IThinkSmallTalkIsBetterThanCommonLispAnyway| and get _exactly_ what
you typed as the symbol name. Oh, I'm sure we'll hear aesthetics
arguments, now, but that is irrelevant: If you want it, you got it.
Thank you for not breaking this property of ANSI Common Lisp.
| While Franz has never delivered a Modern image before the lisp has
| always been capable of running in Modern mode.
Huh? ACL 5.0 Trial was delivered with :case-sensitive-lower, IIRC.
ACL 5.0.1 Trial was delivered with :case-insensitive-upper after
much of the same kind of resistance that you are facing now, having
learned nothing from last time. That just adds to my being annoyed.
| I think that Lisp people prefer to use a hyphen to separate words in
| a symbol instead of Capitalization.
More than that, people are not using MixedCaseWordsStrungTogether in
any environments other than those in which they are taught it is a
good thing, despite no shortage of case sensitive systems. Ever see
users use filenames like that on Unix? Ever see _Windows_ users
flock to the StupidCapsCamp? One would perhaps think that they
should because their programmers tend towards such identifiers, but
that is not what we find in practice.
| Bottom line: Franz is not going to start introducing mixed case APIs
| to normal lisp things. You can use mixed case if you want, it's
| your choice. However when dealing with mixed case objects
| (e.g. Java symbols, XML symbols) we will make use of ACL's mixed
| case ability if the result is a cleaner interface.
FWIW, I think this is a good argument for case sensitivity. Lisp
has always been a language for making communication easy, and the
upper-case thing was mostly due to communication with FORTRAN way
back when (now known as Fortran :). Lisp as such has no intrinsic
need for either case or case sensitivity, which is why it works just
as well to write Common Lisp code in case-insensitive-upper as in
case-sensitive-lower modes. (Yeah, I know I'm rubbing it in.)
John Foderaro
Wow, that's pretty brutal coming from someone I consider a friend.
I'm too shell shocked to know where to begin so I'll just go back
a bit and reiterate that the goal our our case mode switching code
was to painless permit ANSI code to be imported into Modern lisp.
It's like the x86 architectures all support 8086 code.
Intel could have said that in order to run 8086 code on the 386
you had to write it in a certain way the the 386 chip would have
been a lot less popular (which may have been a good thing for the
world, but that's another topic).
Likewise telling people to change their code to use with-standard-io-
syntax
rather than hacking readtables would be possible but would make the mode
less popular. It may even prevent some code from being ported.
The current situation is that most people out there are using
lisps in ANSI mode and producing ANSI-only code.
At Franz nearly all of our code works in ANSI or Modern mode.
There are probably some people developing in Modern-only mode (we see
messages from them on occasion).
What I'd like to see is a movement toward Modern mode. I'd like to
see other lisps support it and I'd like people to start making their
code work in ANSI and Modern modes.
Then when that's done we can start to move toward Modern only
The way we deal with readtable-case makes it easy to convert code
into a mode where it works in ANSI or Modern mode. That's a critical
first step. If we scare people away and make it too hard to do the
conversion they won't bother.
Clearly you've got a problem where doing case conversions in the
reader is critical. The question is whether that can be solved in
another way.
A question for other (human) readers of this is: given that you are
working
in a case sensitive lisp, is readtable-case something you need for
your application.
John Foderaro
Let me make my comment about porting clearer.
If you work in Modern mode you can write code like this
(let* ((Field (create-class 'Field))
(field (create-instance Field)))
(print-class Field)
(print-instance field)
)
That is you can have two variables that differ by case only.
Now if you give this code to your buddy who runs in ANSI mode
it won't work, the reader will only create one symbol FIELD.
If this code is just for your own use then that's ok, you can leave
it as it is.
If you want this code to have wider use then you can either change
the name of one of the variables or else use escaping:
(let* ((|Field| (create-class '|Field|))
(field (create-instance |Field|)))
(print-class |Field|)
(print-instance field)
)
The point I was making in response to Kebe Abe's comment was that
you as an ANSI user won't have to worry about a great influx of
code with mixed case identifiers since the author of the code,
if he wants maximum portability, will have already dealt with the
consequences of mixed case identifiers.
I hope that clears up the confusion.
=========
Yes, ACL 5.0.1 trial was delivered in ANSI mode. That was because
we didn't have any packages at that time that worked better in
Modern mode. It should be possible to switch it to Modern mode
with set-case-modea function (which has been in the lisp for 15 years).
=========
>> The "ANSI reader" can be told to preserve case. Except in Allegro
>> CL, where that functionality has been ripped out on purpose in order
>> to make code that wants to use this functionality break.
Just to clarify this, in ANSI mode the reader works as specified
in the ANSI spec, including preserving case.
Switching to Modern mode is more than just binding a variable or two.
It involves changing the print name of almost every symbol in the system
(including those symbols whose print names are stored in shared
read-only memory).
When this happens you no longer have an ANSI Common Lisp.
Try (find-symbol "CAR") and you'll get nil back.
If it isn't clear to everyone what Erik and I have been discussing
is how things should work in this non-ANSI common lisp. He's looking
toward
the future and saying how things should be ideally. I want that
too but more than that I want to drag people currently using ANSI
mode into the Modern mode.
John Foderaro
your
>> symbols FooBar if you want, but I as an outsider can still see
>> them as FOOBAR
>> if I want. By making them mixed, you force me to not be able to
interface
>> to your code as either a reader of the text, a viewer of the output,
or a
>> caller of the code without confronting your case choice, and so
>> by consequence
>> you force on people exactly what you said you didn't want to
>> in the paragraph
>> above.
1. Even in ANSI mode I can write |FooBar| and then you are confronted
with
that choice of case. Why is this different than somone doing
FooBar in a Modern mode lisp? And why is |FooBar| ok?
2. There are lots of other things you have to confront if you get my
code.
My choice of variable names for example and even the natural language
in which I write them. Why is that ok but case differences not ok?
3. If you get my code you should either say "thank you" or "no thanks,
it's
not what I want." I shouldn't have to code to your standards unless
you're paying me to do so. If we work on a team then we come up
with coding standards so that we both agree on and then no one is
confronted with anything they dont' expect.
>> This again invites a bad programming practice, tolerating the creation
of
>> symbol clashes and requiring later cleanup, rather than the other
>> way around.
Lisp is a tool and if people want to create symbols that would clash
if loaded into an ANSI lisp that is their right. Using capitalization
to distinguish classes from instances has a long history. It would
be a shame if the lisp system forbid it just because it wouldn't work
in a mode that the person had not intention of using.
>> Calling this modern, especially in uppercase, is an unfair use of a
>> generic term for specific marketing purposes. I hope you will desist.
True a mixed case language was a "Modern" idea in the 1980's and
now it's old hat. But we needed a term that was shorter than
:case-sensitive-lower.
>> also don't think there's evidence of convergence on case sensitivity.
>> HTML and XML are not case-sensitive, for example.
HTML is indeed case-insensitive but XML is case sensitive and
grows in importance every day. Lisp has to be able to deal with it
in a natural way.
>> Incidentally, I assume this also encourages enormous misconceptions
about
>> the internal case of symbols, ...
I didn't understand your example.
In Modern mode
(symbol-name 'car) is "car"
it's wysiwyg.
> I think behavior like this needlessly partitions a tiny community and causes
> the needless drawing of battle lines that could as easily have been avoided
> in favor of focusing the community on real problems.
With the unwashed hordes programming in C and Java our small commmunity
can't duplicate all their efforts. We have to be able to interface
to their work and we have to bring them into to use our tools
to make their work easier. It's hard enough teaching a C or Java
person to not fear parentheses, but to tell them that they can't
just type in SetWindowTitle and have to use something like
|SetWindowTitle| or (jcall "SetWindowTitle" ..) is asking too much.
Lisp should always stay more expressive then the other langauges
so that it can encompass them.
What we've done with the ANSI and Modern mode is create a system where
all the old code can run, and where people can if necessary use
mixed case to naturally interface with existing languages.
John Foderaro
>
> OTOH, I don't see how old code can run without modification and
> conditionalization. For example, the series package exports symbols
> like "COLLECT-SUM" and uses lower-case symbols in the source. The use
> of the modern image requires a conditionalization of the defpackage
> forms, I suppose (like #+modern or something).
>
defpackage does present a problem if you use strings to name packages and
symbols. However it is possible to write defpackages forms in a way
that's portable between modes. As an example, from the AllegroServe
sources:
(defpackage :net.aserve
(:use :common-lisp :excl :net.html.generator)
(:export
#:authorize
#:authorizer
#:base64-decode
#:base64-encode
#:compute-strategy
#:computed-entity
....
))
> This lead me to a possibly irrelevant and naive question: why isn't case
> preservation or modern behavior controlled at the package level?
A proposal was made for this by one of the developers at Franz. I
thought that under the proposal things got pretty complicated especially
when you had case sensitive packages inheriting from case insensitive
packages or vice versa. He came up with a set of rules to handle this
but I personally felt that the complexity added exceeded the benefit
accrued.
Tim Bradshaw
> Is this correct behavior? It seems that the reader preseves the
> case for test and TEST while upcasing defun.
No, in `modern' mode, the symbols exported from the CL (ehem, I mean
the cl) package are lowercase, and the reader and printer preserve
case, but by a different mechanism than the *PRINT-CASE* /
READTABLE-CASE one.
> That sure encourages the use of mixed case symbol names. And
> soon we will have to deal with mixed case CL codes. I don't
> like that.
Me neither, but I can see the reason for doing it given that most
people now see Lisp's future as being parasitic on things like Java
where mixed-case names are absolutely pervasive.
--tim
Tim Bradshaw
> *boggle* You have _broken_ readtable-case so it is hard-wired to
> :preserve no matter what it reports or I set it to. If what you are
> saying is true, then _you_ have harmed the ability to import ANSI
> code and make it work in Modern mode as well by doing that. Except
> you aren't telling anyone about it, which you would if you did make
> that change.
I don't think I saw the full horror of this until just now. Perhaps I
still do not understand.
If I'm in `modern mode' in acl, and I want to read some stuff in case
insensitive uppercase, then I have a choice of:
1. write my own reader;
2. toggle, globally, into ansi mode and back, losing case information
about potentially every symbol in the system in the process.
3. don't use modern mode, and live with || where I need
case-sensitivity.
3 is the only option that I could possibly use. 1 is mad. 2
potentially breaks things in completely random ways, not just because
I lose just the kind of distinction that case-sensitivity get me when
FOO -> FOO -> foo, but because I might have other threads in the
system which will fall about in ANSI mode, so I basically have to do a
without-interrupts while I sit and wait for something to come down
some network connection for 20 minutes.
Is it this bad?
Wouldn't it be possible to split this thing in two -- a part which
controls the readtable case sensitivity of a readtable (which I think
we already have in ANSI CL) and some utility which will change the
case of symbols in one or more packages? That way I could be in a
lower-case lisp (after using the second utility) but I could control
how I read things by adjusting readtable parameters and/or changing
readtables.
--tim
Kent M Pitman
> But you would agree I'm sure that people should be able to write
> code any way they wish in the privacy of their own home. So it's
> right to give people the choice to program in whatever language
> they choose.
Yes, but I'd also like them to *read* code the way they wish in the privacy
of their own home, and a reader which preserves mixed case doesn't allow this.
Nothing in the standard ANSI CL definition prohibits you from calling your
symbols FooBar if you want, but I as an outsider can still see them as FOOBAR
if I want. By making them mixed, you force me to not be able to interface
to your code as either a reader of the text, a viewer of the output, or a
caller of the code without confronting your case choice, and so by consequence
you force on people exactly what you said you didn't want to in the paragraph
above.
> If you want it to run
> on a pure ANSI lisp then you must make sure that if you use
> mixed-case symbols in your program then there are no symbol
> name clashes if the code is read by an ANSI reader.
This again invites a bad programming practice, tolerating the creation of
symbol clashes and requiring later cleanup, rather than the other way around.
I'd say it's better to program in a mode where symbol clashes aren't allowed
if you think there is a reasonable chance you'll try to link your code with
others', since others will not like this.
And if you don't think anyone will ever link with your code, I
honestly have to ask whether you're writing for posterity. Most of my
code has had a substantially longer life than I ever expected. Code I
wrote over 20 years ago is still in active use today, even some code I
didn't expect to be.
> While Franz has never delivered a Modern image before the lisp has
> always been capable of running in Modern mode.
Calling this modern, especially in uppercase, is an unfair use of a
generic term for specific marketing purposes. I hope you will desist.
Or maybe you mean to trick people by using a meaning of modern that only
happens in uppercase-initial mode, hoping they won't notice it doesn't have
the Webster's meaning.
I think this is bad.
I also don't think there's evidence of convergence on case sensitivity.
HTML and XML are not case-sensitive, for example.
Neither the Windows file system nor the Mac file system is case-sensitive.
The English language itself is not case-sensitive.
It is not at all confusing to people to be told that case is not significant,
and there are plenty of ways to defend this behavior as "modern".
> I haven't seen any problems arise due to that.
> I think that Lisp people
> prefer to use a hyphen to separate words in a symbol instead
> of Capitalization. However if you want to refer to a Java
> symbol MakeStringIOPort from lisp it's much clearer to me to refer
> to it as MakeStringIOPort than make-string-i-o-port or MAKESTRINGIOPORT.
Honestly, I'd rather have an interface that referred to it by doing
(defun make-string-i/o-port (...) (jcall "MakeStringIOPort" ...))
I don't see any reason to muck around with the readtable to make this feel
elegant.
> So I see people using mixed case when they need to denote
> objects outside of lisp that are denoted by mixed case symbols.
>
> Bottom line: Franz is not going to start introducing mixed case
> APIs to normal lisp things. You can use mixed case if you want,
> it's your choice. However when dealing with mixed case
> objects (e.g. Java symbols, XML symbols) we will make use of ACL's mixed
> case ability if the result is a cleaner interface.
I think this is quite unfortunate.
Incidentally, I assume this also encourages enormous misconceptions about
the internal case of symbols, since "car" (and I assume you don't require
the person to write "CAR", like I'd probably write) is not uppercase
internal in its printname, and yet retaining the case of "car" means
finding a symbol whose case is flipped from the normal.
Christian Nybų
> I also don't think there's evidence of convergence on case sensitivity.
> HTML and XML are not case-sensitive, for example.
According to <URL:http://www.w3.org/TR/xhtml1/#h-4.2>, XHTML 1.0, the
current W3C recommendation for HTML, is case-sensitive.
--
chr
Robert Monfera
> What we've done with the ANSI and Modern mode is create a system where
> all the old code can run, and where people can if necessary use
> mixed case to naturally interface with existing languages.
I think the goal of allowing natural interfacing is good.
(FooBar x y) looks better than
(call-java-function "FooBar" x y). It oozes openness and
effortlessness.
OTOH, I don't see how old code can run without modification and
conditionalization. For example, the series package exports symbols
like "COLLECT-SUM" and uses lower-case symbols in the source. The use
of the modern image requires a conditionalization of the defpackage
forms, I suppose (like #+modern or something).
This lead me to a possibly irrelevant and naive question: why isn't case
preservation or modern behavior controlled at the package level? Java
function calls and several other things are rightly case-sensitive.
Would it not make sense to give the package maintainer freedom to
specify whether the symbols created in that package are case-sensitive
or not? It would help retain compatibility with packages that are
nothing to do with interfacing (like series), and even let the door open
for future swings back to case-insensitivity in the outside world. As
(interned) symbols are managed by packages, would it not be the right
level, rather than the entire image, in the name of modularity and
scalability?
Thanks for any insight
Robert
Graham Hughes
Kent> I also don't think there's evidence of convergence on case
Kent> sensitivity. HTML and XML are not case-sensitive, for
Kent> example.
A slight correction: XML *is* case sensitive, while HTML is as you say
case insensitive. This is one of the numerous hurdles involved in
going from HTML to XHTML, that is HTML reformulated into XML.
No, I don't understand the reasoning behind changing it either. I've
heard vague noises about `but case sensitive is yucky with Unicode',
but nothing more substantial.
--
Graham Hughes <ghu...@lynda.com>
(defun whee (n e) (subseq (let ((c (cons e e))) (nconc c c)) 0 n))
Erik Naggum
| I'm too shell shocked to know where to begin so I'll just go back
| a bit and reiterate that the goal our our case mode switching code
| was to painless permit ANSI code to be imported into Modern lisp.
I don't see the point of that if it means I can't use Modern Lisp to
write ANSI CL conforming code. But the whole point of this exercise
is that I'm not supposed to write ANSI CL conforming code, anymore,
is it not? At least as far as case is concerned, anyway, because
_you_ think the ANSI standard should be disregarded on that count.
If you consider this something a friend would do to a friend, _I'm_
shocked -- screwing a basic trust is how you _create_ enemies. If
you haven't known about my strong stance on the standard that first
we implement it faithfully, accurately, and completely (during which
we shall learn about many problems that need attention), and then we
make changes that _do_not_break_ it, but navigate within the space
charted by the standard.
| Likewise telling people to change their code to use with-standard-
| io-syntax rather than hacking readtables would be possible but would
| make the mode less popular.
So why are they hacking readtables? Is it because they don't know
about with-standard-io-syntax?
| It may even prevent some code from being ported.
I'd like to see the kinds of code that is portable and the kinds of
code that is not portable. I have shown you one particular example
that is not going to work in your new setup because you break the
functionality of readtable-case. Still, you keep telling me that
you don't give a flying fuck about my needs. Is that how you tell
your friends they are your friends? Let me know when you understand
that I'm pissed as hell at what you have wantonly and needlessly
_broken_ so I can't get something I want very much: lower-case
symbol names.
| The current situation is that most people out there are using lisps
| in ANSI mode and producing ANSI-only code.
Precisely, and they would query readtable-case for its correct value
if they know ANSI Common Lisp.
| At Franz nearly all of our code works in ANSI or Modern mode.
I'm telling you it would work if you didn't break readtable-case,
too. Why are you not getting it, JohN?
| There are probably some people developing in Modern-only mode (we
| see messages from them on occasion).
And what does this mean? "Modern-only"? It does _not_ mean just
lower-case symbol names and a case-sensitive reader. It means using
some language that is _gratuitously_ different from Common Lisp as
defined in ANSI X3.226-1994, simply because you have the chutzpah to
think you can get away with breaking random parts out of personal
likes and dislikes. That's not how we operate in the civilized
world -- either we think the law is the law and we don't break it
even if we disagree with it, or we make that crucial decision to
disregard the law and just do whatever the hell we want and hope to
get away with it. I don't deal with criminals, John, and I don't
deal with people who tell me that they have a product that conforms
to a standard that is being undermined and destroyed by that company.
You are very, very close to becoming a vendor that has made that
crucial decision to scream "fuck the law and the standard!" and go
your own way because you think you can. This isn't about some case
cruft, John, this is about whether Franz Inc has started to think of
itself as so powerful that the standard doesn't matter, anymore,
that personal animosity towards some parts of the standard and the
people who made it shall be more important than the contractual
obligation you have to supply your customer with a conforming ANSI
Common Lisp implementation.
We all know that Franz is the biggest remaining Common Lisp vendor,
and we all know that whatever you do is watched very closely by the
whole community precisely because you can endanger people's work and
our future reliance on the community effort of standardization. If
you decide to be renegades, say so. If you think carefully about
what you are doing and decide that it is in the best interest of
both the Common Lisp community and Franz Inc that you stick to the
standard as much as we can, however you feel about it personally,
you will most probably be able to get people to join your movement.
| What I'd like to see is a movement toward Modern mode.
That's one thing we agree on. So far, you have alienated me. I
hope to have caused a lot of people to regard the bogus ways you
have decided to implement your Modern Lisp as something that they
should _not_ follow, but rather should fight until you listen to
your customers and your contractual obligation to provide people
with a conforming ANSI Common Lisp implementation.
As it is, your first move towards Modern Lisp was to break the Lisp
reader's case conversion. You would like people to move away from
ANSI Common Lisp towards Modern Lisp, which translates to one thing:
You are hell bent on ignoring people who actually want the standard.
| I'd like to see other lisps support it and I'd like people to start
| making their code work in ANSI and Modern modes.
I'd like to see other Common Lisps switch to lower-case symbol names
and case-insensitive readers. That would mean we expose code that
assumes too much about symbol names and _incorrectly_ construct them
at runtime. Yes, that code will break. It will also break in your
"virtual machine" version. It would break less if it could know
which case to expect and use. Please realize this: Code that uses
strings of uppercase characters to build symbols is _not_ going to
work in your "virtual machine" gizmo, John.
| The way we deal with readtable-case makes it easy to convert code
| into a mode where it works in ANSI or Modern mode. That's a
| critical first step. If we scare people away and make it too hard
| to do the conversion they won't bother.
OK, so you really don't give a flying fuck what I think about this.
I'm amazed, nay, _flabbergasted_, again, that you think you have
_not_ scared me away. That you invoke the "friend" word when you do
that is no less insulting. Do you think I'll just accept anything
from you? I don't. You knew that _long_ before you posted your
bullshit about your virtual machine approach not breaking extant
code. The longer you insist that you have the right to break some
of the functionality in the standard, the more you scare me away,
and I hope as many people as will inflict real pain and suffering on
your bottom line if you don't relent will follow me. Yes, you read
that right: I'm so fucking pissed with your disrespect for the
standard and the whole community that goes with it that I'm looking
for alternative technologies to Allegro Common Lisp as we speak. I
_amazed_ that you have the gall to do this at this time.
| Clearly you've got a problem where doing case conversions in the
| reader is critical. The question is whether that can be solved in
| another way.
Yes, it can be solved by not breaking the standard. You never had
to do that to begin with, either. I know, because I've spent a
hundred hours or more pouring over your symbol reader and printer
code. It's twice as complex as it needs to be because of your own
broken design. I spent an inordinate amount of time just getting
Allegro CL to print symbols correctly according to all the printer
variables, and . I'm happy that you cared enough about this to fix
it, but that it had not been done correctly speaks volumes about
what you care about. It still doesn't work correctly for any value
of *print-base* greater than 10, however: It fails to escape the
characters of a symbol that would be read back as a number.
I want you to get off that "the standard is broken, so fuck it" high
horse of yours and start to respect the standard. It's a community
document and _you're_ the outsider when you disregard it, break it,
or implement redundant functionality.
| A question for other (human) readers of this is: given that you are
| working in a case sensitive lisp, is readtable-case something you
| need for your application.
It's part of the standard. You're a vendor who has a product that
claims to conform to the standard. We don't take polls whether
people think the Constitution of the United States is important in
everybody's life or whether we can ignore some sections that stupid
people only save bad people from getting caught.
I have requested a commitment from Franz Inc that you will honor and
uphold the ANSI Common Lisp standard, and I very nearly quit working
with you over not getting a decent answer to this question some time
ago. I'm pissed as hell that you think you have the right to throw
out some pieces of the standard.
Perhaps you should go back to call it Franz Lisp and let the rest of
the world know what you're really selling? I'd drop the product in
a millisecond if you do, of course, so you're guilty of fraud if you
keep up this charade that you're producing a conforming ANSI Common
Lisp implementation when you really are out to hose the parts of the
standard you personally dislike.
Erik Naggum
| The current situation is that most people out there are using
| lisps in ANSI mode and producing ANSI-only code.
Well, if they perform the following operations on their Modern Lisp,
they will get the best of both worlds:
(progn
;; Turn _off_ the internal flag which overrides the readtable-case.
(setq excl::*forced-readtable-case-raw* nil)
;; All readtables will now have :upcase as the readtable-case which
;; will break since all symbols are still in lower-case, so we need
;; to fix them all. This is a little brutal, but what the heck,
;; this is a demonstration that Allegro CL can operate within the
;; standard without the internal hackery and respect readtable-case
;; the way it was meant to be treated.
(loop with objects = (excl::get-objects 11)
for index from 1 to (aref objects 0)
for object = (aref objects index)
do (setf (readtable-case object) :preserve)))
If you want :downcase, remember to set *print-case* to :downcase if
you want to _see_ the new lower-case symbol names. Put this in your
.clinit.cl file, too:
(tpl:setq-default *print-case* :downcase)
We now have a Common Lisp with lower-case symbol (and package) names
that respects the value of readtable-case. Whee!
(9) cl-user
(symbol-name 'car)
=> "car" ;as expected
(10) cl-user
(setf (readtable-case *readtable*) :downcase
*print-case* :upcase)
=> :UPCASE ;just for kicks
(11) cl-user
(SYMBOL-NAME 'CAR)
=> "car" ;as expected
(12) cl-user
'car
=> CAR ;this, too
(13) cl-user
(setf *print-case* :downcase)
=> :downcase ;return to normal
(14) cl-user
'car
=> car ;as expected
I'm not sure I have a _complete_ understanding of _all_ that this
_remarkably_ simple change shows, but the need for the internal
hackery is _gone_, the standard _is_ powerful enough to handle this
new situation, Allegro CL does not operate any differently at all
with these settings (running the test suite reports no changes), and
it seems that the need to destroy the working of readtable-case has
been _thoroghly_ debunked. Just stop lying, do the right thing, and
both Allegro CL and Common Lisp are in fact up to the task. Amazing!
So I have found a way (for now!) to survive John's ploy to undermine
the standard, and as long as it is _this_ simple, I can continue to
recommend Allegro CL for people who want to program in Common Lisp,
including those who think the whole language would be so much better
off if the symbols were all lower-case instead of all upper-case.
Best of all, now people can try out a Common Lisp that _obeys_ the
standard's printer control variables, but with an isolated change to
the Allegro CL and Common Lisp universe.
Probably not a good lesson to learn, but sometimes getting really,
really annoyed with some bonehead decisions other people make can
have interesting and constructive results. Shit, this case-mode
cruft has annoyed me for years, but in 6.0 at least they have fixed
the standards-conforming code sufficiently that I can live with it.
In 5.0, the purportedly standards-conforming code was so broken this
would not have worked correctly.
Not that the reader and printer work 100% correctly, still, but at
least the major blockage to progress has been completely _excised_,
if not exorcised.
OK, so I'm gloating.
cbbr...@hex.net
> HTML and XML are not case-sensitive, for example.
SGML is consciously case _in_sensitive, with some historical
preference for pushing things into upper case, from which HTML
inherits its case insensitivity. (This is not _entirely_ unlike the
CL situation, albeit with the consideration that there's no SGML
equivalent to |FooBar|...)
In contrast, <a href="http://www.ucc.ie/xml/#FAQ-CASE">C.4 Which parts
of an XML document are case-sensitive?</a> indicates that _all_ of XML
is case sensitive, including ID references and such that always were
case insensitive with SGML.
> It is not at all confusing to people to be told that case is not
> significant, and there are plenty of ways to defend this behavior as
> "modern".
This meaning of "modern" seems to be "the new behaviour that Franz has
selected;" I would think it wiser to start by coming up with a
_descriptive_ name for the behaviour. The "modern" family of fonts
(on which Knuth based CMR) are now probably on the order of 80 years
old, for instance.
I think the use of the term "Modern" in this context is _outrageous_
in that it doesn't actually say anything meaningful.
Franz may try to term their system as "Modern" and thus, somehow, in
its "modernity," superior to all of those other systems that "Aren't
Modern."
That just seems _wrong_; it ignores the critical issue of "what's in
the name?"
> I think behavior like this needlessly partitions a tiny community and causes
> the needless drawing of battle lines that could as easily have been avoided
> in favor of focusing the community on real problems.
That sure sounds right...
--
(concatenate 'string "cbbrowne" "@hex.net") <http://www.ntlug.org/~cbbrowne/>
Rules of the Evil Overlord #106. "If my supreme command center comes
under attack, I will immediately flee to safety in my prepared escape
pod and direct the defenses from there. I will not wait until the
troops break into my inner sanctum to attempt this."
<http://www.eviloverlord.com/>
Kent M Pitman
> >> Incidentally, I assume this also encourages enormous misconceptions
> >> about the internal case of symbols, ...
>
> I didn't understand your example.
> In Modern mode
> (symbol-name 'car) is "car"
>
> it's wysiwyg.
Yes, but the pre-defined function CAR's symbol-name is "CAR", not "car".
So when you do (symbol-name 'car) => "car" and then you do
(car '(a)) => a
you find yourself wonderinf ig maybe this implies that
(symbol-name #<SYMBOL whose function is to get the left of a cons>) => "CAR"
Kent M Pitman
> I think the goal of allowing natural interfacing is good.
> (FooBar x y) looks better than
> (call-java-function "FooBar" x y). It oozes openness and
> effortlessness.
But there's nothing that keeps you from having the function importer
define the function FOOBAR that Jcalls "FooBar" and then letting you
write either (FooBar ...) or (FOOBAR ...) or (foobar ...). Indeed, I
myself might write FooBar. But I'd be glad for the opportunity not to
have to type all those caps in interactive testing, for example.
My argument is not with the desire to write something that looks like
the original, it's with the desire to force everyone else to do that.
And that's what case-sensitivity does.
Robert Monfera <mon...@fisec.com> writes:
> This lead me to a possibly irrelevant and naive question: why isn't case
> preservation or modern behavior controlled at the package level? Java
> function calls and several other things are rightly case-sensitive.
> Would it not make sense to give the package maintainer freedom to
> specify whether the symbols created in that package are case-sensitive
> or not? It would help retain compatibility with packages that are
> nothing to do with interfacing (like series), and even let the door open
> for future swings back to case-insensitivity in the outside world. As
> (interned) symbols are managed by packages, would it not be the right
> level, rather than the entire image, in the name of modularity and
> scalability?
This question isn't really irrelevant, certainly. And naivete isn't
something one needs apologize for. I think it's a fine question.
The answer is that *internally* all of CL is and always has been
case-retaining. It's the reader that is case-transforming by default, but
packages are partitioning operations on sets of case-sensitive symbols and
really come too late.
Your question is really about "syntax", not about "package". Or in the
closest CL terminology (not quite right, but in there), it's about
readtables.
You might reasonably ask why package and readtable aren't bound into a single
unified concept, and I don't know a good answer for that. For whatever
historical reason, they are not. Sometimes that's good, and I've seen it
used in interesting ways. For example, in the Lisp Machine, when migrating
code from Zetalisp to CL, it's commonplace for people to first make the
syntax change (using \'s to quote funny chars instead of /'s, for example)
and only later to make package changes. But whether that was "essential"
or just "convenient", I can't say.
On the Lisp Machine, we start all files with a header that you may have
seen saying
;;; -*- Mode: LISP; Syntax: ANSI-Common-Lisp; Package: CL-USER -*-
This tells the compiler not only what language and package, but what syntax.
Other possible syntaxes are Zetalisp (the original LispM syntax) and
Common-Lisp (effectively, cltl1) and at least 5 other more obscure ones
I won't bother you with. To a close approximation, the syntax is the same
as the readtable, though in fact it has subtle differences on packages as
well, since FIND-PACKAGE in the ansi cl package will really call
SYS:FIND-PACKAGE-FOR-SYNTAX with the package name and the ansi cl syntax,
and will get an appropriate name for that package relative to the package
universe for that syntax.
This concept of "Syntax" more or less existed when I came along, but I
was responsible for rationalizing it into an object-oriented scheme
that was explainable and extensible, and I wished that CL would have gone
a little in this direction though there was no obvious way to make that
happen.
About the closest we came was my proposal IN-SYNTAX, which was intended to
allow one to declare syntaxes much as one declares packages, and which got
watered down to the minimal acceptable substitute which is that both LOAD
and COMPILE-FILE bind *READTABLE*, so that in principle you can just set the
readtable at the top of a file as a SETQ (usually in an eval-when, since it
has to affect read-time) and it will affect only that file's loading. That
makes it possible for you to implement the IN-SYNTAX that I didn't get
implemented. But in particular it means you can have a file that sets up a
non-standard syntax and then you can have other files which setq their
readtable to that syntax in a slightly more imperative way, but in effectively
the same functional way as if you'd used IN-PACKAGE.
So unlike the maclisp days where loading someone's special file with funny
syntax tended to "pollute" the load-time environment by modifying the readtable
everyone would use, it's possible to now have "polite" files that use special
syntax but that don't inflict the syntax on the environment into which they
are loaded. Why don't people do more of this? I don't know.
However, back to the point of case-sensitive naming, the problem is hard
because the very way Lisp does linking of modules is through symbol identity,
and a symbol must have the same name in all packages. So no matter how you
define your system (maybe you don't do ANY case sensitive reading and you just
write |FooBar| everywhere, or maybe you modify a private readtable while
you read your symbols, it doesn't matter), when you have exported symbols
they are either going to be |FooBar| or FOOBAR and there's no two ways around
that unless you provide literally separate packages that export identical
functionality under two different names.
The claim by the CL designers after years of fighting is that it's best to
export FOOBAR because a client can still write FooBar in their code if they
want, but they aren't forced to. If you export |FooBar|, you are forcing
either the use of vertical bars or case retention, either of which is known
to be offensive to at least some portion of the community... The only place
that the exporting of FOOBAR is known to break down is (a) people who make
heavy use of PRINT (because there is no way to attach a
"preferred casification" to symbols; probably not a difficult thing to
add, but nonstandard) and (b) people who use symbol sets distinguished only
by case [rare].
The counterclaims I have heard for years. I don't deny that there is a
faction who just likes mixed case, but I think the CL solution of allowing
flexible use of case on input is a nice compromise that goes most of the way
and I wish it were enough.
Kent M Pitman
> >>>>> "Kent" == Kent M Pitman <pit...@world.std.com> writes:
>
> Kent> I also don't think there's evidence of convergence on case
> Kent> sensitivity. HTML and XML are not case-sensitive, for
> Kent> example.
>
> A slight correction: XML *is* case sensitive, while HTML is as you say
> case insensitive. This is one of the numerous hurdles involved in
> going from HTML to XHTML, that is HTML reformulated into XML.
Did they change this right before the final spec? I'd swear it was not
case sensitive (except entities) right up until the end. SGML is not
case sensitive for element names, is it? How can XML be an SGML subset
and have case sensitive names? Am I just hopelessly confused here.
(Sorry but I have extensive reference books on this that are all packed
right now as I move from one house to another so I'm left reasoning by
memory and perhaps slinging false claims around. Thanks for the corrections
like the above that people manage to note.)
> No, I don't understand the reasoning behind changing it either. I've
> heard vague noises about `but case sensitive is yucky with Unicode',
> but nothing more substantial.
I actually think it's a good idea for XML to be case-sensitive since it's
going to be dynamically parsed/unparsed seriously often, and fast name
checks will improve efficiency.
I don't think a similar argument can be made about CL symbols, which largely
are not something one parses a lot in a typical application, and so I don't
think the same rules apply. I think facility of manual typein is WAY more
important. Not to mention the other niceties like usefulness in transmitted
ascii text of uppercasing CAR, CDR, etc. to make them stand out when fonting
isn't handy. I could go on but won't.
Kent M Pitman
> Yes, ACL 5.0.1 trial was delivered in ANSI mode. That was because
> we didn't have any packages at that time that worked better in
> Modern mode. It should be possible to switch it to Modern mode
> with set-case-modea function (which has been in the lisp for 15 years).
Btw, while at Harlequin I whined internally about Liquid CL coming up in
non-ANSI mode, too.
I think this does an enormous discourtesy to the end user. People pick up
CL books and try to use them and wonder why what they read doesn't work.
That doesn't help our evangelism one bit. Or they pick up something
non-standard and assume the book was wrong; that doesn't help either.
Erik Naggum
| SGML is consciously case _in_sensitive, with some historical
| preference for pushing things into upper case, from which HTML
| inherits its case insensitivity.
Not so. SGML is by default case insensitive in element names and
case sensitive in entity names. This may be changed in the SGML
declaration at will, incidentally.
Did you know that in a mailbox specification on the Internet, the
domain part is case insensitive, while the user part is case
sensitive. E.g, <er...@naggum.net> and <er...@NAGGUM.NET> name the
same mailbox, but <er...@NAGGUM.NET> and <ER...@NAGGUM.NET> name
different mailboxes, unless the host system decides to coalesce
them, but that is a local decision. The same applies to message-IDs
which use the mailbox syntax.
| I think the use of the term "Modern" in this context is _outrageous_
| in that it doesn't actually say anything meaningful.
On the contrary, and your next paragraph has it just right.
| Franz may try to term their system as "Modern" and thus, somehow, in
| its "modernity," superior to all of those other systems that "Aren't
| Modern."
Yes, that's it! It's a political name. On the other hand, we could
use ANSI Common Lisp the same way. Modern Lisp, whatever it is, it
is not ANSI. Depending on how much they are willing to incorporate
the full standard and stop breaking it randomly, I think it would be
better to return to the old Franz Lisp if they are determined to set
out on their own course rather than work within the Lisp community
to make important decisions in the open and with a defined level of
commitment beyond some whim from some VP or other about what the
next violation of the standard shall be.
Now, mind you, I think lower-case symbol names in Common Lisp would
do the language a world of wonder, but we have come to the point in
the Common Lisp world where it does not really matter that _often_
which case the slightly "internal" symbol names are. However, when
it matters, upper-case names look _really_ archaic. When computers
produce output to me in all upper-case, I find that about as rude
and/or backward as people who send e-mail or sms messages in all
upper-case. I half expect to receive postcards from such people on
80-column punch cards or to receive software from them on paper-tape
rolls, huge disk packs, or 9-inch magtape. I don't want Common Lisp
to fall into that category. At least there will be less explaining
to do to people who read Lisp code and who can now trust that the
symbol name actually consists of the letters they see. John calls
this "wysiwyg", but that's just too cute.
| That just seems _wrong_; it ignores the critical issue of "what's in
| the name?"
It's right there. "We are more modern than you are", basically.
I'm really not sure what to call such a beast. I'm not fond of
"Modern", and I proposed to call it "More Common Lisp" as a sort of
pun on the C -> C++ naming path as well as suggesting that it is
more common with lower-case than uppercase, it has more in common
with other languages if it does the same, etc. It didn't catch on.
| > I think behavior like this needlessly partitions a tiny community
| > and causes the needless drawing of battle lines that could as
| > easily have been avoided in favor of focusing the community on
| > real problems.
|
| That sure sounds right...
I think this came about because of the way it was mishandled through
a bad choice of migration criteria and a very bad choice of what to
nuke in the standard in the process, not what was attempted gained
in the process, but that may be just myopia on my part. I don't
think there would have been case wars if people's code would work in
both systems initially, namely from a readtable-case of :upcase to
one of :downcase and internally lower-case names, progressing to an
eventual :perserve if this really turns out to be useful.
Erik Naggum
| This lead me to a possibly irrelevant and naive question: why isn't case
| preservation or modern behavior controlled at the package level?
Basically because packages share symbols a lot. If you search the
external symbols on each of the package on a package's use list in
different cases, you're going to go nuts before you get used to
which package a symbol is actually in.
| It would help retain compatibility with packages that are nothing to
| do with interfacing (like series), and even let the door open for
| future swings back to case-insensitivity in the outside world.
This should be controllable with the readtable, instead, so that
when you process some code from a slightly different world, you can
tune a lot of things to make it right. Allegro CL has a "named
readtable" feature, and you can easily bind *readtable* at the top
of special files, but this requires that readtables are supported.
With the patch I posted to nuke excl::*forced-readtable-case-raw*,
you get this behavior back.
| As (interned) symbols are managed by packages, would it not be the
| right level, rather than the entire image, in the name of modularity
| and scalability?
Yes. This is why the readtable is the correct place to make this
decision, not a global variable that controls the entire image.
However, you must have consistency in how you store the symbol's
names. If you alternate between lower-case and upper-case, you will
lose track of which readtable applies to which package, and there
lies madness, too.
Hallvard B Furuseth
> I'm really not sure what to call such a beast. I'm not fond of
> "Modern", and I proposed to call it "More Common Lisp" as a sort of
Quiet (i.e. not shouting)? Tactful? Pretty? Sensitive?
--
Hallvard
Erik Naggum
| Did they change this right before the final spec? I'd swear it was
| not case sensitive (except entities) right up until the end. SGML
| is not case sensitive for element names, is it? How can XML be an
| SGML subset and have case sensitive names? Am I just hopelessly
| confused here.
SGML does not specify case sensitivity, only the means to specify
it. The SGML declaration includes that specification in the NAMING
NAMECASE GENERAL or ENTITY fields.
| I think facility of manual typein is WAY more important.
Curiously, that _is_ also an argument for lower-case symbols as well
as a case-sensitive reader.
| Not to mention the other niceties like usefulness in transmitted
| ascii text of uppercasing CAR, CDR, etc. to make them stand out when
| fonting isn't handy. I could go on but won't.
I think it boils down to familiarity. You don't need upper-case
symbols in Lisp to write them in upper-case in the text. I grew up
on TOPS-10 and -20, where upper-case and case insensitivity was the
rule, on TOPS-10 also without exception... It was a hassle to get
lower-case letters in filenames under TOPS-20 as they each had to be
escaped with ^V, even in source code. (Why _do_ I remember these
things? :) Several of the (now) old-timers I met at the time have a
fondness for upper- case that escapes me (no pun intended, sadly).
I learned to write a technical handwriting as a kid and I never got
used to this longhand cruft that could not possibly become readable
no matter how you did it, so I have very legible small letters, too,
and highly prefer them to writing print in capital. Over the years,
I have found a strange attraction to lower-case that predated my
exposure to Unix, but it sure felt good the first time I met a Unix
system in 1980. And all upper-case still feels "clunky" to me.
Erik Naggum
| Quiet (i.e. not shouting)? Tactful? Pretty? Sensitive?
That's a prett goody direction. I think I like "sensitive Lisp".
Simple, elegant, sensitive. A cat lover's Lisp. :)
Paolo Amoroso
wrote:
> honestly have to ask whether you're writing for posterity. Most of my
> code has had a substantially longer life than I ever expected. Code I
> wrote over 20 years ago is still in active use today, even some code I
Just out of curiosity: is it written in Common Lisp or some earlier dialect
such as Zetalisp?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/