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/
cbbr...@hex.net
> * cbbr...@hex.net
> | 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.
"MCL" is, I think, already taken.
Two obvious alternatives offer themselves:
a) CL++
b) (incf 'CL)
:-)
--
(concatenate 'string "cbbrowne" "@hex.net") <http://www.ntlug.org/~cbbrowne/>
Keeping a secret "Hall Of Flame" file of people's mail indiscretions,
or copying messages to private mailing lists for subsequent derision,
is good fun and also a worthwhile investment in case you need to
blackmail the senders later.
-- from the Symbolics Guidelines for Sending Mail
vsync
> b) (incf 'CL)
Uhhhhhh.... (incf CL) perhaps?
--
vsync
http://quadium.net/ - last updated Sat Nov 4 01:05:18 PST 2000
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil))
Tim Bradshaw
> 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).
In fact, you can do:
(defpackage :foo
...
(:export #:collect-sum ...))
which ensures stuff is OK.
Kent M Pitman
> On Mon, 6 Nov 2000 00:04:24 GMT, Kent M Pitman <pit...@world.std.com>
> 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?
A lot of it that I know of (and there are probably things I don't) is
part of Macsyma and was originally written in Maclisp (1978-81), and
some years later (1985-86) ported to CL. The translation to CL gave
it the real longevity. And certainly there's a lot of code I wrote
while at Symbolics (1985-1992) that continues to be in use; that was
in both Zetalisp and Common Lisp.
For that matter, a lot of code I wrote in Teco in the late 70's and
early 80's seems to still be used in a few obscure circles (since a
y2k bug was reported in a time-related library I wrote). Sure, we
tried to "write for the future", but a surprising number of times that
we thought we were writing "throwaway hacks", the stuff persisted lots
longer than expected.
It's one reason I advocate people putting a date-stamp on comments in
code. I think the same pattern (of surprising duration of use) is
true in buildings, btw. A lot of the "temporary" buildings built in
world war II that were expected to survive only the war are either
still up or only recently torn down. People mostly can't afford to
have something really be temporary when they are suddenly faced with
the expense of redoing something that really mostly already works and
can simply be coaxed to live a little longer.
Keke Abe
John Foderaro <j...@unspamx.franz.com> wrote:
> [...] 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.
In MCL, I can write #_SetWTitle, #_setwtitle, or anyway I like. **
And that makes my life easier, not harder.
regards,
abe
** (CCL::FF-CALL-SLEP #<SHARED-LIBRARY-ENTRY-POINT "SetWTitle"....
John Foderaro
email.
Change is difficult but necessary for a language to survive.
John Foderaro
> 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:
>
the answer is 4: switch to :case-insensitive-lower mode.
This mode doesn't have a fancy name yet. If you're in Modern mode then
switching to this mode is very fast (it just requires setting a few
variables). It will cause names to be downcased.
John Foderaro
>
> 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.
>
I'd like a serious answer to this question:
Assume that I know Japanese and you don't.
Would you rather get a program from me with all identifiers in
Japanese or one in English with mixed case identifiers?
I assume you'll say that you would prefer the mixed case version.
If that's your answer then shouldn't we first forbid identifiers to be
written an any language that an English-speaker can't understand before
we forbid mixed case English identifiers?
Marc Battyani
"Tim Bradshaw" <t...@cley.com> wrote in message
news:ey3r94q...@cley.com...
...
> 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.
Yuck!
I don't understand the current fad for Lisp/Java interaction.
Ok a Java FFI can be interesting but no more nor less than the C FFI.
Is there any interesting reason for this fad that I have missed?
Marc Battyani
Marco Antoniotti
John Foderaro <j...@unspamx.franz.com> writes:
I am going to send email and a hard-copy letter if necessary. (I
already did send a simple question to in...@franz.com)
I am not questioning the goodness or not of having a case sensitive
reader. (I am still wondering what was in the committee's mind when
they decided not to make the symbols in COMMON-LISP¹ lower case and
the standard READTABLE-CASE :PRESERVE).
But please, if you are going to make such sweeping changes, don't
force them unto us (well, at least me) the way you just did.
AFAIU, the minimal changes really required of the CL implementors
would be to downcase all symbols in their implementations and to set
the READTABLE-CASE to :PRESERVE. I am surely missing a lot here.
If this is enough, you should have campaigned with the other
implementors to make this change. This would have created a "de
facto" standard and all the currently running applications would have
followed suite.
Then you could have gone to X3J13 and ask for the relevant changes.
The way way you set up your "Modern" CL reader is incompatible with
the standard and it puts a burden on the user who writes code which
adheres to the ANSI standard. This burden is a long time result of
the choice not to make the CL reader case-sensitive, but, it is now
there because of your choice not to distribute an ANSI image.
So, let's try to make something good out of this.
Is there a way to actually standardize² a "case sensitivity" of the
reader? If yes, then I am sure that the people at Xanalys and
Digitool, the CMUCL, CLisp, Cormen folks, and the KCL camp people will
follow suite. However, people at Franz should be willing to hear the
arguments of other people as well.
Cheers
Marco Antoniotti
¹The package COMMON-LISP (all caps) is not recognized by the
ACL 6.0 reader. At a minimum, the variable
excl:*ignore-package-name-case* should be set to T as a default.
Moreover, at least for the ANSI required packages, you should have
put the all-caps nickname (or viceversa) in your implementation.
²By the term "standardize" I mean to at least produce a consensus among the
implementors on an interface which will not be changed arbitrarily by
any of them in the (near) future. The "cost" to implementors should
also be taken into account.
--
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
w.deakin
> I'd like a serious answer to this question:
>
> Assume that I know Japanese and you don't.
> Would you rather get a program from me with all identifiers in
> Japanese or one in English with mixed case identifiers?
>
> I assume you'll say that you would prefer the mixed case version.
Yes, whatever.
> If that's your answer then shouldn't we first forbid identifiers to be
> written an any language that an English-speaker can't understand before
> we forbid mixed case English identifiers?
Yup. However, I would like an answer to the more serious question: What has
this spurious nonsense got to do programming in common lisp?
Best Regards,
Will Deakin
Marco Antoniotti
John Foderaro <j...@unspamx.franz.com> writes:
> In article <3A0618EA...@fisec.com>, mon...@fisec.com says...
> >
> > 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
> ....
> ))
>
Yes. You can do this, but: how do you make sure that all the *extra*
symbols do eventually get collected?
Moreover, I find this inelegant. Of course if there was an agreement
that the READTABLE-CASE was :PRESERVE, then you could write
(defpackage "my-package" (:use "common-lisp")
(:export "function1"
"function2"
"ILookLikeAJavaFunction"))
without many problems.
Cheers
Rainer Joswig
<mar...@cs.nyu.edu> wrote:
> John Foderaro <j...@unspamx.franz.com> writes:
>
> > If things don't work as people think they should, they generally send us
> > email.
> > Change is difficult but necessary for a language to survive.
>
> I am going to send email and a hard-copy letter if necessary. (I
> already did send a simple question to in...@franz.com)
I wonder what all this sudden fuzz is about. IIRC ACL
shipped on the NeXT Cube almost a decade ago with similar
image settings (the excuse at that time was to better interface
to the Objective C environment of NeXT). This all
is neither new nor very "modern".
Macintosh Common Lisp comes with one of the largest
interfaces to foreign code (12000 foreign functions, 27000 constants, ..),
where the foreign code is mostly written in Assembly, Pascal, C and C++.
The code is mostly written using Pascal naming conventions
(like in "OTCancelSynchronousCalls").
MCL preparses the header files, generates Lisp versions
and provides an index over them. It even loads the definitions on demand.
This is all relatively painless, without any extensive
reader or package hackery.
I wonder what kind of magic I am missing? Why should MCL
even consider switching, since it already has a really cool
**working** solution?
--
Rainer Joswig, Hamburg, Germany
Email: mailto:jos...@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
John Foderaro
> Yup. However, I would like an answer to the more serious question: What has
> this spurious nonsense got to do programming in common lisp?
If your newsreader includes the ability to thread messages then read up
the chain of messages for which this is a followup and the answer will
be clear. If you don't use such a newsreader then you'll find that
Netscape's newsreader will threading.
John Foderaro
says...
>
> But please, if you are going to make such sweeping changes, don't
> force them unto us (well, at least me) the way you just did.
>
>
Let's be very clear about this.
The free trial version of acl6.0 for Unix is distributed with
Modern mode the default.
There is this readme.txt file at the top level of that distribution:
======
Thank you for downloading and installing the Trial Edition of Allegro
CL 6.0 for Linux or FreeBSD.
To make the downloadable file as small as possible, we have only
included one Allegro CL image, one is in International "modern" mode
(case sensitive lower, as opposed to case insensitive upper of "ANSI"
images).
To build a ANSI image, you can execute the following form:
(progn
(build-lisp-image "alisp.dxl" :case-mode :case-insensitive-upper
:include-ide nil :restart-app-function nil)
(sys:copy-file "sys:mlisp" "sys:alisp"))
======
Thus we are in effect supplying both the ANSI and Modern version
it's just that you have to build the ANSI version on your machine.
This is done to save you time downloading the distribution via a modem.
The ANSI version follows the X3J13 spec as regards readtable-case.
I would welcome standardizing on a way to get case sensitivity.
But as you've seen there are still some people who say
what what have is good enough so why bother changing.
So we're putting out what hawe now for people to experiment with.
I think that it's important for people to get experience with something
before they standardize on it. Also it's going to take a groundswell
of users wanting case sensitivity to convince the vendors to
come up with a 'standard' way of implementing it.
John Foderaro
says...
>
> Yes. You can do this, but: how do you make sure that all the *extra*
> symbols do eventually get collected?
>
Well the gensyms get collected by the garbage collector.
We usually use keywords for denoting package names but only because
that's a style we've adopted. There aren't that many package names. We
could use gensyms for them too if we want to save a few bytes from the
image.
> Moreover, I find this inelegant.
Elegance is in the eye of the beholder. Many people find the ANSI
alternative, a list of all upper case symbol names, to be even worse, so
you can't please everyone.
Kenny Tilton
> 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.
I had heard that mixed case was scorned here on c.l.l, but I had no recall
of such a thread, delighted to find one.
I first observed mixed case sans hyphens programming the Mac OS (before it
was called that) and that of course was written in pascal. I immediately
adopted the technique in VAX Basic and then Common Lisp (not that either
compiler cared). Now unmixed-case-words-strung-together looks terribly busy
to me, except as a function name. Go figure.
At what hour tomorrow am I to be shot?
kt
Barry Margolin
Kenny Tilton <kti...@nyc.rr.com> wrote:
>I had heard that mixed case was scorned here on c.l.l, but I had no recall
>of such a thread, delighted to find one.
>
>I first observed mixed case sans hyphens programming the Mac OS (before it
>was called that) and that of course was written in pascal. I immediately
>adopted the technique in VAX Basic and then Common Lisp (not that either
>compiler cared). Now unmixed-case-words-strung-together looks terribly busy
>to me, except as a function name. Go figure.
One of the main reasons why mixed-case names aren't generally used in Lisp
is because most Lisp systems map input to a single case by default, to give
the appearance of case insensitivity. So if you type:
'WhatsInAName
the Lisp system will respond:
WHATSINANAME
Since the case changes aren't preserved, it's very inconvenient to use
them.
Personally, I've never liked the mixed-case style. In normal prose we
separate words with spaces, and underscores and hyphens are reasonable
standins for them. Using case changes as word delimiters just doesn't look
natural to me.
--
Barry Margolin, bar...@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Lieven Marchand
> 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.
And if the author only uses one implementation (yours) and isn't aware
of the non standard behaviour? If he ever has to port his code to
another implementation he isn't going to thank you. This behaviour of
encouraging people to write to your own "standard" reeks of Microsoft.
> I want that too but more than that I want to drag people currently
> using ANSI mode into the Modern mode.
Interesting choice of words: drag. Does this imply they don't want to
go there from their own free will? Although I like case insensitivity,
and find very little value in your |field| vs. |Field| example from a
software engineering aproach, I have nothing against a case sensitive
CL with lower case symbols, but breaking old code without reason in
the process is not the way to go.
--
Lieven Marchand <m...@bewoner.dma.be>
Lambda calculus - Call us a mad club
John Foderaro
says...
> And if the author only uses one implementation (yours) and isn't aware
> of the non standard behaviour? If he ever has to port his code to
> another implementation he isn't going to thank you. This behaviour of
> encouraging people to write to your own "standard" reeks of Microsoft.
>
Are you suggesting that we remove everything from our Lisp that isn't
part of the ANSI standard? That would include the lisp threading
facility, the foreign function interface, the socket interface and much
more. We could do that and sure enough you would have a lisp in which
everything you wrote would work on other ANSI Common Lisps.
Is that the lisp you would want to use?
I doubt it, unless you're teaching a very first class in Lisp.
The fact is that every ANSI Common Lisp out there has extensions unique
to that implementation and people use those extensions.
Yes this causes a problem when porting from one implemenation to the
other but people accept that problem.
Case sensitivity is just one more variant. In fact it's far less likely
to be a porting issue than, for example, the particular foreign function
interface you use.
> Interesting choice of words: drag. Does this imply they don't want to
> go there from their own free will?
Ever since the Common Lisp definition started to gel evolution in the
Lisp language has slowed. Lisp used to be a springboard for
experimenting with language ideas, then change became a dirty word.
So yes, we have to get Lisp jumpstarted again.
> Although I like case insensitivity,
> and find very little value in your |field| vs. |Field| example from a
> software engineering aproach,
If you look at object oriented case sensitive languages you'll generally
find this is the convention they use (Smalltalk, C++, Java).
> I have nothing against a case sensitive
> CL with lower case symbols, but breaking old code without reason in
> the process is not the way to go.
That's the key point I've been making. Old code continues to work either
in ANSI mode or in Modern mode. That's my #1 goal for without it we
require everyone to choose one or the other and people will just stick
with the old ANSI version.
John Foderaro
There's no question that ACL can run in Modern mode with readtable-case
and *print-case* active. On thing that's missing from your code is how
to deal with fasl files. The fasl reader does automatic case conversion
so that you can compile in one mode and read in another mode. If
readtable-case is active then you have to somehow encode that in the fasl
files and let the fasl reader know about the current setting so it will
do the right thing before interning symbols.
As I've said my goal is to be able to load ANSI code into a Modern lisp
and make it run with minimal porting effort and change to the code. This
will encourage people to use Modern mode (or maybe I should say that it
will not discourage them from using Modern mode). The real test as to
whether making readtable-case active in Modern mode is a good idea is
whether it impacts the importing of ANSI code.
I have no emotional attachment to the way things are currently done.
It's just a program after all. There are procedures for effecting
changes in programs.
cbbr...@hex.net
> John Foderaro <j...@unspamx.franz.com> writes:
> > 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.
>
> aware of the non standard behaviour? If he ever has to port his code
> to another implementation he isn't going to thank you. This
> behaviour of encouraging people to write to your own "standard"
> reeks of Microsoft.
.. Or of Oracle, or of IBM, or others, depending on the moment...
> > I want that too but more than that I want to drag people currently
> > using ANSI mode into the Modern mode.
>
> Interesting choice of words: drag. Does this imply they don't want to
> go there from their own free will? Although I like case insensitivity,
> and find very little value in your |field| vs. |Field| example from a
> software engineering aproach, I have nothing against a case sensitive
> CL with lower case symbols, but breaking old code without reason in
> the process is not the way to go.
Interesting indeed.
There is quite a stark contrast between:
"I want to drag people ... into the Modern mode"
and
"I think that the _merits_ of the Modern mode represent a
compelling argument that will cause people to _want_ to use it."
--
(concatenate 'string "cbbrowne" "@hex.net") <http://www.ntlug.org/~cbbrowne/>
Appendium to the Rules of the Evil Overlord #1: "I will not build
excessively integrated security-and-HVAC systems. They may be Really
Cool, but are far too vulnerable to breakdowns."
Erik Naggum
| Are you suggesting that we remove everything from our Lisp that isn't
| part of the ANSI standard?
John, please listen, now. Nobody is suggesting any such thing.
Least of all I, but you know that, already. I support what you do
in extra-standard work. I have argued strongly, vociferously, and
fervently at times, that people _should_ use implementation-defined
extensions both to the language (like the effect of threads on the
binding behavior of special variables) because that moves the
language _forward_. I don't support what you do to _break_ the
standard, because that moves the language _backward_.
| Case sensitivity is just one more variant. In fact it's far less
| likely to be a porting issue than, for example, the particular
| foreign function interface you use.
It would be even less of a problem if you didn't break the workings
of readtable-case. I have shown you, with the code to support my
claim, that your choice to break that functionality is gratuitous at
best, and purposefully undermining the standard because you think
that particular functionality is a kludge to fix a botch at worst.
Your insistence on not getting this has pissed me off for a long
time, and you're doing exactly nothing to understand it now, either.
| Ever since the Common Lisp definition started to gel evolution in the
| Lisp language has slowed. Lisp used to be a springboard for
| experimenting with language ideas, then change became a dirty word.
| So yes, we have to get Lisp jumpstarted again.
I think I have said so quite explicitly, but I said one more thing
that you consistently omit: First we fully implement the _entire_
standard, because that works as a better springboard to really know
what needs to be changed or expanded. If you jump from a broken
springboard, it's just foolish to blame non-broken springboards, but
that's what you keep doing, John. Because you _break_ the standard
you don't like, you _blame_ the standard for not supporting what you
need, and use that as an excuse to continue to dislike it, but this
is fantastically counter-productive. But as I have shown you, by
nuking that stupid *force-readtable-case-raw* thing, you can get
what you want _within_ the standard operating parameters of the
readtable and the printer control variables. Take this to heart.
| > Although I like case insensitivity, and find very little value in
| > your |field| vs. |Field| example from a software engineering
| > aproach,
|
| If you look at object oriented case sensitive languages you'll
| generally find this is the convention they use (Smalltalk, C++,
| Java).
Others have chosen a namespace-like approach. Like Common Lisp does
special variables with *stars*, Dylan has classes with <brackets>.
I actually think this makes a helluva lot of sense, that it is quite
elegant, and furthermore, the abuse of case reminds me of German.
The use of underscores is clearly Too Ugly, so some fools instead
went for AlternatingCapitalLetters, which I can't help snicker at --
it looks like the really want to be programming with crayons! With
their keyword-rich languages and highly redundant syntaxes, exactly
what kept them from using internal _whitespace_ in identifiers? If
you look at the grammars of these languages, you find that there
_is_ room for internal whitespace in identifiers. So why don't
they? Braindamaged language designers who can't think outside of
the box they live in, that's what.
I don't think caving in to other language's bad choices is a good
choice for doing stupid things in Common Lisp. Common Lispers are
like English-speakers: used to words with several meanings depending
on the context and any modifying words in the context. This is not
a problem that needs solving. In languages designed by people who
have never quite progressed beyond coloring the parts of speech
differently when parsing sentences, hating the fact that many words
exist in multiple roles, they can't have an identifier named the
same as a type, or a function the same as a variable. This is so
_ridiculous_! How could anyone _be_ so unintelligent as to set this
kind of mess up for himself?
Now, why do I want a Common Lisp with case sensitive symbols and
normally all lower-case symbols? Because I want the _freedom_ of
actually referring to a symbol as, say, NORDPOOL in all caps, and
have it print back to me the same way it was read. That has nothing
to do with what other languages have conventions for -- the fact
that they _have_ those conventions _came_ from that freedom, so it's
the (fundamental) freedom I want, not their (random) conventions.
| That's the key point I've been making. Old code continues to work
| either in ANSI mode or in Modern mode.
This is just plain wrong, John. It is only true if you follow Franz
Inc coding standards in ANSI mode. People don't do that. They'd
have to change their ways to use a case-sensitive Lisp no matter
what you think, precisely because of the nature of the change. I'm
staring in disbelief at your repeated assertions that I know to be
completely untrue and I wonder what the hell you're thinking. Who
the hell do you think you're fooling with this useless propaganda?
| That's my #1 goal for without it we require everyone to choose one
| or the other and people will just stick with the old ANSI version.
I have given you an alternative that you won't listen to: Switch to
lower-case symbol names as a separate step from case sensitivity.
That way, people will find their dependencies on case first, and
when that is gone (since it's a good idea not to have that kind of
dependencies, since the case of symbols is an arbitrary decision).
This can only be done if you are honest about the case change, which
you are not, and which it bugs me to no end that you don't realize.
_When_ people have become accustomed to lower-case symbols and have
stopped making assumptions about the internal case of symbols,
there's a natural fall-out: case sensitivity will be much closer,
and much less harmful to introduce to the Common Lisp world.
If you introduce case sensitivity with lower-case symbols at the
same time, you will meet with legitimate and strong resistance,
because it is just too much at once. Contrary to what you think,
there _is_ no migration path from a Lisp with upper-case symbols and
a case-insensitive reader to a Lisp with lower-case symbols and a
case-sensitive reader which you can walk, carrying all the baggage
in one trip. If you have to make several trips, you need to break
the migration path in two or more parts so people can make one trip
per "leg" in the whole migration path, but they must also not be
allowed to return. Each step must leave something behind that you
_don't_ want. In the case of Common Lisp, you are asking us to
leave too _much_ behind that we are supposed not to want, like your
stupid (sorry, John, but that's exactly what I think it is) disdain
for the standard's solution to the problem of case, and we won't
move. Enticing people to make changes in their lives is hard work,
but there are some things you need to do right: First, make them
want to move by offering something at the other end of a journey
across the migration path, but also make them want to leave
something they do not want behind and make sure the two are so
tightly coupled they can't have one without leaving the other.
Second, make sure that you can't go back and pick up your old ways,
or people will do just that. The leaving behind thing is serious
business. (You seem to think that people are as disgusted with the
case issue in Common Lisp that you cannot fathom that people do not
want to leave readtables behind, but that's your _big_ mistake.)
This wisdom actually comes from my father, who was in charge of
"rationalization" at an industrial plant when I was just a kid. At
the time, it was a problem that workers returned to their old ways
despite what the management thought were good reasons to move to a
new way of doing things. The problem wasn't that the reasons were
not good enough. The problem was that they _could_ return. All the
effort of the rationalization had been spent on making the move into
a smooth process, like crossing a plain. But that's just wrong.
You have to cross a hill or at best a mountain pass to move to a
better world and _stay_ there. That's why I don't move to the
U.S. -- it's easy enough for me to get the best of both worlds, not
to mention some crucial developments in the politics of the U.S.,
what with the dire consequences of having that moron George W. Bush
in the driver's seat for four to eight years and his Supreme Court
justices and other key personnel in charge for the next several
decades, I imagine myself wanting out of there like so many other
Americans currently feel like fleeing the place before it's too late.
What you are suggesting to us all, John, is that we leave behind the
things in the standard that you personally hate with a passion.
(Please don't try to deny this -- at first I couldn't believe the
hostility towards the resolution to the case issue in Common Lisp
that you harbored.) But most of us don't feel that way about these
issues. On the contrary, many of us are actually happy with the way
it has been decided and how it has worked out. We're not going to
pick up your hatred and leave all that behind. You're not that good
a cult leader, John, and if you think in cult terms (like a "Modern
Cult"), you're doing it all wrong. The Common Lisp community is
just that: a community, where we _respect_ a common set of rules and
laws and standards. You don't. That's _your_ problem, not ours.
You _must_ be thrown out if you persist in disrespecting what the
rest of the community respects. Don't do that to yourself! This is
a fight you can't win. You can win if you _don't_ fight, however.
If you want us to do something differently, make sure we get
something back for doing it that can motivate us to join you. The
freedom of using and preserving case information is enough for me,
for instance. The simplicity of dealing with symbols that look
excatly like they are written is appealing to me. I think upper-
case symbols look old and clunky and don't want to explain why we do
things that way to people I'd like to use Common Lisp, not the least
because I fail. Case is an arbitrary decision if you have a case
insensitive reader, but like all arbitrary decisions, they have to
fall down on one side, and that side invariably carries some kinds
of connotations with it. Upper-case communicates "old and clunky"
to a lot of people. I'd like to move away from that to a new world.
But you can't lie to people if you want them to join you. That only
works for idiots who run for President, and that's only because they
get much power it's worth the loss of credibility to get it. You
are not going to get any power just because some Lispers move from
upper- to lower-case symbol names, and you have already realized
that you aren't going to get the entire community with you, anyway.
That code written to ANSI X3.226-1994 is going to continue to work
when ou downcase the symbol names and don't even downcase in the
reader, but claim that you upcase, insead, is just obviously false.
I can't believe you think you can fool anyone with that hoax, John.
It pisses me off that you do, too, because it's such a gross insult
to people's intelligence. Common Lisp programmers are among the
very smartest programmers around. You treat them like they are
stupid because they don't _rebel_ against upper-case symbol names
when it's _you_ who are stupid because you _rebel_ instead of work
_with_ the community to make this at first an implementation-defined
property of the Common Lisp implementation.
The way you're going about this case issue has bugged me for years.
The way you have consistently denigrated those who don't agree with
you on the case issue may in fact explain why they stick to _their_
ways instead of listening to you, and why you don't budge, either.
I was not there at the time, but I have a feeling from what I have
read in the publicly available notes, that you went about this as
irrationally and counter-productively in the committee as you do now
and that you failed because you never realized that in order to get
your choice, you have to make the other choice available, too.
If we shall ever succeed in getting Common Lisp away from specifying
that all symbol names are in upper-case and that the reader upcases,
we must make it implementation-defined, forcing people to check if
they need to know, and use symbols to get their names, not the other
way around, meaning that the reader has the _only_ opportunity to
leave _its_ decision behind in the code. This means full support
for readtable-case and the printer control variables, which you
hate. This means that the Franz Inc coding standards that works for
both lower-case and upper-case Lisps becomes more popular, and we
can get a new and better world where the internal case of symbols no
longer matters. But we do this the community-friendly way, through
the standards bodies, with working systems that _respect_ the work
of the standards bodies and the communities behind them. You have
shown us that a lower-case Lisp works just fine. That is good. I
have shown you that you don't have to break readtable-case to get
that lower-case Lisp. That is good, too. Now we can show people
that if they write code that does not assume an arbitrary decision
has been made one particular way, they will win something and write
better and more robust code, too. That is a good way to go.
A splinter group, a Modern Cult, an implementation broken in the way
it deals with specified behavior, is a very bad, very stupid way to
make a community move in your chosen direction. I am so thoroughly
annoyed with you for not using your sometimes brilliant mind to get
this simple picture, but continuing to do stupid things that hurts
the Lisp community with your hatred for parts of the standard. You
have not listened to me before, and I sort of doubt that you will
listen to me now, but you're a really smart guy with a serious
hangup that needs to be cured before you can get the respect your
work deserves. The reason is that you don't respect those who hold
opinions on the case issue different from your own and ignore their
needs and their requirements, which are far more important things
than whether some code "works" or not.
With a standard, we build a society based on trust in common resepct
for the standard, in best-effort implementations of it, and we hold
implementers harmless for mistakes if they also work to fix them.
With a standard, we build communities that work and communicate
together with a common baseline that is not subject to violation
except by malicious outsiders, criminals, and destructive forces of
other kinds. With a standard, we sign contracts and pay monies for
work assuming the entire contents of the standard as part of the
specification for that work by reference. With a standard, we take
part in a very, very long legal tradition that extends far beyond
programming and contracts: That of trusting an authoritative third
party to resolve our disputes, reasonable as well as unreasonable.
With your standards-breaking attitude, specifically that _you_
should be that authority (no longer a trusted third party) and that
whatever _you_ decide shall prevail, you throw not just some parts
of this framework of trust out the window, but _all_ of it.
This works for Microsoft because they have succeeding in building
their own society and community around trust in their authority,
such as it is. Microsoft has built their community around them.
Franz Inc is a vendor that sells to a community they have not built
on their own. They do not own the community and they cannot dictate
the community will. Franz Inc _chose_ to implement Common Lisp
instead of continuing Franz Lisp. That meant something to you once.
It means something to me now, and not just because I like the way
the standard does things, but because I like standards as such,
because I like lawa snd organized societies that relieve me of
fighting for my rights all the time so I can instead form bonds with
people based on mutual trust and respect. Granted, today's
political reality is a far cry from what I expect and want to live
under, but my operating principle is that _I_ shall not contribute
to any further destruction of society-building mechanisms as defined
and reasonably well upheld. I am deeply insulted and offended when
you don't give a fuck about these principles, John, and just want to
go off and destroy all the work that went into building this
community just because you harbor a long-standing hatred for the
committee's choice of upper-case symbol names.
Let's build a bigger community, not more and smaller societies.
Let's find ways to make room for your lower-case needs within the
important political desire not to specify arbitrary decisions so
strictly that reasonable choices are no longer available. And that
includes you, John: You have to make room for the upper-case needs
and other people's desire to have reasonable choices, too.
David Bakhash
> 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.
Maybe it did, and maybe it didn't. But comparing them is not
tasteless in my opinion. I program in both, earn my living from both,
have to make decisions every couple of months on which to use for
what problems. So I *have* to compare them since they're the only two
general-purpose programming languages I know.
> 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...
I recently worked on a Common Lisp extension specification, and the
work was tremendous. It took more out of me than coding, and demanded
an extreme amount of forethought. It was only then that I came to
respect the CL spec, and how much effort it must have taken on the
parts of those who were doing the hammering.
In that process I was working with someone whose views were extremely
different from mine. For example in discussing the CL specification,
the mentioned the main things he felt were wrong decisions. One was
the separate symbol function namespace issue. Ouch! How could you
argue with someone who's no less smart than you, has been programming
in CL longer, and whose opinion is no less valuable than yours in the
democratic sense? We argued it out, like always, but in the end it's
a matter of taste and opinion. So, just think how many such issues
there were for CL. I have to think about it because I wasn't there to
experience it. I try to understand the issues and the way they
arrived at answers by reading about the issues in the HS. But I
really wish I had access to historical documentation of who wanted
what and why.
The most important point is that -- no -- most people who use CL don't
pay this massive respect to the effort that went on during
standarization. I think the same goes for Perl. Most people just
learn Perl, some even fall in love with it, but don't realize how many
people (especially Larry Wall) sweated over it, over its libraries,
and over porting and testing it all over the place. Does that work
deserve the bashing it gets? Lots of very cool ideas, and even
meta-object methodologies can be experimented with in Perl, as I have
played around with it. There's a reason for the `use strict' pragma,
and that's to appease people who don't want to maintain spaghetti.
And Perl doesn't have to look all nasty, especially if you're willing
to suppress that itch to save a few characters here and there. It's a
beautiful language in its own right. I think what's wrong is to put
down a language without experience programming in it (and this is a
general statement, as I'm assuming that most Perl bashers on this
newsgroup have tried Perl, and might even use it for shell scripting,
since CL is a relatively weak in this respect).
There are aspects to my limited creativity in programming that simply
do not manifest themselves in CL. I can't really explain why. But in
Perl they show up. To me, that means a lot. It's true that what I've
done in CL is cooler than in Perl, but when you're one guy, doing
contracts to make a living, and you receive a problem and have to
hammer out a solution, and they want to easily be able to test and run
it, then Perl has been quite good.
For those who bash it, but can't honestly say they've given it a fair
chance, please do. Even a CL diehard swears that it's not all that
bad. No matter what your style is, I believe that Perl can support
it, except macrology, in which it's deficient, as far as I know.
Funny that I'm going to contradict myself now, but one of the best
ways to enjoy Perl is specifically to NOT compare it to CL (but only
as you're learning it). If you do, you'll likely want to give up
instantly.
dave
Friedrich Dominicus
>
> The most important point is that -- no -- most people who use CL don't
> pay this massive respect to the effort that went on during
> standarization. I think the same goes for Perl. Most people just
> learn Perl, some even fall in love with it, but don't realize how many
> people (especially Larry Wall) sweated over it, over its libraries,
> and over porting and testing it all over the place. Does that work
> deserve the bashing it gets?
IMHO the answer is a clear no. Language bashing is hardly appropriate
most of the time. There are good ideas in any language and it was and
is much work (even today) to implement a language. Comparison is
nevertheless allowed and IMHO should be done. To come to an somewhat
fair judgement, one even must compare them.
But I guess whith this answer I'm a bit than slighly off-topic ;-)
--
for e-mail reply remove all after .com
Tim Bradshaw
I said case-insensitive uppercase. But assuming I can live with
case-insensitive lowercase, can you do this on a per-readtable basis?
I *really* don't want to have to do all this stuff inside a
without-interrupts.
What I want to be the case in fact is that there should be two
features:
1. what the reader does in terms of case conversion, or not. The
features provided by the standard seem adequate for this. If Franz
feel they are inadequate I'd like whatever they provide to be at
least reflected in the standard parameters.
2. what case symbols are in packages. It would be nice to have some
tool which would do the conversion of a package, possibly under
programmer control. Perhaps it is too hard to consider conversion
of just one package, in which case something that would simply map
over all symbols would be OK. Ideally this thing should take a
predicate which could decide whether to convert a symbol, and
perhaps another function which could optionally return the new
name.
Obviously I haven't though out this design very far. But the current
Franz design is appalling, it just randomly bundles in these two
issues: I couldn't possibly consider using it any more now than I did
in 1989 when I first came across it.
--tim
Tim Bradshaw
> Yuck!
> I don't understand the current fad for Lisp/Java interaction.
> Ok a Java FFI can be interesting but no more nor less than the C FFI.
> Is there any interesting reason for this fad that I have missed?
Everyone else did it 4 years ago, therefore it is now time for Lisp to
do it.
--tim
w.deakin
> If your newsreader includes the ability to thread messages then read up
> the chain of messages for which this is a followup and the answer will
> be clear. If you don't use such a newsreader then you'll find that
> Netscape's newsreader will threading.
Thank you for you help and concern with regard to my newsreader. However, this is
*not* the problem.
The problem is that Franz apear to have made a policy decision to break the ANSI
Common Lisp standard, for what appears to be no sufficiently good reason.
Wittering about translating Japanese into English would then appear to be nothing
other than a smokescreen.
In reply to a posting from Erik Naggum you say:
> I have no emotional attachment to the way things are currently done.
> It's just a program after all. There are procedures for effecting
> changes in programs.
OK then, so why not affect changes such that the standard is observed? or are you
not emotionally attached to the ANSI standard either?
As an aside: if it is correct that Franz has decided to break with the ANSI
standard, (sigh), I would politely suggest that you have a bit of a PR problem.
Best Regards,
Will Deakin
-- who is somewhat annoyed because he is probably overly emotional attached to
the idea of a standardised common lisp.
Kent M Pitman
> As an aside: if it is correct that Franz has decided to break with
> the ANSI standard, (sigh), I would politely suggest that you have a
> bit of a PR problem.
I don't think they can "break" the standard. The standard is unaffected.
HOWEVER, their decision not to support the standard by default means the
following to me:
Normally, when someone posts to this newsgroup asking what gratis
versions of ANSI CL are available to try out, I am careful to
recommend both Franz and Harlequin as being among the primary options,
since I ordinarily consider both to be strong, credible, commercially
powerful implementations of the standard. SO, until I hear that
Franz has made a commitment to making ANSI CL be what a user sees when
they start up the product by default, I will no longer personally opt
to refer people to the Franz trial option.
It is Franz's right to make a market decision to put ANSI CL second in
favor of some other design of their choice. It is the right of we in
the community--individually as people with personal preferences, or
collectively as whatever organizations we belong to--to take whatever
public position on this we wish. That's what markets are about.
To the extent that Franz is supporting what I think the market needs,
I'm happy to refer customers to them. To the extent that they deviate
from that, I will personally refer customers elsewhere.
Franz continues to provide a quality product, but if they choose to
be ashamed of CL, then I as a CL supporter will choose to be ashamed
of them. It works both ways, and they have made the choice. I am
merely reacting to it.
If they want to make this a community thing, they are welcome to create
a venue (ansi, ieee, ietf, or the franz standard making authority, for
all i care) that issues and documents a competing standard. And I hope
the diverse community that creates and endorses that standard will rally
around it. But our community, for better or worse, made ANSI CL, and
that's what I'm going to rally around in this forum.
I have taken similar positions on other not-quite-ANSI-CL implementations
in the past, it's just not been so visible because omitting one of those
from a public recommendation was routine, since people usually only
recommend the top 2 or 3 implementations except on the ALU faq pages.
It's unusual to be in the case where someone HAS a compliant version of
CL but merely chooses not to put it forward as their primary option, but
far be it from me to deter them in their desire to have people not see
them as an ANSI CL at first blush. I'm more than happy to give higher
visibility to some of the less-often-mentioned implementations instead.
That's how I plan to handle it, anyway. Others are welcome to choose
their own path.
Kent M Pitman
> "w.deakin" <w.de...@pindar.com> writes:
>
> > As an aside: if it is correct that Franz has decided to break with
> > the ANSI standard, (sigh), I would politely suggest that you have a
> > bit of a PR problem.
>
> I don't think they can "break" the standard. The standard is unaffected.
Sorry, it was late at night, and as has been rightly pointed out to me, my
eye missed that deakin hadn't just said "break" but "break with"; as such,
this remark in my reply was somewhat out of place.
hai...@honolulu.ilog.fr
>
> the symbols exported from the CL (ehem, I mean the cl) package ...
Are package names also case sensitive in ACL 6 "modern mode", or only the
symbols? Can "modern mode" be switched on or off on a per package basis,
as in CLISP?
Bruno
Marco Antoniotti
John Foderaro <j...@unspamx.franz.com> writes:
> In article <y6c1ywp...@octagon.mrl.nyu.edu>, mar...@cs.nyu.edu
> says...
> >
> > Yes. You can do this, but: how do you make sure that all the *extra*
> > symbols do eventually get collected?
> >
>
> Well the gensyms get collected by the garbage collector.
> We usually use keywords for denoting package names but only because
> that's a style we've adopted. There aren't that many package names. We
> could use gensyms for them too if we want to save a few bytes from the
> image.
In ACL 6.0
(defpackage :zut (:export #:qwe))
expands into
(eval-when (compile eval load)
(excl::defpackage-1 ':zut '((:export #:qwe))))
I may be wrong, but it seems to me that the '((:export #:qwe)) becomes
a constant list in a compiled file.
Do you collect also top level "already executed" forms? If not, how
can the collector get to the symbol?
> > Moreover, I find this inelegant.
>
> Elegance is in the eye of the beholder. Many people find the ANSI
> alternative, a list of all upper case symbol names, to be even worse, so
> you can't please everyone.
Point taken.
Cheers.
Marco Antoniotti
hai...@honolulu.ilog.fr writes:
There is a variable
excl:*ignore-package-name-case*
but it is set to NIL as a default. At a minimum Franz should be set
to T as a default.
Cheers
Joe Marshall
well, i fOr one applaud franz'S bold step of breaKinG with thE AnsI
stAndArd (not tO menTion breaKinG lEgAcY code) in goiNg to
cAsE-sensiTive IdEntIfIer. JusT Think How this enabLes YoU tO do
thIngs thAt Were ViRtually impOsSible tO dO befOre (i doN't KnOw AboUt
YoU, but on my kEyboArd thE verTicaL bAr is UncoMfortAblE fAr aWay).
Since this will solvE All thE pRoBlems we haVe hAd inTerfacing LisP
with java, we will finally be aBle tO Add A ricH set of mOdern
oBject-orienTeD lIbrArIes tO thE arChaiC and sParse set of Standard
coMmon lisp librarieS.
And we Now haVe an EnorMoUslY lArgEr set of iDenTifiers tO ChOoSe
froM! Imagine, in one stRoke, frAnz has increaseD thE nUmbEr Of
MachInE diStinGuiShable iDenTifiers by A hundredfOld, or even a
thOuSandfOld fOr YoU mOre verbose progrAmMers. Even if thE nUmbEr Of
hUmAn diStinGuiShable iDenTifiers hAsn't increaseD as Much, thE seT
is still BiggeR, and theReFoRe, BetteR.
But has frAnz gonE fAr EnoUgh? i doN't Think so. aiMing tO be mOdern
in this pOst-ModErn woRld is positiVely reTro. Mixed case, by itSelf,
is mereLy A cumbersome synTacTic Device. sure, pEoplE will add
ObScure and arcane ruleS as tO wHen tO miX case, but heRe is the
opportUnItY tO coDify an aRbitRaRy ConventiOn befOre pEoplE get uSed
tO oNe. FurthermOre, theRe aRe so ManY oTher microsynTacTic
IdIosYncrAcIes thAt haVe been left uNexploRed. HeRe aRe some of my
ideas:
1. i Think we ShOuld make suRrouNdiNg AstErIsks not jusT a
ConventiOn fOr spEcIal vArIablEs, but A requirement. We Could then do
away with spEcIal deClaratiOnS.
2. IDenTifiers aRe UsEd fOr VaRyiNg semaNtic purpOseS. ratheR
than HiDe theiR PurPose beHinD A riGid wall of stAndArd case, we
ShOuld make Sure thAt pEoplE uNdeRstaNd thAt theRe is A clEar
differenCe beTween A variabLe thAt is BouNd by A lEt expRessioN And
one thAt is BouNd by A lambda. Case simPly dOeS not go fAr enougH,
thoUgh. i pRopose addinG A NoN-AlphAbEtIc PrefiX, SuCh as $ or % to
variableS.
3. Let'S faCe it. parenThesis aRe wAy Too coNfusiNg even fOr LisP
ProfessionaLs. it is Much EasIer tO haVe A spEcIal set of MatchIng
GrOupinG chaRacteRs fOr thE vArIoUs different kInds of groUpIng. For
InstAncE, lEt binDings ShOuld haVe sQuArE braCketS, progns (bOth
lItErAl and ImplIed) ShOuld haVe Curly Braces, eTc. eTc. In facT, If
we can diStinGuiSh fUnctIons From vArIablEs by MicrosYntAx alOne, the
MacrosYntAx becomes redundant. we can EithEr remove It (imagine a
paRethesis free lIsp) or UsE thE rEdUndAncY tO hElp users CatCh
Errors by refuSinG tO coMpIlE unLess both thE micro and macro sYntAx
matCh.
4. it Would be niCe tO be aBle tO traCe thE lEgAcY of thE bUilt-In
SymbOlS. i pRopose thAt thOse iDeas thAt originaLly came From the
MaclIsp -> Zetalisp EvolUtIon be All uppeR case, and thOse thAt came
From inTerLisP be caPiTaLizeD, whIlE aNy thAt came From otheR
dIalEcts, SuCh as pCl, ShOuld be All lowEr case. This will emphasiZe
thE riChneSs of thE HisTory of LisP.
5. We alSo Need A rIchEr package sYstEm mOdel. I'd lIkE tO be aBle to
UsE jusT thE uppeRcase sYmbols of package a and thE lowErcAsE OneS
From package B (but i wanT Them visibLe as UppErcAsE).
So kuDos tO frAnz fOr hAvIng thE courage tO sTanD Up aGainSt thE LisP
coMmUnItY At larGe and fOr hAvIng thE VisioN tO Drag us kickiNg And
scrEaMing inTo thE ModErn worLd.
Now we be mOre than lisp progrAmMers. We will be 3lItE d00dZ.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Marco Antoniotti
Marco Antoniotti <mar...@cs.nyu.edu> writes:
> hai...@honolulu.ilog.fr writes:
>
> > Tim Bradshaw <t...@cley.com> wrote:
> > >
> > > the symbols exported from the CL (ehem, I mean the cl) package ...
> >
> > Are package names also case sensitive in ACL 6 "modern mode", or only the
> > symbols? Can "modern mode" be switched on or off on a per package basis,
> > as in CLISP?
>
> There is a variable
>
> excl:*ignore-package-name-case*
>
> but it is set to NIL as a default. At a minimum Franz should be set
> to T as a default.
I meant "Franz should set it to T as default".
Haven't had enough coffee this morning. I get bagels, but I miss the
Bar Pasquino. :) So much for memory lane.
John Foderaro
says...
> I may be wrong, but it seems to me that the '((:export #:qwe)) becomes
> a constant list in a compiled file.
>
> Do you collect also top level "already executed" forms? If not, how
> can the collector get to the symbol?
>
Certainly one way to do file compilation is to create a per-file block
of constants. That's how we did it in the Franz Lisp compiler (late
70's early 80's). Our Common Lisp compiler works differently and
builds the constants when they are needed during the fasl process and
then no longer refers to them, so that they are garbage collected away
if not other reference exists. This applies to top level anonymous
lambda expressions as well as those are just data too.
- john foderaro
franz inc.
Rainer Joswig
<j...@content-integrity.com> wrote:
> well, i fOr one applaud franz'S bold step of breaKinG with thE AnsI
> stAndArd
i tHiNk joE HaS a g00d poInt. wE nOW NEed AN eMax ComaNd:
m-x ModeRniZe (reGioN / buFFer / WoRld). iT shOUlD Do
piEcewiZe SouRce COloRiNG, 2.
John Foderaro
>
> The problem is that Franz apear to have made a policy decision to break the ANSI
> Common Lisp standard, for what appears to be no sufficiently good reason.
>
Let's go through this one more time:
The commerical version on cd-rom comes with prebuilt ANSI images with
all the ANSI semantics you know and love.
The free trial version which has to be downloaded comes with
a Modern image and instructions that will get you an ANSI image
in less time than it would taken to download the ANSI image from us.
The Modern mode is not new, it's been in our lisp for 15 years
and was accessible via (set-case-mode :case-sensitive-lower).
This not a 'sudden' shift away from the ANSI standard (unless you're
speaking in geological time).
One of the things we want you to try is the opensourced xml parser which
works best in the Modern International version.
No matter which Common Lisp you use, you are using a Common Lisp
that has extended the ANSI standard. The ANSI standard doesn't
include a function for exiting the image so at the very least
you're using a non-standard function for this purpose (nnless you
^Z and kill -9 the process, or are running on a Lisp machine).
Each CL implementor has extended the standard in a way they felt would
best serve their users. Some of these enhancements cause
unexpected behavior from a pure ANSI CL viewpoint. But there is
a good reason behind it.
Let me give you an example from ACL which may work in a similar
way in other Lisps with threading:
I start this process going that will print 0 as long as *print-base*
is 10.
(mp:process-run-function "foo"
#'(lambda () (loop (print (- *print-base* 10)) (sleep 15))))
Now in my listener I (setq *print-base* 16). What will the process
print? Well it turns out to keep printing 0.
Have we broken with the ANSI standard since setq no longer seems to
work?
I would say no. When we extended our CL to include threads we had
to decide how to keep existing ANSI programs from breaking if they were
running inside a thread (but had no idea that they were running
inside a thread since that's not in the ANSI spec). The answer
was to, by default, lambda bind a set of important CL special
variables (like *print-base*) at the start of each thread, so that
each thread was insulated to some extent from other threads.
Again it's the virtual machine idea -- you take a function that
knows nothing about threads and allow it to run unchanged
in a thread-based system.
So we have extended Common Lisp to support a Modern mode.
You don't have to use this extension just like you don't have to
use any other extension. We will always support an ANSI mode.
In doing so we are responsible for ensuring that existing ANSI
common lisp programs can be made to work in that mode.
case sensitivity is and always has been a very sensitive topic
for reasons I don't understand. Lots of people don't like
the loop macro but no one has ever suggested that we engineer Lisp
so that the loop macro can never run in it. However that
was not the case for case sensitivity.
So there will always be people who hate case sensitivity and see
no need for it. Those people can just build the ANSI image.
What I'd like to see is people who might find Modern mode interesting
give the Modern mode a try and give us feedback. We've had one
piece of feedback that readtable-case should be active.
I'd like to hear about experiences from others.
We've got a system that works but we're willing to change it
if that will increase the usefullness of it and if will
convince other implementors of Common Lisp to include
the Modern mode extension.
- john foderaro
modern mode cult leader
Erik Naggum
| There's no question that ACL can run in Modern mode with
| readtable-case and *print-case* active.
Then why do you destroy that functionality in "Modern" mode by
default? This is so irrational of you that I can no longer give you
the benefit of the doubt as to your motives.
| On thing that's missing from your code is how to deal with fasl
| files.
This may come as a shock to you, but symbol interning in fasl
loading has nothing whatsoever to do with readtables. I carefully
did _not_ change the values of the variables *current-case-mode* and
*current-case-mode-number* because those hold important information
for the fasl writer and reader, namely the preferred case of
symbols. I fully recognize that you need to know that.
If readtable-case is not a problem in :case-insensitive-upper, it
cannot possibly be a problem in :case-insensitive-lower, either.
I'm insulted by your implication that _I_ am carelessly breaking
your already broken code. There is nothing "missing" from my code,
John. Quit the goddamn FUD propaganda, will you? I think I know
your agenda, now: Destroy ANSI Common Lisp, by creating distrust in
your own implementation of it. This can _only_ backfire, John.
There are no references to *forced-readtable-case-raw* in the fasl
reader or writer, just for your information. You could have checked
that sooner than I could, and before you made your bogus "argument".
What the hell do you think you're going to accomplish with all this
nonsensical bullshit? What are you _trying_ to accomplish?
| If readtable-case is active then you have to somehow encode that in
| the fasl files and let the fasl reader know about the current
| setting so it will do the right thing before interning symbols.
This is so mind-bogglingly out of focus I can't imagine that you
actually believe this nonsense yourself.
The fasl reader needs to know whether the symbols are to be stored
in lower-case or upper-case. That has absofuckinglutely nothing to
do with the readtable-case! At least get your facts right before
your propaganda machine runs _completely_ amok, will you? Damn it,
I think you're working hard to obfuscate the issues so much it is no
longer possible to identify you as the culprit.
| As I've said my goal is to be able to load ANSI code into a Modern
| lisp and make it run with minimal porting effort and change to the
| code.
Then why do you destroy standard functionality? Why do you force
people to find *force-readtable-case-raw* and if they want standard
behavior? Why do you at all _believe_ that code written with the
tacit or explicit assumption that internal symbol case is upper-case
will work when the internal symbol case is lower-case? None of this
makes any _sense_, John.
| This will encourage people to use Modern mode (or maybe I should say
| that it will not discourage them from using Modern mode). The real
| test as to whether making readtable-case active in Modern mode is a
| good idea is whether it impacts the importing of ANSI code.
I hope people are soundly discouraged from using "Modern" mode.
Why do you have to engage in FUD propaganda against readtable-case?
If people are using readtable-case, your destruction of its defined
functionality would have impacted people severely, as it impacted me
severely. I still don't think you fully appreciate what this means.
I think you are still supermyopically focusing on your own needs and
basically saying "screw you" to everyone who does not share them.
By re-enabling readtable-case, people get what they specify that
they want. You had to destroy the functionality of readtable-case
because you wanted to lie about the internal case of symbol names.
It's that lying that you should be severely punished for, because
you are thereby doing the Common Lisp community a major disservice.
| I have no emotional attachment to the way things are currently done.
| It's just a program after all. There are procedures for effecting
| changes in programs.
I'm asking for an adjustment in your attitude towards the standard,
from utter disrespect and disregard to respect and appreciation that
it is a _baseline_, not something we take polls to see if you need
to implement or not. A faithful implementation of the standard
means that people don't have to test for compliance all the time,
which you force them into doing by signalling that Franz Inc only
implements tha parts of the standard that people ask for in polls.
I have been critical of Franz Inc's conformance track record for
years, but I thought we had made some progress over those years,
too. You're showing me that there has been no progress at all.
That is very, very disappointing and annoying, and I'm pissed as
hell with you for destroying the trust I thought I was building
towards you in particular and Franz Inc in general to actually
deliver what I want, a conforming ANSI Common Lisp implementation.
I _don't_ want "John Foderaro's special hacks Lisp du jour", and I
_don't_ want to have to drum up public support for features in the
standard that I would like to use before you implement them right.
Netiher do I want to test _everything_ to see if you have done the
basic features right. I want to _trust_ the baseline so it can in
fact work like a baseline.
However, as long as you think you are doing everything right and do
not listen to criticism, we shall have no reason to trust Franz Inc
even to _strive_ to produce a conforming Common Lisp implementation
and it is an _accident_ if it is, because you really want to be
making a different kind of Lisp. From all the assurances I have
received from other people at Franz Inc, I thought this period of
distrust was over, but you're doing a marvelous job of destroying
that trust, too, John. What's the next thing you don't like in the
standard that you're going to break for us, huh?
The main reason I still distrust CLISP is that its main author is a
snotty bastard who thinks he knows much better than me what I want
from a Common Lisp system, specifically that I _don't_ want a fully
conforming system. That's not only wrong, it means that I have no
idea what he has and has not implemented to that specification, what
he considers that he knows better and has done _differently_ just
for kicks, etc. as soon as I found out that he had a real agenda
against the standard, I stopped using CLISP completely. I don't
know the story on the newer CLISP, as I have a hard time re-trusting
people. Now, that was no big loss at the time, but dropping
Allegro CL because you are working hard to destroy three yaers'
worth of work to build trust in your conformance to the standard
would have a serious impact on my work at this time. I'd rather not
be forced into making that decision, but it is clear that we need to
work on taming your personal animosity towards the standard so you
do not cause random malfunction and disregard of defined smenatics,
or some sort of "elective implementation" because polling people
about feature X did not reach high enough numbers to cause you to
implement it correctly.
I'm not sure whether you take these things seriously at all, John,
but if you continue with your agenda against the standard, you will
cause serious problems for Franz Inc. Breaking readtable-case in
"Modern" mode was one of those staggeringly stupid moves that you
should have thought very carefully about before making. There's
time to undo the damage, but the more you insist, the more work it
will take to believe you won't destroy something else the next time.
John Foderaro
a keyboard capable of generating a strangely mixed case message like
that for many years. But you didn't to it until now, and you only
did it now to show that you could do it.
What can we learn from that?
One thing is that having the abilty to type mixed case at will
doesn't mean you will use it. People were (and some still are)
scared that putting case sensitivity into Common Lisp will
cause people to write identifiers like fOBArBAz. This was and is a
silly
argument and especially now that we have lots of experience in code
written
in C, C++, Java, Smalltalk to show that people, if they use
mixed case identiifers at all, use them in a very a controlled
manner.
Joe's messages demonstrates something that we're so used
to that we don't even notice it: that people use case in a
rational manner even though they aren't constrained to do
so (as kmp says: English isn't case sensitive).
O-V R:nen
> i tHiNk joE HaS a g00d poInt. wE nOW NEed AN eMax ComaNd:
> m-x ModeRniZe (reGioN / buFFer / WoRld).
isn't M-x stUdlIfY-RegioN enougH?
Richard Fateman
I wonder if any other programming language news group has
such bitter comments about case conversion.
The history of this matter goes back to the original
Common Lisp committee which included members from
MIT (including Kent Pitman), CMU, Stanford, ... and UC
Berkeley (including John Foderaro and myself).
As I recall, the persons coming from an MIT/CMU/Stanford
DEC pdp-10 (or is it PDP-10 :)
background had an almost universal emotional attachment
to upper case. Having (between 1968--1974) been at MIT myself,
and a one-time owner of a type33 teletype,
I can attest to the fact that there were many devices
(terminals, displays, printers) that were upper case only not
by choice, but because they did not have lower case
character sets available. In any case, making a virtue
of necessity, the CL standards crowd familiar with PDP-10 lisps
insisted on the case-insensitive upper case standard. The
upstart UNIX crowd (and perhaps Multics) argued
that case-sensitive was a good idea [but could not
get consensus, and so went along with the upper case crowd.]
I think the result is unfortunate, and to suggest that
I am not alone, I suggest that people look at
Guy Steele Jr's books on CL
in which both input and most output is in lower case.
This seems to be the convention followed by most other
authors as well.
Another example: A few years ago I wrote (in Allegro CL) a parser for
the Mathematica language, a language which is VeryCaseSensitive.
Converting it to ANSI CL is not too hard, but looking at
the program internal form when it is run in ANSI case-insensitive
mode is nasty. That is, instead of Sin[x+y] looking like
(Sin (Plus x y))
It looks like
(|Sin| (|Plus| |x| |y|)).
I dislike this, perhaps because ( and | and ) are visually close,
and that the use of | adds no information (to a human). The only
reason is that it is necessary to allow the expression to be
read back into a case-insensitive lisp. That is, a human is
forced to read something ugly for the convenience of the computer
system. This has got to be a violation of some nth law of
computer-human-interface criteria.
There are, of course, ways around this, but subverting the
read-eval-print loop unnecesarily is not my favorite
occupation. I try to write programs that I can hand to
students; I rarely want to teach them about read-table
hackery.
I have not studied this whole thread.
I cannot say whether ACL 6 is "just right". However,
I suspect this
"modern" lisp setting will serve me just fine and run
every program I've ever written, without change.
I also respect the rights of others to practice their own
religions including those which include ANSI CL as a
subset. I've also read Gulliver's Travels.
Regards
Richard Fateman
Tim Bradshaw
> Then why do you destroy standard functionality? Why do you force
> people to find *force-readtable-case-raw* and if they want standard
> behavior? Why do you at all _believe_ that code written with the
> tacit or explicit assumption that internal symbol case is upper-case
> will work when the internal symbol case is lower-case? None of this
> makes any _sense_, John.
I think you've just explained something that's been sitting at the
back of my mind for a long time concering the whole case stuff.
People who don't think very hard often end up writing code that looks
like this:
(intern (format nil "~A-WIDGET" name))
If name is a symbol this isn't going to work because of *print-case*,
and sure enough I've found several different bits of code in at least
two systems which break if you work with *print-case* :downcase for
this reason. So I end up fixing this by saying something like:
(intern (format nil "~A-WIDGET" (symbol-name name)))
But this breaks gloriously in a `modern' mode lisp (or rather, it
works, but it violently breaks assumptions about accessor names). So
you end up with something like this, I think:
(intern (format nil "~A-~A" (symbol-name '#:widget) (symbol-name name)))
Which I think (please bear with me if I've still got it wrong) works
in both ANSI CL and `modern' mode. Well, actually I'm not sure what
happens if the case mode changes between when a file is compiled and
when it is loaded, but that's kind of an implementation issue.
Now the point is that people *do write this kind of code*: generating
symbol names from other symbol names is something that you do in
macros all the time. Many people -- including experienced Lisp people
-- write code that looks like my first example. People who like to
see output in lower case eventually convert this to code that looks
like the second example. Almost no-one probably writes stuff that
looks like the third example.
So as Erik says, it really isn't the case that code written with the
traditional assumptions will work in a `modern' lisp -- quite a lot of
it won't even work with *print-case :downcase!
--tim
Joe Marshall
> Your message demonstrates a very important point. You've had
> a keyboard capable of generating a strangely mixed case message like
> that for many years. But you didn't to it until now, and you only
> did it now to show that you could do it.
I don't understand why this is an important point. In fact, I don't
understand how this relates to my keyboard at all.
> What can we learn from that?
Even the most obscure emacs functions occasionally have pedagogic uses.
> One thing is that having the abilty to type mixed case at will
> doesn't mean you will use it.
Well, I am all for functionality that won't be used!
> People were (and some still are) scared that putting case
> sensitivity into Common Lisp will cause people to write identifiers
> like fOBArBAz. This was and is a silly argument and especially now
> that we have lots of experience in code written in C, C++, Java,
> Smalltalk to show that people, if they use mixed case identiifers at
> all, use them in a very a controlled manner.
Actually I'm afraid that they will write identifiers like FooBarBaz
and fooBarBaz, and FOOBARBAZ, and foobarbaz, all in the same code, and
all meaning subtly different things.
So do I write HashTable or Hashtable or hashTable? Is the P
capitalized? Or perhaps only when it would have been -p?
> Joe's messages demonstrates something that we're so used
> to that we don't even notice it: that people use case in a
> rational manner even though they aren't constrained to do
> so (as kmp says: English isn't case sensitive).
It also demonstrated that putting upper case letters in the middle of
words makes them hard to read. It also demonstrated that words with
different case have the same human meaning regardless of whether the
machine thinks so or not (so let's fix the human?)
John Foderaro
integrity.com says...
> Actually I'm afraid that they will write identifiers like FooBarBaz
> and fooBarBaz, and FOOBARBAZ, and foobarbaz, all in the same code, and
> all meaning subtly different things.
>
Why are you concerned how I write my code for my project that you will
never see? If you are concerned about how code is written for your
project then you should have a team meeting to establish coding
standards.
Go out and find a C, C++ or Java programmer. It's not hard. Ask them if
this is one of their fears. When they say no, ask them why not. Ask
them how mixed case makes their life easier and their code easier to
read.
> So do I write HashTable or Hashtable or hashTable? Is the P
> capitalized? Or perhaps only when it would have been -p?
>
It's your code, you decide. Freedom's a cool thing.
> It also demonstrated that putting upper case letters in the middle of
> words makes them hard to read.
Let me demonstrate the opposite and then we'll agree that mixed case can
be used for good or for evil, it's the choice of the author:
three identifiers:
MYDOGSPOT mydogspot myDogSpot
which is easier to read? did you read the first one as "my dogs pot"
or "my dog spot"?
Tim Bradshaw
> Why are you concerned how I write my code for my project that you will
> never see? If you are concerned about how code is written for your
> project then you should have a team meeting to establish coding
> standards.
I obviously couldn't care less about code that I will never see. But
people do write libraries,, and I've spent enough time trying to
follow the insane capitalization conventions in things like the C X11
libraries to be deeply frightened of what might happen. And I suppose
I could have asked for team meetings with Sun & Microsoft to decide
their conventions for Java and Win32, but I fear they would not listen
to me.
>
> Go out and find a C, C++ or Java programmer. It's not hard. Ask them if
> this is one of their fears. When they say no, ask them why not. Ask
> them how mixed case makes their life easier and their code easier to
> read.
While you're at it, ask the C/C++ ones why GC makes their code slow
and why lisp is impossible to read. If you want to know whether it
makes their life easier and their code easier to read you need to
actually measure things, not just ask people what they think: people
think all sorts of wrong stuff.
> MYDOGSPOT mydogspot myDogSpot
>
> which is easier to read? did you read the first one as "my dogs pot"
> or "my dog spot"?
Why did you leave out the obvious my-dog-spot?
--tim
John Foderaro
> I obviously couldn't care less about code that I will never see. But
> people do write libraries,, and I've spent enough time trying to
> follow the insane capitalization conventions in things like the C X11
> libraries to be deeply frightened of what might happen.
Are you more frighted about mixed case indentifiers or people writing
API's using natural langauges that you don't understand? They can do
that today and to me that's a far harder to get past.
The reason that you don't have to worry about either is that there is a
pressure put on authors to create interfaces that satisfy the most
people. Thus API's are written in English and they follow Common Lisp
hypen conventions. Sure someone could write an interface in any
language and using bizarre conventions, but it would receive little
use. It's like natural selection.
> And I suppose
> I could have asked for team meetings with Sun & Microsoft to decide
> their conventions for Java and Win32, but I fear they would not listen
> to me.
>
Why should they? You'll agree I'm sure that reasonable people can
disagree and that while you don't like MixedCaseIdentifiers there are
people who do.
Your choice is to either to use or not use their product. Vote with
your feet as they say.
We have to remind ourselves that our opinions are just that, opinions
and there are people that feel differently.
I hate the extended loop macro with a passion and I hate to read code
that uses it, but I will fight to the end to ensure that people who want
to use the loop macros in Common Lisp can use it. A language designer
must be unselfish.
>
> Why did you leave out the obvious my-dog-spot?
>
since the question just involved whether a word with capital letters in
the middle was less readable than one without.
Thomas A. Russ
> Joe's messages demonstrates something that we're so used
> to that we don't even notice it: that people use case in a
> rational manner even though they aren't constrained to do
> so (as kmp says: English isn't case sensitive).
Right. English isn't case sensitive. Unfortunately, most computer
languages (including Common Lisp) is case sensitive.
It just turns out that Common Lisp normally makes it sufficiently
difficult to use mixed case that one typically doesn't run into any
problems. Unfortunately, it is too late to have advocate a case
insensitive lisp without breaking a lot of existing code.
Now I prefer to have my legacy code continue to work when new releases
of my programming language come out, thank you very much.
--
Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
Kent M Pitman
> I wonder if any other programming language news group has
> such bitter comments about case conversion.
Well, I'd bet few, if only because few other languages have a rational
alternative ... since most don't allow hyphens as constituent characters.
Certainly, there were many compatibility reasons for uppercase being
canonical in the beginning, but that doesn't mean that uppercase is
"old fashioned".
All uppercase has been "grammatically acceptable" for a long time on
billboards and book titles and medicine directions in situations
where all lowercase is not "grammatically acceptable". Even if
compatibility was a factor, it doesn't mean that growing beyond that
compatibility need makes uppercase completely dumb.
I hate to attack you and your profession in a way that may appear to
personally single you out, but I have to say I really think you are
"bad data" in your desire to accomodate the VeryCaseSensitive in
things like Mathematica. Mathemeticians in particular have typically
used every element of typography (from font family to font weight to
font style to case to accent marks) to carry meaningful information,
but there is little evidence that there is a general desire on the
part of the population to move in this kind of featurized overload
because of the numerous namespaces they are constantly working with
combined with a passion for the concise. I do think the human mind
tolerates some overload, but I think there is an upper limit at which
point it becomes quickly ludicrous to the general population.
Once, a long time ago, I told you about my Fortran->Lisp translator at
a conference and you told me it was too slow since it didn't do native
targeting; it ran emulated. I said "That's ok, I have users who are
happy with the speed." Your reply, which made me sad, was "then
you're talking to the wrong people". This remark bothered me, but I take
its deeper meaning to say "depending on your goal, some markets are worth
ignoring, and once in a while one has to think hard about which possible
universe they are selecting by their choice of which market to care
about".
I suppose one way I could now go is to observe that you are obviously
characteristic of those Franz wants to talk to, and to say "they're talking
to the wrong people". Maybe that's indeed what I'm saying, but I'll try
not to put it into such dismissive terms, since my goal is not to see you
ignored as rather to see other goals of my own not be ignored, and since
there's a difficulty in seeing both goals met--though I think there are
common grounds that have been overlooked by Franz in its zeal to just
decide to act unilaterally rather than to engage others in a serious
community discussion. They appear to think that by simply acting, they
will solve the problem. And that's their right. But in so doing they
alienate some, myself among them.
I do believe it's probably an objective fact that the community is split
into smaller communities, some of whom will revel in case distinction,
some who will tolerate it, and some who will abhor it. The problem isn't
establishing the presence of these groups, it's measuring their size and
assessing the importance of each both today and for the future.
You seem to fall into the camp that revels in the use of case, and it's
merely my intuition that this is a small set. I fall into the constituency
that abhors the use of case for such things, and I imagine my set to be
larger, though I admit many in my camp are not articulate about what they
like and don't. I suspect they would mostly say "that's nerdy" or "that's
hard to remember" or "that's anal" when confronted with style rules such
as you suggest, because they would have trouble understanding it as a
choice a designer made that could have been made differently, and because
they have trouble pointing to dependent decisions that followed from having
made that decision in a relatively independent way.
To me, when this situation comes up, the important data I always point
to is that when people do memory errors, they tend to misremember
things in a way that suggests memory is stored in "auditory" rather
than "visual" form. People misremember things selecting others that
"sound the same", not "look the same". And since speech generally
does not carry case information, I conclude that while people probably
don't have an obvious mental preference for upper or lower case, they
probably do have an obvious mental preference for not having terms
that conflict only in case, unless the case is also implied
redundantly by some contextual setting and the case information is
purely "a reminder" and not "the deciding factor". I want a language
that people can "talk about" out loud and can "remember", and I think
that favors making case be at most "retained". I could perhaps live
with a Lisp in which case folding was to the first use, as the Mac and
Windows NT file system do for filenames. But that's the limit of how
far I could go. When it affects my typein, and I have to remember not
only the spelling but also the pattern of casification, the burden on
me and my limited cognitive abilities is too great.
> Another example: A few years ago I wrote (in Allegro CL) a parser for
> the Mathematica language, a language which is VeryCaseSensitive.
> Converting it to ANSI CL is not too hard, but looking at
> the program internal form when it is run in ANSI case-insensitive
> mode is nasty. That is, instead of Sin[x+y] looking like
>
> (Sin (Plus x y))
>
> It looks like
>
> (|Sin| (|Plus| |x| |y|)).
>
My problem is not with working with you and others to come up with a
compromise to allow you to write (Sin (Plus x y)) and even to see this
printback from the printer. My problem is with the orthogonal claim
that this requires changing the internal case, which I don't think it
does, and also with the implicit claim that it's ok to have unrelated
functions sin and plus or SIN and PLUS which are distinct. At the point
where I have to notate case in spoken speech to talk about what you've
done, again you've made it too hard. I want to be able to write
(sin (plus x y)) if I choose and have that mean the same thing, provided
I have chosen the same "namespace/package" as you have.
However, in the end, this isn't about case. This is about the hard-fought
compromises that have been made that tied together a bunch of opposing
vendors with some sense of acceptance of the importance of "community"
that extends beyond a vendor. What upsets me more than the case issue
here is that Franz is unilaterally asserting that a product which advertises
ANSI compliance will not first show itself as ANSI compliant, thus
causing the newest and most confused users to become confused and to post
more confused remarks on forums like comp.lang.lisp, creating a burden
on us all to explain why Franz did what we would not have had them do.
There are any of myriad ways that implementations differ and my answer
is: bring your implementation inline for the good of the community.
I don't plan to make an exception here just because Franz thinks it's
so big in the market that it doesn't have to care, or because it thinks
people will prefer their implementation to the standard. I'm not here
to advocate the purchase of any Franz product--I'm here to promote Lisp
generally. To the extent that Franz buys into the community story, I'm happy
to do them a favor and point traffic their way. But to the extent
they elect themselves guardians of "how lisp should look", I'm happy to
let them stand alone on that without my help.
Mind you, I don't care if the venue of record is ANSI or something
else. Of late, I'm tired of ANSI (which I view as slow and clumsy)
and likely to seek another venue to which I may contribute any future
work I do on standards. I don't mean to be saying "ANSI or nothing"
here. But ANSI was the chosen vehicle of the vendors and the users
back in 1986, and what we have now is what resulted from that. It's
pretty darned fixed for now, and maybe it does need some change, but
toward that end maybe another process would serve us better. I hope so.
But I won't settle for a single-vendor approach because I want
community buy-in of some sort, whether it's IEEE or IETF or ALU or
whatever. Having one vendor issuing the rules (consider Java or Dylan
or C# as examples) means there really is no "community buyin". Once
successfully underway in the community, as with Java or Dylan, a
vendor neutral forum should control things. I think that might have
rescued Dylan at a critical moment when it threw away lispy syntax,
and it might have offered a hope of rescuing Java from some of the
dumber elements of its design. I wish C# were poised to do better,
but I doubt it will.
I want the community of people who would port programs and
who would switch vendors to decide. Because it benefits end-user
programmers enormously to be able to tell a vendor that they don't
like something and will shop for another implementation if it's not
fixed. I will not promote single-vendor solutions because this locks
people into the whims of a vendor, and that is fundamentally not
healthy for the end user. The market is what makes things better.
Franz is playing the market. I can't blame them for that. But I don't
have to buy what they're selling; that's the flip side of the coin.
And they shouldn't blame me for that either.
Tim Bradshaw
> I wonder if any other programming language news group has
> such bitter comments about case conversion.
Probably not. However I think this kind of stuff matters more in
Lisp, because Lisp is all about being able to read and manipulate its
own source Very few other languages expose READ, and so the fact that
(the equivalent of) READTABLE-CASE may no longer reflect reality in
(the equivalent of) Allegro would not matter to users of those
languages. Similarly users of other languages do not often spend time
constructing symbols from other symbols, and so their code won't break.
I'm just glad we can fight about this rather than pointer aliasing, or
whatever it is the C newsgroups are fighting about this week: at least
we've made it up a few levels.
--tim
Lieven Marchand
> Lieven Marchand <m...@bewoner.dma.be> writes:
> > And if the author only uses one implementation (yours) and isn't
> > aware of the non standard behaviour? If he ever has to port his code
> > to another implementation he isn't going to thank you. This
> > behaviour of encouraging people to write to your own "standard"
> > reeks of Microsoft.
>
> .. Or of Oracle, or of IBM, or others, depending on the moment...
>
One of the things I appreciate enormously in the excellent Informix
manuals is that they clearly label syntax and functions as belonging
to the diverse SQL standards or as their own extension. The man pages
on most Unix systems also have a CONFORMING TO section naming the
standards that support that function.
I have no problem choosing to use vendor extensions. I just don't
think people should be ambushed or dragged into them.
--
Lieven Marchand <m...@bewoner.dma.be>
Lambda calculus - Call us a mad club
Lieven Marchand
> In article <m3wveh2...@localhost.localdomain>, m...@bewoner.dma.be
> says...
> > And if the author only uses one implementation (yours) and isn't aware
> > of the non standard behaviour? If he ever has to port his code to
> > another implementation he isn't going to thank you. This behaviour of
> > encouraging people to write to your own "standard" reeks of Microsoft.
> >
>
> Are you suggesting that we remove everything from our Lisp that isn't
> part of the ANSI standard? That would include the lisp threading
> facility, the foreign function interface, the socket interface and much
> more. We could do that and sure enough you would have a lisp in which
> everything you wrote would work on other ANSI Common Lisps.
> Is that the lisp you would want to use?
> I doubt it, unless you're teaching a very first class in Lisp.
>
You can stop attacking that strawman. Nothing I said implied that. If
I use things like excl:foo or lw:bar, I know I am using
extensions. What I do expect is that for code in a package using only
the COMMON-LISP package I can use the ANSI standard document to reason
about its behaviour. The image you ship as standard breaks this IMHO
reasonable expectation.
> Yes this causes a problem when porting from one implemenation to the
> other but people accept that problem.
>
People accept it because they are aware of it. Your stealth approach
to MoDeRn mode will lead to surprising behaviour for people not aware
of both your extension and the whole CL read-table apparatus. I had
been programming for quite a while in CL before I found it necessary
to study read-tables and the exact way in which ANSI CL is case
sensitive.
> > Interesting choice of words: drag. Does this imply they don't want to
> > go there from their own free will?
>
> Ever since the Common Lisp definition started to gel evolution in the
> Lisp language has slowed. Lisp used to be a springboard for
> experimenting with language ideas, then change became a dirty word.
> So yes, we have to get Lisp jumpstarted again.
>
This is another strawman. Nobody here has argued against the concept
of change, only against this particular way of changing. I've looked
at your hierarchical package stuff, which I find an interesting idea,
and at your specification for Gray streams the Next
Generation. Putting the specification up for public comment and
independent implementation is a very good way of adding to CL.
> > Although I like case insensitivity,
> > and find very little value in your |field| vs. |Field| example from a
> > software engineering aproach,
>
> If you look at object oriented case sensitive languages you'll generally
> find this is the convention they use (Smalltalk, C++, Java).
>
And Ada most emphatically does not and if I recall the rationale
correctly, they rejected it on a conscious design decision. But we can
quote languages at each other for a long time, and as I said, I'm
happy to give people the choice.
>
> > I have nothing against a case sensitive
> > CL with lower case symbols, but breaking old code without reason in
> > the process is not the way to go.
>
> That's the key point I've been making. Old code continues to work either
> in ANSI mode or in Modern mode. That's my #1 goal for without it we
> require everyone to choose one or the other and people will just stick
> with the old ANSI version.
Judging from the response here, you aren't making many
followers. After having evaluated both Allegro and Lispworks, I
decided to buy Lispworks, so you may ignore me, but as a paying
customer of Xanalys, I would urge them not to take your advice on
implementing Modern mode.
John Foderaro
>
> Unfortunately, it is too late to have advocate a case
> insensitive lisp without breaking a lot of existing code.
It's been my experience that because legacy code doesn't really have
case dependencies except in a few easy to identify places (defpackage
forms, and creating symbol names to intern), it is always possible to
convert legacy code so that it works in either Modern or ANSI mode.
If you know of code that you think can't be converted in this way please
let me know.
>
> Now I prefer to have my legacy code continue to work when new releases
> of my programming language come out, thank you very much.
>
.. and we are determined that you will always have that option.
Kent M Pitman
> Are you more frighted about mixed case indentifiers or people writing
> API's using natural langauges that you don't understand?
I don't have as a goal for them to write API's in languages that I
don't understand. The point of an API is interchange. I want it
written in the worldwide interchange langauge of choice. That happens
to be English, for which I am quite embarrassed and apologetic,
because it makes me feel like I or some of my cohorts rolled over
others to make it happen, and in some ways I suppose we did. But it
wasn't my choice personally and the deed is done. You get it changed
to some other language and I'll learn that language and use it without
complaint. But I've tried in good faith to work with friends in
multilingual environments, offering APIs in multiple languages, and
it's quickly obvious to any involved that (a) it isn't reasonable to
have to have a function name for every function in every single
natural language because it's too many function names and (b) it isn't
reasonable to have everyone have to learn the language and dialect
[e.g., "color" vs "colour" in American/British dialectal variation] of
every other participant and (c) the only reasonable way out of the
tower of babel is a canonical interchange language.
To the extent that someone wants to program privately in a particular
language, I don't see why you have to lie to them and tell them the case
of the built-in functions is other than what it is. Were I you, I
would just make a shadow package called "cl-user" (since package names
are case-sensitive anyway) and I'd start defining
(defun car (x) (CAR x))
(defun cdr (x) (CDR x))
(defun cons (x y) (CONS x y))
...
and I'd either implement value cell sharing or tell them a few option
variables are in all uppercase. I'd make cl-user:nil have a value of
CL-USER:NIL and so you'd have to use () or nil but not 'nil. I'd then
just turn on the readtable case stuff in the packages where I did my
internal programming, and I'd export stuff in the standard way that
exports are understood to be done in CL--in all uppercase. There's even
some benefit of that because the case-sensitive people could see that as
a double-check that a thing was meant as an export.
None of this requires deviation from the standard.
The decision to deviate from the standard creates a "work in this universe"
or "work in that one" because code does not cross-load between the two
unless written to ferociously detailed specs of a particular vendor, and I
see no reason to hold everyone in the community hostage to style rules of
another vendor. I often feel I'm going over the deep end to ask people
to start files with a file attribute list like the first line in:
;;; -*- Mode: LISP; Syntax: ANSI-Common-Lisp; Package: CL-USER -*-
(in-package "CL-USER")
for the sake of the Lisp Machine. I think even that's a lot to ask of people.
And what you're asking is way more invasive than that.
> The reason that you don't have to worry about either is that there is a
> pressure put on authors to create interfaces that satisfy the most
> people. Thus API's are written in English and they follow Common Lisp
> hypen conventions. Sure someone could write an interface in any
> language and using bizarre conventions, but it would receive little
> use. It's like natural selection.
Yep.
> ... You'll agree I'm sure that reasonable people can
> disagree and that while you don't like MixedCaseIdentifiers there are
> people who do.
>
> Your choice is to either to use or not use their product. Vote with
> your feet as they say.
No, this isn't so. There are myriad other solutions that you have not
mentioned in this discussion. For example, you very briefly alluded to
a default conversion which had bugs, and then dismissed the conversion
solution rather than just fix the bugs. You talked about a name like
FrobIOSystem
and the idea of using FROB-I-O-SYSTEM as being ugly. But you didn't talk
about something like
(defpackage "IO-SYSTEM"
(:unpack-capital-names t)
(:preferred-capital-name-expansions ("IO" "I/O")))
so that it could turn into
FROB-I/O-SYSTEM
which I would like really a lot better, and which could still be done with
a minimum of ease. Ditto with ParseXMLFile going to PARSE-XML-FILE by a
similar trick. And I find that a lot less problemsome than some of the
other things we've discussed.
Another possible solution you didn't mention is the Windows NT / Windows 98 /
MacOS solution of retaining case on first use, so you'd load a package
definition with a :remember-case-for-prin1 option turned on
and then just remember the first referenced casification on a plist
so that (prin1 'xml-file) would print as xml-file or XML-FILE or XML-file or
XML-File or Xml-File or xml-File according to what the owner had first used,
and yet any casification would be ok. This would also work for
FrobXMLFile
even though symbol-name of this symbol might return "FROBXMLFILE". It takes
a little more memory, but not an appreciably huge amount, and would be
100% compatible. We could just make a SYMBOL-PREFERRED-NAME that accessed
either this property or, if not present, the symbol name, and then both
old and new programs could find "FrobXMLFile" when they cared to use that
name.
But again, you didn't try that either. Because you didn't take it to the
community first. You just acted and did not involve us, implicitly asserting
that we had no ideas to offer and were not sensitive to your needs.
> We have to remind ourselves that our opinions are just that, opinions
> and there are people that feel differently.
But decisions foisted upon us by vendors are not just opinions. They are
things we all have to live with, like it or not. And the thing is, we had
lots of meetings for lots of years to talk about what we could and could
not live with, and this was a settled deal. Only Franz thinks it is not
settled, and only Franz seems to be willing to work away from rather than
toward a normative standard in terms of what customers see first off.
That's a decision you can make, but don't expect the troops of other
companies or the affected users of your product who don't like it to just
line up and say "well, it's just their opinion". It's not.
> I hate the extended loop macro with a passion and I hate to read code
> that uses it, but I will fight to the end to ensure that people who want
> to use the loop macros in Common Lisp can use it.
Different beast. From outside you cannot tell it's been used.
> A language designer must be unselfish.
Uh, just so you know, I don't think vendors are not language designers.
They implement things that language designers decide.
I *do* think language designers are and should be selfish. You and I, at
a meeting of vendors, should make our selfish cases and vote our selfish
desires, making compromises as we can afford to, but in the end I think
we're allowed to be selfish. But the outcome of the vote is the rule and
I guess I think it's implicit in the decision of each vendor to be involved
in the standard that they will try to abide by the outcome to the best they
can. If they don't, they shouldn't call their product ANSI compliant.
I also personally think it is an unfair marketing ruse to say that
your product is "ansi compliant" and then when you get it to tell someone
they have to reconfigure it to make it so. It's one thing if the installer
asks "install in ansi-compliant mode?" but quite another if the product
just installs and then doesn't work as advertised and you have to know to
reconfigure it. I am similarly dismayed when I get something that's supposed
to work on windows or linux x windows but comes configured for dos or linux
tty mode and I have to recompile it to get it into the right mode. Too much
work, too much opportunity for error on my part. I'd rather have bought
someone else's product and I'm angry that anyone told me just to make a buck
that what they were giving me is what it isn't.
> > Why did you leave out the obvious my-dog-spot?
>
> since the question just involved whether a word with capital letters in
> the middle was less readable than one without.
(You left out "MyDogSpot", btw.)
But my real problem with the the question was it didn't reasonably
address the issue at all, since it didn't match any actual real-world
dilemma. You just seemed to assert that there were four names and
that it should be obvious from this that there was problem. But you
should instead have shown real worked scenarios of who was doing what
and where the interface points were and asked for solutions that were
favorable for all concerned. I think such compromise solutions do
exist, and they are not what you have done, which is to pretty much
unconditionally thrust an alternate universe on some users in a way
that to adopt that will lock them out of other libraries that other
people are making.
Barry Margolin
> 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.
Not all criminals are bad. If you're going to make analogies with criminal
laws, then perhaps what Franz is doing could be considered analogous to
civil disobedience.
--
Barry Margolin, bar...@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Joe Marshall
> In article <itpz1v...@content-integrity.com>, jrm@content-
> integrity.com says...
> > Actually I'm afraid that they will write identifiers like FooBarBaz
> > and fooBarBaz, and FOOBARBAZ, and foobarbaz, all in the same code, and
> > all meaning subtly different things.
> >
>
> Why are you concerned how I write my code for my project that you will
> never see?
Actually, I find myself frequently examining code that you wrote.
> If you are concerned about how code is written for your
> project then you should have a team meeting to establish coding
> standards.
Good idea. (Hey everyone, let's use the ANSI coding standards that
we've been using for the past decade and a half! All in favor? Aye.
Motion passes.) Whew. I thought that'd be harder.
> Go out and find a C, C++ or Java programmer. It's not hard. Ask
> them if this is one of their fears. When they say no, ask them why
> not. Ask them how mixed case makes their life easier and their code
> easier to read.
Why would I care what a C++ programmer thinks? The ones that *like*
to code in C++ are hopelessly wedged. I can easily find ones that
agree with me, too.
> > It also demonstrated that putting upper case letters in the middle of
> > words makes them hard to read.
>
> Let me demonstrate the opposite and then we'll agree that mixed case can
> be used for good or for evil, it's the choice of the author:
>
> three identifiers:
>
> MYDOGSPOT mydogspot myDogSpot
>
> which is easier to read? did you read the first one as "my dogs pot"
> or "my dog spot"?
Sure, the last is a tad easier to read. A tad harder to type,
though. None of these is as easy to read as my-dog-spot or even
my_dog_spot. The thing I object to is finding out that
(eq 'mydogspot 'myDogSpot) => NIL
Kevin Layer
wrote:
>I also personally think it is an unfair marketing ruse to say that
>your product is "ansi compliant" and then when you get it to tell someone
>they have to reconfigure it to make it so. It's one thing if the installer
>asks "install in ansi-compliant mode?" but quite another if the product
>just installs and then doesn't work as advertised and you have to know to
>reconfigure it. I am similarly dismayed when I get something that's supposed
>to work on windows or linux x windows but comes configured for dos or linux
>tty mode and I have to recompile it to get it into the right mode. Too much
>work, too much opportunity for error on my part. I'd rather have bought
>someone else's product and I'm angry that anyone told me just to make a buck
>that what they were giving me is what it isn't.
I have trouble believing we have perpetrated a "ruse" because we
require someone considered to be a programmer to wait a few seconds
for the following form
(progn
(build-lisp-image "alisp.dxl" :case-mode :case-insensitive-upper
:include-ide nil :restart-app-function nil)
(sys:copy-file "sys:mlisp" "sys:alisp"))
to complete and to produce a case insensitive upper image.
Not to mention that this is in a **free** product. One that we
provide to the community at great effort and expense.
Kevin Layer
Franz Inc.
Kent M Pitman
> Not all criminals are bad. If you're going to make analogies with criminal
> laws, then perhaps what Franz is doing could be considered analogous to
> civil disobedience.
Perhaps an apt analogy. But, importantly, not all civil disobedience is
good, either. I've often seen people who do civil disobedience get
miffed that they got arrested, but the proper role of civil disobedience
is to say that you feel strongly enough about something that you're
willing to endure the ire and civil penalties and whatever else may
come. Respect for you is not always immediate, and sometimes never
comes, but if it comes it comes from the community's gradual respect for
your enduring what it throws at you. Respect does NOT arise from your
demanding to be treated as if all you had done was legal and
unconditionally societally appropriate. Civil disobedience is about being
brave, knowing you will not have the upper hand. There is nothing brave
in doing something for which you are merely entitled to be respected.
Kevin Layer
<j...@content-integrity.com> wrote:
>The thing I object to is finding out that
>(eq 'mydogspot 'myDogSpot) => NIL
Joe, then you should invest an amount of time must less than that
already spent on your postings to comp.lang.lisp to build yourself a
case insensitive upper image. It is that simple to get your
satisfaction.
Kevin Layer
Franz Inc.
Kent M Pitman
> ... Not to mention that this is in a **free** product. One that we
> provide to the community at great effort and expense.
But it either is or is not presented as an ANSI CL offering. If it is,
it should be configured that way. If it is not, then it's nice that you
offered a free "whatever-it-is" but don't expect me to tell anyone they
should be using it any more than I'd tell them to use free offerings of
emacs-lisp, scheme, cltl1, or cltl2. The community we're discussing here
no this newsgroup has, to my satisfaction, elected ANSI CL as its unifying
definition and I'm happy about that because it keeps us from having platform
and vendor wars. We can all cooperate usefully without regard to the myriad
different vendors that are involved, and that's a BIG WIN.
If you're not working from the spec of apparent consensus, you don't need
our approval, but then I question your use of this venue, which is about
discussing the consensus dialect (once that was cltl1, then cltl2, and now
ansi-cl; i've seen no movement to have it be ansi-cl-as-perturbed-by-franz).
Saying it's "free" doesn't fix a non-compliance for you any more than it
has excused CLISP or GNU CL or any of the others that we've beaten up on
other occasions. We've beaten up those implementations on other occasions,
but the price of that if we want to be fair is to take our lumps when we
find ourselves in the other position, especially voluntarily, as has happened
now to you.
Any implementation has bugs, which is why we don't talk about "conformance"
in many places in the spec, but rather "purporting to conform". What it
means to "purport to conform" is effectively that you are
prepared to receive reports of nonconformance and fix them; that if you
don't conform, it's an accident or a limitation of resources, not a willful
decision. If you're willfully non-compliant, you're not purporting to
conform. Is :ANSI-CL or any other ANSI-related feature on the features
list for your Modern implementation? I hope not.
I can't tell you how it pains me to have to take these position. I
really like you guys at Franz on a personal level. I have the greatest
respect for the technical merits of your product. I don't like being
put in a position of having to appear snippy with people I like. But I
feel you have acted in a way that should have expected this kind of
reaction and should not be surprised by the result.
Tim Bradshaw
> Why should they? You'll agree I'm sure that reasonable people can
> people who do.
Yes I agree with this.
> Your choice is to either to use or not use their product. Vote with
> your feet as they say.
So I should write my own X11 library, or my own web server or
whatever. Hmm.
The issue is that it is *not* the case that the code someone who uses
a particular style writes will not affect others. It will, because
sooner or later they will write something to which others have to
interface. Established conventions might save you from this for a
while, but they will change: *C* had an established convention of all
lowercase function names, once.
Whether that change is good, bad, or neither is not the point, the
point is that it is just silly to assume that I have a choice not to
be affected by it.
>>
>> Why did you leave out the obvious my-dog-spot?
>>
> since the question just involved whether a word with capital letters in
> the middle was less readable than one without.
An argument from a single, carefully-chosen example proves absolutely
nothing. Surely you know that?
I don't think there's any point in continuing this thread so I'll not
followup further.
--tim
Tim Bradshaw
> You can stop attacking that strawman. Nothing I said implied that. If
> I use things like excl:foo or lw:bar, I know I am using
> extensions. What I do expect is that for code in a package using only
> the COMMON-LISP package I can use the ANSI standard document to reason
> about its behaviour. The image you ship as standard breaks this IMHO
> reasonable expectation.
I'm not sure this is right. I believe that in the *paid for*
distribution there is a conforming image or two, as well as several
others. Whether that is `default' or not I'm not sure -- I'm not sure
if Franz actually provide a program called `lisp', they may provide
various variants.
What the free version does I'm not sure.
--tim