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
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182371042747250@naggum.net>
* Marco Antoniotti <·······@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.
| 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
You've described your position well so let me briefly outline
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.
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182446271277745@naggum.net>
* John Foderaro <···@unspamx.franz.com>
| 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
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
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
franz inc
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182464267622666@naggum.net>
* John Foderaro <···@unspamx.franz.com>
| 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
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
From: Barry Margolin
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <o6%N5.28$lh.381@burlma1-snr2>
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> 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, ······@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.
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfwr94nh0rd.fsf@world.std.com>
Barry Margolin <······@genuity.net> writes:
> 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.
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182468289670750@naggum.net>
* John Foderaro <···@unspamx.franz.com>
| 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.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
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.
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182576265131590@naggum.net>
* John Foderaro <···@unspamx.franz.com>
| 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.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <nkj66lzmym5.fsf@tfeb.org>
Erik Naggum <····@naggum.net> writes:
> 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
Tim Bradshaw <···@tfeb.org> writes:
> People who don't think very hard often end up writing code that looks
> like this:
>
> (intern (format nil "~A-WIDGET" name))
....
>
> 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.
Indeed. I took some time before I understood the need to wrap the
FORMAT with a WITH-STANDARD-IO-SYNTAX form, like I saw someone on this
group (Erik?) do in his examples.
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey366m29gic.fsf@cley.com>
* Erik Naggum wrote:
> *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
In article <···············@cley.com>, ···@cley.com says...
> 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.
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey3hf5k87tp.fsf@cley.com>
* John Foderaro wrote:
> In article <···············@cley.com>, ···@cley.com says...
>> 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.
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
As appalling as you may find it, we can say that it works.
We develop in Modern mode, we compile in Modern mode
and you use resulting code in ANSI or Modern mode.
We aren't trying to support both modes at once inside
a single lisp. Let's face it, you know which mode you
want to develop in. It's so easy to write code that
works in both modes that you can straddle the fence
for a long time.
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <nkjg0l2py8h.fsf@tfeb.org>
John Foderaro <···@unspamx.franz.com> writes:
> As appalling as you may find it, we can say that it works.
> We develop in Modern mode, we compile in Modern mode
> and you use resulting code in ANSI or Modern mode.
>
You don't seem to be reading what I wrote. What I want to be able to
do is, from a running program (written in whatever mode, I am *not*
talking about writing code here), read (with READ) some data with
control over the case conversion. And I want to do that *without*
globally toggling some switch, because while I'm reading it I really
don't want to have to block out all other processes and cause my
application to stop responding to events for some long period.
Can I do that?
--tim
Tim Bradshaw <···@tfeb.org> writes:
> control over the case conversion. And I want to do that *without*
> globally toggling some switch, because while I'm reading it I really
> don't want to have to block out all other processes and cause my
> application to stop responding to events for some long period.
>
> Can I do that?
hear, hear!
I am using read to read in s-expressions which are supposed to be
case-insensitive (and I'm not sure if I want to break that, it's
not a matter only of changing complicated code but also an enormous
amount of programs which create input to that code), and I want
to combine that code (which happens to have a few of the dirty interns
of (format nil "..~a...") stuff as well, I guess I'm a lousy programmer
since I wrote that even though I *years* ago struggled with the case
problems of deKleers famous ATMS code, but I digress...) with the
interesting new case-sensitive stuff (like the XML parser)...
--
(espen)
On 08 Nov 2000 10:14:06 +0000, Tim Bradshaw <···@tfeb.org> wrote:
>John Foderaro <···@unspamx.franz.com> writes:
>
>> As appalling as you may find it, we can say that it works.
>> We develop in Modern mode, we compile in Modern mode
>> and you use resulting code in ANSI or Modern mode.
>>
>
>You don't seem to be reading what I wrote. What I want to be able to
>do is, from a running program (written in whatever mode, I am *not*
>talking about writing code here), read (with READ) some data with
>control over the case conversion. And I want to do that *without*
>globally toggling some switch, because while I'm reading it I really
>don't want to have to block out all other processes and cause my
>application to stop responding to events for some long period.
You are worrying about this needlessly. The varaibles in question are
by default bound per process.
Kevin Layer
Franz Inc.
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <nkjzojao07y.fsf@tfeb.org>
Kevin Layer <·····@known.net> writes:
> You are worrying about this needlessly. The varaibles in question are
> by default bound per process.
>
So are you saying that if I am in (say) modern mode, and, in a
process, I say (set-case-mode :case-insensitive-lower) that will work
for that process only? Presumably this will not be the case for
:case-insensitive-upper as this has to rename all the symbols in the
world so it can't be per process can it?
--tim
On 08 Nov 2000 17:14:09 +0000, Tim Bradshaw <···@tfeb.org> wrote:
>Kevin Layer <·····@known.net> writes:
>
>> You are worrying about this needlessly. The varaibles in question are
>> by default bound per process.
>>
>
>So are you saying that if I am in (say) modern mode, and, in a
>process, I say (set-case-mode :case-insensitive-lower) that will work
>for that process only? Presumably this will not be the case for
>:case-insensitive-upper as this has to rename all the symbols in the
>world so it can't be per process can it?
set-case-mode is not intended to be used in this way.
http://www.franz.com/support/documentation/6.0/doc/pages/operators/excl/set-case-mode.htm
says:
This function can be called at any time but should, if possible, be
called as the first action in a fresh invocation of Lisp (and better
would be to use the image with the desired case mode and do not use
this function at all). Note that the system will not be able to
resolve conflicts if case mode is changed after Lisp has been running
for some time. However, sometimes it is necessary to change case modes
more than once. Suppose you want to work in case-sensitive, lowercase
preferred mode but need to load files written for a standard
(case-insensitive, uppercase) Lisp. You might first set the mode to
:case-insensitive-lower, load the files, and then set the mode to the
desired :case-sensitive-lower.
Kevin Layer
Franz Inc.
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <nkjwveeny00.fsf@tfeb.org>
Kevin Layer <·····@known.net> writes:
> set-case-mode is not intended to be used in this way.
>
> http://www.franz.com/support/documentation/6.0/doc/pages/operators/excl/set-case-mode.htm
>
> says:
yes, I've read that. Let me reiterate my question (I'm not trying
some rhetorical trick here, I think it may have got lost in the
thread).
This description is modelled on an actual system although it's
obviously simplified and I doubt the application will ever be
converted to be case-sensitive (*far* too much random & inconsistent
use of case in it!).
Let's say I have my application running in `modern' mode. This
application is multithreaded and threads come and go at a fair rate
(possibly several per second). These processes can't block for too
long (typical gc is OK, a 60 second pause probably is not). As a
`background' task it also needs to read and or write some large
amounts of data, which it does with READ and PRINT and such like
functions. These reads/writes can take minutes to complete. These
reads/writes need to be case-insensitive, upper-case preferred as they
involve large amounts of data which is defined that way. I could
*probably* live with case-insensitive lowercase-preferred, although
that would be significantly more painful. It is essential that the
lisp does not block when these long reads/writes are happening.
What I would do if readtable-case worked (which I understand it does
not in a `modern' image) is something somewhat like this (obviously
I'd not cons a readtable each time through...):
(let ((rt (copy-readtable nil)))
(setf (readtable-case rt) :upcase)
(with-standard-io-syntax
(let ((*readtable* rt))
(read in))))
Can I do this, or something equivalent, in ACL, in `modern' mode?
Thanks
--tim
On 08 Nov 2000 18:02:07 +0000, Tim Bradshaw <···@tfeb.org> wrote:
>(let ((rt (copy-readtable nil)))
> (setf (readtable-case rt) :upcase)
> (with-standard-io-syntax
> (let ((*readtable* rt))
> (read in))))
>
>Can I do this, or something equivalent, in ACL, in `modern' mode?
Yes, because *readtable* is bound (by default, unless changed by the
user explicitly) per process.
Kevin Layer
Franz Inc.
On Wed, 08 Nov 2000 10:42:09 -0800, Kevin Layer <·····@known.net>
wrote:
>On 08 Nov 2000 18:02:07 +0000, Tim Bradshaw <···@tfeb.org> wrote:
>
>>(let ((rt (copy-readtable nil)))
>> (setf (readtable-case rt) :upcase)
>> (with-standard-io-syntax
>> (let ((*readtable* rt))
>> (read in))))
>>
>>Can I do this, or something equivalent, in ACL, in `modern' mode?
>
>Yes, because *readtable* is bound (by default, unless changed by the
>user explicitly) per process.
>
>Kevin Layer
>Franz Inc.
Correction: readtable-case doesn't currently work in Modern mode.
We have a entry for this issue in our bug database filed on 9apr2000.
We will definitely review it and see what can be done.
Kevin Layer
Franz Inc.
In case you're curious one could get the features of a case conversion
on a per-thread basis by just binding some special variables. It's
do-able but there's no api for it. It's not a clean solution to the
problem anyway.
One reason that this hasn't been an issue in the past is that people
generally work with compiled code. A module can be compiled in either
mode and loaded into a lisp in the other mode. The reader doesn't come
into play when dealing with different mode'ed modules being fasl loaded
dynanmically.
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <nkjk8acgf6d.fsf@tfeb.org>
Kevin Layer <·····@known.net> writes:
> Correction: readtable-case doesn't currently work in Modern mode.
>
> We have a entry for this issue in our bug database filed on 9apr2000.
> We will definitely review it and see what can be done.
>
Thanks. For the record, I would like readtable-case to work as
documented in the standard as I use it in other places (to read
case-sensitively into an ANSI CL). So when I switch to a `modern' CL
readtable-case would be :preserve by default but I could switch it to
all the normal things.
As an additional enhancement it would be really cool if you could
expose slightly more of the case-conversion which goes on when
switching modes -- for instance it would be nice to be able to choose
whether symbols in a given package get touched by a predicate, or
perhaps to have a predicate which gets called per symbol and can
decide whether it is touched (and perhaps even one that can return the
new print name). I realise that these would slow down the conversion
process, though on my (fairly slow) machine it's a sub-1-second
process at present, so I could live with that, anyway (I remember it
taking several minutes in 1990!)
I'd be happy to mail this to the franz support address if it helps to
have more requests filed.
--tim
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182667031466468@naggum.net>
* John Foderaro <···@unspamx.franz.com>
| As appalling as you may find it, we can say that it works.
And you will listen to nobody else. *sigh*
| We aren't trying to support both modes at once inside a single lisp.
Nobody asks you to.
| Let's face it, you know which mode you want to develop in.
Yeah, let's face it: You don't _know_, because the _code_ does not
contain information as to that choice, but you can _guess_ and you
can _remember_.
| It's so easy to write code that works in both modes that you can
| straddle the fence for a long time.
Sure it's easy, and the code is even conforming, but it is still a
change from common idiomatic expression. Can't you at least be
honest enough to admit to the _fact_ that you need a coding standard
that differs from plain ANSI Common Lisp?
Why do you have to pretend that what you do is not changing
anything? First this lie ("virtual machine") about what the reader
does, then the lie about old conforming code that works just fine,
and now this lie that there is no effort to change the programmer's
coding conventions, either.
I just want you to be honest about what you're doing, John. That
would have saved you a lot of distrust and loss of goodwill.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
Tim Bradshaw <···@cley.com> writes:
> I don't think I saw the full horror of this until just now. Perhaps I
> still do not understand.
Yes. I think that the situation is not as bad as you might have
expressed in the choices below.
> 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;
No. You can definitely avoid this.
> 2. toggle, globally, into ansi mode and back, losing case information
> about potentially every symbol in the system in the process.
I think after reading a post from one of the Franz guys, you can do
this without fear, and things will work just right.
> 3. don't use modern mode, and live with || where I need
> case-sensitivity.
When do you actually _need_ case insensitivity? It's not that often.
If it happens, then use the |'s. Or, do what MCL does, and employ a
reader macro, such as the #_CallThisInJava, which not only is
annotationally expressive, it's more powerful than just interpreting
the following symbol as case-sensitive; it can expand that cleverly,
depending on what you're really trying to do (like FFI/FLI stuff).
Plus, this is just plain, pure Common Lisp. There's no excuse to
_not_ use what's already there. Writing the #_ reader macro will
certainly involve a bit of work, but SO WHAT! Look what you get, and
look what you prevent -- breaking with the standard.
> [choice] 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.
No. Someone (from Franz, I think) already explained that the
variables involved with case are thread-specific. You definitely hit
something that was a possible problem, but they beat you to it, and
it's actually kind obvious, considering how *all*
multiprocessing-capable Lisps seems to treat the variables set by
WITH-STANDARD-IO-SYNTAX as thread-special variables.
> 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.
I personally wouldn't want that, as it would confuse the hell out of
me. We don't need to add complexity to the package system, not to
mention that I don't even know that it would work right.
dave
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey3wvearfbp.fsf@cley.com>
* David Bakhash wrote:
>> 2. toggle, globally, into ansi mode and back, losing case information
>> about potentially every symbol in the system in the process.
> I think after reading a post from one of the Franz guys, you can do
> this without fear, and things will work just right.
> [...]
> No. Someone (from Franz, I think) already explained that the
> variables involved with case are thread-specific. You definitely hit
> something that was a possible problem, but they beat you to it, and
> it's actually kind obvious, considering how *all*
> multiprocessing-capable Lisps seems to treat the variables set by
> WITH-STANDARD-IO-SYNTAX as thread-special variables.
I think some other followups in this thread explain why this won't
work.
--tim
Tim Bradshaw <···@cley.com> writes:
> > No. Someone (from Franz, I think) already explained that the
> > variables involved with case are thread-specific. You definitely hit
> > something that was a possible problem, but they beat you to it, and
> > it's actually kind obvious, considering how *all*
> > multiprocessing-capable Lisps seems to treat the variables set by
> > WITH-STANDARD-IO-SYNTAX as thread-special variables.
>
> I think some other followups in this thread explain why this won't
> work.
Then I'm still confused, which I guess I already knew.
But I think that between something like a #_ reader macro and the
:invert option on readtable-case, the "right" thing can be done
without sacrificing the Standard.
dave
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey3itpuragh.fsf@cley.com>
* David Bakhash wrote:
> Then I'm still confused, which I guess I already knew.
> But I think that between something like a #_ reader macro and the
> :invert option on readtable-case, the "right" thing can be done
> without sacrificing the Standard.
yes, the point is that readtable-case *doesn't work* in ACL's `modern'
mode! If it worked, I'd have no problem.
--tim
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182935908719547@naggum.net>
* Tim Bradshaw <···@cley.com>
| yes, the point is that readtable-case *doesn't work* in ACL's `modern'
| mode! If it worked, I'd have no problem.
To be fair, I posted patches that makes it work, Tim. The real patch
is a replacement to set-case-mode that uses the readtable-case instead
of *force-readtable-case-raw*, but a new value to readtable-case is
required to retain user knowledge. I have selected :default, which
uses the value of *default-readtable-case-raw*, which means you can
change just one variable to make the _unmodified_ readtables use the
new setting. readtable-case can be set to :default, but it always
returns one of the four predefined values. All readtables start out
in :default, so you really get what you ask for if you set its case.
#:Erik
--
ALGORITHM: a procedure for solving a mathematical problem in a finite
number of steps that frequently involves repetition of an operation.
ALGOREISM: a procedure for solving an electoral problem in a finite
number of steps that frequently involves repetition of an operation.
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey34s1dqdpx.fsf@cley.com>
* Erik Naggum wrote:
> To be fair, I posted patches that makes it work, Tim. The real patch
> is a replacement to set-case-mode that uses the readtable-case instead
> of *force-readtable-case-raw*, but a new value to readtable-case is
> required to retain user knowledge. I have selected :default, which
> uses the value of *default-readtable-case-raw*, which means you can
> change just one variable to make the _unmodified_ readtables use the
> new setting. readtable-case can be set to :default, but it always
> returns one of the four predefined values. All readtables start out
> in :default, so you really get what you ask for if you set its case.
If I got those patches by saying (sys:update-allegro) I'd be very
happy!
--tim
From: Marco Antoniotti
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <y6c66m2pbdz.fsf@octagon.mrl.nyu.edu>
Erik Naggum <····@naggum.net> writes:
> * Marco Antoniotti <·······@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.
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
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Erik Naggum <····@naggum.net> writes:
> > 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.
>
> [...]
>
> I hope the Franz people here hear you.
They hear, but they don't listen. Unfortunately, this is the problem
with religion. Everyone has his own, and no one wants to listen.
> 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.
There are justifications, and they've been written about. Some of
them might be idiosyncratic; some may not be the preference of the
masses. But they defined the language to be flexible enough to
accomodate all of the situations that I've ever needed, and that's
much more than I can say about any other language.
We all have our preferences. I would have preferred the default
language to be defined with the standard syntax having readtable-case
to be :downcase, the symbols in the :cl package to be lower case, and
the *print-case* to be :upcase (i.e. preserve case). That way I can
just suddenly switch to :preserve and things still generally work, and
symbols both look nice and print nicely by default. But do I care
what I think when dealing with the rest of the community? Only as far
as I have an opinion, and that it's something that's fun to talk about
in retrospect (kinda like talking about whom we would have voted for,
had we known...).
This thread is about something much more serious. It's that we see
all of the users pretty much saying that they care most about
conforance. This is despite having many differing opinions on things
like case (i.e. KMP, Erik, and I all have different preferences with
respect to case, just as an example, and yet we're asking for the same
thing: don't break with the standard). The reason is that we know we
can acheive what we want with what CL has built-in (provided our
implementors don't break it).
KMP posted solutions to people's desire to have the symbols in the
Common Lisp package being lowercase. It just goes to show that if you
want it, it's right there. There's really very little that you can't
do. I think it's extreme, but not as much as tossing out the stuff we
depend on. For the case issues that I deal with (and, interestingly,
we're working on an embedded Lisp for a product and have to deal with
case a lot), Franz's Modern mode would be a nightmare. I'm surprised
they don't understand why that is.
dave
In our last episode (04 Nov 2000 23:57:22 +0000),
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...]
--
········@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 <········@interchange.ubc.ca>
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182427125786078@naggum.net>
* 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.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
Erik Naggum <····@naggum.net> writes:
> 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
From: Friedrich Dominicus
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <87em0ochnd.fsf@frown.here>
David Bakhash <·····@alum.mit.edu> writes:
>
> 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
From: Robert Monfera
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3A04CA75.96A92BE8@fisec.com>
Erik Naggum wrote:
> 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
In article <·················@fisec.com>,
Robert Monfera <·······@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
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey3r94q9w12.fsf@cley.com>
* Keke Abe wrote:
> 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
From: Marc Battyani
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <8u6nft$810$1@reader1.fr.uu.net>
"Tim Bradshaw" <···@cley.com> wrote in message
····················@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
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey3d7g887rw.fsf@cley.com>
* Marc Battyani wrote:
> 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
From: ······@honolulu.ilog.fr
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <8u8u8d$fvp$1@honolulu.ilog.fr>
Tim Bradshaw <···@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?
Bruno
From: Marco Antoniotti
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <y6cy9yv23w5.fsf@octagon.mrl.nyu.edu>
······@honolulu.ilog.fr writes:
> Tim Bradshaw <···@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.
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
From: Marco Antoniotti
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <y6clmuv22zk.fsf@octagon.mrl.nyu.edu>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> ······@honolulu.ilog.fr writes:
>
> > Tim Bradshaw <···@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.
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
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182432540790078@naggum.net>
* ····@mac.com (Keke Abe)
| 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.)
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
In article <·····················@solg4.keke.org>, ····@mac.com says...
> 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.
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182450051259505@naggum.net>
* John Foderaro <···@unspamx.franz.com>
| 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.)
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
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
franz inc
John Foderaro <···@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.
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 <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
In article <··············@localhost.localdomain>, ···@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.
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 <···@unspamx.franz.com> writes:
> In article <··············@localhost.localdomain>, ···@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.
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey3zojb754i.fsf@cley.com>
* Lieven Marchand wrote:
> 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
From: Marco Antoniotti
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <y6ck8aeeaj0.fsf@octagon.mrl.nyu.edu>
Tim Bradshaw <···@cley.com> writes:
> * Lieven Marchand wrote:
> > 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.
As a matter of fact the Trial edition comes with instructions to
generate an ANSI image.
As per the commercial distribution, we can take the word of Franz and
expect all the images on the CD.
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
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182561860085563@naggum.net>
* John Foderaro -> Lieven Marchand
| 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.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
John Foderaro <···@unspamx.franz.com> wrote:
>...
>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.
That sounds good, we need a *faster* evolving Standard Common Lisp (BTW as
Ken Pitman said it somewhere, ANSI looks to be a too slow vehicle - this
would be a better discussion subject than the current one...) Experimenting
with new extensions is good even if it breaks the standard, I even would
say, above all if it breaks the standard. However an experiment must
remains an experiment: no one should be an experimenter without knowing it,
at some right time conclusions have to be drawn, etc.
I think you can easily get rid of some of the critiques (some of them are
valuable in my opinion) by providing a free ANSI image too from the Franz
download page and add explanations about the reasons Franz wants to promote
the 'modern' lisp reader. And hopefully stops this surrealistic thread.
BTW the 'modern' name is really a bad choice and will remain a subject of
jokes even after it will disappear ... finally not so bad, we all need to
laugh :-)
>...
>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.
That's fine. However as a Franz customer I am worried about what I have
heard from you in this thread and from the support team when I was testing
the beta.
First of all, let me say, � premi�re vue, I'm not interrested in the Modern
mode except if it was something dymamic (something I could associate with a
package or change using a mode switching function) which seems to be not
feasible. I don't see any interrest in 'foo' and 'fOo' being different
symbols (just see this feature as source of bugs). Because of this, having
to use strings to interface with some foreign language is not a big
concern.
Second and more important, I am worried to get a less powered ACL if I
'stick with the old ANSI version'. For example somewhere else you wrote :
>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).
What does this mean exactly?
--
Francis Leboutte
www.algo.be +32-(0)4.388.39.19
In article <··································@4ax.com>,
··········@algo.be says...
>
> BTW the 'modern' name is really a bad choice and will remain a subject of
> jokes even after it will disappear ... finally not so bad, we all need to
> laugh :-)
>
We've been kidding about the name but let me tell you where it comes
from. Take out a piece of paper and write a timeline. On the timeline
place computer languages at the time they were introduced. Label the
left part of the timeline "Ancient" and the right part "Modern".
Now ask yourself what do most (perhaps all on your timeline) of the
modern languages have in common in terms of their treatment of case
sensitivity of identifiers. Once you've done that you'll see that Modern
mode is just a shorthand for "similar to the case sensitivity rules found
in modern languages".
> I don't see any interrest in 'foo' and 'fOo' being different
> symbols (just see this feature as source of bugs).
I don't know of anyone who would use a symbol named fOo. I've been using
a lisp in Modern mode for over 20 years and I've never been tempted to
use such a symbol. However I was writing code in Lisp to run in a Java
VM and I was happy that I could express the name of every Java symbol in
my Lisp program without resorting to escaping or coming up with some
hypenated mapping.
> Second and more important, I am worried to get a less powered ACL if I
> 'stick with the old ANSI version'. For example somewhere else you wrote :
>
> >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).
>
We have no plans to make any existing facility of ACL that worked without
Modern mode now require Modern mode. So it will never become less
powerful. The xml parser is brand new and it's an interface to a a case
sensitive language (xml) which some have called Lisp with angle brackets
instead of parentheses. The xml parser need an 16-bit character lisp
and one running in Modern mode. This is how it's most easily written and
how xml is most easily manipulated. Our feeling is that if you are
someone who is interested in manipulating xml then you have to be think
about case sensitivity: <foo> is different than <fOo>. In this case you
may actually appreciate the Modern mode. There are ANSI lisp xml
parsers out there. Our xml parser is open source so an ANSI lisp
derivative could probably be made of it. Also in the end it's customers
of ours that drive what we do - and by that I don't mean people saying
that they don't like the idea of a modern only module but people with
real problems to solve needing, say, our particular xml parser but
running in ANSI mode.
John Foderaro wrote:
>
> We've been kidding about the name but let me tell you where it comes
> from. Take out a piece of paper and write a timeline. On the timeline
> place computer languages at the time they were introduced. Label the
> left part of the timeline "Ancient" and the right part "Modern".
>
If that's the case, then you should drop the Modern name as soon as
possible. The funny thing about timelines is that the bound on the
right-hand side moves. Ten years from now calling a particular set of
features "Modern Lisp" will make just as much logical sense as does the
name "Modern Art". Do you plan to sell something called "Post-Modern
Lisp" around 2010?
As a guy who did his dissertation in Franz Lisp (University of Maryland
variant), and who helped Xerox AI Systems implement their Common Lisp
(Interlisp-D: case-sensitive, upper-case preferred - clearly the worst
case), I have some empathy with both sides here. I have to come down on
the side of respecting the ANSI standard, though. If a system says it's
ANSI-compliant, then either:
* it should be ANSI right out of the box
* you should be able to make it ANSI with one operation (loading one
vendor-provided file, max)
Unless I'm really confused, ACL 6.0 Trial Edition meets neither of
these.
--
Remove obvious stuff to e-mail me.
Bob Bane
From: Richard Fateman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3A09AED2.5CC84814@cs.berkeley.edu>
For amusement (if this thread needed some amusement)
I thought I'd provide an anecdote.
In 1971 I was given an office at MIT with a teletype
machine. It could be used for access to timesharing
systems such as ITS (the Incompatible Timesharing
System of MIT AI/LCS) as well as Multics. However,
connecting it to Multics was rather pointless because
the system commands were all in lower case. For example,
one could not
LOGIN
one had to
login
and the teletype just did not have lower case.
Faced with this dilemma, a solution was constructed to
provide the only built-in system command that could be
typed in upper case. It was called
MAP
(presumably this was also unusual in that it could
be typed before login, but my memory of Multics is
vague).
In reality I wonder if the reason it made it into
Multics was the programmer I asked to do it was
coincidentally Michael A. Padlipsky (MAP).
Cheers.
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfwzojai4om.fsf@world.std.com>
Richard Fateman <·······@cs.berkeley.edu> writes:
> For amusement (if this thread needed some amusement)
> I thought I'd provide an anecdote.
>
> In 1971 I was given an office at MIT with a teletype
> machine. [...] However, connecting it to Multics was
> rather pointless because the system commands were all
> in lower case [...] and the teletype just did not
> have lower case. [...] A solution was constructed to
> provide the only built-in system command that could be
> typed in upper case. It was called "MAP" [...]
A related anecdote is that a compatibility feature of Unix (which
seems to have gone away in my linux system) is that if you logged in
with an all-uppercase name, Unix would say "gee, his terminal must
have only upper case" and would not only "helpfully" map all input
uppercase characters to lowercase. I think you had to do something
like put a \ in front of a character to retain the uppercase, and I
think output came out likewise (all uppercase, but with caps escaped).
(This made sense on a TTY console, but was very confusing if you had
accidentally logged in from a casification-capable console with the
caps lock key on and didn't realize what you'd done. :-)
The need for these weird workarounds could mostly have been avoided if
Multics and Unix had had case-insensitive commands, of course, but
they didn't. Indeed, in those days there were commands with the same
names and different cases. Being one day told that the reason my
request to "kill" a Unix process was failing was that I needed to use
"KILL" instead (for the more dramatic effect I was seeking) is an
example of the horrors that I think case-sensitive systems invite but
that I think programmers and system designers should seek to avoid,
exactly because the difference is hard to pronounce and therefore
awkward both to communicate and to remember.
From: Valeriy E. Ushakov
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <8ucidm$2nad$1@news.spbu.ru>
Kent M Pitman <······@world.std.com> wrote:
> A related anecdote is that a compatibility feature of Unix (which
> seems to have gone away in my linux system) is that if you logged in
> with an all-uppercase name, Unix would say "gee, his terminal must
> have only upper case" and would not only "helpfully" map all input
> uppercase characters to lowercase.
Hey, I started (and worked for couple of years) on one of those (PDP11
with 2.9BSD). The terminal was able to properly *input* both upper
and lower case, but can only *ouput* in all-upper, since the lowercase
part of the terminal font was occupied by Russian alphabet.
SY, Uwe
--
···@ptc.spbu.ru | Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen
Richard Fateman <·······@cs.berkeley.edu> writes:
> For amusement (if this thread needed some amusement)
> I thought I'd provide an anecdote.
>
> In 1971 I was given an office at MIT with a teletype
> machine. It could be used for access to timesharing
> systems such as ITS (the Incompatible Timesharing
> System of MIT AI/LCS) as well as Multics. However,
> connecting it to Multics was rather pointless because
> the system commands were all in lower case. For example,
> one could not
> LOGIN
> one had to
> login
>
> and the teletype just did not have lower case.
>
> Faced with this dilemma, a solution was constructed to
> provide the only built-in system command that could be
> typed in upper case. It was called
> MAP
> (presumably this was also unusual in that it could
> be typed before login, but my memory of Multics is
> vague).
Even today the login program of most commercial Unixen will go into
case translating mode if you type your username in all caps.
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <nkjhf5ggebz.fsf@tfeb.org>
Bob Bane <····@removeme.gst.com> writes:
> * you should be able to make it ANSI with one operation (loading one
> vendor-provided file, max)
One thing I thought of for acl (in fact I tested this slightly) ACL
reads a system-wide init file which (I think) lives in the
distribution directory. A default init file could be provided which:
asks you if you want an ansi cl (or just makes one), perhaps runs some
demos or something on windows to impress people, and then renames
itself out of the way (saying where it renamed itself to, so you can
make the lisp `new' again). That means you could get an ANSI image
without having to ship one, as this file would be some tens of lines
long only.
--tim
John Foderaro <···@unspamx.franz.com> writes:
> We've been kidding about the name but let me tell you where it comes
> from. Take out a piece of paper and write a timeline. On the timeline
> place computer languages at the time they were introduced. Label the
> left part of the timeline "Ancient" and the right part "Modern".
> Now ask yourself what do most (perhaps all on your timeline) of the
> modern languages have in common in terms of their treatment of case
> sensitivity of identifiers. Once you've done that you'll see that Modern
> mode is just a shorthand for "similar to the case sensitivity rules found
> in modern languages".
Could you stop this misinformation?
First of all, ANSI CL is case sensitive. You seem to have a problem
with the case chosen for the language symbols (although Modula-3 makes
the same choice, to name a modern language) and with the default
reader table case setting.
Second, case sensitivity has less to do with a modern/ancient
distinction and more with an C/Algol background distinction. Most
Algol derived languages like Pascal and Ada are case insensitive.
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
In article <··············@localhost.localdomain>, ···@bewoner.dma.be
says...
> Could you stop this misinformation?
>
I would if I were.
> First of all, ANSI CL is case sensitive.
Let's not get too pedantic. In the discussion we've been having the last
few days we've used the term case sensitive to refer to the the default
behavior of the reader when it collects the characters that identify a
symbol. ANSI CL more closely resembles a case insensitive language when
you compare its behavior to that of other langauges, case sensitive or
insensitive.
> Second, case sensitivity has less to do with a modern/ancient
> distinction and more with an C/Algol background distinction. Most
> Algol derived languages like Pascal and Ada are case insensitive.
The heritage of the language is irrelevant as to whether it is ancient or
modern on the timeline. The key point is that most Modern languages
significant enough to get noticed are case sensitive.
That's got to say something about whether humans are mentally capable of
dealing with programming in a case sensitive langauge. If you believe
that Lisp should be able to interface with programs written in other
languages then it is also a significant fact.
From: Thomas A. Russ
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ymiofzq0zyx.fsf@sevak.isi.edu>
John Foderaro <···@unspamx.franz.com> writes:
> In article <··············@localhost.localdomain>, ···@bewoner.dma.be
> says...
>
> > First of all, ANSI CL is case sensitive.
>
> Let's not get too pedantic. In the discussion we've been having the last
> few days we've used the term case sensitive to refer to the the default
> behavior of the reader when it collects the characters that identify a
> symbol. ANSI CL more closely resembles a case insensitive language when
> you compare its behavior to that of other langauges, case sensitive or
> insensitive.
Actually, no. If ANSI CL were case insensitive, then a lot of the
discussion would be rather moot. In that case it wouldn't matter
whether the internal representation of a standard CL symbols were "CAR"
or "car" since a case-insensitive comparison wouldn't distinguish
between them.
A lot of the hoops that you are going through stem from the fact that CL
is, in fact, case sensitive and happens to have uppercase names for all
the built-in functions. The intercession of the reader upcasing the
symbols before the lisp system sees them just adds to the confusion.
If ANSI CL were case insensitive, people like me wouldn't care about
whether READTABLE-CASE were broken or not, since it would be totally
irrelevant.
It seems to me that trying to ignore distinctions like this is one of
the factors that generates more heat in this debate than would otherwise
be warranted.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
we seem to be going backwards if we can't even agree on what case
sensitivity means when describing a language.
here are some examples that may clarify things.
in C the expression foo == FOO may or may not be true.
C is a case sensitive language.
in Common Lisp the expression (eq foo FOO) is always true.
(assuming that foo has a value).
Lisp is case insensitive language under default conditions of readtable-
case.
in unix the files "foo" and "FOO" may contain different contents.
unix filename lookup is case sensitive.
in dos the files "foo" and "FOO" are the same.
dos filename lookup is case insensitive.
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfwg0l1y8se.fsf@world.std.com>
John Foderaro <···@unspamx.franz.com> writes:
> we seem to be going backwards if we can't even agree on what case
> sensitivity means when describing a language.
>
> here are some examples that may clarify things.
>
> in C the expression foo == FOO may or may not be true.
> C is a case sensitive language.
(eql '|foo| 'FOO) => NIL ; Lisp is a case-sensitive language
Lisp's reader is case-translating (sometimes) but its internal system is
and pretty much always has been case-sensitive.
> in Common Lisp the expression (eq foo FOO) is always true.
> (assuming that foo has a value).
FOO, you mean. But yes. And assuming it's not a symbol macro. And
assuming its value is not a declared number or character type. But sure.
The only problem is that (equal '(eq foo FOO) '(EQ FOO FOO)). That doesn't
make the system case-sensitive, it's just a remark about the reader.
#.`(,(intern "EQ") ,(intern "foo") ,(intern "FOO")) is not always true,
and that's the point of saying Lisp is a case-sensitive language.
Scheme [somewhat ambiguously] defines its semantics by its textual
nature; Common Lisp quite unambiguously defines its syntax as incidental
and defines its object structure as the thing to which language semantics
is attached.
> Lisp is case insensitive language under default conditions of readtable-
> case.
No. Lisp translates case in this situation. But translation is not
sensitivity. There is no attempt to "sense" during read. Sensing occurs
during code-walking of macroexpand, compile, etc. Those actions are
identity-sensitive, and consequently case-sensitive because a given identity
can have only one name.
> in unix the files "foo" and "FOO" may contain different contents.
> unix filename lookup is case sensitive.
the equivalent of lookup in Lisp is intern, not read.
the analog of read in unix would be command line parsing. There are a lot
of shells, and it's not impossible to conceive of a shell that did case
translation by default, just as lisp did. this would not require "changing
unix".
> in dos the files "foo" and "FOO" are the same.
> dos filename lookup is case insensitive.
lisp has no equivalent facility because it is not case-insensitive.
you could, i suppose, write a
(defun my-intern (x) (intern (string-upcase x)))
or
(defun my-intern (x) (intern (string-downcase x)))
or
(defun my-intern (x) (intern (string-flipcase x)))
or
(defun my-intern (x) (intern (string-randomize-case x)))
which forced it to ignore some of the things in the readtable.
but that would not make it case-insensitive. it would just make
your program be deliberately obtuse.
In article <···············@world.std.com>, ······@world.std.com says...
> (eql '|foo| 'FOO) => NIL ; Lisp is a case-sensitive language
If you'll allow me to write this as the equivalent
(eql '\f\o\o 'FOO)
it will be easier to see where you're wrong. The backslash before a
character explicitly undoes the normal reader processing for the
following character. It says to the reader: stuff this thing in the name
exactly as I give it to you without any monkey business.
Because the backslash *overrides* the processing of the reader you can't
use it on every character of a token and then make *any* conclusions
about the kind of processing the reader makes on its input. So we learn
nothing from your example.
People are overthinking this term case sensitive. The purpose of
language is communication. Let's setup a scenario:
A person comes and sits down next to you where there is a Lisp prompt.
This person is a programmer.
He has never seen lisp and wants to try it out.
You describe how about the eq expression and the single quote.
He asks you: is lisp case sensitive or insensitive?
What are you going to tell him?
1. "it's case sensitive". then he types in (eq 'HiMom 'himom) to the
reader, sees the result and calls you a liar.
2. "it's normally used in a case insensitive mode but there are ways to
control the reader so that it will preserve or even invert the case you
type in". This is accurate. He knows what case insensitive means since
it's a term used in other programming languages. So he types in (Eq 'Foo
'FOO) is is happy when it returns t. Communication has occured. The
right language was used.
From: David J. Fiander
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <87r94lmeul.fsf@golem.waterloo.on.ca>
John Foderaro <···@unspamx.franz.com> writes:
>
> 1. "it's case sensitive". then he types in (eq 'HiMom 'himom) to the
> reader, sees the result and calls you a liar.
>
> 2. "it's normally used in a case insensitive mode but there are ways to
> control the reader so that it will preserve or even invert the case you
> type in". This is accurate. He knows what case insensitive means since
> it's a term used in other programming languages. So he types in (Eq 'Foo
> 'FOO) is is happy when it returns t. Communication has occured. The
> right language was used.
or
3. It's case sensitive internally, but the reader slams case
upper by default for historical reasons so that it looks case
insensitive, and all of the standard-defined identifiers are
upper-case. It's possible to do things both to change the
default behaviour and to tell the reader to not slam case for
a particular instance.
Which third is both intelligible and right. Until this
discussion, I thought of Lisp case insensitive, but I now
understand how it's not.
- David, noting how his sig-quote is apposite
--
David J. Fiander | We know for certain only when we know little.
Librarian | With knowlege, doubt increases
| - Goethe
John Foderaro <···@unspamx.franz.com> writes:
> [A customer] asks you: is lisp case sensitive or insensitive?
>
> What are you going to tell him?
I would say "Is IS case-sensitive, but the reader normally translates case
to a default case, so it will feel case-insensitive in the default mode.
Identifiers are compared in a case-sensitive way after the case-translation,
and you can suppress case-translation in a variety of ways, either locally
for a given symbol or globally in a given environment."
I think the problem here is really NOT the issue of case sensitivity, nor
of case translation. I think the problem here is merely the initial case
of 978 symbols in the CL package (and maybe a few keywords). Ironically,
I think the problem, if viewed in this way, is that CL *is* case-sensitive
and that having a case-sensitive language gives any programmer the write
to anger the hell out of people who might want to use their code by making
the case of their API unpalatable. The CL system is written in a case chosen
by its makers, and the Franz people don't like that. Ironically, if CL were
really case-insensitive, Franz wouldn't be confronted by this because it
could just choose to perceive the base CL API as lowercase and no one could
show them wrong; it is exactly becuase CL *is* case-sensitive that Franz
is in a bind.
Now, it seems to me that a good deal of the problem is the functions.
(CAR (foo))
looks dorky to some who like case-sensitive, which I think again ironic since
it was their call to say that case should be elected by the code author,
and since they didn't write CAR. But so it goes. I sort of imagine this
must come up in spades in user code in case-sensitive languages, but people
just live with it. Perhaps it's just a deathwish for all-uppercase and has
nothing to do with case translation or case sensitivity at all. Perhaps if
the canonical internal case had been lowercase, we'd just not be having
this discussion.
But whatever the case, so to speak, the functions are pretty much solvable
by doing
(defvar *lowercase-cl-package* (make-package "cl" :use '()))
(do-external-symbols (symbol (find-package "CL"))
(when (fboundp symbol)
(let ((friend (intern (string-downcase (symbol-name symbol))
*lowercase-cl-package*)))
(setf (symbol-function friend) (symbol-function symbol)))))
Of course, I'd probably do it long-hand, enumerating each symbol and
maybe I'd use an inline declaration and an explicit arg signature in some
cases to make sure important compiler declarations didn't get lost. But
this gets the basic idea. There's also the issue of functions that take
keyword arguments needing to take lowercase keywords as arguments, but this
could be finesssed pretty straightforwardly, I think.
The "cl" package isn't constrained by the ANSI spec; it's just
another user package, so some license can be taken with its details. It's
not a non-conformism that its symbol names are lowercase. It's permissible
for its "nil" not to be eq to cl:nil. I'd almost call that a feature,
actually.
Parameter variables could be dealt with in a variety of ways, but I'd just
leave them uppercase. There's tons of precedent for option variables in
case-sensitive languages to have a different case than functions, so it'd
be no big deal toe explain off. Or one could just leave them omitted
from the "cl" package and that would make it even more clear, since obviously
the entire "CL" package would be available to call into with its uppercase
names (just as any user package which chose uppercase names would be
available).
So here's the question: What are the TECHNICAL problems that Franz sees
that cause it to want to solve this problem in a way that involves a whole
separate image and that I haven't addressed here? I'm intersted in a
discussion of actual code scenarios, not discussion of how people like me
have it in for Franz or their customers, which I certainly do not.
Such technical scenarios were not, to my knowledge, raised during
standardization when it would have been appropriate. I thought we addressed
the scenarios that were raised, and I thought this issue was put to bed.
There were better times to deal with this than now, and they seem to have
gone to waste. Even so, though, I think a lot of good could come from
beginning from the assumption that the community can evolve a workable
solution rather than beginning from the assumption that Franz has to
unilaterally provide us with one and we must either accept it or be branded
non-cooperative.
So let's hear a discussion of the problems to be solved and then let's talk
about the possibility that there might be solutions within the standard
dialect that we all worked so hard to create.
I'm a little worn out at this point to give the questions you raised
the complete response they deserve.
I will agree that the case of identifiers in the system defined
packages should have been either lowercase or undefined and made an
implementation choice (the existence of all the code we've written at
Franz is some indication that it is possible and quite easy to program
Common Lisp in a way that is independent of the case of the system
identifiers).
I will disagree that sufficient evidence wasn't presented to those who
made the decision (before x3j13) that Common Lisp would map unescaped
characters to upper case [it was years later that other options were
allowed via setting readtable-case]. In my opinion the choice was
made based on personal wants and not the wants of the community (the
biggest Lisp community at the time being the Franz Lisp community which
overwhelming requested that Common Lisp allow them to continue to
program in a case sensitive manner (in the normally accepted sense of
the word)). While many here seem to think of the committee who made
that decision were divine and thus infallible, I think that you
recognize that they were just humans at that there is a positive
probability that the decision they made was the wrong one for today's
needs.
Lisp is a flexible language and anything is possible in it, however if
it's too painful to use people will go elsewhere. I want to see the
number of Lisp users grow and that means eliminating obstacles.
Here's a piece java code from sun's jdk
public void init() {
notImage = getImage(getCodeBase(), "images/not.gif");
crossImage = getImage(getCodeBase(), "images/cross.gif");
addMouseListener(this);
}
Here is what it looks like in my java in lisp syntax language:
(def-java-method init () void
:public
(setq notImage (getImage (getCodeBase) "images/not.gif")
crossImage (getImage (getCodeBase) "images/cross.gif"))
(addMouseListener this))
note how easy it is to translate one to the other because both have
equivalent expressibility in symbols. Of course in ANSI Common Lisp
I have to read this in the :preserve case mode.
But what if I want to add some lisp macros to the file?
I have to write in all caps;
(DEFMACRO MY-SETQ (..) ...)
Of course I could try a readtable case of :invert so then I could write
my lisp code in lower case but my java compiler would have to then work
to recover the original intented case of all identifiers in the java
code.
It's a pain. It's a hoop that I shouldn't have to go through.
xml is another example. I'd like to be able to use the symbols I see in
an xml file in my code without having to escape them.
The best way to find a set of examples of why a case sensitive lisp is a
good idea is to give it to people and let them use it. That's all we're
doing. No one is having anything shoved down their throat. It's a
voluntary test. If no one uses it but us then the rest of the Common
Lisp community needn't even concern themselves with it. If people start
to use it and help us make it more usable, then we'll end up with a
number of compelling examples of why it's important. So we've got a
win-win situation.
From: Barry Margolin
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <S2EO5.27$sG1.450@burlma1-snr2>
In article <·························@news.dnai.com>,
John Foderaro <···@unspamx.franz.com> wrote:
>Here is what it looks like in my java in lisp syntax language:
>
>(def-java-method init () void
> :public
> (setq notImage (getImage (getCodeBase) "images/not.gif")
> crossImage (getImage (getCodeBase) "images/cross.gif"))
>
> (addMouseListener this))
>
>note how easy it is to translate one to the other because both have
>equivalent expressibility in symbols. Of course in ANSI Common Lisp
>I have to read this in the :preserve case mode.
Why? Are there other functions named getimage, GETIMAGE, or Getimage that
would cause conflicts if you didn't preserve the case? I presume that the
foreign function declarations let you specify that the Lisp function
GETIMAGE maps to the Java function getImage, so the right thing happens
when linking. Common Lisp FFI's have had to deal with this for years;
:PRESERVE is only needed if you need the FFI to determine the mappings
automatically.
>xml is another example. I'd like to be able to use the symbols I see in
>an xml file in my code without having to escape them.
I'm not very familiar with the details of XML, but I understand it's based
on SGML, and I'm under the impression that this is case insensitive. I
know that HTML, another SGML-based language, is: I can write <A HREF=...>,
<a href=...>, or <a HrEf=...> and they're all equivalent. Is this
something specified by the DTD, and XML specifies case-sensitivity?
>The best way to find a set of examples of why a case sensitive lisp is a
>good idea is to give it to people and let them use it. That's all we're
>doing. No one is having anything shoved down their throat. It's a
>voluntary test. If no one uses it but us then the rest of the Common
>Lisp community needn't even concern themselves with it. If people start
>to use it and help us make it more usable, then we'll end up with a
>number of compelling examples of why it's important. So we've got a
>win-win situation.
I've used case-sensitive languages (Multics PL/I, Multics Maclisp),
case-insensitive languages (BASIC), and upcasing languages (PDP-10 Maclisp,
Common Lisp). IMHO, the differences aren't overwhelming. One of the
things that's common in case-sensitive languages is the development of
conventions for use of case; for instance, in the C community, it's common
to use ALL_UPPER for macros and all_lower for ordinary functions and
variables, and even if you choose the same name for both there's rarely any
confusion, and some Multics development groups had conventions for uses of
uppercase and lowercase prefixes on variables or functions (similar in some
ways to Hungarian notation, e.g. Pfoo would be a pointer to a foo). And of
course, there are the programming communities that like to use capital
letters as word delimiters (as in John's Java example), instead of
separators like _ or -. Conversely, some people decry these practices. I
personally think that the getCodeBase style is unesthetic and harder to
read or type than get_code_base or get-code-base; it basically comes down
to a religious issue.
--
Barry Margolin, ······@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.
In article <················@burlma1-snr2>, ······@genuity.net says...
> Why? Are there other functions named getimage, GETIMAGE, or Getimage that
> would cause conflicts if you didn't preserve the case?
This is input to a compiler written in Common Lisp that generates a java
class file as output. The compiler knows nothing about any particular
Java function, it learns which functions and classes are available by
reading java class files in the class search path. These class files
contain not only the java bytes codes but an encoding of the 'api' of
that class file. Thus we have to get the casification perfect in order
to locate the correct function in the correct class file.
> I'm not very familiar with the details of XML, but I understand it's based
> on SGML, and I'm under the impression that this is case insensitive.
but xml is case sensitive. strange perhaps, but true.
I
From: Barry Margolin
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <UwFO5.39$sG1.556@burlma1-snr2>
In article <··························@news.dnai.com>,
John Foderaro <···@unspamx.franz.com> wrote:
>In article <················@burlma1-snr2>, ······@genuity.net says...
>> Why? Are there other functions named getimage, GETIMAGE, or Getimage that
>> would cause conflicts if you didn't preserve the case?
>
>This is input to a compiler written in Common Lisp that generates a java
>class file as output. The compiler knows nothing about any particular
>Java function, it learns which functions and classes are available by
>reading java class files in the class search path. These class files
>contain not only the java bytes codes but an encoding of the 'api' of
>that class file. Thus we have to get the casification perfect in order
>to locate the correct function in the correct class file.
Couldn't it do a case-insensitive comparison with the function names in the
class files? In other words, it would act as if there were a foreign
function definition for every function in every class file, right?
--
Barry Margolin, ······@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.
From: Chris Page
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <B63074B6.3FCD%page@best.com>
in article ················@burlma1-snr2, Barry Margolin at
······@genuity.net wrote on 2000.11.09 2:27 PM:
> In article <··························@news.dnai.com>,
> John Foderaro <···@unspamx.franz.com> wrote:
...
>> This is input to a compiler written in Common Lisp that generates a java
>> class file as output.
...
> Couldn't it do a case-insensitive comparison with the function names in the
> class files? In other words, it would act as if there were a foreign
> function definition for every function in every class file, right?
I can only assume from John's comments that Java must be case-sensitive in
this respect, otherwise his code would already be doing case-insensitive
comparisons.
However, what if it performed a case-insensitive lookup *unless there are
conflicts*? Then, "getImage", "getimage", and "GETIMAGE" would all work
equally well, and escaped versions (e.g., |getImage|) could be used to
distinguish conflicting names. It seems to me that this solution would be
best, in that Java symbols would be treated the same as Lisp symbols, and
symbols (either Java or Lisp) whose case is important would be called out in
the source code, and in the same way.
--
Chris Page
let mailto = concatenate( "page", ·@", "best.com" );
From: Chris Page
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <B630774B.3FD4%page@best.com>
in article ··················@best.com, Chris Page at ····@best.com wrote on
2000.11.09 3:35 PM:
> I can only assume from John's comments that Java must be case-sensitive in
> this respect, otherwise his code would already be doing case-insensitive
> comparisons.
>
> However, what if it performed a case-insensitive lookup...
Oops! I just noticed that John said this was compiled to produce Java class
files, which means he has no control over how the names are looked up by the
Java VM, for calls to Lisp from Java, although I believe my comments are
still valid when referring to Java names from Lisp.
To maintain the case of the Java method being defined, couldn't he arrange
for def-java-method to preserve case just for the method name? I'm not yet
familiar with the details of the reader (I'm in the middle of teaching
myself Lisp, starting with CLtL2), and perhaps the implementation would be
complicated, but isn't it possible?
--
Chris Page
let mailto = concatenate( "page", ·@", "best.com" );
From: Barry Margolin
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <IUGO5.42$sG1.556@burlma1-snr2>
In article <··················@best.com>, Chris Page <····@best.com> wrote:
>in article ··················@best.com, Chris Page at ····@best.com wrote on
>2000.11.09 3:35 PM:
>
>> I can only assume from John's comments that Java must be case-sensitive in
>> this respect, otherwise his code would already be doing case-insensitive
>> comparisons.
>>
>> However, what if it performed a case-insensitive lookup...
>
>Oops! I just noticed that John said this was compiled to produce Java class
>files, which means he has no control over how the names are looked up by the
>Java VM, for calls to Lisp from Java, although I believe my comments are
>still valid when referring to Java names from Lisp.
Oh, I didn't notice this, either. In that case, I see the problem.
>
>To maintain the case of the Java method being defined, couldn't he arrange
>for def-java-method to preserve case just for the method name? I'm not yet
>familiar with the details of the reader (I'm in the middle of teaching
>myself Lisp, starting with CLtL2), and perhaps the implementation would be
>complicated, but isn't it possible?
No. Source expressions are read *before* anything is executed. By the
time def-java-method runs, all it has is the result of reading, which is a
case-mapped symbol.
--
Barry Margolin, ······@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.
In article <················@burlma1-snr2>, ······@genuity.net says...
>
> Couldn't it do a case-insensitive comparison with the function names in the
> class files? In other words, it would act as if there were a foreign
> function definition for every function in every class file, right?
>
This would work a large percentage of the time but not 100% of the time.
Java programmers (like C programmers) like to use ALL CAPS for constants
and may use an all lowercase variable of the same name. (I think there
was an all caps constant in the example I gave). Since case is distinct
Java programmers (like C programmers) don't even think about whether if
there would be a clash if cases weren't distinct.
So if we did case insensitive comparisons to find matching functions we
would always have to scan up the entire class hiearchy, find all the
matching functions and then ask the user to resolve things if there was
an ambiguity. Doable yes, but this is a big and unnecessary hoop to
jump through if only Lisp has the expressive power of Java in terms of
naming identifiers (which is does only if you escape away the natural
case insensitive behavior).
From: Erik Naggum
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <3182806813442169@naggum.net>
* John Foderaro <···@unspamx.franz.com>
| Doable yes, but this is a big and unnecessary hoop to jump through
| if only Lisp has the expressive power of Java in terms of naming
| identifiers (which is does only if you escape away the natural case
| insensitive behavior).
Since it appears from your comments that you do not know Common Lisp
very well, but approach it as if the defaults are your only option,
I think it is important to inform you of the several interesting
options you have when you want case sensitivity in the reader and
also get the expected results when coding.
First, just (setf (readtable-case *readtable*) :preserve) and write
symbols in the Common Lisp package in upper-case. Everything else
will be in lower-case if you write it that way, and that which is in
mixed case will have their case retained, too.
Second, if you don't want to write symbols literally in upper-case,
you can (setf (readtable-case *readtable*) :invert) and have the
case reverted for mono-case symbols, and retained for mixed case
symbols. This causes a similarly case-sensitive reader, but has the
advantage that symbols whose names are upper-case will read and
print with lower-case.
I find it odd that you continue to talk about a Common Lisp that has
a lot less functionality than the Common Lisp I know and which is
specified to do a number of things you seem to want but do not want
to do the way you can do them. Again, I find this odd. It _looks_
like the reason for your problems and issues with the reader comes
from not implementing the standard faithfully before changing it.
There is nothing _natural_ about the upcasing reader. It is merely
the default setting. As long as we know that Franz Inc argues very
strongly that people "just" have to evaluate a few lines of code to
get an ANSI Common Lisp from the Modern lisp image, it seems rather
disingenuous to argue against changing these other default values,
or as if they cannot be changed as easily as building a new image.
#:Erik
--
Al-Gore-ism: a procedure for solving an electoral problem in a finite
number of steps that frequently involves repetition of an operation.
See also algorithm.
Erik Naggum <····@naggum.net> writes:
> Second, if you don't want to write symbols literally in upper-case,
> you can (setf (readtable-case *readtable*) :invert) and have the
> case reverted for mono-case symbols, and retained for mixed case
> symbols. This causes a similarly case-sensitive reader, but has the
> advantage that symbols whose names are upper-case will read and
> print with lower-case.
The problem I see with :invert is that it doesn't exactly solve what
Franz was trying to do from the outset. Basically, if you use
:invert, then you get a case-sensitive reader for mixed-case
(something they want). A symbol like 'remove-duplicates works just
great when interfacing with the :common-lisp package (and so if you
just make sure your code accessing symbols in the :common-lisp
packages is written in lower case, you're still doing good). And even
the mixed-case stuff in foreign libraries is good! It's the non-mixed
case in foreign libraries that jacks everything up. But the solution
is just so simple that it strikes me as crazy that they didn't use it
instead of breaking with the standard:
### Use the same :invert rules when reading foreign code ###
Why not? Effectively, there's a symbol table that they create for
foreign libraries, right? Only the external symbols of the foreign
stuff matters, and if that stuff uses the :invert rules, then we're
all happy. In fact, there can be TWO alternatives for people who want
to use their Java interface:
1) use :invert on your readtable when using the Java stuff (or, even
more simply, just set your *readtable* to theirs when using the
Java stuff, or copy theirs, and modify it in acceptable ways that
don't break the interface, according to what they specify you can
do with the readable.
2) Use a nice, simple reader macro to escape the symbols. Someone
suggested #_ because it's used in MCL. I like that. It's not bad
at all:
(defun foo (bar baz)
(#_createWindow bar (#_size baz)))
Plus, with a reader macro, you can do much more than access the
symbol. It can pretty much expand into whatever you want it to.
Please correct me if my analysis is flawed.
> There is nothing _natural_ about the upcasing reader. It is merely
> the default setting. As long as we know that Franz Inc argues very
> strongly that people "just" have to evaluate a few lines of code to
> get an ANSI Common Lisp from the Modern lisp image, it seems rather
> disingenuous to argue against changing these other default values,
> or as if they cannot be changed as easily as building a new image.
But the other big deal is that the symbol names in the :common-lisp
package are upper case, and so it's kinda hard to deal with the case
issue while leaving those symbols upper case.
I'm actually interested to know what "Modern" programmers really want
in terms of case. I think I'm hapy with:
o readtable-case being set to :invert
o *print-case* being set to :downcase
o writing in all lower-case, all the while _knowing_ that the symbols
in the :common-lisp package are internally uppercase. This means
that:
(intern (format nil "~a-ID" fname))
is safer than
(intern (format nil "~a-~a" fname '#:id))
since the *print-case* re-downcases the uppercasing done by the
reader. Of course, you can do:
(intern (format nil "~a-~a" fname '#:ID))
This way, we write code in lower case (nice), get case sensetivity
(maybe nice, depending on what you want), and can interface well with
foreign libraries.
dave
From: Erik Naggum
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <3182934287817000@naggum.net>
* David Bakhash <·····@alum.mit.edu>
| But the other big deal is that the symbol names in the :common-lisp
| package are upper case, and so it's kinda hard to deal with the case
| issue while leaving those symbols upper case.
Not so. This is not hard. I have a working solution that I
implemented last night that obviates the need for a modern mode
_image_ in Allegro CL. It's now a variable with some support
machinery around it. John thinks so little of changing his code that
I'm sure he won't object to the minor changes this will require in
code that blithely assumes "Modern mode". No changes are required to
code that blithely assumes standard behavior, of course.
#:Erik
--
ALGORITHM: a procedure for solving a mathematical problem in a finite
number of steps that frequently involves repetition of an operation.
ALGOREISM: a procedure for solving an electoral problem in a finite
number of steps that frequently involves repetition of an operation.
Barry Margolin <······@genuity.net> writes:
> Common Lisp). IMHO, the differences aren't overwhelming. One of the
> things that's common in case-sensitive languages is the development of
> conventions for use of case; for instance, in the C community, it's common
> to use ALL_UPPER for macros and all_lower for ordinary functions and
Or even syntactical *rules*: Edinburgh-style Prolog uses the case of
the initial character of an identifier to determine whether it's a
variable or constant, which, imho, is a much more sensible use of
case sensitivity...
--
(espen)
From: Kent M Pitman
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <sfw4s1gowt6.fsf@world.std.com>
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Barry Margolin <······@genuity.net> writes:
>
> > Common Lisp). IMHO, the differences aren't overwhelming. One of the
> > things that's common in case-sensitive languages is the development of
> > conventions for use of case; for instance, in the C community, it's common
> > to use ALL_UPPER for macros and all_lower for ordinary functions and
>
> Or even syntactical *rules*: Edinburgh-style Prolog uses the case of
> the initial character of an identifier to determine whether it's a
> variable or constant, which, imho, is a much more sensible use of
> case sensitivity...
So one can have variables Pi and pi where Pi is 3.1415926535 but pi is
allowed more leeway to vary? That is, do people commonly make variables
and constants by the same name? Particularly in an API, if such concept
is meaningful to Prolog, since it's really interface points we're talking
about, and the question of whether case-folding an interface (modulo
namespaces like Functions and Classes has come up).
It seems plain that the Java issue of
public Foo foo (Foo foo) {...}
is not really a major problem because it could translate to
(defclass foo ...)
(defmethod foo ((foo foo))
(let ((#1=#:result ...))
(declare (type foo #1#))
#1#))
with no concern that the foo's are going to collide, even in spite of the
case folding.
And the case of
public Foo () { ... }
is not a problem because that's really an internal matter that no one can
call anyway, corresponding to initialize-instance or some such.
There is some issue of
public class Foo {
public int FOO = 3;
public int foo (int x) { FOO };
}
which requires both a slot named foo and a function named foo, but
conceptually this corresponds to
(defclass foo () ((foo :initform 3)))
(defmethod foo ((self foo) (x fixnum)) (slot-value self 'foo))
and since the slot is always accessed externally by "." there's little
problem using either (foo some-foo some-fixnum) or (slot-value some-foo 'foo)
from the outside either.
So the question is whether people do a lot of
public class Foo {
public int FOO = 3;
public int Foo = 4;
public int foo = 5;
}
in prolog, because while it's possible in Java, I haven't run into a
lot of it, so I'm not very worried about how to translate it, and it
doesn't seem an undue burden to say that an API-importation macro should
fail saying "automatic case-folding map has failed; you must resolve the
conflict between FOO and Foo". We do the exact same thing of requiring
SHADOWING-IMPORT when symbols collide from two competing packages, and
no one thinks it unreasoanble at that point to have to be clear. Moreover,
in the SHADOWING-IMPORT case, because CL requires that the symbol not be
renamed, there must be a loser. But in an FFI callout to another language,
I don't see why there can't be useful renamings of all of the parts because
they can just be fully renamed, consequently the outcome is even brighter
than we already accept for the symbol-conflict case.
You'll have to substitute prolog syntax for the above since I'm not enough
up on Prolog to be able to do so. Sorry about that.
Kent M Pitman <······@world.std.com> writes:
> So one can have variables Pi and pi where Pi is 3.1415926535 but pi is
> allowed more leeway to vary? That is, do people commonly make variables
> and constants by the same name?
The question is somewhat difficult to answer, since 'variable' and
'constant' are not the same concepts in the context of prolog. Roughly,
they correspond to logical variables and constants.
So if you state 'programmer(Ken)', you basically state that 'everything is
a programmer', and if you state 'programmer(ken)' you state that 'ken is a
programmer'. And if you ask '?-programmer(Ken)' you ask whether 'there
exists a programmer' and prolog will possibly come up with some alternative
solutions for bindings to the variable Ken that will resolve the question.
And if you ask '?-programmer(ken)' you are asking prolog to prove or refute
the claim that 'ken is a programmer'.
To answer your question: Prolog programmers of course only write things
like
mother(x,John) :- father(X,john)
if they really want to confuse people :-)
(I haven't seen too much prolog code the last years, so I can't give
you The Ultimate Prolog Style Guide)
--
(espen)
On Fri, 10 Nov 2000 12:07:01 GMT, Kent M Pitman <······@world.std.com> wrote:
> Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
>
> > Barry Margolin <······@genuity.net> writes:
> >
> > > Common Lisp). IMHO, the differences aren't overwhelming. One of the
> > > things that's common in case-sensitive languages is the development of
> > > conventions for use of case; for instance, in the C community, it's common
> > > to use ALL_UPPER for macros and all_lower for ordinary functions and
> >
> > Or even syntactical *rules*: Edinburgh-style Prolog uses the case of
> > the initial character of an identifier to determine whether it's a
> > variable or constant, which, imho, is a much more sensible use of
> > case sensitivity...
>
> So one can have variables Pi and pi where Pi is 3.1415926535 but pi is
> allowed more leeway to vary?
In Prolog "pi" is a literal symbol. It has no value other than itself. "Pi" is
a (single assignment) variable. There is no notion of a constant variable (?!),
unless things have changed since I last reduced my goals... :-j
__Jason
Kent M Pitman <······@world.std.com> writes:
>
> So one can have variables Pi and pi where Pi is 3.1415926535 but pi
> is allowed more leeway to vary?
In Prolog, pi is an atom which is a concept somewhat analoguous to
Lisp symbols. Such atoms are used in a variety of ways. An atom can be
used as the name of a predicate (which loosely corresponds to a Lisp
function), as the name of a structure (for building structured data),
a symbolic constant, or can even be used as a string.
Atoms must either start with a lowercase letter or be quoted,
e.g. 'This is also an atom'.
Logical variables must start with an uppercase letter. Unlike atoms
which name predicates and other important entities, the particular
names of variables are of lesser importance.
In terms of the mathematcial constant pi, one would define a predicate
with name pi and define it like this:
pi(3.1415926535).
In a program, this can be used to test whether some variable, say
MyVar, is equal to pi:
?- MyVar = 3, pi(MyVar).
Prolog will answer no in this case. The same predicate can also be
used to 'generate' the value of pi:
?- pi(MyVar).
The answer here will be:
MyVar = 3.1415926535
> That is, do people commonly make variables and constants by the same
> name?
The word 'constant' is misleading here (and not used in this context
in Prolog) as we are really talking about atoms, i.e. symbols, and not
about 'const variables'.
> Particularly in an API, if such concept is meaningful to Prolog,
It is meaningful. An API in Prolog would be specified as a set of
predicates, e.g. if lists had no special support in prolog one could
define an API for list processing in this way:
% empty(?list)
% car(+List, -Car)
% cdr(+List, -Cdr)
% cons(+Car, +Cdr, -Cons)
As you can see, I have used both car and Car here, and a Prolog
programmer would not be confused by this. The names of variables are
irrelevant anyway, a client of this API does not use the variable
names, one would construct a pair like this:
?- cons(1, 2, Pair).
And the answer might be:
Pair = cell(1,2)
As you can see, the variable names from the API don't appear in a call
to the predicate.
The above API can be implemented like this:
empty(nil).
cons(Car, Cdr, cell(Car, Cdr)).
car(nil, nil).
car(cell(Car,_), Car).
cdr(nil, nil).
cdr(cell(_,Cdr), Cdr).
The funny thing is that even though I specified the interface with a
certain directionality, e.g. car being called with the first argument
as an in parameter (indicated by the plus sign) and returning a result
via the second argument (indicated by the minus sign), the
implementation supports also calls in the opposite direction, I can
call car to construct a cell with unspecified Cdr:
?- car(List, 1).
List = cell(1,_)
> since it's really interface points we're talking about, and the
> question of whether case-folding an interface (modulo namespaces
> like Functions and Classes has come up).
There are no classes in Prolog. The closest thing to a function is a
predicate. The name of a predicate is an atom, hence starts with a
lower-case letter or is a quoted atom. Prolog is strictly
case-sensitive, the atom foo is distinct from fOO, which is distinct
from 'Foo'.
Joachim
--
work: ········@realtimeint.com (http://www.realtimeint.com)
private: ·······@kraut.bc.ca (http://www.kraut.bc.ca)
From: Barry Margolin
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <fHUO5.53$sG1.704@burlma1-snr2>
In article <··············@wallace.ws.nextra.no>,
Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote:
>Barry Margolin <······@genuity.net> writes:
>
>> Common Lisp). IMHO, the differences aren't overwhelming. One of the
>> things that's common in case-sensitive languages is the development of
>> conventions for use of case; for instance, in the C community, it's common
>> to use ALL_UPPER for macros and all_lower for ordinary functions and
>
>Or even syntactical *rules*: Edinburgh-style Prolog uses the case of
>the initial character of an identifier to determine whether it's a
>variable or constant, which, imho, is a much more sensible use of
>case sensitivity...
I've never really liked that syntax. Many pattern-matching languages use
something like ?<identifier> as the way to mark a pattern variable, and
I think it would have made more sense for Prolog to have used something
like that. In fact, I think some of the Prolog-in-Lisp implementations did
precvisely that.
But I think I can understand why the designers of Edinburgh syntax went
that way. Mathematicians and logicians make heavy use of case distinctions
in their formulas (since just about all their variables are single letters,
all they have to play with is case and font, and they use them
excessively), so they probably felt that this would be more acceptable to
the logic community.
--
Barry Margolin, ······@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.
Barry Margolin <······@genuity.net> writes:
> But I think I can understand why the designers of Edinburgh syntax went
> that way. Mathematicians and logicians make heavy use of case distinctions
> in their formulas (since just about all their variables are single letters,
> all they have to play with is case and font, and they use them
> excessively), so they probably felt that this would be more acceptable to
> the logic community.
And alphabet. The Greek and Hebrew alphabets are nearly exhausted so
the Cyrillic seems to next. The Tate-Shafarevich group is commonly
denoted by the Cyrillic letter Sha. Since most modern languages seem
to take Unicode as alphabet, programmers can start to take advantage
of this also.
Perhaps we need to revive the extended character functions for when we
have to interface with the java class ru.big-bussiness.RussianParser?
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
Lieven Marchand <···@bewoner.dma.be> wrote:
+---------------
| Perhaps we need to revive the extended character functions for when we
| have to interface with the java class ru.big-bussiness.RussianParser?
+---------------
"big-bussiness"? As in, a "large kiss"? ;-} ;-}
[Perhaps. Russians *are* known for occasional displays of exuberant
affection... especially when they've just gotten the better of you
in a business deal.]
-Rob
-----
Rob Warnock, 31-2-510 ····@sgi.com
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
From: Thomas A. Russ
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <ymig0l023mv.fsf@sevak.isi.edu>
John Foderaro <···@unspamx.franz.com> writes:
> Here is what it looks like in my java in lisp syntax language:
>
> (def-java-method init () void
> :public
> (setq notImage (getImage (getCodeBase) "images/not.gif")
> crossImage (getImage (getCodeBase) "images/cross.gif"))
>
> (addMouseListener this))
...
>
> Of course I could try a readtable case of :invert so then I could write
> my lisp code in lower case but my java compiler would have to then work
> to recover the original intented case of all identifiers in the java
> code.
Well, I suppose one potential extension would be to provide a function
called something like:
SYMBOL-PRINT-NAME
which would return the name that would be used by the printer (with due
regard for things like readtable case, *PRINT-CASE*, etc.) to print a
symbol. Using that instead of SYMBOL-NAME would deliver the original
intended case of all identifiers under a readtable case of :INVERT
without requiring any more work on the part of the java compiler code.
> It's a pain. It's a hoop that I shouldn't have to go through.
It doesn't appear that painful. It is just substituting one function
name for another. That hardly seems like a hoop to go through.
> xml is another example. I'd like to be able to use the symbols I see in
> an xml file in my code without having to escape them.
I still don't see how the readtable case options prevent you from doing
this.
> The best way to find a set of examples of why a case sensitive lisp is a
> good idea is to give it to people and let them use it.
This isn't an issue of whether the unescaped input to lisp should be
case sensitive or not. The main issue is why can't this be done in a
way that is compatible with the ANSI standard?
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
···@sevak.isi.edu (Thomas A. Russ) writes:
> John Foderaro <···@unspamx.franz.com> writes:
>
> > Here is what it looks like in my java in lisp syntax language:
> >
> > (def-java-method init () void
> > :public
> > (setq notImage (getImage (getCodeBase) "images/not.gif")
> > crossImage (getImage (getCodeBase) "images/cross.gif"))
> >
> > (addMouseListener this))
> ...
> >
> > Of course I could try a readtable case of :invert so then I could write
> > my lisp code in lower case but my java compiler would have to then work
> > to recover the original intented case of all identifiers in the java
> > code.
>
> Well, I suppose one potential extension would be to provide a function
> called something like:
>
> SYMBOL-PRINT-NAME
(defun symbol-print-name (x)
(type symbol x)
(format nil "~S" (symbol-name x)))
would the above do?
...
> > The best way to find a set of examples of why a case sensitive lisp is a
> > good idea is to give it to people and let them use it.
>
> This isn't an issue of whether the unescaped input to lisp should be
> case sensitive or not. The main issue is why can't this be done in a
> way that is compatible with the ANSI standard?
I believe this we should move this to the new thread. Having
extensive programming experience in Java I can see John's points, but
the above question remains.
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
In article <···············@sevak.isi.edu>, ···@sevak.isi.edu says...
> The main issue is why can't this be done in a
> way that is compatible with the ANSI standard?
The ANSI standard lisp is powerful enough that anything *can* be done.
The question is how easily and naturally it can be done.
Common Lisp can name things that are case insensitive, like html tags,
domain names, files on DOS, and words in certain written languages.
To names things with case sensitive names, like xml tags, C identifiers,
and Java identifiers you have to use escapes to turn off the
normal reader behavior or else change the reader behavior wholesale
with readtable-case and deal with the consequences when
naming Common Lisp functions and variables.
It can be done though. Definitely.
John Foderaro <···@unspamx.franz.com> writes:
> Common Lisp can name things that are case insensitive, like html tags,
> domain names, files on DOS, and words in certain written languages.
>
> To names things with case sensitive names, like xml tags, C identifiers,
> and Java identifiers you have to use escapes to turn off the
> normal reader behavior or else change the reader behavior wholesale
> with readtable-case and deal with the consequences when
> naming Common Lisp functions and variables.
>
> It can be done though. Definitely.
I'm wondering why symbols are considered to be so important. Most of
these things seem to be more suited to strings, or, as in the case of
filenames, objects such as LOGICAL-PATHNAME, which are constructed
from strings.
--
vsync
http://quadium.net/ - last updated Fri Nov 10 03:41:55 PST 2000
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil))
In article <··············@piro.quadium.net>, ·····@quadium.net says...
.
>
> I'm wondering why symbols are considered to be so important
Symbols are important (and much better than strings) because
1. symbols can be compared with a fast eq operation (usually one machine
instruction) compared to using equal for strings.
2. symbols are stored in packages and there is only one
symbol with a given name in a given package.
3. symbols have value cells so you can use them as variables
4. symbols have function bindings so you can call them
as functions.
5. symbols have property lists, a great place to store
information about the symbol.
strings really can't compare to symbols for representing
a foreign object that either has a value or is
a function or both.
John Foderaro <···@unspamx.franz.com> writes:
> strings really can't compare to symbols for representing a foreign
> object that either has a value or is a function or both.
funny you mention this. This is why it's kinda cool that if a (say)
Java application uses the symbol named "list", but Common Lisp also
has a symbol 'list interned, then your current package can still
effectively _use_ the Java library package as-is, but in such a way
that you use #_list when you refer to the Java-imported symbol, and
just plain old list when you refer to the Common Lisp symbol. This is
nice because you can have #_List, #_list, and #_LIST, all coming from
Java, without clashing with the one in the :common-lisp package.
Of course, you'll probably say "well, if I wanted to refer to the
symbol from the Java library, I'd rather have done something like
JavaClass:list, and JavaClass:List." Well, as long as when you import
those symbols from the Java package into your current Lisp package,
you take care to handle the shadowing cases, etc.
But isn't this the whole point? To be able to treat something like a
Java Class file as a library? I mean, Java classes are similar to
packages in some sense. They have their own namespace. Well, what
about the namespace of the packages themselves colliding? That's a
pretty scary thought. But all these problems go away nicely given
something like #_.
dave
so in other words we're replacing the ||'s for escaping by
#_.
My personal goal in this was to make a friendly
and familiar environment for Java programmers so they
would see lisp as a good place to develop Java
programs and eventually see that there's a lot
they can do in Lisp without dealing with
Java.
Let's look at another segment of that TicTacToe program
that's supplied with the java toolkit.
public void mouseReleased(MouseEvent e) {
int x = e.getX();
int y = e.getY();
switch (status()) {
case WIN:
case LOSE:
case STALEMATE:
play(getCodeBase(), "audio/return.au");
white = black = 0;
if (first) {
white |= 1 << (int)(Math.random() * 9);
}
first = !first;
repaint();
return;
}
// Figure out the row/column
Dimension d = getSize();
int c = (x * 3) / d.width;
int r = (y * 3) / d.height;
if (yourMove(c + r * 3)) {
repaint();
switch (status()) {
case WIN:
play(getCodeBase(), "audio/yahoo1.au");
break;
case LOSE:
play(getCodeBase(), "audio/yahoo2.au");
break;
case STALEMATE:
break;
default:
if (myMove()) {
repaint();
switch (status()) {
case WIN:
play(getCodeBase(), "audio/yahoo1.au");
break;
case LOSE:
play(getCodeBase(), "audio/yahoo2.au");
break;
case STALEMATE:
break;
default:
play(getCodeBase(), "audio/ding.au");
}
} else {
play(getCodeBase(), "audio/beep.au");
}
}
} else {
play(getCodeBase(), "audio/beep.au");
}
}
One could translate this to a lisp syntax
using simple rules and end up with:
(def-java-method mouseReleased((e MouseEvent)) void
:public
(let ((x (e.getX))
(y (e.getY)))
(let ((stat (status)))
(if* (or (= stat WIN)
(= stat LOSE)
(= stat STALEMATE))
then (play (getCodeBase) "audio/return.au")
(setq white 0 black 0)
(if* first
then (setq white (logior white
(<< 1 (the int 5)
#+ignore ; can't handle cast
(* (Math.random) 9)))))
(setq first (not first))
(repaint)
(return-from mouseReleased)))
(let* ((d (getSize))
(c (/ (* x 3) d.width))
(r (/ (* y 3) d.height)))
(if* (yourMove (+ c (* r 3)))
then (repaint)
(let ((stat (status)))
(if* (= stat WIN)
then (play (getCodeBase) "audio/yahoo1.au")
elseif (= stat LOSE)
then (play (getCodeBase) "audio/yahoo2.au")
elseif (not (= stat STALEMATE))
then (if* (myMove)
then (repaint)
(setq stat (status))
(if* (= stat WIN)
then (play (getCodeBase)
"audio/yahoo1.au")
elseif (= stat LOSE)
then (play (getCodeBase)
"audio/yahoo2.au")
elseif (not (= stat STALEMATE))
then (play (getCodeBase)
"audio/ding.au"))
else (play (getCodeBase)
"audio/beep.au"))))
else (play (getCodeBase) "audio/beep.au")))))
which is equally readable even to java programmers.
However if the conversion rules now include putting #_ before
every java identifier you get:
(def-java-method #_mouseReleased((#_e #_MouseEvent)) #_void
:public
(let ((#_x (#_e.getX))
(#_y (#_e.getY)))
(let ((#_stat (#_status)))
(if* (or (= #_stat #_WIN)
(= #_stat #_LOSE)
(= #_stat #_STALEMATE))
then (#_play (#_getCodeBase) "audio/return.au")
(setq #_white 0 #_black 0)
(if* #_first
then (setq #_white (logior #_white
(<< 1 (the #_int 5)
(* (#_Math.random) 9)))))
(setq #_first (not #_first))
(#_repaint)
(return-from #_mouseReleased)))
(let* ((#_d (#_getSize))
(#_c (/ (* #_x 3) #_d.width))
(#_r (/ (* #_y 3) #_d.height)))
(if* (#_yourMove (+ #_c (* #_r 3)))
then (#_repaint)
(let ((#_stat (#_status)))
(if* (= #_stat #_WIN)
then (#_play (#_getCodeBase) "audio/yahoo1.au")
elseif (= #_stat #_LOSE)
then (#_play (#_getCodeBase) "audio/yahoo2.au")
elseif (not (= #_stat #_STALEMATE))
then (if* (#_myMove)
then (#_repaint)
(setq #_stat (#_status))
(if* (= #_stat #_WIN)
then (play (#_getCodeBase)
"audio/yahoo1.au")
elseif (= #_stat #_LOSE)
then (#_play (#_getCodeBase)
"audio/yahoo2.au")
elseif (not (= #_stat #_STALEMATE))
then (#_play (#_getCodeBase)
"audio/ding.au"))
else (#_play (#_getCodeBase)
"audio/beep.au"))))
else (#_play (#_getCodeBase) "audio/beep.au")))))
It's would work but I find this considerably uglier.
Who's to say how many java programmers I can bring over
from the dark side into Lisp but telling them that they
just can't use their java names and have to preceed
every java thing with #_ makes it seem less inviting
to me.
John Foderaro <···@unspamx.franz.com> writes:
> else (#_play (#_getCodeBase) "audio/beep.au")))))
>
> It's would work but I find this considerably uglier.
> Who's to say how many java programmers I can bring over
> from the dark side into Lisp but telling them that they
> just can't use their java names and have to preceed
> every java thing with #_ makes it seem less inviting
> to me.
First off, see my posted suggestion on how you might do this without
the #_ and all the while having case sensitivity, and not breaking
with the standard. (Summary: force user to use :invert for
readtable-case, and read in the java symbol tables with the same
rules.
Of course, the user can just as well use :preserve, but then they have
to type their Lisp code in uppercase).
dave
In article <··························@news.dnai.com>, John Foderaro
<···@unspamx.franz.com> wrote:
> so in other words we're replacing the ||'s for escaping by
> #_.
>
> My personal goal in this was to make a friendly
> and familiar environment for Java programmers so they
> would see lisp as a good place to develop Java
> programs and eventually see that there's a lot
> they can do in Lisp without dealing with
> Java.
I don't buy this. This has to be the biggest bullshit
I ever heard. Why would any Java programmer
pay big bucks to develop Java programs with
Lisp syntax?
>
> Let's look at another segment of that TicTacToe program
> that's supplied with the java toolkit.
>
>
> public void mouseReleased(MouseEvent e) {
> int x = e.getX();
> int y = e.getY();
>
> switch (status()) {
> case WIN:
> case LOSE:
> case STALEMATE:
> play(getCodeBase(), "audio/return.au");
> white = black = 0;
> if (first) {
> white |= 1 << (int)(Math.random() * 9);
> }
> first = !first;
> repaint();
> return;
> }
>
> // Figure out the row/column
> Dimension d = getSize();
> int c = (x * 3) / d.width;
> int r = (y * 3) / d.height;
> if (yourMove(c + r * 3)) {
> repaint();
>
> switch (status()) {
> case WIN:
> play(getCodeBase(), "audio/yahoo1.au");
> break;
> case LOSE:
> play(getCodeBase(), "audio/yahoo2.au");
> break;
> case STALEMATE:
> break;
> default:
> if (myMove()) {
> repaint();
> switch (status()) {
> case WIN:
> play(getCodeBase(), "audio/yahoo1.au");
> break;
> case LOSE:
> play(getCodeBase(), "audio/yahoo2.au");
> break;
> case STALEMATE:
> break;
> default:
> play(getCodeBase(), "audio/ding.au");
> }
> } else {
> play(getCodeBase(), "audio/beep.au");
> }
> }
> } else {
> play(getCodeBase(), "audio/beep.au");
> }
> }
>
>
>
> One could translate this to a lisp syntax
> using simple rules and end up with:
>
>
> (def-java-method mouseReleased((e MouseEvent)) void
> :public
>
> (let ((x (e.getX))
> (y (e.getY)))
>
> (let ((stat (status)))
> (if* (or (= stat WIN)
> (= stat LOSE)
> (= stat STALEMATE))
> then (play (getCodeBase) "audio/return.au")
> (setq white 0 black 0)
> (if* first
> then (setq white (logior white
> (<< 1 (the int 5)
> #+ignore ; can't handle cast
> (* (Math.random) 9)))))
>
> (setq first (not first))
>
> (repaint)
> (return-from mouseReleased)))
>
> (let* ((d (getSize))
> (c (/ (* x 3) d.width))
> (r (/ (* y 3) d.height)))
>
> (if* (yourMove (+ c (* r 3)))
> then (repaint)
> (let ((stat (status)))
> (if* (= stat WIN)
> then (play (getCodeBase) "audio/yahoo1.au")
> elseif (= stat LOSE)
> then (play (getCodeBase) "audio/yahoo2.au")
> elseif (not (= stat STALEMATE))
> then (if* (myMove)
> then (repaint)
> (setq stat (status))
> (if* (= stat WIN)
> then (play (getCodeBase)
> "audio/yahoo1.au")
> elseif (= stat LOSE)
> then (play (getCodeBase)
> "audio/yahoo2.au")
> elseif (not (= stat STALEMATE))
> then (play (getCodeBase)
> "audio/ding.au"))
> else (play (getCodeBase)
> "audio/beep.au"))))
> else (play (getCodeBase) "audio/beep.au")))))
>
>
> which is equally readable even to java programmers.
>
> However if the conversion rules now include putting #_ before
> every java identifier you get:
>
You are really making this up. How stupid are Lisp users,
do you think? If Franz wants to break ANSI CL standards
and lock customers into their world, go ahead.
This really pisses me off.
a) why would anybody translate Java code like this to Lisp?
If you want to write Java code, use Java. If
you want to *call* Java, just call Java.
b) Why would anybody use Java identifiers in Lisp code
(see the let stuff) for variables, etc.. See a sane
example below from MCL, how in the real world Lisp code looks that
is tightly calling foreign functionality.
Let's look at some real world code that is written
that way. This is a function from MCL which calls
the Navigation Services (which under MacOS provides
the various file/directory open dialogs):
#$something is a constant
#_something is a call to the MacOS
Where #_navputfile is defined as:
(deftrap-inline "_NavPutFile"
((defaultLocation (:pointer :aedesc))
(reply (:pointer :navreplyrecord))
(dialogOptions (:pointer :navdialogoptions))
(eventProc :pointer) (fileType :ostype) (fileCreator :ostype)
(callBackUD :unsigned-long))
:signed-integer
() )
(defun nav-choose-new-file-dialog (&key directory
(prompt "As...")
(button-string "Save")
(mac-file-type :text) ;; these args are new
(mac-file-creator (application-file-creator *application*))
(cancel-button-string "Cancel")
(window-title "Choose a New FIle")
window-position
name
extended-reply-p ;user requests more details - returns a second value (key-value pair list)
format-query-p ;include popup in dialog for document format selection
&aux retried)
(when (and directory (null name))
(setq name (mac-file-namestring (file-namestring directory)))
(when (eq (length name) 0)(setq name nil)))
(when (or (and directory
(pathname-directory directory) ;; <<<
(setq directory (directory-namestring (full-pathname directory))))
(setq directory (choose-file-default-directory)))
(set-choose-file-default-directory-2 directory)
)
(restoring-dead-keys
(with-aedescs (aedesc)
(rlet ((reply :navreplyrecord)
(options :navdialogoptions))
(set-default-dialog-options
options :location window-position :windowtitle window-title
:actionbuttonlabel button-string :cancelbuttonlabel cancel-button-string
:savedfilename name :message prompt :NavNoTypePopup (not format-query-p))
(setf (pref aedesc :aedesc.descriptortype) #$typefss)
(setf (pref aedesc :aedesc.datahandle) (make-record :fsspec))
(when directory (make-fsspec-from-directory-hdl
(pref aedesc aedesc.datahandle)
directory))
(unwind-protect
(with-foreign-window
(prog () ;hiding-windoids
(put-external-scrap)
again
(let ((result (#_navputfile (if directory aedesc *null-ptr*) ;; defaultlocation
reply
options ;(if (or button-string prompt name) options *null-ptr*) ;dialogoptions
event-wdef ;(or *event-ptr* *null-ptr*) ;*null-ptr* ;eventproc
mac-file-type
mac-file-creator
*my-nav-ud*))) ; callbackud
(let ((foo (check-nav-result result retried)))
(when (and (eq foo :try-again)(null retried))
(setq retried t)
(go again)))
(when (eq result $noerr)
(unless (pref reply navreplyrecord.validrecord)
(throw-cancel :cancel))
(let ((selection (pref reply navreplyrecord.selection))
(result)
(extended-results))
(setq result (parse-doclist selection))
(when result
(set-choose-file-default-directory-2
(if (consp result)(car result) result)))
;;; Extended reply - turn on if user asked for format-query-p
(setq extended-reply-p (or extended-reply-p format-query-p))
(when extended-reply-p
(push (pref reply navreplyrecord.keyScript) extended-results)
(push :keyScript extended-results)
(push :not-implemented-yet extended-results)
(push :file-translation extended-results)
(push (pref reply navreplyrecord.translationNeeded) extended-results)
(push :translation-Needed-p extended-results)
(push (pref reply navreplyrecord.isStationery) extended-results)
(push :stationery-p extended-results)
(push (pref reply navreplyrecord.replacing) extended-results)
(push :replacing-p extended-results))
(if extended-reply-p
(return (values result extended-results))
(return result)))))))
(#_navdisposereply reply))))))
I don't know what Franz is doing, but **I** want portable code that leverages
the ANSI CL standard and portable libraries on top of that. If on a certain
platform, platform specific code has to written (this is absolutely okay),
I want to do it in such a way that I don't have to break the underlying
Common Lisp, in such a way that other software specially has to be
ported to run on this changed Common Lisp. Surely Franz can do whatever
they want with their Lisp, but I would never support such decisions
nor do I think they are technically/philosophically/practically necessary.
More MCL code:
(defmethod view-draw-contents ((self thermometer))
(let* ((pos (view-position self))
(size (view-size self))
(lr (add-points pos size))
(direction (thermometer-direction self)))
(with-pen-saved
(#_PenPat *black-pattern*)
(#_PenMode #$PatCopy)
(rlet ((rect :rect :topLeft pos :botRight lr))
(#_FrameRect rect)
(setq pos (add-points pos ·@(1 1))
lr (subtract-points lr ·@(1 1)))
(setf (rref rect :rect.topLeft) pos
(rref rect :rect.botRight) lr)
(let* ((values (list (thermometer-value self)))
(patterns (list (thermometer-pattern self)))
(max-value (thermometer-max-value self))
(length (thermometer-length self))
(vertical? (eq direction :vertical))
(left (point-h pos))
(right (point-h lr))
(top (point-v pos))
(bottom (point-v lr))
(start (if vertical? bottom left))
(total 0)
pattern patterns-list)
(declare (dynamic-extent values patterns))
(declare (list values patterns))
(declare (fixnum left right top bottom start length))
(if (listp (car values)) (setq values (car values)))
(if (listp (car patterns)) (setq patterns (car patterns)))
(setq patterns-list patterns)
(flet ((limit (value min max)
(max min (min max value))))
(dolist (value values)
(setq pattern (pop patterns-list))
(if (null patterns-list) (setq patterns-list patterns))
(let* ((pixels (limit
(muldiv (incf total value) length max-value)
0 length))
(split (if vertical?
(- bottom pixels)
(+ left pixels))))
(declare (fixnum pixels split))
(if vertical?
(setf (rref rect :rect.topLeft)
(make-point left
(limit split
top
(limit (1- start) top bottom)))
(rref rect :rect.botRight)
(make-point right (limit start top bottom)))
(setf (rref rect :rect.botRight)
(make-point (limit split
(limit (1+ start) left right)
right)
bottom)
(rref rect :rect.topLeft)
(make-point (limit start left right) top)))
(if (listp pattern)
(#_FillCRect rect (car pattern))
(#_FillRect rect pattern))
(setq start split))))
(if vertical?
(setf (rref rect :rect.topLeft) pos
(rref rect :rect.botRight) (make-point right start))
(setf (rref rect :rect.topLeft) (make-point start top)
(rref rect :rect.botRight) lr))
(let ((fill-pattern (thermometer-fill-pattern self)))
(if (consp fill-pattern)
(#_FillCRect rect (car fill-pattern))
(#_FillRect rect fill-pattern))))))))
here comes your funny code:
> (def-java-method #_mouseReleased((#_e #_MouseEvent)) #_void
> :public
>
> (let ((#_x (#_e.getX))
> (#_y (#_e.getY)))
>
> (let ((#_stat (#_status)))
> (if* (or (= #_stat #_WIN)
> (= #_stat #_LOSE)
> (= #_stat #_STALEMATE))
> then (#_play (#_getCodeBase) "audio/return.au")
> (setq #_white 0 #_black 0)
> (if* #_first
> then (setq #_white (logior #_white
> (<< 1 (the #_int 5)
> (* (#_Math.random) 9)))))
>
> (setq #_first (not #_first))
>
> (#_repaint)
> (return-from #_mouseReleased)))
>
> (let* ((#_d (#_getSize))
> (#_c (/ (* #_x 3) #_d.width))
> (#_r (/ (* #_y 3) #_d.height)))
>
> (if* (#_yourMove (+ #_c (* #_r 3)))
> then (#_repaint)
> (let ((#_stat (#_status)))
> (if* (= #_stat #_WIN)
> then (#_play (#_getCodeBase) "audio/yahoo1.au")
> elseif (= #_stat #_LOSE)
> then (#_play (#_getCodeBase) "audio/yahoo2.au")
> elseif (not (= #_stat #_STALEMATE))
> then (if* (#_myMove)
> then (#_repaint)
> (setq #_stat (#_status))
> (if* (= #_stat #_WIN)
> then (play (#_getCodeBase)
> "audio/yahoo1.au")
> elseif (= #_stat #_LOSE)
> then (#_play (#_getCodeBase)
> "audio/yahoo2.au")
> elseif (not (= #_stat #_STALEMATE))
> then (#_play (#_getCodeBase)
> "audio/ding.au"))
> else (#_play (#_getCodeBase)
> "audio/beep.au"))))
> else (#_play (#_getCodeBase) "audio/beep.au")))))
>
>
>
> It's would work but I find this considerably uglier.
> Who's to say how many java programmers I can bring over
> from the dark side into Lisp but telling them that they
> just can't use their java names and have to preceed
> every java thing with #_ makes it seem less inviting
> to me.
>
>
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Have you ever used Java? If so you'll notice right
away that:
1. there is no macro facility. If you're doing exporatory
programming and unsure if you should use arrays or
hash tables in this part of the code then you have to
choose or the other and start hardwiring in that
decision. Macros allow you abstract out that
choice.
2. If you do GUI programming (and that's mainly
what java's used for) you'll find that there are
two protocols (1.0.2 and 1.1). Which should
you code to? The old protocol is is the only
one supported by certain older browsers.
With macros you could write in a protocol
independent fashion and in fact with
a Lisp web server you could generate on the
fly the correct class file based on the
User-Agent string passed by the browser.
3. java is full of protocols where you to build
things, write method handlers and link
the things into other things. This is
tedious and error prone and in Java has
to be done 'by hand'. Definining things
as macros goes a long way to making it easy
to do and eliminate errors.
Frankly if someone put a gun to my head and
said that I had to build an application
in Java I would insist that I use lisp
as the preprocessor for it.
In article <·························@news.dnai.com>, John Foderaro
<···@unspamx.franz.com> wrote:
> Have you ever used Java? If so you'll notice right
> away that:
> 1. there is no macro facility.
Look for extensions to Java in Java that do
a) provide more generic programming or
b) provide source code transformations for Java.
For both there are already libraries available.
Google comes up with some pointers easily.
http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html
or http://www.ai.mit.edu/projects/dynlangs/Talks/java-macros.htm .
> If you're doing exporatory
> programming and unsure if you should use arrays or
> hash tables in this part of the code then you have to
> choose or the other and start hardwiring in that
> decision. Macros allow you abstract out that
> choice.
Well, this is another solution - I'd say.
> 2. If you do GUI programming (and that's mainly
> what java's used for)
Sorry?
> you'll find that there are
> two protocols (1.0.2 and 1.1). Which should
> you code to? The old protocol is is the only
> one supported by certain older browsers.
> With macros you could write in a protocol
> independent fashion and in fact with
> a Lisp web server you could generate on the
> fly the correct class file based on the
> User-Agent string passed by the browser.
I don't think generating Java code (Java code
is not JVM code) "on the fly" serves that much needs.
Especially I don't think a Lisp generating Java is a
good answer to that particular problem.
> 3. java is full of protocols where you to build
> things, write method handlers and link
> the things into other things. This is
> tedious and error prone and in Java has
> to be done 'by hand'. Definining things
> as macros goes a long way to making it easy
> to do and eliminate errors.
But what would you do as a Java-using developer?
Using Lisp to assemble Java code? I would
use Java to assemble Java code.
> Frankly if someone put a gun to my head and
> said that I had to build an application
> in Java I would insist that I use lisp
> as the preprocessor for it.
I don't think that's the way to go. Seems like
Franz is puzzled about the future directions
of Lisp. Seems like they think it's
Java and want to have some transition from Lisp
to Java. I guess this is the main problem,
you should talk to your Java customers whether they
like it. Here on comp.lang.lisp you'll find
the Lisp community - developers who are using
Lisp. A Lisp that maybe is extensively interfaced to the
outside world (including Java) - but not a
perverted sub-standard Lisp.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
The fact that there are many homegrown java preprocessors
around is not surprising nor does it impact my
argument in any way. The only question is whether
any of them are officially recognized as the
java preprocessor and then whether it has sufficient
power to match what you can do in a lisp proprocessor.
> I don't think generating Java code (Java code
> is not JVM code) "on the fly" serves that much needs.
I already mentioned in a few other threads on this
topic that we do indeed generate JVM code
(i.e. java class files) and we don't just write
out Java source code.
> Especially I don't think a Lisp generating Java is a
> good answer to that particular problem.
>
Thank you for your opinion on this matter.
> But what would you do as a Java-using developer?
> Using Lisp to assemble Java code? I would
> use Java to assemble Java code.
huh? byte codes are byte codes no matter who
created them. If you use Lisp as your interface
to the JVM you can issue a single command
have have Lisp build the class files, start
a java vm, run the programm through a set
of tests and then display the results.
It's like a power-console.
> I don't think that's the way to go.
Thank you for your considered opinion on how
we should run our business.
> Seems like
> Franz is puzzled about the future directions
> of Lisp. Seems like they think it's
> Java and want to have some transition from Lisp
> to Java.
From day one the mission of Franz has been to
make Lisp be a tool that people can use
to solve real world problems. It turns out
that these problems nearly always involve
interfacing with objects outside the
Lisp world. This all began 6 years before Franz was
even started when Professor Richard Fateman, faced
with the need to use in lisp algorithms in a large
mathematical library told us, his students, not
to just recode those algorithms in Lisp but
to find some way to make Lisp call the code
in those libraries. That's where the notion
of a foreign function call first arose.
I brought up the Java compilation program not to
try to sell the notion to you, but as example of the kind
of problem that people face when interfacing to
objects with case sensitive names outside of Lisp.
You may not like Java or that people are interfacing
Lisp with Java. But if you are going to talk
about language design you must think about the
wants and needs of other people, ones who don't
think that this is perversion.
In article <··························@news.dnai.com>, John Foderaro
<···@unspamx.franz.com> wrote:
> Thank you for your opinion on this matter.
Good luck.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
"John Foderaro" <···@unspamx.franz.com> wrote in message
·······························@news.dnai.com...
> I already mentioned in a few other threads on this
> topic that we do indeed generate JVM code
> (i.e. java class files) and we don't just write
> out Java source code.
Where is this facility documented?
From: Robert Monfera
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <3A0DEF1C.EF6CA89A@fisec.com>
Rainer Joswig wrote:
> I don't think generating Java code (Java code
> is not JVM code) "on the fly" serves that much needs.
> Especially I don't think a Lisp generating Java is a
> good answer to that particular problem.
I do not know what that particular problem is, but it's indeed a good
idea that
- lisp can generate java bytecodes and call methods
(the JVM is "just" a new CPU and op.system for Lisp)
- lisp can use Swing (in the absence of a competitive, contemporary,
multi-platform CLIM-equivalent)
- lisp is extended with as smooth integration as possible through corba,
com, odbc and other connectivity means.
As I wrote a couple of years ago, I was surprised that Lisp vendors were
not among the first Java vendors, too, given their superior experience
and the relative ease of putting together a Java source compiler (both
bytecode and native), a JVM and a JIT compiler (maybe Steele did not
call his old buddies?!?). This would have helped Common Lisp, too: more
research funds, spotlight on the vendors and their upscale Lisp products
(to which the better java brewers can upgrade), and the use of
platform-independent infrastructure created around java. Lisp vendors
could have offered macros, run-time changes, image dump and a million
other things as competitive advantage. Maybe Franz believes that moving
in this direction is still a good idea.
Robert
From: Duane Rettig
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <4puk1x5qj.fsf@beta.franz.com>
Robert Monfera <·······@fisec.com> writes:
> Rainer Joswig wrote:
>
> > I don't think generating Java code (Java code
> > is not JVM code) "on the fly" serves that much needs.
> > Especially I don't think a Lisp generating Java is a
> > good answer to that particular problem.
>
> I do not know what that particular problem is, but it's indeed a good
> idea that
> - lisp can generate java bytecodes and call methods
> (the JVM is "just" a new CPU and op.system for Lisp)
> - lisp can use Swing (in the absence of a competitive, contemporary,
> multi-platform CLIM-equivalent)
> - lisp is extended with as smooth integration as possible through corba,
> com, odbc and other connectivity means.
I think our philosophy is precisely one of connectivity. I also think
that our current product mix (all in lisp) demonstrates that.
> As I wrote a couple of years ago, I was surprised that Lisp vendors were
> not among the first Java vendors, too, given their superior experience
> and the relative ease of putting together a Java source compiler
I don't have evidence, but I have heard it said that there are at
least a few ex-lisp programmers/developers developing Java. So in
a sense, this is true.
From my point of view, seeing the trouble other lisp vendors have had
when they dilute themselves by trying to vend other languages, I would
consider it dangerous for our long-term stability to try to vend other
languages besides lisp. A better language for us to have vended was
Dylan, which in my opinion is very lisp-like (several years ago, just
before Apple put out the first Technology Release of Dylan and then
dropped it, we went to Apple to look at Dylan, with the potential of
supporting the technology. We were impressed with the technology, but
felt that too much more was still required to break it out to market
than we could afford, and so we declined). Supporting Java itself
would be a step backward for us because it is Java that brings language
implementation closer to lisp by incorporating some lisp technologies,
and so we are content to support interfaces to it, and thus provide
connectivity between lisp and Java (as well as to other things like
OLE and Corba), while waiting for it to evolve further (and closer to
lisp :-).
> (both
> bytecode and native), a JVM and a JIT compiler (maybe Steele did not
> call his old buddies?!?). This would have helped Common Lisp, too: more
> research funds, spotlight on the vendors and their upscale Lisp products
> (to which the better java brewers can upgrade), and the use of
> platform-independent infrastructure created around java. Lisp vendors
> could have offered macros, run-time changes, image dump and a million
> other things as competitive advantage. Maybe Franz believes that moving
> in this direction is still a good idea.
In a sense, where the macrology and other added veneers are actually done
in lisp, yes. I seriously doubt that we will ever touch the Java language
itself.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
In article <·················@fisec.com>, Robert Monfera
<·······@fisec.com> wrote:
> I do not know what that particular problem is, but it's indeed a good
> idea that
> - lisp can generate java bytecodes and call methods
> (the JVM is "just" a new CPU and op.system for Lisp)
> - lisp can use Swing (in the absence of a competitive, contemporary,
> multi-platform CLIM-equivalent)
> - lisp is extended with as smooth integration as possible through corba,
> com, odbc and other connectivity means.
Many would like that. But to "like" something and to
get something is not the same. In the last years
I have seen many people propose great ideas. Less delivery.
It still seems that Lisp programming is hard and not everybody
is capable of actually delivering a Lisp application (instead
of just talking about "features" and "technology"). Either
you give up and lose - or work harder.
Some technology has been provided (CORBA, ODBC, Java connectivity,
HTTP, XML, ...), though.
> call his old buddies?!?). This would have helped Common Lisp, too: more
> research funds, spotlight on the vendors and their upscale Lisp products
> (to which the better java brewers can upgrade), and the use of
> platform-independent infrastructure created around java. Lisp vendors
> could have offered macros, run-time changes, image dump and a million
> other things as competitive advantage. Maybe Franz believes that moving
> in this direction is still a good idea.
Everybody can do what they want. Lucid could invest the money they
earned with Lisp in C++ environments. Apple bought Lisp
technology/wizards and invested heavily in Dylan. Harlequin invested
in Dylan. CMU gave up CL and went the Dylan route, too. Let other
Lisp vendors invest heavily in Java/whatever and see what happens.
Good luck!
Actually what I see as the winning strategy for Lisp vendors is to
serve the needs of **Lisp** application developers. By improving
Lisp. By helping them to succeed. By leveraging Lisp standards.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
From: Duane Rettig
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <4lmupx56f.fsf@beta.franz.com>
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <·················@fisec.com>, Robert Monfera
> <·······@fisec.com> wrote:
>
> > call his old buddies?!?). This would have helped Common Lisp, too: more
> > research funds, spotlight on the vendors and their upscale Lisp products
> > (to which the better java brewers can upgrade), and the use of
> > platform-independent infrastructure created around java. Lisp vendors
> > could have offered macros, run-time changes, image dump and a million
> > other things as competitive advantage. Maybe Franz believes that moving
> > in this direction is still a good idea.
>
> Everybody can do what they want. Lucid could invest the money they
> earned with Lisp in C++ environments. Apple bought Lisp
> technology/wizards and invested heavily in Dylan. Harlequin invested
> in Dylan. CMU gave up CL and went the Dylan route, too. Let other
> Lisp vendors invest heavily in Java/whatever and see what happens.
> Good luck!
I agree with this, and answered similarly in another article. I
don't think you'll see Franz Inc. doing this.
> Actually what I see as the winning strategy for Lisp vendors is to
> serve the needs of **Lisp** application developers. By improving
> Lisp. By helping them to succeed. By leveraging Lisp standards.
Yes, I agree with this as well. However, we see very few Lisp
developers that are able to work _only_ on Lisp; there is usually
some interfacing to other languages that is necessary. So we work
on two fronts; improve the Lisp, and make sure it can interface to
the other languages that the Lisp developers must deal with. This
helps to help the Lisp developers to be more successful.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Barry Margolin
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <i3_P5.12$h23.534@burlma1-snr2>
In article <····························@news.is-europe.net>,
Rainer Joswig <······@corporate-world.lisp.de> wrote:
>I don't buy this. This has to be the biggest bullshit
>I ever heard. Why would any Java programmer
>pay big bucks to develop Java programs with
>Lisp syntax?
I don't think Java programmers are the target audience. I think the target
is Lisp programmers who want to write applications and libraries whose
target environment is the JVM, e.g. web applets. These applications need
to be able to call or be called by other Java routines.
And the goal of all this case-hacking is to avoid having to write lots of
FFI definitions that translate between Lisp symbols and external names. I
guess the reason that they don't want explicit translators is because with
For languages like C and Pascal, FFI definitions are also needed to contain
the parameter prototypes, so that types will be translated appropriately;
but since Java is based on manifest types like Lisp is, this isn't
necessary.
--
Barry Margolin, ······@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.
Barry Margolin <······@genuity.net> writes:
> In article <····························@news.is-europe.net>,
> Rainer Joswig <······@corporate-world.lisp.de> wrote:
> >I don't buy this. This has to be the biggest bullshit I ever
> >heard. Why would any Java programmer pay big bucks to develop Java
> >programs with Lisp syntax?
>
> I don't think Java programmers are the target audience.
Sorry, but John specifically wrote:
My personal goal in this was to make a friendly and familiar
environment for Java programmers so they would see lisp as a good
place (...)
(...)
Who's to say how many java programmers I can bring over from the
dark side into Lisp (...)
From: Robert Monfera
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <3A0D7A88.C3CD999@fisec.com>
Let me guess, it's tic-tac-toe in Intercal, right?
Robert
John Foderaro wrote:
> (def-java-method #_mouseReleased((#_e #_MouseEvent)) #_void
> :public
>
> (let ((#_x (#_e.getX))
> (#_y (#_e.getY)))
>
> (let ((#_stat (#_status)))
> (if* (or (= #_stat #_WIN)
> (= #_stat #_LOSE)
> (= #_stat #_STALEMATE))
> then (#_play (#_getCodeBase) "audio/return.au")
> (setq #_white 0 #_black 0)
> (if* #_first
> then (setq #_white (logior #_white
> (<< 1 (the #_int 5)
> (* (#_Math.random)
...
"John Foderaro" <···@unspamx.franz.com> wrote
> My personal goal in this was to make a friendly
> and familiar environment for Java programmers so they
> would see lisp as a good place to develop Java
> programs and eventually see that there's a lot
> they can do in Lisp without dealing with
> Java.
Uh?
This is really confusing and scaring.
A leading Lisp vendor that first seems to not care much about the standard,
and then says he wants to "make a friendly and familiar environment for Java
programmers".
Is this really what you mean? Do you intend to follow the Microsoft way with
C# and the multiple assorted languages based on top of a common VM?
Marc Battyani
In article <············@reader1.fr.uu.net>, ·············@fractalconcept.com says...
> A leading Lisp vendor that first seems to not care much about the standard,
> and then says he wants to "make a friendly and familiar environment for Java
> programmers".
>
First of all, the remark about 'seems to not care much about the standard'
makes me feel that I shouldn't even write anything on this forum since it just
seems to ignored.
As for the second part of your comment let me ask you, how are we going
to grow the Lisp community without stealing people from other
communities? There aren't that many places where Common Lisp is
taught as the first programming language. Virtually all programmers
coming to Lisp are going to have experience in some other
programming language. Java is often the first programming language.
I want to bring those Java programmers over to Lisp and make
them realize the power of programs writing programs. I'm not
out to write a super java development environment, just something
that will make Java programmers understand how bankrupt
the Java language really is.
"John Foderaro" <···@unspamx.franz.com> wrote in message
·······························@news.dnai.com...
> As for the second part of your comment let me ask you, how are we going
> to grow the Lisp community without stealing people from other
> communities?
I'd rather try to attract people by success stories. As you've noticed, Lisp
is, by far, the best way to make Internet applications. And this can attract
people. Look for instance at your htmlgen macro vs the alternatives in other
languages. Lisp truly shines when it comes to complex applications and
programs dynamically writing programs.
I think this is the way you try to do it with allegroserve and your xml/html
parser.
I've shown htmlgen to Java developpers (using JServ) and they were quite
impressed at the generated code.
>There aren't that many places where Common Lisp is
> taught as the first programming language.
I know this (I'm even teaching Lisp to students of an elementary school).
Java is spreading.
> Virtually all programmers
> coming to Lisp are going to have experience in some other
> programming language. Java is often the first programming language.
> I want to bring those Java programmers over to Lisp and make
> them realize the power of programs writing programs. I'm not
> out to write a super java development environment, just something
> that will make Java programmers understand how bankrupt
> the Java language really is.
That way I can understand it. And I agree with you, Java sucks. I had to do
some Java and was badly missing macros, closures, multiple dispatch etc...
Marc Battyani
John Foderaro wrote:
> It's would work but I find this considerably uglier.
> Who's to say how many java programmers I can bring over
> from the dark side into Lisp but telling them that they
> just can't use their java names and have to preceed
> every java thing with #_ makes it seem less inviting
> to me.
The ugliness quotient drops considerably if you don't #_ local variables
(and you shouldn't need to unless you need to explicitly convert between
Java values and Lisp values):
(def-java-method #_mouseReleased((#_e #_MouseEvent)) #_void
:public
(let ((x (#_e.getX))
(y (#_e.getY)))
(let ((stat (#_status)))
(if* (or (= stat #_WIN)
(= stat #_LOSE)
(= stat #_STALEMATE))
then (#_play (#_getCodeBase) "audio/return.au")
(setq #_white 0 #_black 0)
(if* #_first
then (setq #_white (logior #_white
(<< 1 (the int 5)
(* (#_Math.random)
9)))))
(setq #_first (not #_first))
(#_repaint)
(return-from #_mouseReleased)))
(let* ((#_d (#_getSize))
(c (/ (* x 3) #_d.width))
(r (/ (* y 3) #_d.height)))
(if* (#_yourMove (+ c (* r 3)))
then (#_repaint)
(let ((stat (#_status)))
(if* (= stat #_WIN)
then (#_play (#_getCodeBase) "audio/yahoo1.au")
elseif (= stat #_LOSE)
then (#_play (#_getCodeBase) "audio/yahoo2.au")
elseif (not (= stat #_STALEMATE))
then (if* (#_myMove)
then (#_repaint)
(setq stat (#_status))
(if* (= stat #_WIN)
then (play (#_getCodeBase)
"audio/yahoo1.au")
elseif (= stat #_LOSE)
then (#_play (#_getCodeBase)
"audio/yahoo2.au")
elseif (not (= stat #_STALEMATE))
then (#_play (#_getCodeBase)
"audio/ding.au"))
else (#_play (#_getCodeBase)
"audio/beep.au"))))
else (#_play (#_getCodeBase) "audio/beep.au")))))
--
Remove obvious stuff to e-mail me.
Bob Bane
From: Tim Bradshaw
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <nkjwve7kiry.fsf@tfeb.org>
vsync <·····@quadium.net> writes:
> I'm wondering why symbols are considered to be so important. Most of
> these things seem to be more suited to strings, or, as in the case of
> filenames, objects such as LOGICAL-PATHNAME, which are constructed
> from strings.
>
I disagree. I much prefer to write
(:html (:head (:title x))
(:body (:h1 x)
(:p "this is a para")))
to something like:
("html" ("head" ("title" x)) ...)
The former case makes all the right distinctions -- elements of the
language (here html) are represented by symbols (keyword symbols in
this case), with strings for literal data and (here) non-keyword
symbols for variables (and in fact general Lisp expressions). This
just smells right to me and I guess it does to most Lisp people, in a
way that the stringy case doesn't.
--tim
(incidentally my htout package which generates HTML from this stuff
can be found at http:// www.tfeb.org/lisp/hax.html#HTOUT. It's pretty
trivial).
From: Sunil Mishra
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <3A1032BC.70808@everest.com>
Tim Bradshaw wrote:
> vsync <·····@quadium.net> writes:
>
>
>> I'm wondering why symbols are considered to be so important. Most of
>> these things seem to be more suited to strings, or, as in the case of
>> filenames, objects such as LOGICAL-PATHNAME, which are constructed
>> from strings.
>>
>
>
> I disagree. I much prefer to write
>
> (:html (:head (:title x))
> (:body (:h1 x)
> (:p "this is a para")))
>
> to something like:
>
> ("html" ("head" ("title" x)) ...)
>
> The former case makes all the right distinctions -- elements of the
> language (here html) are represented by symbols (keyword symbols in
> this case), with strings for literal data and (here) non-keyword
> symbols for variables (and in fact general Lisp expressions). This
> just smells right to me and I guess it does to most Lisp people, in a
> way that the stringy case doesn't.
>
> --tim
>
> (incidentally my htout package which generates HTML from this stuff
> can be found at http:// www.tfeb.org/lisp/hax.html#HTOUT. It's pretty
> trivial).
But arguably your representation is not extensible. You cannot attach
additional information to your tags (other than property lists, which
historically tend to land programs and programmers in hot water). You
cannot effectively adapt your printer to xml, because namespaces turn
out to be somewhat tricky to do right. I would use neither symbols nor
strings for representing html tags, but perhaps some data structure that
is explicitly typed as an xml element. Even if symbols are a lot more
convenient.
As to why symbols are important... IMHO their primary calling is to name
lisp objects. They are glorified canonical strings with the ability to
name objects and values. Which gives us some important abstractions for
talking about code and data. And sometimes in our programs whether the
object corresponding to a particular name actually exists is sometimes
immaterial. This property of symbols is used extensively in logic, and I
think is a great source of strength for common lisp. (I'm sure this
correspondence is not coincidental.) Perhaps that is the sense in which
Tim meant to use HTML tags, but then the critical problem (again, IMHO)
is that there is an implicit assumption regarding the equality of the
name of the html tag, and the symbol that he's using to represent the
html tag. While I think the equality should be thought of as accidental,
and if anything interesting must be done with the symbol then there
ought to be some sense of a "real" object behind it.
Sunil
From: Tim Bradshaw
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <nkjaeb3u25k.fsf@tfeb.org>
Sunil Mishra <············@everest.com> writes:
>
> But arguably your representation is not extensible. You cannot attach
> additional information to your tags (other than property lists, which
> historically tend to land programs and programmers in hot water).
I don't understand this. Even my trivial system adds information to
tags -- it needs to know about empty elements for instance. It does
this by using the symbol as a key into a hashtable. Symbols make
really *good* keys for information like this: that's kind of what
they're for.
> You
> cannot effectively adapt your printer to xml, because namespaces turn
> out to be somewhat tricky to do right. I would use neither symbols nor
> strings for representing html tags, but perhaps some data structure that
> is explicitly typed as an xml element. Even if symbols are a lot more
> convenient.
Well, I deliberately was not aiming at generalisation, and convenience
is quite a significant win if you want to type something in. You
could make an almost idential argument about Common Lisp source code,
yet symbols seem to work quite well!
> but then the critical problem (again, IMHO)
> is that there is an implicit assumption regarding the equality of the
> name of the html tag, and the symbol that he's using to represent the
> html tag. While I think the equality should be thought of as accidental,
> and if anything interesting must be done with the symbol then there
> ought to be some sense of a "real" object behind it.
>
Well, sure. That's how it works in Lisp -- you type (defun x ...) and
the system looks up the function definition of DEFUN and finds a
macro, and so on.
In fact there's a significant trick here: the macro gets *the source
form* with symbols and stuff, not some form with everything replaced
by `real objects', and this is crucial, because it means that the
macro gets to look at source about which only a tiny commitment has
been made as to what it means: there's syntax there but no semantics t
speak of. So the *macro* can decide what it means. This is great
because it means that you can extend the language to do all this
wonderul stuff. But this whole trick leans on using these cheap and
nasty things like symbols and conses: they are how you avoid making
too much commitment.
It's not really that my representation of HTML is not extensible, it's
that Lisp is sufficiently extensible that I can seamlessly and almost
trivially add my HTML representation to it. And this low-commitment
trick is important to making that possible, and symbols are important
to that.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> vsync <·····@quadium.net> writes:
>
> > I'm wondering why symbols are considered to be so important. Most of
> > these things seem to be more suited to strings, or, as in the case of
> > filenames, objects such as LOGICAL-PATHNAME, which are constructed
> > from strings.
> >
>
> I disagree. I much prefer to write
>
> (:html (:head (:title x))
> (:body (:h1 x)
> (:p "this is a para")))
>
> to something like:
>
> ("html" ("head" ("title" x)) ...)
Oh. Yes. So do I, actually. But in the cases mentioned in the
article I was replying to, such as accessing Java identifiers, it
doesn't seem to make that much sense to use the Lisp namespace to
access Java things. And for cases involving arbitrary user input (or
input from files, which is the same thing, really), I shudder at the
security implications of using READ.
I like symbols. Symbols rock. I just like to use them inside the
Lisp world, and use strings to talk to the other world.
--
vsync
http://quadium.net/ - last updated Mon Nov 13 01:46:23 PST 2000
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil))
From: Tim Bradshaw
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <nkjzoj2svm4.fsf@tfeb.org>
vsync <·····@quadium.net> writes:
>
> Oh. Yes. So do I, actually. But in the cases mentioned in the
> article I was replying to, such as accessing Java identifiers, it
> doesn't seem to make that much sense to use the Lisp namespace to
> access Java things. And for cases involving arbitrary user input (or
> input from files, which is the same thing, really), I shudder at the
> security implications of using READ.
>
I'm not sure I see what security implications you mean. Obviously you
want to control things like the readtable and *read-eval* and the
other readtable control variables, and you need to check that what you
read is what you expect by walking over it, but I don;t think it's
unsafe as such. There was a thread a while ago where I posted some
(rough) code that did this.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> I'm not sure I see what security implications you mean. Obviously you
> want to control things like the readtable and *read-eval* and the
> other readtable control variables, and you need to check that what you
> read is what you expect by walking over it, but I don;t think it's
> unsafe as such. There was a thread a while ago where I posted some
> (rough) code that did this.
Yes, I'm also puzzled every time this comes up. Of course you need to
turn off *read-eval*, and of course you need to do things like not
funcalling anything you haven't authorized, but otherwise I think that
using READ on user-supplied data is generally both safe and a good idea.
I'd even say that you're *much* less likely to shoot yourself in your
foot than if you'd worked with input parsing in Perl or C.
--
(espen)
From: Kent M Pitman
Subject: Using READ as an internet firewall [was Re: What case problem ...]
Date:
Message-ID: <sfwlmumr76r.fsf_-_@world.std.com>
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Tim Bradshaw <···@tfeb.org> writes:
>
> > I'm not sure I see what security implications you mean. Obviously you
> > want to control things like the readtable and *read-eval* and the
> > other readtable control variables, and you need to check that what you
> > read is what you expect by walking over it, but I don;t think it's
> > unsafe as such. There was a thread a while ago where I posted some
> > (rough) code that did this.
>
> Yes, I'm also puzzled every time this comes up. Of course you need to
> turn off *read-eval*, and of course you need to do things like not
> funcalling anything you haven't authorized, but otherwise I think that
> using READ on user-supplied data is generally both safe and a good idea.
>
> I'd even say that you're *much* less likely to shoot yourself in your
> foot than if you'd worked with input parsing in Perl or C.
Well, mostly I'd agree, but what's a newsgroup without some back and forth?
It still leaves you in the position of having to utterly trust your
vendor or to audit their code. Consider that many security breaches
are said to come from data overruns in fixed-length strings during
parsing that are exploited to write new program into interesting
places. Lisp's memory model is different, and that may make it harder
to exploit such overruns, so that's good. But still you could injure
a system if there was an overrun. Lisp also doesn't define
fixed-length inputs so in principle there should be no problem, but
auditing that may be tough compared to auditing your own code that
does character-by-character analysis. Then again, there's still a
question of whether you believe your compiler and runtime systems will
properly support you, but you can at least do statistical testing of
that, and maybe that's equivalent to worrying about whether the
implementors did READ right.
I don't know. I always get perhaps-inappropriately nervous when I
need to trust a bigger-than-necessary hammer to do security for me.
It's one reason I don't put Windows NT boxes straight onto the net. I
know they are intended for that, but there are so many opportunities
to lose that I prefer Linux, which somehow I envision as not doing me
any unasked favors. Somewaht I model READ as conceptually equivalent
to Microsoft ... though without the monopoly.
--Kent
(now somewhat waiting for someone who isn't clear on the intent
and obvious conceptual limitations of an analogy to fire off
a probably-overzealous defense of READ's sacred honor ...
maybe I deserve that, dunno. Internet security is a very personal
issue to a lot of people--who's to say who's right other than the
person whose job it is to put their name on the line in any given
case and say "I'll take the blame if I'm wrong"?)
From: Erik Naggum
Subject: Re: Using READ as an internet firewall [was Re: What case problem ...]
Date:
Message-ID: <3183202924198672@naggum.net>
* Kent M Pitman <······@world.std.com>
| It still leaves you in the position of having to utterly trust your
| vendor or to audit their code.
I think it depends a little on how you collect the input. I do not
see a problem with collecting your own input, making sure it's sane,
and then calling read. I do see a problem with a protocol that uses
read directly, as it has no control over when character consumption
terminates. A simple syntax error like omitting a closing delimiter
could cause the reader to want to gobble up the rest of the input.
| Consider that many security breaches are said to come from data
| overruns in fixed-length strings during parsing that are exploited to
| write new program into interesting places. Lisp's memory model is
| different, and that may make it harder to exploit such overruns, so
| that's good.
A simple abuse of a naive implementation would simply transmit so much
data to a Lisp process that it would consume all system memory. There
is no shortage of large and expensive objects that take little space
in the data stream, like uninterned symbols, pathnames, etc. This
would be more of a denial of service attack, but blowing up the memory
consumption of a Lisp process is quite serious if it's intended to run
for a long time instead of die and restart all the time.
#:Erik
--
ALGORITHM: a procedure for solving a mathematical problem in a finite
number of steps that frequently involves repetition of an operation.
ALGOREISM: a procedure for solving an electoral problem in a finite
number of steps that frequently involves repetition of an operation.
Erik Naggum <····@naggum.net> writes:
> I think it depends a little on how you collect the input. I do
> not see a problem with collecting your own input, making sure it's
> sane, and then calling read. I do see a problem with a protocol
> that uses read directly, as it has no control over when character
> consumption terminates. A simple syntax error like omitting a
> closing delimiter could cause the reader to want to gobble up the
> rest of the input.
Could you suggest something other than the obvious repeated READ-CHAR
to make totally sure that the data itself is fixed? i.e. what else
can you do except to make sure that the data itself is bounded
size-wise?
Also, as for running EVAL on the code (the most dangerous part of the
whole thing), how would one insure that a program which just infinitly
consed, such as:
(loop for i upfrom most-positive-fixnum collect (expt i i))
of course, this one would fail under most implementations because of
math ops of such large numbers (most Lisps actually can't just use up
all of virtual memory for arbitrarily large numbers, unfortunately --
not even CLISP which has the reputation as being the best with respect
to bignums).
Surely, one could figure out how to make any Lisp deadlock, and so
unless you put a WITH-TIMEOUT around that evaluation, you're screwed.
I'd like to know about ways to protect the system from arbitrary
consing. In a way, where Lisp implementations barf at huge numbers
could be viewed as a feature (as in this case, a security feature), I
wouldn't want to count on this for running code securely.
dave
Kent M Pitman <······@world.std.com> writes:
> (now somewhat waiting for someone who isn't clear on the intent
> and obvious conceptual limitations of an analogy to fire off
> a probably-overzealous defense of READ's sacred honor ...
> maybe I deserve that, dunno. Internet security is a very personal
> issue to a lot of people--who's to say who's right other than the
> person whose job it is to put their name on the line in any given
> case and say "I'll take the blame if I'm wrong"?)
Okay. Here's some back-and-fourth.
A while back, I posted this exact question. Tim and I (and others)
discussed the possibility of building safety into CL for applications
such as reading CL code off a wire (or, in general, from a stream).
Writing very basic code-walkers for CL is very easy. If your
application is to just filter out symbols and dangerous things, and
to allow some subset of the language (as well as some very basic
limitations, like no defpackage, find-symbol, intern, import, etc.),
then you can go quite a ways withOUT writing an external language,
reader, parser, compiler, etc. The tools are right there in front of
us:
with-standard-io-syntax
*read-eval*
defpackage & make-package
unintern
find-symbol
read
eval
compile
funcall
lambda
(setf readtable)
set-macro-character
these are _exactly_ the tools I want to have for writing a
mini-language, a code-checker, etc. I had the idea to do this
originally for a client/server application, trying to do everything in
Common Lisp. Now that I've written a more serious package for such
things, I am _sure_ that it's the right thing for many applications --
basically, any time you're reading, and evaluating user code. You
send up saving a lot of work on the language design, and just have to
put some thought into the code checking facilities, a beefed-up
reader, etc.
READ is definitely a heavy-duty tool. But it works, and it is
specifically designed to read Lisp objects, which is what Lisp
programmers work with. If you limit these objects to constant
literals for pure data storage, and write special packages for your
execution code, then you can get pretty far.
I'll try to post my latest code if I can get clearance from the
company I'm working for now. It's not too far off from Tim's code
that was posted last time we discussed this, and (of course)
contains a code walker. But it's intended for serious use.
Writing a program to read safe lisp, and barf if it's not is an
educational excercise, and worth doing, in case anyone's just bored
and wants a fun challenge.
dave
From: Matt Curtin
Subject: Re: Using READ as an internet firewall [was Re: What case problem ...]
Date:
Message-ID: <86r9478zq3.fsf@animal.interhack.net>
>>>>> "David" == David Bakhash <·····@alum.mit.edu> writes:
David> If your application is to just filter out symbols and
David> dangerous things, and to allow some subset of the language
David> (as well as some very basic limitations, like no defpackage,
David> find-symbol, intern, import, etc.), then you can go quite a
David> ways withOUT writing an external language, reader, parser,
David> compiler, etc.
The problem with this, of course, is that "filtering out bad stuff"
violates the principle of Least Privilege, i.e., instead of
disallowing the things that you don't want, it should allow nothing by
default and allow only the things that you do want and whose affect on
the system you've already analyzed.
Because Lisp is not subject to the sort of stupidity inherent in
"lesser" languages[1], I agree that Lisp is a much more reasonable
choice for this sort of application than many other languages. (Of
course, there are other languages that are not subject to fixed-length
buffers. Perl also provides a very nice feature in its ability to
identify data which are "tainted"... Obviously, the case for Lisp
needs to include lots of the other good stuff which makes Lisp so
incredibly useful.)
Using more capable (and safer) tools doesn't eliminate our need to
move with care or to adhere to good security design principles; they
merely help us avoid stupid implementation mistakes.
Footnotes:
[1] Assuming that the implementation itself isn't subject to the
problem, of course, which might be quite a lot to assume if you
can't see and audit the implementation yourself.
--
Matt Curtin, Founder Interhack Corporation http://www.interhack.net/
"Building the Internet, Securely." research | development | consulting
From: Erik Naggum
Subject: Re: Using READ as an internet firewall [was Re: What case problem ...]
Date:
Message-ID: <3183679945164742@naggum.net>
* Matt Curtin
| The problem with this, of course, is that "filtering out bad stuff"
| violates the principle of Least Privilege, i.e., instead of
| disallowing the things that you don't want, it should allow nothing by
| default and allow only the things that you do want and whose affect on
| the system you've already analyzed.
But this is actually pretty easy to accomplish. Just bind *readtable*
to a copy of the standard readtable and go modify it to your heart's
content -- you now have full control over everything the reader does.
I would suggest you make # a constituent character unless you _really_
need dispatching while reading your data.
| Using more capable (and safer) tools doesn't eliminate our need to
| move with care or to adhere to good security design principles; they
| merely help us avoid stupid implementation mistakes.
I agree, except I think "merely" is an understatement.
| Footnotes:
| [1] Assuming that the implementation itself isn't subject to the
| problem, of course, which might be quite a lot to assume if you
| can't see and audit the implementation yourself.
Not really. (1) You have to be extraordinarily clever to get a C/C++
implementation exactly right, because the designs of those languages
make it hard to implement anything intelligently and safely -- you
have to think in another language, such as Lisp, to think of all the
things you have to take care of. Take a look at the string class in
C++, just how much _more_ it does than the old char*. (2) If you use
features in the language that are used for many other things, too, you
get community debugging experience for free. This is very much unlike
the kinds of things people do in C/C++, where safety and security are
_not_ the norm, and in many cases, morons with one keyboard too many
think they may sacrifice some efficiency if they don't write their own
code, which will never be exposed to community debugging experiences.
Having a data reader _in_ the language that the whole system depends
on for its proper operation means you would find bugs so much sooner.
#:Erik
--
ALGORITHM: a procedure for solving a mathematical problem in a finite
number of steps that frequently involves repetition of an operation.
ALGOREISM: a procedure for solving an electoral problem in a finite
number of steps that frequently involves repetition of an operation.
Erik Naggum <····@naggum.net> writes:
> * Matt Curtin
> | The problem with this, of course, is that "filtering out bad stuff"
> | violates the principle of Least Privilege, i.e., instead of
> | disallowing the things that you don't want, it should allow nothing by
> | default and allow only the things that you do want and whose affect on
> | the system you've already analyzed.
I don't know if I can agree with you on this. I tell the reader what
is acceptable, and it merily goes on its way. It essentially has a
table of things it wants to see; things not there cause conditions in
the system. So I'm not sure if what I'm doing really violates this
principle.
The reader might ``read'' garbage, but so would any tokenizer. It
just makes sure that what it just read is valid. I don't see anything
wrong with that.
> But this is actually pretty easy to accomplish. Just bind *readtable*
> to a copy of the standard readtable and go modify it to your heart's
> content -- you now have full control over everything the reader does.
> I would suggest you make # a constituent character unless you _really_
> need dispatching while reading your data.
This is the primary thing I've done, and I don't see another way. Of
course, I definitely do want to read in arrays and other data, so I
leave the # dispatch macro character alone. I do add some syntax
though, and definitely deactivate *read-eval*, which is the most
obvious security hole.
> | Footnotes:
> | [1] Assuming that the implementation itself isn't subject to the
> | problem, of course, which might be quite a lot to assume if you
> | can't see and audit the implementation yourself.
It's like this. You read a form, or a collection of forms. You do
this safely, with *package* and *readtable* bound. You walk through
code. There is definitely an issue here, though, regarding READ. I
call READ, and therein lies the main issue: what if they just give you
an essentially non-terminating integer? (a simple way to hurt a system
reading input, say over a socket). This is a serious problem that I
havn't figured how how to solve just yet. But aside from this,
everything is pretty simple and straight-forward (granted, once you've
read the docs on packages a few hundred times).
The ability to call EVAL in Lisp is a dream. I know it can be done in
other languages, but it's not the same (e.g. in Perl). The
transformation, and the simplicity in walking the code make CL nice.
I'm sure this is easier in Scheme, especially considering that they
don't have the dozens of special operators that we do.
One thing I'd like to do is to leave my box listening on a text
socket, let random people connect (up to a certain number), and see if
anyone can crash my system with less than a 1 Mb data stream. I'll
publish the vast majority of Common Lisp as readable and executable,
and even EVAL their code. And while, in that code, they can compute
just about anything, and have access to arrays, macros, DEF*** for
almost all ***, I'd be surprised if I couldn't protect the system from
bad stuff (i.e. massive consing, evil symbol, package, and reader
hacks, etc.).
The only issue here is to be as non-restrictive as possible on what
you allow, but at the same time not allow people to destroy
everything.
The reason I feel good about this sort of thing is that Common Lisp
has an API for the very way it read and evaluates code, and I don't
want to reproduce a single bit of that effort. I almost feel like I'm
cheating.
dave
From: Pierre R. Mai
Subject: Re: Using READ as an internet firewall [was Re: What case problem ...]
Date:
Message-ID: <87lmueeqzt.fsf@orion.bln.pmsf.de>
David Bakhash <·····@alum.mit.edu> writes:
> It's like this. You read a form, or a collection of forms. You do
> this safely, with *package* and *readtable* bound. You walk through
> code. There is definitely an issue here, though, regarding READ. I
> call READ, and therein lies the main issue: what if they just give you
> an essentially non-terminating integer? (a simple way to hurt a system
> reading input, say over a socket). This is a serious problem that I
> havn't figured how how to solve just yet. But aside from this,
> everything is pretty simple and straight-forward (granted, once you've
> read the docs on packages a few hundred times).
Since finite input strings will to the best of my knowledge not
generate anything on read that has infinite (better non-bounded)
memory usage, reading from the socket into finite-sized buffers,
keeping track on memory usage, and then using read-from-string should
catch at least the most obious DoS attacks[1].
Another approach might be based on keeping track of the number of
characters read through read-char (e.g. by putting advice on
read-char/unread-char, or by using a suitably extended gray stream)
and bailing out if this exceeds some limit.
Regs, Pierre.
Footnotes:
[1] OTOH the only way to secure a system connected to an open,
untrusted network like the internet against all forms of DoS
Attacks is to not offer a service in the first place.
As long as the failure modes are all safe, DoS attacks are "easy"
to take into account in your risk management strategy, since
their effects are fairly easy to assess. That doesn't mean that
you shouldn't take care to reasonably minimize the chances of
them occurring, though.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Pekka P. Pirinen
Subject: Re: Using READ as an internet firewall [was Re: What case problem ...]
Date:
Message-ID: <ix4s11v61n.fsf@harlequin.co.uk>
"Pierre R. Mai" <····@acm.org> writes:
> Since finite input strings will to the best of my knowledge not
> generate anything on read that has infinite (better non-bounded)
> memory usage, reading from the socket into finite-sized buffers,
> keeping track on memory usage, and then using read-from-string should
> catch at least the most obious DoS attacks[1].
Yes, but since he's proposing to offer an eval-server for a
Turing-complete language, there's no way all unbounded computations
can be detected in advance (cf. the Halting Theorem), so he'll still
need a watcher thread/process that will terminate the server if it
overuses resources. Once that's in place, it can take care of big
objects in READ just as well.
> [1] OTOH the only way to secure a system connected to an open,
> untrusted network like the internet against all forms of DoS
> Attacks is to not offer a service in the first place.
Indeed. And a TCP- or IP-level attack is more likely on the current,
relatively unpoliced net.
--
Pekka P. Pirinen, Adaptive Memory Management Group, Harlequin Limited
Real programs don't eat cache.
From: Pierre R. Mai
Subject: Re: Using READ as an internet firewall [was Re: What case problem ...]
Date:
Message-ID: <87em05asyp.fsf@orion.bln.pmsf.de>
·····@harlequin.co.uk (Pekka P. Pirinen) writes:
> "Pierre R. Mai" <····@acm.org> writes:
> > Since finite input strings will to the best of my knowledge not
> > generate anything on read that has infinite (better non-bounded)
> > memory usage, reading from the socket into finite-sized buffers,
> > keeping track on memory usage, and then using read-from-string should
> > catch at least the most obious DoS attacks[1].
>
> Yes, but since he's proposing to offer an eval-server for a
> Turing-complete language, there's no way all unbounded computations
> can be detected in advance (cf. the Halting Theorem), so he'll still
> need a watcher thread/process that will terminate the server if it
> overuses resources. Once that's in place, it can take care of big
> objects in READ just as well.
Yes, I was only addressing the issue in the context of using read
without eval (since securing eval is a much larger task than securing
read, anyway), which IIRC was the issue originally at the heart of
this thread.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Pekka P. Pirinen
Subject: Re: Using READ as an internet firewall [was Re: What case problem ...]
Date:
Message-ID: <ixofza7o4l.fsf@harlequin.co.uk>
David Bakhash <·····@alum.mit.edu> writes:
> One thing I'd like to do is to leave my box listening on a text
> socket, let random people connect (up to a certain number), and see if
> anyone can crash my system with less than a 1 Mb data stream. I'll
> publish the vast majority of Common Lisp as readable and executable,
> and even EVAL their code. And while, in that code, they can compute
> just about anything, and have access to arrays, macros, DEF*** for
> almost all ***, I'd be surprised if I couldn't protect the system from
> bad stuff (i.e. massive consing, evil symbol, package, and reader
> hacks, etc.).
I'd surprised if you could do this while offering anything that is
recognizably Common Lisp. Certainly, considering the size of CL, it
would be a massive job to construct such a system following the the
principle of Least Privilege. OTOH, if you take the approach you
mentioned "to just filter out symbols and dangerous things", you could
easily build something that appears safe, but cannot be proven to be.
If I wanted to put up a safe evaluation server, open to all the
crackers on Internet, I would not offer any access at all to the
underlying language implementation. It's easy to write interpreters
in Lisp, and you can even use READ as the input mechanism.
--
Pekka P. Pirinen
The only vermin that can attack software are programmers.
I've been thinking about where I would like to see Common
Lisp go as far as this case issue and the only change I'd like to see
is to have the case of the names of system functions be lower (e.g. "car").
Then people could use readtable-case to achieve case sensitivity
or insensitivity. It would also be wysiwyg (unlike the :invert mode
in today's lisp).
I think that it would be too abrupt to do this switch of
system symbol name case in the next standardized version of CL
(in, say, 2001).
Better I think is to declare that in cl-2001 the case of system function
print names is **unspecified** by the standard and the choice of the
implementor (and thus the user who is choses the implementor).
Then five years later we say that cl-2006 will declare that the case
of system function names is **lower case**.
This gives people at least 5 years to make their code either system
case independent or working in a lower case lisp. Given that vendors
support old versions of lisps for customers for a few years, the end
result is that people with existing code in upper case lisp who
fear that this proposal will shut them out can rest assured that
they probably don't have worry about that happening until around 2009.
So this is a proposal that if agreed to would have no effect for many
years except that it would
1. legitimize the image with lower case sysetm names
2. encourage (but not require for many years) people to write code
in a case independent manner.
[[this whole proposal is my personal opinion. I'm just curious
about what people think.]]
proposal (for inclusion in cl-2001):
1. The standard no longer specifies the case the symbol-names of
of the defined system functions, variables and contants.
In a given instance of Common Lisp the names would all
be of one case, called the preferred case for that instance
of lisp.
2. readtable-case can have these values
:normal - meaning convert to the preferred case
:abnormal - meaning convert to the opposite of the preferred case
:preserve - do no conversion
:invert - invert all characters unless the identifier is mixed case
:upcase will be accepted as a deprecated equivalent of :normal
:downcase will be accepted as a deprecated equivalent of :abnormal
:invert will be deprecated.
[note: better names than normal and abnormal will be chosen].
3. *print-case* is similar to readtable-case
Impact on exiting code: none.
If the implementation chooses it will warn if deprecated values
are used, so you may have to change a bit of code
where you set readtable-case and *print-case* to eliminate warnings.
Impact on existing implementations:
At the minimum Implementors will have to accept :normal and
:abnormal for readtable-case and *print-case*
At the maximum implementors of an upper case preferred lisp
will create and distribute a lower case preferred lisp as well.
Advantages:
Existing Common Lisp programs and systems are still Common Lisp
programs and systems.
Programmers are encouraged to write code in a way that doesn't
depend on the preferred case of the lisp. They are not required
to do so -- it's a portability issue: if they want their code
to be portable between Common Lisps differing in preferred case
then they must make their code independent of preferred case.
If they don't care about such portability then they can program
assuming the preferred case of their Lisp system.
People who so desire can write case sensitive code in a
natural manner using a lower-case preferred lisp with
the readtable-case set to :preserve. Such code may or may
not be runnable in a lisp with another value of readtable-case
or in a lisp with a different preferred case. It's up to
the author of the code to determine how much he cares about
portability across implementations or with different values
of readtable-case and write his code accordingly.
People who prefer to work in a case insensitive mode can choose
either a lower case or upper case preferred lisp and set
the readtable-case to :normal.
Disadvantages:
There could split the community if people don't care about portability
when they write their code. The portability considerations due
to this change are much less than for, say, foreign function
interface or threading modules.
From: Barry Margolin
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <kKUO5.54$sG1.330@burlma1-snr2>
In article <··························@news.dnai.com>,
John Foderaro <···@unspamx.franz.com> wrote:
>Better I think is to declare that in cl-2001 the case of system function
>print names is **unspecified** by the standard and the choice of the
>implementor (and thus the user who is choses the implementor).
What happens to programs that do things like (intern "CAR")?
--
Barry Margolin, ······@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.
In article <················@burlma1-snr2>, ······@genuity.net says...
>
> What happens to programs that do things like (intern "CAR")?
>
>
you get the symbol with that print name. Whether you get the
car symbol that is defined in the CL spec depends on the value
of *package* and whether your implementation is a lower case or
upper case preferred lisp.
So doing (intern "CAR") with the hope that you'll get the
familiar car symbol is perfectly legal but will only
succeed in a upper case perferred lisp. (in this thing we've
named cl-2001). It's not portable to all existing cl-2001
implementations (e.g. those which are lower case preferred)
but it's up to you to decide whether you care about portabilty.
From: Barry Margolin
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <owYO5.64$sG1.794@burlma1-snr2>
In article <··························@news.dnai.com>,
John Foderaro <···@unspamx.franz.com> wrote:
>In article <················@burlma1-snr2>, ······@genuity.net says...
>>
>> What happens to programs that do things like (intern "CAR")?
>>
>>
>
>you get the symbol with that print name. Whether you get the
>car symbol that is defined in the CL spec depends on the value
>of *package* and whether your implementation is a lower case or
>upper case preferred lisp.
So if your goal is to get the one that's defined in the CL spec, how would
you propose that be accomplished? Something like
(intern (if *default-upcase* "CAR" "car"))
? Everyone who calls INTERN or FIND-SYMBOL would have to modify their code
to deal with this new situation, wouldn't they? That seems like a serious
incompatibility for such little gain.
This seems like something you would have had to address in your "modern"
Lisp configurations. Have you? Or is this the breakage that Erik is
fuming about?
--
Barry Margolin, ······@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.
In article <················@burlma1-snr2>, ······@genuity.net says...
>
> (intern (if *default-upcase* "CAR" "car"))
>
well actually I'd do something like (intern (symbol-name 'car))
but something as basic as this is something usually not done (I.e why
not just use the symbol car to begin with?)
> ? Everyone who calls INTERN or FIND-SYMBOL would have to modify their code
> to deal with this new situation, wouldn't they? That seems like a serious
> incompatibility for such little gain.
>
I've written a lot of code and converted a lot of code written by others
so that it works in Modern mode (and continues to run in ANSI mode).
I've found calls to intern which
I've had to make work in either mode, but I don't think that I've
ever seen a call to find-symbol, but I may have seen one in the
Orion database system from MCC.
I can only say that in practice it really isn't a problem.
> This seems like something you would have had to address in your "modern"
> Lisp configurations. Have you? Or is this the breakage that Erik is
> fuming about?
>
No, he's unhappy that when readtable-case was added to Common Lisp ten or
so years ago we didn't try to figure out how to get readtable-case
and our existing case modes to interact. This problem lay dormant
for 10 years and surfaced because Erik was trying to use
readtable-case in modern mode. It's listed as a bug in our
database and the challenge is to support readtable-case and
not lose the ability to easily run ANSI code inside a
Modern mode image.
From: Barry Margolin
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <cmZO5.70$sG1.687@burlma1-snr2>
In article <··························@news.dnai.com>,
John Foderaro <···@unspamx.franz.com> wrote:
>In article <················@burlma1-snr2>, ······@genuity.net says...
>>
>> (intern (if *default-upcase* "CAR" "car"))
>>
>
>well actually I'd do something like (intern (symbol-name 'car))
>but something as basic as this is something usually not done (I.e why
>not just use the symbol car to begin with?)
Come on. If I had the symbol already, I wouldn't need to call INTERN,
would I? This is done when you're computing symbol names on the fly. CAR
was just a simple example.
Macros like DEFSTRUCT do this all the time. For instance, somewhere in
DEFSTRUCT, it does something like:
(intern (format "MAKE-%A" structure-name))
To make this portable with implementation-dependent case, the simplest fix
would probably be:
(intern (format "%A-%A" 'make structure-name))
But it's unlikely that much code is currently written this way, so it would
have to be found and fixed. I suspect there's also code out there that
reads user input using things like READ-LINE, and then calls STRING-UPCASE
before calling INTERN or FIND-SYMBOL, to ensure that it will find the right
symbol.
--
Barry Margolin, ······@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.
In article <················@burlma1-snr2>, ······@genuity.net says...
> To make this portable with implementation-dependent case, the simplest fix
> would probably be:
>
> (intern (format "%A-%A" 'make structure-name))
>
correct, except it would be (intern (format nil "~a-~a" 'make structure-name))
[it looks like you've just been programming in C]
> But it's unlikely that much code is currently written this way, so it would
> have to be found and fixed.
True but in practice it's not hard. I don't know how to prove it to you
though.
From: Barry Margolin
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <wC%O5.76$sG1.692@burlma1-snr2>
In article <··························@news.dnai.com>,
John Foderaro <···@unspamx.franz.com> wrote:
>In article <················@burlma1-snr2>, ······@genuity.net says...
>> To make this portable with implementation-dependent case, the simplest fix
>> would probably be:
>>
>> (intern (format "%A-%A" 'make structure-name))
>>
>
>correct, except it would be (intern (format nil "~a-~a" 'make structure-name))
>[it looks like you've just been programming in C]
I knew something didn't feel right when I was writing that! What little
programming I do these days is mostly Perl, AWK, or Emacs Lisp, all of
which use C's formatting syntax.
>> But it's unlikely that much code is currently written this way, so it would
>> have to be found and fixed.
>
>True but in practice it's not hard. I don't know how to prove it to you
>though.
Perhaps true, but is it worth forcing lots of programmers to go through
that for such a minor benefit? IMHO, incompatible changes should require
more justification than this.
--
Barry Margolin, ······@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.
I'd disagree that this is a minor benefit.
Let me relate an anecdote. Back in 1978 when UC Berkeley got its
first VAX computer, they got a copy of the Vax/Unix operating system
from Bell Labs and began work on adding a virtual memory system to it.
In this this version of Unix, external identifiers (such as function names)
in object files were limited to some small length (12 characters I think).
Even with a 12 character limitation for identifiers you can still write
any C program. So there was no need to change anything. However
the people working on this project (an in particular Bill Joy) recognized
that a 12 character limitiation to identifiers harmed
their ability to clearly write the system they intended to write.
Therefor they wanted no restriction on the length of identifiers. So they
made that happen and that meant changing a large number
of programs (cc, ld, as, nm, adb) as well as creating a new
executable file format and changing the Unix kernel to understand
this format. This also meant breaking with the version of Unix
at Bell Labs.
So this was a tremendous step just to go from 12 character to unlimited
character identifiers. I'm glad they did as it really added to
the clarity of long function names and didn't force unnatural abbreviation.
(e.g. GetWindowTitle -> GetWinTitle). Since most Unixes in use now are
a descendent of this version this change they made is responsible
for the fact at we now take for granted that identifiers for functions
names can be any length.
I wonder how many of us when faced with the question of whether
to make this change would say "We can write everything with 12 character
identifiers and we've got to stick with the standard, and Bell Labs sets
the standard for C [in 1978]".
And so in a roundabout answer to your question about what the benefit
of a Modern lisp, let me say that we can already write everything
we would ever want to write in an ANSI lisp. However a
Modern lisp does give us
1. more expressibility (without escaping things)
2. the ability to more easily represent objects outside the Lisp world that
have case sensitive names.
Thus while Modern mode won't let us write any programs we
couldn't write in ANSI mode, it does make writing
certain programs easier and clearer. That to me is a huge benefit.
John Foderaro <···@unspamx.franz.com> writes:
> And so in a roundabout answer to your question about what the benefit
> of a Modern lisp, let me say that we can already write everything
> we would ever want to write in an ANSI lisp. However a
> Modern lisp does give us
> 1. more expressibility (without escaping things)
> 2. the ability to more easily represent objects outside the Lisp world that
> have case sensitive names.
>
> Thus while Modern mode won't let us write any programs we
> couldn't write in ANSI mode, it does make writing
> certain programs easier and clearer. That to me is a huge benefit.
Again, you seem to be arguing something different from others are
arguing. You seem to continuously be equating your Modern mode with
case sensitivity and being able to interface nicely with code from
other languages. I've already posted what I think is a solution to
this problem, though it is not complete, as I don't think any solution
will accomodate everyone. You can look it up. It's got:
Message-ID: <··············@cadet.dsl.speakeasy.net>
If you have access to Gnus, then use the command
M-^ or
M-x gnus-summary-refer-article <ENTER> <<Message-ID>> <ENTER>
I put double <>'s around the Message-Id because they tend to contain
angle brackets.
dave
John Foderaro <···@unspamx.franz.com> writes:
> Since most Unixes in use now are a descendent of this version this
> change they made is responsible for the fact at we now take for
> granted that identifiers for functions names can be any length.
>
> I wonder how many of us when faced with the question of whether to
> make this change would say "We can write everything with 12
> character identifiers and we've got to stick with the standard, and
> Bell Labs sets the standard for C [in 1978]".
Yet the C90 standard guarantees only 6 significant initial characters
in an external identifier, which are even case insensitive.
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
From: Erik Naggum
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <3182882219798792@naggum.net>
* Barry Margolin <······@genuity.net>
| But it's unlikely that much code is currently written this way, so it
| would have to be found and fixed. I suspect there's also code out
| there that reads user input using things like READ-LINE, and then
| calls STRING-UPCASE before calling INTERN or FIND-SYMBOL, to ensure
| that it will find the right symbol.
The obvious solution to this problem is _not_ to make an irreversible
global change, but to retain upper-case access to symbols even while
you have lower-case access to them. Franz Inc's solution is wrong,
and causes lots or problems in transitioning between upper-case and
lower-case "modes". Such global mode switches are generally not the
best kind of solution, anyway. I truly wonder why they didn't look
further when it has so many obvious drawbacks, apart from breaking
code that relies on the old upper-case behavior, which is considered
something that _shouldn't_ work by some Franz people. I can't believe
the argument that any such code is so easy to change there's no cost
to it. How do you know you've caught them all? How is that easier to
prove than not to break the thing in the first place while allowing
people the choice? And he's never seen find-symbol! That is _not_
comforting. The sheer arrogance here is too much, just too much.
#:Erik
--
ALGORITHM: a procedure for solving a mathematical problem in a finite
number of steps that frequently involves repetition of an operation.
ALGOREISM: a procedure for solving an electoral problem in a finite
number of steps that frequently involves repetition of an operation.
Erik Naggum <····@naggum.net> writes:
> you have lower-case access to them. Franz Inc's solution is wrong,
> and causes lots or problems in transitioning between upper-case and
> lower-case "modes". Such global mode switches are generally not the
> best kind of solution, anyway. I truly wonder why they didn't look
(wading into the fray)
Hmm. I'm fairly early in my Lisp programming journey, and curious:
wouldn't something like a WITH-LOWER-CASE-READER macro be much more
effective than a global setting?
--
vsync
http://quadium.net/ - last updated Fri Nov 10 03:41:55 PST 2000
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil))
vsync <·····@quadium.net> writes:
> Hmm. I'm fairly early in my Lisp programming journey, and curious:
> wouldn't something like a WITH-LOWER-CASE-READER macro be much more
> effective than a global setting?
Would the idea be that:
(symbol-name (with-lower-case-reader 'foo)) => "foo"
(symbol-name (with-upper-case-reader 'foo)) => "FOO"
? I don't think that could work, as a form is read before it's
macroexpanded. You can play around with reader-macros though:
(defun l-reader (stream subchar arg)
(declare (ignore subchar arg))
(let ((*readtable* (copy-readtable *readtable*)))
(setf (readtable-case *readtable*) :downcase)
(read stream t nil t)))
(set-dispatch-macro-character #\# #\l #'l-reader)
(defun U-reader (stream subchar arg)
(declare (ignore subchar arg))
(let ((*readtable* (copy-readtable *readtable*)))
(setf (readtable-case *readtable*) :upcase)
(read stream t nil t)))
(set-dispatch-macro-character #\# #\U #'U-reader)
* #l'foo
|foo|
* #U'foo
FOO
This has a problem, though:
* #l(defun blah () 1)
fails because "function |defun|" is not defined.
But something can be done about that:
(defun munge-form (form)
(cond ((symbolp form)
(let ((uname (string-upcase (symbol-name form))))
(multiple-value-bind
(cl-sym status) (find-symbol uname "CL")
(if (and cl-sym (eq status :external))
cl-sym
form))))
((consp form)
(cons (munge-form (car form)) (munge-form (cdr form))))
(t form)))
(defun l-reader2 (stream subchar arg)
(declare (ignore subchar arg))
(let ((*readtable* (copy-readtable *readtable*)))
(setf (readtable-case *readtable*) :downcase)
(munge-form (read stream t nil t))))
(set-dispatch-macro-character #\# #\l #'l-reader2)
Then
* #l(defun blah () 1)
|blah|
* (|blah|)
1
* #l(blah)
1
I'm not sure this solves any real problem, but mucking with this sort
of thing's more interesting than doing my Category Theory example
sheet...
(#U doesn't work in Modern Lisp, of course.)
Cheers,
M.
--
All parts should go together without forcing. You must remember that
the parts you are reassembling were disassembled by you. Therefore,
if you can't get them together again, there must be a reason. By all
means, do not use a hammer. -- IBM maintenance manual, 1925
From: Erik Naggum
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <3182902092734894@naggum.net>
* vsync <·····@quadium.net>
| Hmm. I'm fairly early in my Lisp programming journey, and curious:
| wouldn't something like a WITH-LOWER-CASE-READER macro be much more
| effective than a global setting?
What would the macro expand to if not a special variable binding,
which is a global setting?
#:Erik
--
ALGORITHM: a procedure for solving a mathematical problem in a finite
number of steps that frequently involves repetition of an operation.
ALGOREISM: a procedure for solving an electoral problem in a finite
number of steps that frequently involves repetition of an operation.
Erik Naggum <····@naggum.net> writes:
> What would the macro expand to if not a special variable binding,
> which is a global setting?
or, more correctly, in a multithreaded lisp: a thread-wide setting.
What I want, and which 'modern mode' doesn't seem to give me,
is simply to have a lisp that can read case-insensitively in
*some* threads while simultanously reading case-sensitively in
other threads.
--
(espen)
From: Kent M Pitman
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <sfwk8a8tbsj.fsf@world.std.com>
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Erik Naggum <····@naggum.net> writes:
>
> > What would the macro expand to if not a special variable binding,
> > which is a global setting?
>
> or, more correctly, in a multithreaded lisp: a thread-wide setting.
>
> What I want, and which 'modern mode' doesn't seem to give me,
> is simply to have a lisp that can read case-insensitively in
> *some* threads while simultanously reading case-sensitively in
> other threads.
ANSI CL will give you that. The whole design of our readtable-based and
printer-option-variable-based solution was around the idea of being
able to accomodate this dynamic swap-off...
It's increasingly apparent to me that the only thing that is really
being objected to by Franz (or maybe just by Foderaro, since I don't
hear a lot of his coworkers jumping in to do anything other than
damage control) is that someone should freely choose their case (in
this case, CL chose upper). Franz (or maybe just Foderaro) appears
to want to both allow people to freely choose their case and to insist
that the "freely chosen" case they choose is not "all uppercase".
This entire discussion, as nearly as I can tell, comes down not to an
issue of case choice, but of forced-lower. After all, if case choice is
legitimately freely chosen, then CL has freely chosen, and it's ok.
That our free choice is not ok suggests the choice is not free.
Perhaps there should be a readtable setting tht says map all
uniformly-cased symbols to lowercase and a function approved-symbol-name
that is defined by
(defvar *approved-symbol-name-hashtable*
(make-hash-table :test 'equal))
(defun approved-symbol-name (symbol)
(let ((symbol-name (symbol-name symbol)))
(or (gethash symbol-name *approved-symbol-name-hashtable*)
(setf (gethash symbol-name *approved-symbol-name-hashtable*)
(if (and (some #'both-case-p symbol-name) ;contains some alpha
(every #'upper-case-p symbol-name)) ;which is all upcased
(string-downcase symbol-name)
symbol-name)))))
As nearly as I can tell, this is the essence of what we're all arguing
about...
Or, put in terms of the :CASE argument of the pathname system, it's as if
:case :local and :case :common were not enough. They appear to want a
:case :approved-by-franz.
I've used some descriptive exaggeration in this message, but honestly
I believe this message to be an essentially true distillation of my
understanding of the conversation to date. If it's not, it would be good
if someone would correct me with specific technical ways in which I'm off
base here.
John Foderaro <···@unspamx.franz.com> wrote:
>In article <················@burlma1-snr2>, ······@genuity.net says...
>>
>> (intern (if *default-upcase* "CAR" "car"))
>>
>
>well actually I'd do something like (intern (symbol-name 'car))
>but something as basic as this is something usually not done (I.e why
>not just use the symbol car to begin with?)
>
>
>> ? Everyone who calls INTERN or FIND-SYMBOL would have to modify their code
>> to deal with this new situation, wouldn't they? That seems like a serious
>> incompatibility for such little gain.
>>
>
>I've written a lot of code and converted a lot of code written by others
>so that it works in Modern mode (and continues to run in ANSI mode).
>I've found calls to intern which
>I've had to make work in either mode, but I don't think that I've
>ever seen a call to find-symbol, but I may have seen one in the
>Orion database system from MCC.
In one legacy application I have found about several ten calls to
find-symbol, here is one example:
(defun sub-FM-pull-down-menu-class
(&optional (sub-FM-keyword *current-sub-FM*))
(let* ((name (concatenate 'string (symbol-name sub-FM-keyword)
"-PULL-DOWN-MENU"))
(class (find-symbol name :cl-user)))
(if class
class
'pull-down-menu)))
>I can only say that in practice it really isn't a problem.
>
Maybe
--
Francis Leboutte
www.algo.be +32-(0)4.388.39.19
From: Erik Naggum
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <3182877325118372@naggum.net>
* Barry Margolin <······@genuity.net>
| This seems like something you would have had to address in your "modern"
| Lisp configurations. Have you? Or is this the breakage that Erik is
| fuming about?
Well, I'm "fuming about" another breakage, that the support for case
insensitivity via readtable-case was broken to get base sensitivity by
default, but yes, this is another breakage that has "bad engineering"
written all over it. That you can't refer to symbols with their
standard upper-case names if you run in a "Modern" Lisp is a serious
problem. Now, there are absolutely no problems combinging the two
"modes" -- just like case sensitivity and insensitivity can co-exist
in the same image. _Something_ caused Franz Inc not to pursue that
venue and I'm not sympathetic to what I'm beginning to understand that
that "something" is: _no_ interest in or commitment to make extensions
within the standard framework when at all possible, but instead taking
an easy way out that does not require implementing the standard fully.
#:Erik
--
ALGORITHM: a procedure for solving a mathematical problem in a finite
number of steps that frequently involves repetition of an operation.
ALGOREISM: a procedure for solving an electoral problem in a finite
number of steps that frequently involves repetition of an operation.
From: Kent M Pitman
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <sfw3dh0le7q.fsf@world.std.com>
John Foderaro <···@unspamx.franz.com> writes:
> Better I think is to declare that in cl-2001 the case of system function
> print names is **unspecified** by the standard and the choice of the
> implementor (and thus the user who is choses the implementor).
Whose CL-2001? What consensus-making body are you working through in making
this unilateral proclamation?
Please note that I say this without prejudice as to whether I might support
this if I were sitting at a standards-making table.
My point, though, is that consensus is consensus. I have been VERY careful
for years since the standard when commenting on it that even though I was
present to vote and even though my fingers did a lot of the typing (and
typos), I have no more formal say about what the standard means than anyone
else. The standard is the standard and stands by itself.
If you believe what you believe, what you should do is join others or even
work on your own to produce a document which is itself a complete standard
(and not, for example as CLTL2 was, a set of diffs) to which people can choose
to adhere or not.
I have said over and over and over again that there are no right and wrong
decisions in Common Lisp, there are only decisions made in a context. You
might have some reasons for wanting what you want, and some people might
like them, too. Maybe everyone. But you won't know until you establish
a context--a whole language, a commitment to an implementation, etc. You
can't just advertise a single feature and say "hey, we all agree this is
cool, right?" because no one has any way to judge.
By the way, ISLISP chose to make the symbol's case not specified. On some
days I wonder why you don't just make an ISLISP-compliant implementation and
work forward from there to build a new market around a standard maybe you
could be more happy with.
In article <···············@world.std.com>, ······@world.std.com says...
> Whose CL-2001? What consensus-making body are you working through in making
> this unilateral proclamation?
I'd call it a proposal rather than a proclamation. The term cl-2001 was just a name I
made up to denote whatever lisp standard follows the current ANSI standard.
The determination of how the next standard comes about (be it a formal standards body
or the publication of a book) is a whole separate issue I wasn't getting into.
Everyone one here has an opinion and I just wanted to get some feedback on this idea.
Someone may know of a reason that it's impossible to do and that would be nice to
know.
Isn't islisp a lisp-1 ?
If that's the case then I'm personally not interested.
From: T. Kurt Bond
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <m3ofznzzwj.fsf@tkb.mpl.com>
John Foderaro <···@unspamx.franz.com> writes:
> Isn't islisp a lisp-1 ?
> If that's the case then I'm personally not interested.
No, it's not a lisp-1.
From "ISLISP Working Draft 20.3", which was what I was able to find on-line:
In ISLisp there are six namespaces: variable, dynamic variable,
function, class, block, and tagbody tag.
(Maybe you were thing of EuLisp, which is a lisp-1?)
--
T. Kurt Bond, ···@tkb.mpl.com
In article <··············@tkb.mpl.com>, ···@tkb.mpl.com says...
> (Maybe you were thing of EuLisp, which is a lisp-1?)
>
Thanks, that's exactly what I was thinking of.
John Foderaro <···@unspamx.franz.com> writes:
> In article <···············@world.std.com>, ······@world.std.com
> says...
>
>> Whose CL-2001? What consensus-making body are you working through
>> in making
>> this unilateral proclamation?
>
> I'd call it a proposal rather than a proclamation. The term cl-2001
> was just a name I made up to denote whatever lisp standard follows
> the current ANSI standard.
>
> The determination of how the next standard comes about (be it a
> formal standards body or the publication of a book) is a whole
> separate issue I wasn't getting into.
In all due fairness, I believe that KMP raised a legitimate issue.
How do you intend to work with the established standard forming body?
Have you contacted the other implementors (other than through this
forum) regarding this issue? (E.g. I monitor cmucl-imp and clisp-list
and have not see a message in this sense).
So this discussion must be split in two again.
1 - what is the venue that will decide what will go and what will not
go in the Revised^1 ANSI standard. (This Scheme-ism makes me shiver
:) )
2 - the proposals to be crafted and submitted to the above venue,
(which should not be C.L.L.).
> Everyone one here has an opinion and I just wanted to get some
> feedback on this idea. Someone may know of a reason that it's
> impossible to do and that would be nice to know.
Having said that, I want to enter the merit of your proposal and
contradict what I just said before about C.L.L. not being the proper
place where to make these porposals. :)
All in all, you favor the introduction of "case modes" which will
eventually break legacy code (barring rewriting of the old code). I
must say that I do not quite like this. Moreover, your proposal does
allow for different implementation to be "conforming" while shipping
with different standard settings in an area where, IMHO, variation
should be kept at a minimum.
#+WARNING
I am thinking out loud after having followed pretty much all that has
been written on the issue.
Moreover it is LONG. I have cut out a set of examples that try to
figure out all possible interactions between variuous cases.
==============================================================================
Since the crux of the problem is two-fold - case sensitivity and symbol
lookup - the personal opinion I formed is that this issue should be
addressed at the package level. I believe that tagging a package with
a (readtable) case may be the right solution. CLisp already hase
something similar.
So the idea would be to do the following
1 - Changes to DEFPACKAGE.
(defpackage "FOO" (:use "COMMON-LISP")
(:nicknames "foo") ; Just to show that you can accomodate this.
(:symbol-name-case <an extended readtable case tag>)
(:export "ZUT"
"gnao"
"Bar"
"qWe"
#:a-Symbol
#:another-symbol
#:AND-ANOTHER
#:|an-Escaped-symBOl|
#:|a Funky symBOl|))
The :SYMBOL-NAME-CASE option will have effect on the way in which
symbols are looked up in the package. It will have one of the
following values:
- :PRESERVE
The symbol names are INTERNed in the package literally�.
The symbol names are to be looked up literally. I.e. the
reader, *after* having read in the symbol and having done
its processing according to READTABLE-CASE looks up the
symbol name in the appropriate package. The match must be
done as if through STRING=.
- :UPCASE
The symbol names are INTERNed in the package after a
STRING-UPCASE equivalent operation has been performed on them.
The symbol names are to be looked up literally. I.e. the
reader, *after* having read in the symbol and having done
its processing according to READTABLE-CASE looks up the
symbol name in the appropriate package. The match must be
done as if through STRING=.
- :DOWNCASE
As per :UPCASE, with STRING-DOWNCASE.
- :INVERT
As per :UPCASE, with STRING-INVERT-CASE�
- :IGNORE
The symbol names are INTERNed in the package literally�.
The symbol names are not to be looked up literally. I.e. the
reader, *after* having read in the symbol and having done
its processing according to READTABLE-CASE looks up the
symbol name in the appropriate package. The match must be
done as if through STRING-EQUAL.
The value of :IGNORE is the default.
The system packages (most notably :COMMON-LISP) and the legacy
packages will just need to add a
(:symbol-name-case :ignore)
or, when so explicitely desired,
(:symbol-name-case :uppercase)
1.1 - Examples <... omissis ...>
1.2 - Problems
The main problem to address in this setup is what to do with inherited
symbols. There are many cases to consider�, however, the following
changes should suffice.
2 - Changes to IMPORT (and to SHADOWING-IMPORT).
IMPORT (and SHADOWING-IMPORT) must be limited.
IMPORT of a symbol in a package with :SYMBOL-CASE-NAME set to :IGNORE
or :PRESERVE is allowed without restrictions.
IMPORT of a symbol in a package with :SYMBOL-CASE-NAME set to :UPCASE
or :DOWNCASE or :INVERT is allowed if and only if the SYMBOL-NAME of
the symbol being imported is STRING-EQUAL to the result of applying
STRING-UPCASE, STRING-DOWNCASE or STRING-INVERT-CASE to the symbol
SYMBOL-NAME itself. Otherwise a condition of type PACKAGE-ERROR (or a
new appropriate one) is signalled.
3 - Inherited symbols.
Since USE-PACKAGE makes symbol "assessible" but not "present" in the
package "issuing" the call, no changes are needed at the interface
level. The lookup of the inherited symbol is done through the current
package, using the features of the used package.
4 - Changes to FIND-SYMBOL.
See comments about DEFPACKAGE.
5 - Changes to MAKE-PACKAGE.
MAKE-PACKAGE will accept the a new keyword :SYMBOL-NAME-CASE with
possible values as described above.
6 - New Function PACKAGE-SYMBOL-NAME-CASE.
A new accessor to retrieve the the aforementioned property.
7 - Changes to LOAD (not strictly necessary).
LOAD should take an extra keyword argument named :READTABLE-CASE,
which will set the value of (a copy of) (READTABLE-CASE *READTABLE*)
before starting to READ the input contents.
8 - Examples
The case of the "CLJava" translator proposed by John Foderaro can be
dealt as follow
(setf (readtable-case *readtable*) :preserve)
(defpackage "Java" (:use "COMMON-LISP")
(:symbol-name-case :preserve)
(:export "addMouseListener" "this"))
(defpackage "CLJava" (:use "COMMON-LISP")
(:symbol-name-case :preserve)
(:import-from "Java" "addMouseListener" "this")
(:export "init" "getImage" "getCodeBase"))
(in-package "CLJava")
(def-java-method init () void
:public
(setq notImage (getImage (getCodeBase) "images/not.gif")
crossImage (getImage (getCodeBase) "images/cross.gif"))
(addMouseListener this))
In the example you could also write
(defpackage "CLJava" (:use "COMMON-LISP" "Java")
(:symbol-name-case :preserve)
(:export "init" "getImage" "getCodeBase"))
9 - Costs
The costs are the estimated to be the following
a - Impact on existing code:
Unable to estimate. It would seem that the current
practice of writing CL code all lower case should remain
unaffected. With :SYMBOL-CASE-NAME set to :IGNORE (the
proposed default) the *PRINT-CASE* problem (when set to
:DOWNCASE) would seem to go away.
Packages written with the current uppercase style will
continue to function without change.
b - Impact on existing implementations:
Moderate: the implementors must add all the code to
support the proposed change. The most vexing problem will
be to modify the behavior of FIND-SYMBOL and IMPORT to
accomodate the different proposed cases.
c - Impact on performance:
"Interpreted" code will - most likely - suffer a
performance hit because of the added complexity in
FIND-SYMBOL.
"Compiled" code will - most likely - not be affected by
the changes proposed, except in the cases where a
FIND-SYMBOL is inserted by the compiler in a way beyond
user control.
ADVANTAGES:
These are the advantages I see in the above proposal (to paraphrase
John Foderaro):
Existing Common Lisp programs and systems are still Common Lisp
programs and systems.
Programmers are not required to follow any special coding standard
unless so required by the declaration of a third party DEFPACKAGE
declaration (or MAKE-PACKAGE invocation).
New code written in a :PRESERVE READTABLE-CASE can be made to work
in any system under programmer control. The :IGNORE default of
the legacy packages and the :USE and IMPORT
(cfr. SHADOWING-IMPORT) rules will ensure that they will not
interfere with the :PRESERVE READTABLE-CASE being used.
It is assumed that the new code will be put in packages with
:SYMBOL-CASE-NAME set to :PRESERVE.
There is no need for separate "images" to be provided by each
implementor.
Portability is ensured to a greater degree than just addressing
the problem at the READTABLE-CASE level. People are forced to
make a decision about declaring how their package work and to
advertise this fact. Their code works in all conforming (to this
proposal that is) implementations; i.e. how their code works is
totally under the programmers' control, and they are not
restricted to the decision on READTABLE-CASE (which could be left
to :UPCASE) made by a given implementation.
DISADVANTAGES:
I foresee the following disadvantages. Actually only one.
Given the (IMHO moderate) burden on the vendors and the
implementors it may be that some systems will not implement
the proposed changes. If the proposal will ever be adopted it
will be the burden of the community to ensure that the vendors and
the implementors will eventually conform.
� This is the current ANSI default.
� The function STRING-INVERT-CASE (and NSTRING-INVERT-CASE) must be
defined appropriatedly and inserted in the standard.
� I know I might be missing a lot here.
==============================================================================
That's all folks. I will have my bullet-proof vest on before I
finally send this message, but try to be nice while shooting.
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
--
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
From: Kent M Pitman
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <sfwitpslpo6.fsf@world.std.com>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> John Foderaro <···@unspamx.franz.com> writes:
>
> > In article <···············@world.std.com>, ······@world.std.com
> > says...
> >
> >> Whose CL-2001? What consensus-making body are you working through
> >> in making
> >> this unilateral proclamation?
> >
> > I'd call it a proposal rather than a proclamation. The term cl-2001
> > was just a name I made up to denote whatever lisp standard follows
> > the current ANSI standard.
> >
> > The determination of how the next standard comes about (be it a
> > formal standards body or the publication of a book) is a whole
> > separate issue I wasn't getting into.
>
> In all due fairness, I believe that KMP raised a legitimate issue.
> How do you intend to work with the established standard forming body?
Incidentally, I didn't mean to imply that ANSI has to be the forum.
I'm amenable to discussion of whether another forum anywhere from IEEE to
IETF to ALU should be used. I'm a litte tired of ANSI, which I find to
be too slow and painful for modern needs.
However, I do think that we can still proceed in a way that doesn't
perturb the existing standard as a base. And I do think that somehow
the a plan for community involvement has to exist.
If Franz would come out and say "we propose our Modern mode in place
of ANSI CL", at least that would be a "plan" for cooperation in the sense
that people could rally around it or not. But instead they DON'T propose
that we consider it standard, they seem to say that the standard is what
people should rally around... and then having said that, they diverge from
it. It's that inconsistency I find troubling, and it's for that reason
that I'm not directing anyone to the franz free trial product until we get
this issue resolved.
> So this discussion must be split in two again.
>
> 1 - what is the venue that will decide what will go and what will not
> go in the Revised^1 ANSI standard. (This Scheme-ism makes me shiver
> :) )
Well, ANSI defines its own venue. The venue for deciding what ANSI will do
is the ANSI committee meetings. There was one scheduled for this year but
it never happened. I think no one felt it was important enough. If Franz
felt otherwise, though, they should have pushed for a meeting. Certainly in
last year's meeting, I got no sense that they felt this was an overwhelming
issue. They didn't vote to open the standard to possible change, as I recall.
> 2 - the proposals to be crafted and submitted to the above venue,
> (which should not be C.L.L.).
Well, there's nothing wrong with airing things here. It's good to get
community feedback. I think the real issue is that there are no proposals
being circulated at all. Franz is just apparently saying what CL does
is wrong and that they've unilaterally decided to diverge. They aren't
proposing anything, and so aren't opening it for us to criticize, as nearly
as I can tell.
As to your proposal to "fix" things, if we were going to make an incompatible
change to ANSI it wouldn't be that hard. But we just recently (last year)
voted (Franz concurring) that the standard was "good enough" that we would
merely endorse it "as is" for another 5 years....
I think we should consider additions nearer than 5 years, but not through
ANSI. And I think we should not consider making any incompatible changes
in the next 5 years, perhaps ever. I could be swayed otherwise. But
mostly I think our efforts are better spent moving forward, not pissing off
our established user base by making incompatible changes now.
Of course, you can always make the claim that the future audience is bigger
than the current audience. I was present at an ISO SC22/WG16 meeting where
we took a vote on whether there were more customers of ISLISP in the present
or in the future. People voted the future, as if that meant something.
But we didn't really have the clout to force implementation of that vote,
so what was the point. My point is that you can claim that claim an
incompatible change to ANSI CL might bring a big audience, but you can't
prove, at least I haven't seen any proof, that it won't just disperse the
small but dedicated audience we have.
In article <···············@world.std.com>, ······@world.std.com says...
> But instead they DON'T propose
> that we consider it standard, they seem to say that the standard is what
> people should rally around... and then having said that, they diverge from
> it. It's that inconsistency I find troubling,
You've put us in a can't-win position.
If people start asking us about a EXTENSION we've made to Common Lisp and we
explain it then you say we're advocating diverging from the standard
(even though every CL implementation extends the standard).
If people get worried that their standard programs now won't work in ACL
and we explain to them that the extension is optional and that we support
and will always support Common Lisp without the extension then you
say that we're rallying around the standard saying that's good enough
for all the programs one would ever want to write.
I'm troubled that you made the statement you made. I'm sure that
you read and understood the context of all the comments we've made, so
I'm curious what was really behind your statement.
> I think the real issue is that there are no proposals
> being circulated at all. Franz is just apparently saying what CL does
> is wrong and that they've unilaterally decided to diverge. They aren't
> proposing anything, and so aren't opening it for us to criticize, as nearly
> as I can tell.
Why don't you go after Xanalys? I understand that they didn't feel
that CL was good enough for all the programs they and their users wanted to
write and unilateraly decided to add a unique
foreign function interface and a threads package. The nerve!
Programs written with their unique interfaces will not run in any other ANSI
lisp. Obviously they are trying to take over the standard.
Let's not let them post here as they don't have the correct community spirit.
Let's get serious again.
How can you say that no proposals have been put forward when I put one forth
a few days ago. It had the important property that it didn't split the
community. It let all existing Common Lisp's still be Common Lisps.
It just broadened the definition of Common Lisp to include other
implementations.
Doesn't this raise the possibility of incompatiblities? My best estimate
is that 100% of all interesting common lisp programs use implementation
specific functions. So there will always be porting issues.
My experience is that the case issues are minor compared to the others.
From: Thomas A. Russ
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <ymi7l6720q7.fsf@sevak.isi.edu>
John Foderaro <···@unspamx.franz.com> writes:
> In article <···············@world.std.com>, ······@world.std.com says...
> > But instead they DON'T propose
> > that we consider it standard, they seem to say that the standard is what
> > people should rally around... and then having said that, they diverge from
> > it. It's that inconsistency I find troubling,
>
> You've put us in a can't-win position.
> If people start asking us about a EXTENSION we've made to Common Lisp and we
> explain it then you say we're advocating diverging from the standard
> (even though every CL implementation extends the standard).
Well, I can't speak for everyone, but what sucked me into this
discussion was the observation that Franz' EXTENSION to Common Lisp
broke the functionality of the readtable.
Now I haven't examined Erik Naggum's proposed fix to Franz' solution to
this particular problem in any detail, but my impression of Naggum's
technical competence is such that I feel there is a very high likelihood
that a standards-conforming extension is possible. So then the question
becomes, why doesn't Franz implement their "modernMode" in such a way as
to preserve readtable functionality?
Furthermore, I have not seen a convincing argument against just using
readtable-case :INVERT to accomplish essentially all of the externally
visible case-sensitive behavior that one wants. The only real argument
against it that I have seen is that then the external and internal
representation of symbol names is different. So what? Why should this
be a major issue? As long as the externally visible behavior is
consistent it shouldn't matter how the language does things internally.
That's why I don't buy the wysiwyg argument, since with the exception I
note below, a normal programmer can't really tell the difference.
How many programmers even care about the internally stored case of
symbol names? Now, certainly some do, but that is restricted to those
programmers (and their programs) which call INTERN or FIND-SYMBOL. But
currently such programmers already have to know about what the internal
case of symbol names is.
Furthermore, one could extend the standard by providing additional
functions which would make it simpler to use these functions such as
something like INTERN-ACCORDING-TO-READTABLE,
FIND-SYMBOL-RESPECTING-READTABLE, as well as a similar extension to
SYMBOL-NAME which produces the printed representation.
If these are too verbose: INTERN*, FIND-SYMBOL*, SYMBOL-NAME* :)
-Tom.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
Under your proposal it seems that you're ignoring readtable-case
except in your equivalent of Modern mode (as compared to what we do
right now which is ignore readtable-case away only in Modern mode).
In the compromise proposal I made a few days ago readtable-case
is never ignored.
John Foderaro <···@unspamx.franz.com> writes:
> Under your proposal it seems that you're ignoring readtable-case
> except in your equivalent of Modern mode (as compared to what we do
> right now which is ignore readtable-case away only in Modern mode).
Yes and no. You basically control at the package level what you want
to go in the package (i.e. how the package should INTERN the symbol
names). The difference is that given this proposal, READTABLE-CASE is
ignored only if the user says so. Your ignoring READTABLE-CASE breaks
ANSI code, my proposal does not.
Maybe the proposal could be amended in such a way to make sure that
:SYMBOL-CASE-NAME could accept a value (maybe :READTABLE) to make sure
that the case is taken from the readtable.
> In the compromise proposal I made a few days ago readtable-case
> is never ignored.
Yes, but eventually you foresee a situation where ANSI code *will*
break. In my proposal this does not happen. Moreover, users will
have more control about what they want to do and the community will
not split: something you envisioned in your proposal.
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
Ok let's assume that *package* is the common
lisp package.
In ANSI common lisp this returns nil since you
get two distinct symbols |car| and |Car|
(progn
(setf (readtable-case *readtable*) :preserve)
(eq (read-from-string "Car")
(read-from-string "car")))
According to you what propose, the symbol-name-case
of the common lisp package is :ignore, meaning that lookups
are done in a case insensitive manner, thus both of these
read-from-strings return the CAR symbol that's defined
by the ANSI spec. Thus this expression returns t.
Obviously I must have misunderstood your proposal but even
after rereading it I can't figure out what I've missed.
John Foderaro <···@unspamx.franz.com> writes:
> Ok let's assume that *package* is the common
> lisp package.
>
> In ANSI common lisp this returns nil since you
> get two distinct symbols |car| and |Car|
>
> (progn
> (setf (readtable-case *readtable*) :preserve)
> (eq (read-from-string "Car")
> (read-from-string "car")))
>
>
> According to you what propose, the symbol-name-case
> of the common lisp package is :ignore, meaning that lookups
> are done in a case insensitive manner, thus both of these
> read-from-strings return the CAR symbol that's defined
> by the ANSI spec. Thus this expression returns t.
Yes.
> Obviously I must have misunderstood your proposal but even
> after rereading it I can't figure out what I've missed.
I'd say that we just interpret things a little differently. All in
all, this is what you also put in your proposal. I just added the
machinery to let the user have as much control as possible, while
trying to make sure that you won't have to make a global transition to
a Lisp where current ANSI programs will eventually break.
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
Marco Antoniotti <·······@cs.nyu.edu> writes:
> John Foderaro <···@unspamx.franz.com> writes:
>
> > Ok let's assume that *package* is the common
> > lisp package.
> >
> > In ANSI common lisp this returns nil since you
> > get two distinct symbols |car| and |Car|
> >
> > (progn
> > (setf (readtable-case *readtable*) :preserve)
> > (eq (read-from-string "Car")
> > (read-from-string "car")))
> >
> >
> > According to you what propose, the symbol-name-case
> > of the common lisp package is :ignore, meaning that lookups
> > are done in a case insensitive manner, thus both of these
> > read-from-strings return the CAR symbol that's defined
> > by the ANSI spec. Thus this expression returns t.
>
> Yes.
>
> > Obviously I must have misunderstood your proposal but even
> > after rereading it I can't figure out what I've missed.
>
> I'd say that we just interpret things a little differently. All in
> all, this is what you also put in your proposal. I just added the
> machinery to let the user have as much control as possible, while
> trying to make sure that you won't have to make a global transition to
> a Lisp where current ANSI programs will eventually break.
Allow me to add a note here.
All the proposals I saw deal only with READTABLE-CASE manipulation.
In the case of John's proposal, there is a blanket statement that
institutes the behavior of symbol lookup on certain (all) packages.
My proposal (which is beyond ANSI) explicitely gives the control about
how symbols get interned in packages to the user, and IMHO it obviates
the problem of eventually breaking currently working ANSI packages.
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
Kent M Pitman <······@world.std.com> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> ...
> > All the proposals I saw deal only with READTABLE-CASE manipulation.
> > In the case of John's proposal, there is a blanket statement that
> > institutes the behavior of symbol lookup on certain (all) packages.
> > My proposal (which is beyond ANSI) explicitely gives the control about
> > how symbols get interned in packages to the user, and IMHO it obviates
> > the problem of eventually breaking currently working ANSI packages.
>
> As I read it, your proposal is still technically incompatible with the
> standard because the standard allows a package to observe the presence
> of other packages and to manipulate their symbols. Since the operation
> of existing operators would yield surprising (i.e., non-standard) results
> on these otherly defined packages, it does create a problem.
I can see that there might be some problems in this respect. However,
I tried to account for these effects by imposing limitations on
IMPORT. I might not understand the subtleties of the problem. Do you
have an example at hand?
> Further, I think your solution (which appeared to deal with the
> problem at the intern level, if I remember right?)
Not quite. In the case of :IGNORE :SYMBOL-CASE-NAME (the proposed
default), INTERN still works in a case sensitive manner, *after* the
reader has done its case translation.
The difference comes at the FIND-SYMBOL level.
> has the problem
> that ANSI is already case-sensitive at the intern level, so adding the
> ability to be case-sensitive there is meaningless.
I agree that it is meaningless at the present. However, I must say
that I am trying to accommodate John's desires here.
> The problem of
> case-translation occurs at read time, not at intern time, so it's as
> if you're suggesting retrofitting other ANSI CL packages be
> case-insensitive during interning. But that would break many ANSI CL
> packages if you just did it by default, since some "hide" seldom-used
> or internal symbols by making them lowercase and others use mixed-case
> or lowercase just out of preference. So that can't work by default;
> and if you require a special option to "protect" such packages, those
> package definitions would have to be changed, undercutting again the
> stability of the standard because already working standard code would
> have to be changed to accomodate this new feature. At the point you
> say it's ok to break existing code, there are lots of things open.
> Many of us don't want to do that.
This is a vary serious counter argument. However:
1 - I am suggesting to make the COMMON-LISP case insensitive upon
symbol lookup in a restrictive way and in a way that will, in the
future, be under programmer/user control. Since the COMMON-LISP
package is standard and all its exported symbols are known, I do
not see much of a problem in this case.
2 - If people are using the trick of hiding seldom used symbols or
internal symbols by making them lowercase, this means that, given
a particular READTABLE-CASE they did something along these lines:
- READTABLE-CASE is :UPCASE
Then people either explicitely used excaping (like
|lower-case-symbol|), or they did an explicit INTERN with a
lowercase string (like (INTERN "lower-case-symbol")), or
something equivalent.
In this case, the same people must have used these
"personal" symbols like
(foo '|lower-case-symbol|)
or
(|lower-case-symbol| 1 2 3)
or even as
(bar (find-symbol "lower-case-symbol"))
(assuming we are in the correct package).
In this case and with :SYMBOL-CASE-NAME set to :IGNORE, your
code would "break" if an only you did something like
(zot (find-symbol "LOWER-case-SYMBOL"))
This would have caused an error in the ANSI package (given
that the user of the symbol did that on purpose), but it
will not quite couse an error with my proposal.
I believe that the user/programmer of the ANSI package is
very, very unlikely to have used such an idiom. Hence, the
proposed case with :SYMBOL-CASE-NAME set to :IGNORE should
not hamper the programmer/user.
- READTABLE-CASE is :PRESERVE
In this case, in the past, people must have written their
code with uppercase COMMON-LISP symbols, like
(COND ((lower-case-symbol 23 44) ...)
(T (Mixed-case-Symbol 234)))
In this case the FIND-SYMBOL on "COND" and "T" still works.
And "lower-case-symbol" and "Mixed-case-Symbol" work as well
and as expected with :SYMBOL-CASE-NAME set to :IGNORE.
You may argue that the user/programmer could have written
something like
(defpackage "ZUT" (:use "COMMON-LISP")
(:export "cond")
(in-package "ZUT")
(setf (readtable-case *readtable*) :preserve)
(DEFMACRO cond (&REST clauses) ...)
i.e. by setting up a specific re-definition of "CL:COND" in
the package, while :USE-ing the COMMON-LISP package
(actually the DEFPACKAGE form is sufficient).
This is a problem. Under my current proposal, INTERN would
lookup CL:COND and the end result may be an unwanted
re-definition of a key operator.
However, note that we could make INTERN smarter. INTERN
could favor the 'local' symbol by making it present in the
package, while still making the (uppercase interned) CL:COND
'accessible' through inheritance. FIND-SYMBOL would favor
the 'locally present' symbol anyway.
In the case of a package defined as
(defpackage "WHY-WAS-I-WRITTEN-LIKE-THIS?" (:use "COMMON-LISP")
(:import-from "COMMON-LISP" "COND")
(:export "cond"))
My proposal would still have a problem, but in this case we
can make FIND-SYMBOL smarter in the case of a
:SYMBOL-NAME-CASE set to :IGNORE.
When :SYMBOL-CASE-NAME is :IGNORE, FIND-SYMBOL could first
do a lookup using STRING= and then a lookup using
STRING-EQUAL as proposed if no symbol was found.
- READTABLE-CASE :DOWNCASE or :INVERT
I am sure other problems may creep in.
I admit that this is becoming more complex. But, I also believe that
is is still saving both goat and cabbage :)
>
> If we were designing a system anew, I might indeed agree that an
> intern-level case-translation system rather than a read-level one
> could have some advantages, or at least would be worth discussing.
> But in the existing situation, I don't see how this is a way out of
> existing problems as much as a way of trading one set of problems for
> another.
In my proposal, INTERN-level case translation happens only if you
explicitely set :SYMBOL-NAME-CASE to either :UPCASE, :DOWNCASE, or
:INVERT. I.e. only for newly written packages for which the
programmer/user makes a conscious decision to go ahead with this.
Otherwise you can expect the package to be in :IGNORE mode, which
affects only FIND-SYMBOL. We can also decide to make the default
:PRESERVE (except, I should add, for the COMMON-LISP package and
probably the KEYWORDS one).
All in all I believe that, while I must admit that breakage of ANSI
packages is possible, it is much, much, (and much) less likely than in
the other proposals I have seen. (Unless of course you want to stick
to ANSI, which is also fine with me).
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
Marco Antoniotti <·······@cs.nyu.edu> writes:
> I admit that this is becoming more complex. But, I also believe
> that is is still saving both goat and cabbage
Marco,
your proposal is too complicated, too much...just too much! I feel
like you're introducing noise into the problem; like you're just
adding complexity to a very simple problem.
The actual solution does not require such insanity.
Just think of it this way:
If you want CL to be case-sensitive, then you'll have to do one of the
following:
1) set the readtable-case to :preserve and either write all symbols in
the :cl package in uppercase, or
2) define a package that uses what KMP suggested, which is the
:lowercase-cl-package (or whatever he called it). You can define
that package yourself. Have fun with it.
3) set the readtable-case to :invert (and probably *print-case* to
:downcase), and just KNOW what it does. That way:
1) you don't break with the standard
2) you don't add complexity
*3) you can easily link to foreign code (Java, C, whatever), both
foreign calls and callbacks.
*(3) simply requires that you consider reading the foreign stuff with
the :invert rules as well. This is the implementor's problem,
and it's not a hard problem, I imagine.
Between reader macros, readtables, printer variables, and simply don't
see why _anyone_ should be breaking an implementation. The more I
think about this, the stupider it gets, and John Foderaro just keeps
on fighting it. Even reading the arguments objectively leads me to
think that there's just no end to this, and that he'll never see it.
I believe that, both for the implementors and the users, if what
Common Lisp currently has is still not enough to acheive what you're
trying to do with respect to case, then you just want too much, and
people like you probably shouldn't be driving the language.
If Franz wanted a case-sensitive Common Lisp, then they could have
just put the right stuff in their dot-clinit.cl file, commented by
default, of course. I can't imagine that the code (all standard) to
accomplish what they wanted out of all this would be more than a dozen
or so lines.
Following this discussion has been very enlightening about Franz. How
much they seem to value the opinions of the community, and key figures
who care a lot about the language and who have spent a lot of time
trying to solve the problems, is scarily low. Basically, John
Foderaro disagrees with just about everyone, despite the fact that the
arguments being made are sound.
If it ain't broken, don't fix it.
case closed.
dave
David Bakhash <·····@alum.mit.edu> writes:
> Following this discussion has been very enlightening about Franz. How
> much they seem to value the opinions of the community, and key figures
> who care a lot about the language and who have spent a lot of time
> trying to solve the problems, is scarily low. Basically, John
> Foderaro disagrees with just about everyone, despite the fact that the
> arguments being made are sound.
Although I agree with you that breaking with the standard was unneccesary,
I think your comment on Franz is inappropriate:
I am impressed by fact that Franz representatives, including John,
actually *do* discuss these matters on comp.lang.lisp. This is a kind
of openness that you won't see from many other companies. That they
enter a somewhat defensive mode is not very surprising - this is
news, after all. Give them some time to think about this before you
condemn them...
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> I am impressed by fact that Franz representatives, including John,
> actually *do* discuss these matters on comp.lang.lisp. This is a
> kind of openness that you won't see from many other companies. That
> they enter a somewhat defensive mode is not very surprising - this
> is news, after all. Give them some time to think about this before
> you condemn them...
Espen. You've got it all wrong. I also commend them for their
participation on the newsgroup. But it doesn't mean that I buy it, or
agree, and we're actually arguing a set of issues that will ultimately
result in decisions.
I only question their practices. Of course, it's up to anyone, at the
end of the day, to decide if they will use Franz, stay with Franz,
trust Franz, etc. I only wanted to raise issues, based on my
_limited_ knowledge. In fact, it's the fact that it is limited, and
yet so slanted that I figured that there is this possibility that I
was in the outlier zone the whole time, and maybe it was just the
Franz New England sales rep that maybe wasn't doing such a great job.
I think that to "condemn" is not necessarily a bad thing, especially
on a newsgroup. But only in the sense of bringing about a positive
change. I'm not a judge or jury, and no one's gonna trust anything I
say here any more or less than what they here from others --
especially if everyone disagrees. And if they do, then I DON'T CARE
that I was wrong. And if I'm "right" then I don't care either, and I
actually hope I am wrong in the general case (though it seems that
further information leads me to think that my original "suspicions"
were on the right track).
I got a personal letter from someone at Franz, and it mentioned
something about my being wrong about something, and that they were
trying to save me some embarrassment. People who are afraid to post
because they're concerned about embarrassment are cowards. I put my
name on these posts, and question. If I think I'm "right" I take a
stand, and if I'm wrong I accept, and then would take a stand on my
improved understanding.
People who can never befriend, or at least work with those they argued
against earlier are grudging, rivalry-oriented morons. I hope you are
not such a person, and I don't think that people at Franz are either.
I certainly am not. It's not about condemnation, so please get it
straight.
dave
David Bakhash <·····@alum.mit.edu> writes:
> I certainly am not. It's not about condemnation, so please get it
> straight.
I'm sorry if that word was too strong in this context. Since I'm not
a native english speaker, it's not easy to weigh my words in such cases.
--
(espen)
David Bakhash <·····@alum.mit.edu> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > I admit that this is becoming more complex. But, I also believe
> > that is is still saving both goat and cabbage
>
> Marco,
>
> your proposal is too complicated, too much...just too much! I feel
> like you're introducing noise into the problem; like you're just
> adding complexity to a very simple problem.
I believe this is a fair comment. I understand that the solution I
propose is complex. And in fact I stated that the main disadvantage
(in the case were it to be accepted by "a sanctioning body") could
have been that some vendors and implementors would have not followed
suite.
It has been fun thinking through all the necessary changes (I missed a
lot of them) that would have given you the ability to keep your
current code as it is and given you the ability to write new case
sensitive code only.
> The actual solution does not require such insanity.
>
> Just think of it this way:
>
> If you want CL to be case-sensitive, then you'll have to do one of the
> following:
>
> 1) set the readtable-case to :preserve and either write all symbols in
> the :cl package in uppercase, or
> 2) define a package that uses what KMP suggested, which is the
> :lowercase-cl-package (or whatever he called it). You can define
> that package yourself. Have fun with it.
> 3) set the readtable-case to :invert (and probably *print-case* to
> :downcase), and just KNOW what it does. That way:
>
> 1) you don't break with the standard
> 2) you don't add complexity
> *3) you can easily link to foreign code (Java, C, whatever), both
> foreign calls and callbacks.
>
> *(3) simply requires that you consider reading the foreign stuff with
> the :invert rules as well. This is the implementor's problem,
> and it's not a hard problem, I imagine.
I understand that this is a solution. However, Franz (actually John)
is rejecting it on the ground that some code may break if it does
contain uppercase only symbols.
Check this out (READTABLE-CASE is :INVERT)
* (symbol-name 'cond)
"COND"
* (symbol-name 'Cond)
"Cond"
* (symbol-name 'COND)
"cond"
*
It is the third case that is not desirable (at least AFAIU).
(BTW. ILISP breaks with READTABLE-CASE set to :invert under
CMUCL. More work to be done).
Having said that, allow me to add that the ANSI standard is fine with
me, but I believe that my (admittedly complex)� solution does save the
day for everyone (at least it tries).
...
Cheers
Marco
� Ok, my solution is complex. However, in my defense, I must say that
I am awed by the amazing complexity of a big part of the ANSI spec.
Both because of its magnitude and because of how much care it shows
in its minute details. The "Effect or READTABLE-CASE on the
Printer" is a case in point: IMHO very little was left to chance and
many ramifications of a decision were very well thought through.
--
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
Marco Antoniotti <·······@cs.nyu.edu> writes:
> I understand that this is a solution. However, Franz (actually
> John) is rejecting it on the ground that some code may break if it
> does contain uppercase only symbols.
Those are NOT acceptable grounds, since their (current) solution also
breaks code *AND* breaks with the Common Lisp standard.
dave
From: Erik Naggum
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <3183236007594313@naggum.net>
* Marco Antoniotti <·······@cs.nyu.edu>
| All the proposals I saw deal only with READTABLE-CASE manipulation.
| In the case of John's proposal, there is a blanket statement that
| institutes the behavior of symbol lookup on certain (all) packages.
| My proposal (which is beyond ANSI) explicitely gives the control about
| how symbols get interned in packages to the user, and IMHO it obviates
| the problem of eventually breaking currently working ANSI packages.
Placing this information in the package is a big mistake. The package
does not know which case you are using today, and it should not know
in the future, either. The package has a hashtable that needs to deal
with access to symbols, and intern needs to know about it, but the
package is the wrong place to store that decision. This is not only a
question of use-package and the "mystery factor" that will force a
user to know which package a symbol is interned in, but of abstraction
and goes to the whole purpose of the package system.
It is _paramount_ that we maintain case insensitivity as a major
concern. If we _design_ for system-wide case sensitivity, we _must_
lose big time on several fronts and we are almost certain to commit a
Foderaro and just go ahead and "solve" all the problems that crop up,
instead of rethinking the problem when the number of problems becomes
too high. Franz Inc's solution, with separate images, global changes
to all symbols, etc, with no memory of original case or anything, is a
fantastic mistake. It "works" because Franz Inc has chosen to invest
the resources it takes to _make_ it work and that has mostly to do
with some irrational antipathies towards upper-case symbols. From
what I can see, it is an unwarranted waste of resources to do it the
way they have done it.
The purpose of a change should be to increase freedom of expression.
Given that, we must consider the consequences of employing both lower-
and upper-case symbols (and code that creates and accesses them) in
the same Lisp image. However, in so doing, we must also consider the
argument that Unicode case translation is expensive. It is expensive
if done wrong, but if we keep in mind that case translation should be
very, very efficient, we optimize this by storing into each character
object as read from a stream more information than strictly necessary
for storing into strings. This is viable because we are going to do a
_lot_ of table lookups at that point, anyway, when using any external
format that translates into Unicode.
#:Erik
--
ALGORITHM: a procedure for solving a mathematical problem in a finite
number of steps that frequently involves repetition of an operation.
ALGOREISM: a procedure for solving an electoral problem in a finite
number of steps that frequently involves repetition of an operation.
From: Tim Bradshaw
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <ey3g0kw27n8.fsf@cley.com>
* John Foderaro wrote:
> Better I think is to declare that in cl-2001 the case of system function
> print names is **unspecified** by the standard and the choice of the
> implementor (and thus the user who is choses the implementor).
> Then five years later we say that cl-2006 will declare that the case
> of system function names is **lower case**.
I kind of like the idea that we might stick with the first stage. if
lowercase & case sensitivity are a win, then people will make their
code work in such a lisp (which would now be allowed by the `standard'
whatever that is to be) in any case. I note that the detailed bit of
the proposal only goes this far too.
I can't find the article now, but I think I liked Erik's scheme more
though.
--tim
From: Tim Bradshaw
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <nkjvgtrkid7.fsf@tfeb.org>
John Foderaro <···@unspamx.franz.com> writes:
>
> 2. readtable-case can have these values
> :normal - meaning convert to the preferred case
> :abnormal - meaning convert to the opposite of the preferred case
> :preserve - do no conversion
> :invert - invert all characters unless the identifier is mixed case
>
> :upcase will be accepted as a deprecated equivalent of :normal
> :downcase will be accepted as a deprecated equivalent of :abnormal
>
> :invert will be deprecated.
>
> [note: better names than normal and abnormal will be chosen].
>
Having :upcase and :downcase be deprecated is no good. It might be OK
when you're using the reader to read Lisp, but sometimes you're just
reading data, and if the spec for your data says uppercase you want it
to be uppercase.
It does seem to me (perhaps I am not reading carefully enough) that
one of the issues in this whole saga is that some people are thinking
of the reader as something that you use just for reading programs: that
is not always the case.
--tim
From: Thomas A. Russ
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <ymilmut12d6.fsf@sevak.isi.edu>
After a bit of thought about the underlying issues, I will ask what I
hope is a not too terribly naive question:
Wouldn't this whole argument essentially go away if one were just to
set readtable case to :INVERT
(setf (readtable-case *readtable*) :invert)
That way one could have case sensitive symbols, both upper, lower and
mixed case. All of the built-in symbols would have to be typed as
lowercase names, but would still be represented as uppercase
internally. Mixed case symbols would be allowed and would be
represented as verbatim mixed case internally (*).
It seems that this solution should satisfy the aesthetics of not having
uppercase either in the input or output, allow mixed case identifiers,
and best of all:
it is in the ANSI standard !!!!
The only place where this might be disconcerting is if someone were to
try the function SYMBOL-NAME on one of the read-in symbols. Of course,
anyone working with SYMBOL-NAME could reasonably be expected to know
about the issues of reader case translation, etc. so I don't see this as
a bit drawback.
(*) I don't understand why the standard didn't invert all the alphabetic
characters, but I guess there must have been some reason.
Example (using ACL 5.0.1 :)
USER> (setf (readtable-case *readtable*) :invert)
:invert
USER> (car '(a b c))
a
USER> (symbol-name 'foo)
"FOO"
USER> (symbol-name 'MyDogSpot)
"MyDogSpot"
USER> (symbol-name 'DANGER)
"danger"
USER> (eq 'DANGER 'danger)
nil
USER>
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
From: Kent M Pitman
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <sfwhf5h3puy.fsf@world.std.com>
···@sevak.isi.edu (Thomas A. Russ) writes:
> ... (setf (readtable-case *readtable*) :invert) ...
> Mixed case symbols would be allowed and would be
> represented as verbatim mixed case internally (*).
> ...
> (*) I don't understand why the standard didn't invert all the alphabetic
> characters, but I guess there must have been some reason.
Because it's not pretty. No one wants when the type
FrobIOSystem
to call a function called fROBiosYSTEM.
But most can agree that among all-lowercase and all-uppercase, each
community has its notion of "normative case" and "unusual case", which
:invert selects among.
I think in fact that if :invert didn't do what it does, it wouldn't be
pracical for you to suggest now. Though I do think it'd be interesting
to hear the arguments for why :invert isn't acceptable, just to understand
the problems it leaves open.
From: Barry Margolin
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <gIDO5.26$sG1.275@burlma1-snr2>
In article <···············@sevak.isi.edu>,
Thomas A. Russ <···@sevak.isi.edu> wrote:
> Wouldn't this whole argument essentially go away if one were just to
>set readtable case to :INVERT
Any data files that were written before doing this would not read back in
properly unless you changed it to :UPCASE or :PRESERVE. If you're
suggesting that the default be changed (including the mode used by
WITH-STANDARD-IO-SYNTAX) then it would be a significant incompatibility.
BTW, I wonder if a historical perspective of *why* CL behaves this way
would be useful. I wasn't there, but I think I can reconstruct some of the
reasons.
* Why is Lisp case-insensitive internally? Because Lisp didn't originally
have string or character data types, so symbols were used in their place.
For string processing, case is often important.
* Why are symbols mapped to a canonical case? To give the illusion of case
insensitivity for source code. In the 60's and 70's there were many
uppercase-only I/O devices in use, so users of those terminals would
perforce write code in uppercase. But users of terminals with lowercase
didn't like having to use Caps-Lock to write their code (they paid extra
for those small letters, and they were determined to use them :). Also,
Maclisp was developed on ITS, which was case-insensitive in many of its
other features (e.g. filenames were all uppercase). So case insensitivity
was perceived as more user friendly and consistent with the rest of the
environment. But they couldn't be truely case insensitive, due to my first
point, so they canonicalized normal input. Interestingly, Multics Maclisp
was case-sensitive and had all the standard symbols in lowercase, because
that was more consistent with the Multics OS's conventions.
* Why map to uppercase rather than lowercase? This is where I'm most
speculative. My theory is that on mixed-case terminals, they liked the
style of having input in lowercase and the computer's output in uppercase,
so they were distinct in a transcript (in typeset transcripts, people often
use different fonts, or bold vs. roman, for the same purpose).
I suspect that Franz feels that most of these reasons are hopelessly
outdated. We now have real strings and characters, so there's little
reason for programs to use symbols as raw data objects, except in code
that's processing source code (e.g. macros that have to construct function
names). Single-case I/O devices are virtually unthinkable (in fact, to
many computer users, single-font devices are considered archaic), so
compatibility with them is not an issue. Whether case sensitivity in
programming languages is good or bad is a religious issue; I believe Franz
was founded by the authors of Franz Lisp, which was developed on Unix and
adopted its case-sensitive, lowercase-preferred style (like Multics
Maclisp, mentioned above), and it appears that they still cling to that
religion.
--
Barry Margolin, ······@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.
From: Thomas A. Russ
Subject: Re: What case problem is Franz trying to solve?
Date:
Message-ID: <ymiem0k23fb.fsf@sevak.isi.edu>
Barry Margolin <······@genuity.net> writes:
> In article <···············@sevak.isi.edu>,
> Thomas A. Russ <···@sevak.isi.edu> wrote:
> > Wouldn't this whole argument essentially go away if one were just to
> >set readtable case to :INVERT
>
> Any data files that were written before doing this would not read back in
> properly unless you changed it to :UPCASE or :PRESERVE.
Sure. But that is true of a lot of other printer and reader control
variables. I would expect that the proper setting of those variables
would be required for writing and then reading a data file. Reading
legacy files might require setting different values.
> If you're
> suggesting that the default be changed (including the mode used by
> WITH-STANDARD-IO-SYNTAX) then it would be a significant incompatibility.
Gosh, no. I wouldn't dare suggest changing the default!! ;)
I suppose that if the readcase :INVERT solution were otherwise
acceptable one could offer a WITH-CASE-SENSITIVE-IO-SYNTAX wrapper that
would set the control variables appropriately.
> * Why is Lisp case-insensitive internally? Because Lisp didn't originally
^^^^^^^^^^^^^^
case-sensitive
> have string or character data types, so symbols were used in their place.
> For string processing, case is often important.
[snip]
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
John Foderaro <···@unspamx.franz.com> writes:
> In article <··············@localhost.localdomain>, ···@bewoner.dma.be
> says...
> > Could you stop this misinformation?
> >
>
> I would if I were.
>
>
> > First of all, ANSI CL is case sensitive.
>
>
> Let's not get too pedantic. In the discussion we've been having the last
> few days we've used the term case sensitive to refer to the the default
> behavior of the reader when it collects the characters that identify a
> symbol. ANSI CL more closely resembles a case insensitive language when
> you compare its behavior to that of other langauges, case sensitive or
> insensitive.
>
I think you deliberately misrepresent ANSI-CL in your document
http://www.franz.com/support/documentation/6.0/doc/case.htm which is
presumably what your README file refers the novice CL programmer too.
You say:
# If you like to work in Lower Case mode then portability to Upper Case
# Mode may cost you the ability to use the full expressibility of the
# Lower Case mode. For example you may want to use the convention that
# your Clos class names are capitalized. Thus you might have a class Box
# and set the value of the symbol Box to the Box class object. You might
# also have another symbol named box whose value is an instance of a the
# class Box. This will work fine in Lower Case mode. However when you
# try reading this code in Upper Case mode the symbols Box and box will
# both end up being the same symbol whose symbol-name is "BOX".
Technically, this is correct, but it gives the novice the impression
that if he has a class Box he can't name a variable box.
Also, the coding style you recommend in that document uses :symbol or
#:symbol in stead of "SYMBOL". There is a trade off in space there
since symbols are typically fairly large. I use the style myself
occasionely and I have nothing against it but if Kent suggests to
provide lower case copies of the :common-lisp symbols you begin a rant
about the megabytes of space this will take. Given that there are 700
and odd symbols in :common-lisp, which is a number I can see you
attain in a moderately large package with your coding style, this
seems inconsistent.
> > Second, case sensitivity has less to do with a modern/ancient
> > distinction and more with an C/Algol background distinction. Most
> > Algol derived languages like Pascal and Ada are case insensitive.
>
> The heritage of the language is irrelevant as to whether it is ancient or
> modern on the timeline. The key point is that most Modern languages
> significant enough to get noticed are case sensitive.
You redefine m0d3rN languages to suit your argument. I've already
quoted you Pascal and Ada, so you add "significant enough to get
noticed". I'll quote you Eiffel to boot, but if only C/C++/Java
satisfies your definition of modern, I'll concede the point. Perhaps
we can change () to {} while we're at it?
> That's got to say something about whether humans are mentally capable of
> dealing with programming in a case sensitive langauge.
The fact that over 1 billion people write in an ideogrammatic language
doesn't mean APL was a good idea ;-)
> If you believe that Lisp should be able to interface with programs
> written in other languages then it is also a significant fact.
Looking at the docs for your Java stuff, it seems it works fine in
ANSI CL mode if you put strings at the appropriate places. To quote
Ada once again, it is to date the only language I know off which has a
standard Annex defining the way to interface to other languages. In
general, interfacing different programming languages involves so many
different difficult arcane and system dependent things that identifier
case is a very minor part of the problem. And frankly, breaking the
code in the language you use to interface to one you obviously don't
want to use is cutting off your nose to spite your face.
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
In article <··············@localhost.localdomain>, ···@bewoner.dma.be
says...
> Technically, this is correct, but it gives the novice the impression
> that if he has a class Box he can't name a variable box.
>
ok that wasn't clear. The idea was that you would store in the variable
Box the class object for a box and in the variable box an instance of
that class. So if both are variables then there is a clash.
> Also, the coding style you recommend in that document uses :symbol or
> #:symbol in stead of "SYMBOL". There is a trade off in space there
> since symbols are typically fairly large.
In the place they are used, the defpackage expression is executed and
thrown away, thus whether you use #:symbol or "SYMBOL" the garbage
collector will recover the space on the next gc.
> I have nothing against it but if Kent suggests to
> provide lower case copies of the :common-lisp symbols you begin a rant
> about the megabytes of space this will take. Given that there are 700
> and odd symbols in :common-lisp, which is a number I can see you
> attain in a moderately large package with your coding style, this
> seems inconsistent.
Keeping two pointers to the same thing makes things hard to manage (if
you've ever used soft or hard links in the Unix you know that you often
end up following pointers to old or non existent files.).
And we would want more than just the common lisp functions to have lower
case names so that we could name them without using the caps lock key.
The lisp I'm running right now has 9146 functions objects in it.
> I've already
> quoted you Pascal and Ada, so you add "significant enough to get
> noticed". I'll quote you Eiffel to boot, but if only C/C++/Java
> satisfies your definition of modern, I'l
'
we all draw the line differently. I'd say that Pascal and Ada are
ancient, as is C.
C++ is modern and of course Java is.
Pascal's descendents Modula-2 and Modula-3 are modern and are case
sensitive (even though Pascal is case insensitive).
> Looking at the docs for your Java stuff, it seems it works fine in
> ANSI CL mode if you put strings at the appropriate places
it's a matter of taste of course. You'll find that since slot names in
Java have case sensitive names too that you'll end up with most of the
program inside string quotes. Sure it's doable but it's not attractive.
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfw1ywkpxmm.fsf@world.std.com>
John Foderaro <···@unspamx.franz.com> writes:
> Keeping two pointers to the same thing makes things hard to manage (if
> you've ever used soft or hard links in the Unix you know that you often
> end up following pointers to old or non existent files.).
> And we would want more than just the common lisp functions to have lower
> case names so that we could name them without using the caps lock key.
> The lisp I'm running right now has 9146 functions objects in it.
So you don't just want to confront everyone with the ability to type a case
and have it be sticky, but you ALSO want to tell them they can only choose
a case that makes you happy?? How amazingly weird.
Correct me if I'm wrong, but isn't the whole point of giving people the
flexibility to have case be sticky so that people can choose whatever case
they want and inflict it on all of their clients?
If I choose to write in all-uppercase, what on earth are you going to
do to make sure you can call my functions without using the caps lock key??
In article <···············@world.std.com>, ······@world.std.com says...
> John Foderaro <···@unspamx.franz.com> writes:
>
> > Keeping two pointers to the same thing makes things hard to manage (if
> > you've ever used soft or hard links in the Unix you know that you often
> > end up following pointers to old or non existent files.).
> > And we would want more than just the common lisp functions to have lower
> > case names so that we could name them without using the caps lock key.
> > The lisp I'm running right now has 9146 functions objects in it.
>
> So you don't just want to confront everyone with the ability to type a case
> and have it be sticky, but you ALSO want to tell them they can only choose
> a case that makes you happy?? How amazingly weird.
>
> Correct me if I'm wrong, but isn't the whole point of giving people the
> flexibility to have case be sticky so that people can choose whatever case
> they want and inflict it on all of their clients?
>
> If I choose to write in all-uppercase, what on earth are you going to
> do to make sure you can call my functions without using the caps lock key??
>
Please rephase. I don't understand what you're getting at. Since I
never tell anyone how to write anything, you must have misunderstood what
I was saying, but I can't understand what understanding you got of it so
I can't clear it up.
John Foderaro <···@unspamx.franz.com> writes:
> In article <··············@localhost.localdomain>, ···@bewoner.dma.be
> says...
> > Technically, this is correct, but it gives the novice the impression
> > that if he has a class Box he can't name a variable box.
> >
>
> ok that wasn't clear. The idea was that you would store in the variable
> Box the class object for a box and in the variable box an instance of
> that class. So if both are variables then there is a clash.
I understood although I've never wanted to do this. But what the CL
novice is going to retain from it is that he can't do
(defmethod foo ((box Box)) nil)
which is false.
> Keeping two pointers to the same thing makes things hard to manage (if
> you've ever used soft or hard links in the Unix you know that you often
> end up following pointers to old or non existent files.).
It would certainly be feasible. Take the print name out of the current
struct and make a symbol a cons of the printname and a struct with the
remaining members.
> Pascal's descendents Modula-2 and Modula-3 are modern and are case
> sensitive (even though Pascal is case insensitive).
>
I've written a fair amount of code in Modula-3, it's a fine language
and Java didn't steal enough from it, but it's a weird argument for
your case. Sure, it's case sensitive but they chose to make the
keywords UPPER CASE and don't give you any choice about it ;-)
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
John Foderaro <···@unspamx.franz.com> writes:
> C++ is modern and of course Java is.
C++ and Java are modern in the sense that GHB is a modern drug, but
does that mean that they are *good* to you?
--
(espen)
From: Pierre R. Mai
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <87u29ga73p.fsf@orion.bln.pmsf.de>
John Foderaro <···@unspamx.franz.com> writes:
> In article <··············@localhost.localdomain>, ···@bewoner.dma.be
> says...
> > Technically, this is correct, but it gives the novice the impression
> > that if he has a class Box he can't name a variable box.
> >
>
> ok that wasn't clear. The idea was that you would store in the variable
> Box the class object for a box and in the variable box an instance of
> that class. So if both are variables then there is a clash.
And why would one want to do that? This is like arguing that if you
want to have a function Box and store this function in the value slot
of Box, too, you can't have another variable called box. While this
is technically true, it begs the question of why you'd want to do it
in the first place: We don't usually store functions in both the
function and value slots of a symbol, and likewise we don't usually
store class objects in both the class and variable namespaces either.
Furthermore, the only place where I'd think this to be really of
interest seems global variables. And if we are talking about globals,
we are talking about special variables in Common Lisp, and those
should definitely not be named Box, but *Box*, for obvious reasons.
Why not just state that you can't have two variables called Box and
box and be done with it. That would have made the problem just as
evident to the programmer as your approach, but would have left out
the preaching of the advantages of "Modern Mode".
> > I've already
> > quoted you Pascal and Ada, so you add "significant enough to get
> > noticed". I'll quote you Eiffel to boot, but if only C/C++/Java
> > satisfies your definition of modern, I'l
> '
>
> we all draw the line differently. I'd say that Pascal and Ada are
> ancient, as is C.
> C++ is modern and of course Java is.
> Pascal's descendents Modula-2 and Modula-3 are modern and are case
> sensitive (even though Pascal is case insensitive).
So let me get this straight: Modula-2, which is a couple of years
older than Ada, _and_ hasn't been updated for ~ 20 years, whereas Ada
has been updated fairly substantially in the 90s, is modern, and Ada
is _ancient_? Not just old, or aged, but _ancient_?
So since Ada has both much more modern programming constructs
(genericity, objects, inheritance, ...), and has been developed later
than Modula-2, what is it that makes Ada ancient, and Modula-2 modern?
Might it be by any chance the case-sensitivity?
I personally am quite willing to concede that ANSI Common Lisp as it
stands has probably not met the needs of a portion of its community
when it comes to case-sensitivity. I'm also convinced that we should
all work towards redressing this situation.
What I don't get, is why you fail to see that people would be a lot
more willing to listen to the issues at hand if they didn't get the
impression that you were trying to discredit case-insensitivity at all
costs.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In article <··············@orion.bln.pmsf.de>, ····@acm.org says...
> Why not just state that you can't have two variables called Box and
> box and be done with it.
Maybe the whole example was too obscure. I was recalling actual code
from a symbolic algebra system named Andante written by
David Barton. Instead of Box there were class objects
assigned to variables like Field and Ring etc.
> So let me get this straight: Modula-2, which is a couple of years
> older than Ada, _and_ hasn't been updated for ~ 20 years, whereas Ada
> has been updated fairly substantially in the 90s, is modern, and Ada
> is _ancient_? Not just old, or aged, but _ancient_?
I was talking about the birth of the language. Ada (aka Green) was
born in the late 70's. I'd agree that Modula-2 is about the
same age and should be classified as Ancient as well.
I only used two terms Ancient and Modern to make things simpler.
anyway, you tell me which languages you consider modern (you can use email
since we're getting far afield from lisp) and then we'll see
if there's anything in common with the majority of them
as regards case sensitivity.
In article <··························@news.dnai.com>, John Foderaro wrote:
>The heritage of the language is irrelevant as to whether it is ancient or
>modern on the timeline. The key point is that most Modern languages
>significant enough to get noticed are case sensitive.
> That's got to say something about whether humans are mentally capable of
>dealing with programming in a case sensitive langauge. If you believe
>that Lisp should be able to interface with programs written in other
>languages then it is also a significant fact.
>
What does the popularity of Visual Basic say about what humans are mentally
capable of? Humans are capable of a great many, many things. However, simply
that people are capable of something isn't enough. There has to be
compelling evidence that actually doing this thing is worth the while. Lisp
can interface quite elegently with other languages without this hack.
Calling foreign functions with strings is a good idea, in my opinion. It
keeps it clear that there be dragons where we're going. If I want to hide
the details of my interface to the other languages I can make little
wrappers. Hell, I could even write a macro to do so for me, generating a
normal Lisp name, draw-line-2d, from DrawLine2D that calls the foreign
function interface appropiately.
--
-Simon Raahauge DeSantis
From: Jon S Anthony
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3A09F2F5.134F@synquiry.com>
John Foderaro wrote:
>
> powerful. The xml parser is brand new and it's an interface to a a case
> sensitive language (xml) which some have called Lisp with angle brackets
> instead of parentheses. The xml parser need an 16-bit character lisp
> and one running in Modern mode. This is how it's most easily written and
> how xml is most easily manipulated. Our feeling is that if you are
> someone who is interested in manipulating xml then you have to be think
> about case sensitivity: <foo> is different than <fOo>. In this case you
> may actually appreciate the Modern mode. There are ANSI lisp xml
> parsers out there. Our xml parser is open source so an ANSI lisp
> derivative could probably be made of it. Also in the end it's customers
> of ours that drive what we do - and by that I don't mean people saying
> that they don't like the idea of a modern only module but people with
> real problems to solve needing, say, our particular xml parser but
> running in ANSI mode.
OK, here's one of those real customers and I can tell you that I am
rather alarmed to find out that the xml parser which _we_ initially
funded (with significant $$ as you probably know) is not going to work
in ANSI mode. Are you really telling me this????
I have to say that one of things I had hoped would come out of this
contract was a Franz supported version which could be used by others,
but not that you would turn around and hang us out to dry.
I suppose our only hope is that
> We have no plans to make any existing facility of ACL that worked without
> Modern mode now require Modern mode. So it will never become less
which I take to me that at least the version we have internally will
still function in ANSI 6.0.
I am _not_ a happy camper.
/Jon
--
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
From: Kevin Layer
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <mkem0ku2r6.fsf@ultra.franz.com>
Jon S Anthony <···@synquiry.com> writes:
> John Foderaro wrote:
> >
> > powerful. The xml parser is brand new and it's an interface to a a case
> > sensitive language (xml) which some have called Lisp with angle brackets
> > instead of parentheses. The xml parser need an 16-bit character lisp
> > and one running in Modern mode. This is how it's most easily written and
> > how xml is most easily manipulated. Our feeling is that if you are
> > someone who is interested in manipulating xml then you have to be think
> > about case sensitivity: <foo> is different than <fOo>. In this case you
> > may actually appreciate the Modern mode. There are ANSI lisp xml
> > parsers out there. Our xml parser is open source so an ANSI lisp
> > derivative could probably be made of it. Also in the end it's customers
> > of ours that drive what we do - and by that I don't mean people saying
> > that they don't like the idea of a modern only module but people with
> > real problems to solve needing, say, our particular xml parser but
> > running in ANSI mode.
>
> OK, here's one of those real customers and I can tell you that I am
> rather alarmed to find out that the xml parser which _we_ initially
> funded (with significant $$ as you probably know) is not going to work
> in ANSI mode. Are you really telling me this????
First, the version you paid for isn't the version that John was
talking about. Your version is DOM based. The version referenced
above is this one:
http://opensource.franz.com/xmlutils/pxml.htm
Second, we've delivered the version for the contract, and we haven't
changed it.
We decided to start from scratch because one reason: performance. The
DOM based parser was too slow. I recall from discussions with Franz
people that you guys we not unhappy with the performance. Well, I
was. I was using the DOM version to parse our website, and it took
way too long and took too much memory. The version we have released
is easily 20 times faster, and it uses a lot less memory in the
process.
Another reason the DOM based parser was abandoned was conformance.
The new parser passes all but a few of the http://www.oasis-open.org
tests. An analysis of the failures is here:
http://opensource.franz.com/xmlutils/pxml.htm#conformance
It was clear the DOM parser would not do well on the tests.
This is why we rewrote the XML parser.
> I have to say that one of things I had hoped would come out of this
> contract was a Franz supported version which could be used by others,
> but not that you would turn around and hang us out to dry.
I don't see how we've hanged you out to dry. I am very sorry you feel
this way.
> I suppose our only hope is that
>
> > We have no plans to make any existing facility of ACL that worked without
> > Modern mode now require Modern mode. So it will never become less
>
> which I take to me that at least the version we have internally will
> still function in ANSI 6.0.
>
> I am _not_ a happy camper.
Given the above explanation, are you happier?
From: Kevin Layer
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <mkaeb8u299.fsf@ultra.franz.com>
Jon S Anthony <···@synquiry.com> writes:
Having switched to gnus for sending my reply to you, I screwed up and
sent the draft prematurely.
I wanted to add some more.
More reasons for the new XML parser:
The programming model in the new one is simpler.
The speed of the DOM parser is roughly equivalent to the Java DOM
parser. We feel the importance of XML parse for e-commerce is
critical. I've seen references in the press (June 1, 2000 issue of SD
Times) about how the JDOM has "become an albatross around developer'
necks" because of the weight of the implementation.
Getting back to the new XML parser, it is intended to run in Modern
mode. It works somewhat in ansi mode, but not well. The author and I
looked at it, and it wouldn't take much to make it work in ansi mode.
We do give out the source code, so users can even do it themselves.
Perhaps at some point we'll do the work. I don't know.
Even if it is fixed, the parse output will be ugly in ansi mode
because all the symbols will have | around them. XML is case
sensitive, after all.
Kevin Layer
Franz Inc.
Kevin Layer wrote:
>
> Getting back to the new XML parser, it is intended to run in Modern
> mode. It works somewhat in ansi mode, but not well. The author and I
> looked at it, and it wouldn't take much to make it work in ansi mode.
> We do give out the source code, so users can even do it themselves.
> Perhaps at some point we'll do the work. I don't know.
>
> Even if it is fixed, the parse output will be ugly in ansi mode
> because all the symbols will have | around them. XML is case
> sensitive, after all.
>
I personally would put up with ugly printed XML parse output if it meant
I could use the parser alongside ANSI code without having to modify
either one of them. How often do you look at raw XML parse trees,
anyway, except while debugging?
We all appreciate having a free fast XML parser (at least, I do! I need
to mung XML and was not looking forward to writing a parser or tuning
someone else's. As a customer, thanks!). We're just greedy users who
want both new tools and the benefits of working in a language whose
specification doesn't change weekly.
If someone made changes to your parser to make it work in ANSI mode, and
submitted them to you, would you accept them and fold them in (assuming
they didn't completely uglify the code)?
--
Remove obvious stuff to e-mail me.
Bob Bane
From: ·····@known.net
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <m3hf5fyz0c.fsf@relay.known.net>
Bob Bane <····@removeme.gst.com> writes:
> Kevin Layer wrote:
> >
> > Getting back to the new XML parser, it is intended to run in Modern
> > mode. It works somewhat in ansi mode, but not well. The author and I
> > looked at it, and it wouldn't take much to make it work in ansi mode.
> > We do give out the source code, so users can even do it themselves.
> > Perhaps at some point we'll do the work. I don't know.
> >
> > Even if it is fixed, the parse output will be ugly in ansi mode
> > because all the symbols will have | around them. XML is case
> > sensitive, after all.
> >
> I personally would put up with ugly printed XML parse output if it meant
> I could use the parser alongside ANSI code without having to modify
> either one of them. How often do you look at raw XML parse trees,
> anyway, except while debugging?
>
> We all appreciate having a free fast XML parser (at least, I do! I need
> to mung XML and was not looking forward to writing a parser or tuning
> someone else's. As a customer, thanks!). We're just greedy users who
> want both new tools and the benefits of working in a language whose
> specification doesn't change weekly.
>
> If someone made changes to your parser to make it work in ANSI mode, and
> submitted them to you, would you accept them and fold them in (assuming
> they didn't completely uglify the code)?
Yes, assuming we agreed with the changes. I might even do it myself,
in my spare time.
Kevin Layer
Franz Inc.
From: Jon S Anthony
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3A0C476A.F98@synquiry.com>
Kevin Layer wrote:
> Jon S Anthony <···@synquiry.com> writes:
>
> First, the version you paid for isn't the version that John was
> talking about. Your version is DOM based.
>
> Second, we've delivered the version for the contract, and we haven't
> changed it.
I take this to simply be that my original point,
> > which I take to mean that at least the version we have internally
> > will still function in ANSI 6.0.
is true. However,
> We decided to start from scratch because one reason: performance. The
> DOM based parser was too slow. I recall from discussions with Franz
> people that you guys we not unhappy with the performance.
This is simply false. I have the evidence if you really want it.
What was stated quite clearly was that the performance was _not_ good,
but that correct functionality was the _first_ priority, and _then_
performance would be addressed. I suppose this was another thing that
was lost when Lewis left Franz.
> The version we have released is easily 20 times faster, and it uses
> a lot less memory in the process.
...
> I don't see how we've hanged you out to dry. I am very sorry you feel
> this way.
...
> Given the above explanation, are you happier?
Not particularly. You have created a new xml parser (which looks to
be significantly better) and which we are not going to be able to use
since it only "works somewhat in ansi mode" and really is intended to
only be run in "modern" mode. Obviously Franz is free to do whatever
it wants as I would have to agree that the contract was (basically)
completed. OTOH, I would've hoped that we would not have been left
out and forgotten wrt requirements for this new version.
> Getting back to the new XML parser, it is intended to run in Modern
> mode. It works somewhat in ansi mode, but not well. The author and I
> looked at it, and it wouldn't take much to make it work in ansi
> mode. We do give out the source code, so users can even do it
> themselves. Perhaps at some point we'll do the work. I don't know.
>
> Even if it is fixed, the parse output will be ugly in ansi mode
> because all the symbols will have | around them. XML is case
> sensitive, after all.
First, that is subjective. Second, what makes you think the parser
output in Lisp is going to be viewed by anyone? I'm not sure that
makes any sense except for possibly debugging purposes. The whole
idea is that you pull this stuff into a Lisp representation for
_internal_ processing and then squirt the results back out in XML to
be "viewed" or otherwise used by the usual XML tools. That's
certainly how you would typically use it in an ecommerce setting, and
that's true of how its used here.
/Jon
--
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
From: ·····@known.net
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <m3em0jyyuo.fsf@relay.known.net>
Jon S Anthony <···@synquiry.com> writes:
> Kevin Layer wrote:
>
> > Jon S Anthony <···@synquiry.com> writes:
> >
> > First, the version you paid for isn't the version that John was
> > talking about. Your version is DOM based.
> >
> > Second, we've delivered the version for the contract, and we haven't
> > changed it.
>
> I take this to simply be that my original point,
>
> > > which I take to mean that at least the version we have internally
> > > will still function in ANSI 6.0.
>
> is true. However,
>
> > We decided to start from scratch because one reason: performance. The
> > DOM based parser was too slow. I recall from discussions with Franz
> > people that you guys we not unhappy with the performance.
>
> This is simply false. I have the evidence if you really want it.
> What was stated quite clearly was that the performance was _not_ good,
> but that correct functionality was the _first_ priority, and _then_
> performance would be addressed. I suppose this was another thing that
> was lost when Lewis left Franz.
Well, I'm sorry for that. I did ask the question and I've reported
the answer I got.
> > The version we have released is easily 20 times faster, and it uses
> > a lot less memory in the process.
> ...
> > I don't see how we've hanged you out to dry. I am very sorry you feel
> > this way.
> ...
> > Given the above explanation, are you happier?
>
> Not particularly. You have created a new xml parser (which looks to
> be significantly better) and which we are not going to be able to use
> since it only "works somewhat in ansi mode" and really is intended to
> only be run in "modern" mode. Obviously Franz is free to do whatever
> it wants as I would have to agree that the contract was (basically)
> completed. OTOH, I would've hoped that we would not have been left
> out and forgotten wrt requirements for this new version.
>
>
> > Getting back to the new XML parser, it is intended to run in Modern
> > mode. It works somewhat in ansi mode, but not well. The author and I
> > looked at it, and it wouldn't take much to make it work in ansi
> > mode. We do give out the source code, so users can even do it
> > themselves. Perhaps at some point we'll do the work. I don't know.
> >
> > Even if it is fixed, the parse output will be ugly in ansi mode
> > because all the symbols will have | around them. XML is case
> > sensitive, after all.
>
> First, that is subjective. Second, what makes you think the parser
> output in Lisp is going to be viewed by anyone? I'm not sure that
> makes any sense except for possibly debugging purposes. The whole
> idea is that you pull this stuff into a Lisp representation for
> _internal_ processing and then squirt the results back out in XML to
> be "viewed" or otherwise used by the usual XML tools. That's
> certainly how you would typically use it in an ecommerce setting, and
> that's true of how its used here.
I wasn't clear. I was thinking that some people might want to create
xml by creating the Lisp form of it. We do this for our
documentation. We call it lxml. All our documentation for 6.0
(except for a couple of items) is now in lxml. We create documents in
this form. Other people might want to do this, too.
Kevin Layer
Franz Inc.
John Foderaro wrote:
>
> I've been using
> a lisp in Modern mode for over 20 years and I've never been tempted to
> use such a symbol. However I was writing code in Lisp to run in a Java
> VM
That was very far sighted of you.
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfwofzqzezd.fsf@world.std.com>
Francis Leboutte <··········@algo.be> writes:
> John Foderaro <···@unspamx.franz.com> wrote:
>
> >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.
>
> That sounds good, we need a *faster* evolving Standard Common Lisp
Which might or might not mean a faster evolving core. I think we are
divided on this point of debate, but I begin with the belief/assumption
that any language that needs to evolve doesn't require changing ANSI CL
to get to. I believe this partly because I see enormously
(read: prohibitively) high community cost for making this change, and
nothing I can think of that asks for change in the ANSI CL "core" is
worth the dollars I think it would cost to implement such change. So
I'd leave this fixed.
> (BTW as Ken
[Kent]
> Pitman said it somewhere, ANSI looks to be a too slow vehicle - this
> would be a better discussion subject than the current one...)
Well, it is to slow for me for "new development", which is what I think
should be done. I think it's deliberately slow in order to assure stability
of things that are "basically well-understood and agreed upon". Put another
way, it's not a tool for language design, it's a tool for putting to bed
things that are designed in a firm way that stays put. We use the metaphor
"cast in concrete" and I think that's a good one.
The need for a standard at all came about years ago because Lisp was changing
so fast that people building applications were hurting by having to forever
be jumping to make repairs every time some "language designer" or "language
implementor" (the two concepts were then blurred) got the energy to make a
change. We didn't mean to cut off experimenting, only to allow the market a
choice to either use a solid, standard product and avoid constant change if
that's what they wanted or to use what we imagined at the time would be the
alternative which was a rapidly changing but high-maintenance alternative.
We assumed there would be a healthy business in both, and that the successes
demonstrated in the latter would filter down eventually into the former by
deliberative process.
I'm all for experimentation. I just don't regard such experimentation as
standard. I don't totally understand Franz's resistance to just coming out
and saying, as someone [Erik?] suggested, that they want to sell Franz lisp
and not Common Lisp. That seems an entirely plausible and defensible
situation, and not logically inconsistent with their present market pitch,
which seems to mostly downplay the name of the language they're using anyway,
in favor of merely mentioning words like "dynamic" and "object-oriented".
But the name "Common Lisp" means something--it means it's common, that others
share it, that its a consensus result. And Franz Lisp, whether or not so
named, is not common, not shared, not a consensus result. None of that makes
it bad. But it does mean the name should be chosen right to avoid
misunderstanding.
> Experimenting with new extensions is good even if it breaks the standard,
It's fine for you to assert this, just be careful not to get my name too
close to it as if I might be party to this suggestion. :-) Pending being
convinced otherwise, I completely oppose the "even if" part of this sentiment.
I don't think an "extension" is something the requires change to the part
that is being extended. I do think we should experiment with extensions.
As for the core, we can talk about change if the community desperately feels
it can't get to the extensions it needs, but I think we've had no discussion
among the community about this and I don't see pressing ahead with invasive
change barring some discussion on this.
> I even would
> say, above all if it breaks the standard. However an experiment must
> remains an experiment: no one should be an experimenter without knowing it,
> at some right time conclusions have to be drawn, etc.
It's true, you could just say that some people could sign up for optional
"experimental subject" work. But I guess part of what I'm saying is that
if we invest in experiments that allow the premise that the language is
going to require change, we're going to find that the language requires
change. That's going to follow from the fact that something useful is likely
to result from almost ANY initial conditions, and so eventually someone will
want the initial conditions to be made true in order to be able to use the
results of the experiment in a non-experimental way. It is, therefore,
important to invest wisely in how we experiment, and I say we should first
experiment WITHOUT invasive preconditions, just in case we get success that
way. If we do, there is no NEED to go back and change things. But if a
success would be possible either by changing the core or not, and we begin
by experimenting with changing the core, then pretty soon we'll gratuitous
strong need to change the core in order to leverage a success that oughtn't
have needed said changes.
And the whole point of holding the core stable is because multiple experiments
will be in effect at the same time, and they need a common set of
circumstances. Another bad thing about changing the core for one experiment
is that it potentially injures other ongoing experiments in a way that hasn't
been shown to be necessary either by shaking the foundation upon which
they are built.
However, I think the other point of your remark--that people should
not be subject of an experiment without knowing it--is a good one.
[Some other comments by Francis elided here as I had nothing really to add
to what he'd already said.]
Here's a quiz. Get our your ANSI spec and tell me what does foo
return:
(defvar *x* 0)
(defun foo ()
(setq *x* 1)
*x*)
Anyone reading the ANSI spec would say that it returns 1.
Certainly any Lisp novice would say that it returns 1.
But in a Common Lisp with the threading extension you can't predict what
foo will return. Some other thread could get control and change the
value of *x* before it was returned. [in this particular example ACL
won't run another thread between the setq and the time the value is
pulled out of *x* and returned but I know of Lisps that would].
So according to your notition that no extension should be added that
affects the 'core' of Lisp shouldn't we agree that any lisp that
includes a threading facility shouldn't be called a Common Lisp.
Is CMU CL the only real common lisp?
From: Joe Marshall
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <8zquphoa.fsf@content-integrity.com>
John Foderaro <···@unspamx.franz.com> writes:
> Here's a quiz. Get our your ANSI spec and tell me what does foo
> return:
>
> (defvar *x* 0)
>
> (defun foo ()
> (setq *x* 1)
> *x*)
>
>
> Anyone reading the ANSI spec would say that it returns 1.
> Certainly any Lisp novice would say that it returns 1.
>
> But in a Common Lisp with the threading extension you can't predict what
> foo will return. Some other thread could get control and change the
> value of *x* before it was returned. [in this particular example ACL
> won't run another thread between the setq and the time the value is
> pulled out of *x* and returned but I know of Lisps that would].
In a common lisp with a threading extension, I would indeed be
surprised and dismayed if foo returned anything but 1, IF I DID NOT
EXPLICITLY INVOKE/USE/ENABLE THE THREADING. (and yes, I appreciate
that certain utilities might implicitly use threads).
I would expect a product called `Common Lisp' to work like one of the
standard definitions of `Common Lisp', preferably the latest,
greatest, and most used. I would expect that certain extensions may
invalidate certain parts of the standard, but I would assume that I
would not need to know or understand how if I weren't using those
extensions. I would also assume that if I *did* use such a facility,
it would cause as small a change in the standard semantics as is
reasonable.
So, even if I *did* explicitly want to use the threading option, I'd
be unhappy if foo returned anything but 1 if I was careful not to
screw around with global variables in other threads.
> So according to your notition that no extension should be added that
> affects the 'core' of Lisp shouldn't we agree that any lisp that
> includes a threading facility shouldn't be called a Common Lisp.
Obviously this reply was intended for someone else.
However, I believe that the Common Lisp spec distinguishes between
conforming and non-conforming implementations and conforming and
non-conforming code. I also recall that it says (or implies) that an
implementation that does not follow the standard behavior when given
conforming code is not a conforming implementation.
> Is CMU CL the only real common lisp?
Not today....
-----= 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! =-----
In article <············@content-integrity.com>, ···@content-
integrity.com says...
> In a common lisp with a threading extension, I would indeed be
> surprised and dismayed if foo returned anything but 1, IF I DID NOT
> EXPLICITLY INVOKE/USE/ENABLE THE THREADING. (and yes, I appreciate
> that certain utilities might implicitly use threads).
It's not just certain utilities. If you start our Windows version you
end up in an IDE with threads running. The same is true for Lispworks.
This is likely how novices will first encounter lisp and they don't know
threading from a hole in the ground. Yet they are being put in an
environment where the ANSI spec doesn't always apply. You may recall my
post about *print-base* being bound silently in each thread in ACL.
But I think this is ok. There seems to be this tendency in software
design for designers to think they they are smarter then their users.
Every version of Windows (95,98,ME) has gotten a more and more dumbed
down interface. Using Windows ME is like using a cartoon.
On the other hand I have great respect for the novices. I think that
they can adapt to things that don't quite fit the spec.
From: Joe Marshall
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <zojanopl.fsf@content-integrity.com>
John Foderaro <···@unspamx.franz.com> writes:
> In article <············@content-integrity.com>, ···@content-
> integrity.com says...
> > In a common lisp with a threading extension, I would indeed be
> > surprised and dismayed if foo returned anything but 1, IF I DID NOT
> > EXPLICITLY INVOKE/USE/ENABLE THE THREADING. (and yes, I appreciate
> > that certain utilities might implicitly use threads).
>
> It's not just certain utilities. If you start our Windows version you
> end up in an IDE with threads running. The same is true for Lispworks.
And with ACL running under Emacs. But these threads are, for the most
part, don't destroy the illusion that my program is running in an ANSI
compliant lisp. I assumed that this was by design.
-----= 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! =-----
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <nkjg0l0gci8.fsf@tfeb.org>
John Foderaro <···@unspamx.franz.com> writes:
> It's not just certain utilities. If you start our Windows version you
> end up in an IDE with threads running. The same is true for Lispworks.
> This is likely how novices will first encounter lisp and they don't know
> threading from a hole in the ground. Yet they are being put in an
> environment where the ANSI spec doesn't always apply. You may recall my
> post about *print-base* being bound silently in each thread in ACL.
>
But there's a difference between something that *can't* comply with
the spec and a choice not to. The case for multiprocessing is pretty
clear. For instance what does this return?
(defun silly (cons)
(if (not (consp cons)) t (eq (car cons) (car cons))))
I can think of three answers, actually:
1. Naive ANSI: T;
2. Naive multiprocessing: T or NIL because the cons can be modified
by another thread (of course this depends on the implementation, I don't
know if it can be NIL in ACL, but, for instance
(eq (car x) (progn (sleep 100) (car x))) probably can);
3. Cleverer multiprocessing: T, because the compiler optimizes it away.
But something like (2) is just a property of a multiprocessing system
-- if something like it isn't true, you don't really have
multiprocessing in any interesting way.
Similarly, for a lowercase Lisp, I think that
(string= (symbol-name 'car) "car")
pretty much has to be true. But I *don't* think that:
(string= (symbol-name (read-from-string "foo")) "foo")
has to be true (assume the only bit of the readtable I'm allowed to
change is the case...).
So I think it's really fine to have things like per-thread specials
&c: you *have* to define non standard behaviour for this if you want
multiprocessing, but you don't *have* to define non standard behaviour
for READTABLE-CASE (or readtable-case...): a case-sensitive lisp which
obeys readtable-case is clearly possible, although you probably *will*
need to change what the default value is: that would, to me, be a
change you *have* to make.
--tim
On Wed, 08 Nov 2000 12:08:28 +0100, Francis Leboutte
<··········@algo.be> wrote:
>I think you can easily get rid of some of the critiques (some of them are
>valuable in my opinion) by providing a free ANSI image too from the Franz
>download page and add explanations about the reasons Franz wants to promote
>the 'modern' lisp reader. And hopefully stops this surrealistic thread.
You are suggesting that someone download something instead of spending
a few seconds building something. Depending on connection speeds, the
download could take as long as 1.5 hours. That sounds like a step
backward to me.
Kevin Layer
Franz Inc.
Kevin Layer <·····@known.net> wrote:
>On Wed, 08 Nov 2000 12:08:28 +0100, Francis Leboutte
><··········@algo.be> wrote:
>
>>I think you can easily get rid of some of the critiques (some of them are
>>valuable in my opinion) by providing a free ANSI image too from the Franz
>>download page and add explanations about the reasons Franz wants to promote
>>the 'modern' lisp reader. And hopefully stops this surrealistic thread.
>
>You are suggesting that someone download something instead of spending
>a few seconds building something.
Not at all. Is my written English that much approximate?
>Depending on connection speeds, the
>download could take as long as 1.5 hours. That sounds like a step
>backward to me.
>
>Kevin Layer
>Franz Inc.
--
Francis Leboutte
www.algo.be +32-(0)4.388.39.19
Lieven Marchand <···@bewoner.dma.be> writes:
> John Foderaro <···@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.
>
> 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...
> > 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."
········@hex.net writes:
> Lieven Marchand <···@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 <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfwhf5l63lm.fsf@world.std.com>
John Foderaro <···@unspamx.franz.com> writes:
> 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.
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.
From: Marco Antoniotti
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <y6c66m19hoh.fsf@octagon.mrl.nyu.edu>
John Foderaro <···@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 ····@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
In article <···············@octagon.mrl.nyu.edu>, Marco Antoniotti
<·······@cs.nyu.edu> wrote:
> John Foderaro <···@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 ····@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: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
In article <···············@octagon.mrl.nyu.edu>, ·······@cs.nyu.edu
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.
From: Joachim Achtzehnter
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <m2k8a931r1.fsf@wizard.kraut.ca>
John Foderaro <···@unspamx.franz.com> writes:
>
> If things don't work as people think they should, they generally
> send us email.
Oh yeah! And then people waste their time and money trying to convince
you guys that there is in fact something wrong. Like when your
non-compliant ACL5.x broke a third-party library we were using. It
took us at least half a dozen emails back and forth with at least two
senior Franz people before Franz Inc. finally admitted that the change
could brake ANSI conforming code. Not to mention the time we had spent
debugging that library before we reported the problem.
> Change is difficult but necessary for a language to survive.
If you care about your customers at all, do it by providing extensions
to the standard, not by breaking it. Common Lisp is arguably one of
the best programming languages around, although not many people know
about it. Disregarding the standard just to make it look more "modern"
won't help convince people that this is a mature, well-designed
language.
Joachim
--
work: ········@realtimeint.com (http://www.realtimeint.com)
private: ·······@kraut.bc.ca (http://www.kraut.bc.ca)
Joachim Achtzehnter <·······@kraut.ca> writes:
> > Change is difficult but necessary for a language to survive.
>
> If you care about your customers at all, do it by providing
> extensions to the standard, not by breaking it.
I think that is is the basic sentiment I have, and this says what I've
been trying to say all along. Even though Erik (and probably others)
have put a lot of thought into how Franz can achieve the same ends
without compromising the Standard, I have too, and have posted as much
about it as I have time to.
If Franz does not yet understand why it's important to struggle
through this problem a bit more until they have found a conforming
solution, then I think people will just keep posting, and thinking
about the problem -- even if they don't use Franz in any important
part of their business or life.
I find it odd that individuals are seem to be struggling with this to
no end, apparently more than Franz itself. But I think I've read one
post from a Franz employee that they consider the readtable-case
"broken", and thus a "bug" (IIRC), and that they will set out to fix
it (though ironically, I think it was broken intentionally).
dave
> 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.
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
In article <·················@nyc.rr.com>,
Kenny Tilton <·······@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, ······@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.
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfwn1fet187.fsf@world.std.com>
John Foderaro <···@unspamx.franz.com> writes:
> 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.
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.
>> 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.
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
franz inc.
In article <··························@news.dnai.com>,
John Foderaro <···@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"....
····@mac.com (Keke Abe) writes:
> In article <··························@news.dnai.com>,
> John Foderaro <···@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.
>
> ** (CCL::FF-CALL-SLEP #<SHARED-LIBRARY-ENTRY-POINT "SetWTitle"....
Yes. This is the whole point of the argument, and most Common Lisp
programmers, including myself, are more than happy to use
|CaseSensitiveSymbol|, and even higher-level reader macros like
#_CaseSensitiveForeignCall than to resort to such extreme measures.
Common Lisp already has the ability to handle such things while
adhering to the standard.
In ACL I recall a file which describes all of the ways that ACL does
not conform to the standard. I remember reading through that file
once and realizing that they could easily have obeyed the standard in
some of the these cases, but chose not to (as opposed to there being
subtle bugs that they hadn't gotten to yet). It was their preferred
behavior, I'm guessing. I'm sure that others had read that file, and
I'd appreciated that they compiled such a list of things to be aware
of. Nothing on that list, however, torqued me the way the current
issue does, even though I already have had to mostly give up on using
ACL in most of my work, since I'm just a singleton programmer and
contractor, and the Franz pricing model is prohibitive for me.
I'm glad that people like Keke have seen alternative solutions and
express them in this forum, because it seems almost as though Franz
Inc. might in fact be unaware that such solutions are possible without
breaking something that programmers have come to trust. I've always
agreed with the suggestions that I read in the ACL docs (in fact, a
lot of the what I know, and consider to be excellent programming
techniques I've learned by reading the ACL docs. One of them is in
the doc/case.htm file. One of the great suggestions I read there is:
============ start $ACL_HOME/doc/case.htm snippet ====================
5.3 Creating symbols
The most common non-portable form we come across looks like this
(defun constructor (struct) (intern (format nil "MAKE-~a" struct)))
This assumes that this code will run in Upper Case mode. Writing it as
this allows the case of the "make-" to be determined by the case of
the :make- symbol's printname, which will be correct for the case
mode:
(defun constructor (struct) (intern (format nil "~a~a" :make- struct)))
============= end $ACL_HOME/doc/case.htm snippet ====================
Well, I don't mess with the case mode, as I'm happy with the default
case mode in Common Lisp (i.e. case-insensitive-upper).
Same with defpackage usage, in which I always try to use symbols
rather than symbol names.
Well, if Franz cares, I can easily state with 100% certainty that I am
in favor of _not_ breaking the standard, and having seen many
magabytes of other people's Lisp code over the past few years, I am
100% sure that they won't be pleased with this either, because tip 5.3
above might be a good tip, but it's not the way many CL programmers
operate, and there's a lot of code out there that assumed that the
standard could be counted on.
Also, I think that Franz is getting a false sense of what the outcomes
of such a change will be. Do they think that people will flock to CL
because of this change? Or do they hope that the small percentage of
weak-minded programmers who approach CL with a seemingly open mind,
but then abandon after noting the case rules will now decide to stick
around for a couple more minutes until they find out how many symbols
there are in the :common-lisp package, and if that's okay, maybe
they'll notice a macro definition for the first time, with all the
parens and quotes and backquotes, commas, ,@ signs, and all, and just
say "What is this crap?" and tell their geek friends about what a
nightmare CL is. Common Lisp is not for these people, and we
shouldn't try to make it for them if it means breaking the standard.
Also, I find it hard to believe that Franz is more concerned with
easing entry for new users than keeping loyal patrons happy. This is
an evil sign that I've noticed with many businesses. They treat the
to-be customer very differently from when you finally _become_ a
customer. Once you're in, you get the royal screw, and what can you
do? This is why I utterly despise Bell Atlantic (Verizon), and
Sprint, and like companies that actually care for their customers,
like Xanalys. The before-and-after phenomenon is so apparent to me
that I wonder how these companies manage to get away with it.
John Foderaro has this attitude that he expressed as follows:
"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..."
Basically, you're dealing with someone who values the dollar more than
anything else. Secondly, you're dealing with someone whose ego is
obviously out of control if he thinks his way is better than the
standard's, and he's gonna just say "screw the standard". Thirdly,
you're dealing with someone who's unmistakably used the term "my
code". Is ACL _really_ his code? How many of us have reported bugs
to Franz? How many of us have provided patches and suggestions? How
many software engineers have worked on ACL? Now it's _his_ code?
It's bad enough to have to deal with a corrupt company, but to deal
with someone like this, who _should_ understand the power he has, and
thus the responsibility, but instead makes out like there's no
standard or legacy involved, and tells people to screw off because he's
got his loyal customers by the balls, has made and continues to make
more than enough money, and enjoys the power of being able to change
the behavior of a popular Lisp implementation without regard for the
standard. Now it's _his_ Lisp, and he'll have it his way. "You don't
agree? Then screw off." is what I'm hearing loud and clear. He
doesn't need you anymore, and if *you* don't stay, well, enough will,
and he's ready to take on heaps of new clients who will appreciate his
better judgment.
Power and money coupled with avarice and intelligence make for a scary
combination. This is not the first time, and it won't be the last
time for you'll see this from Franz Inc.
dave
In article <··············@cadet.dsl.speakeasy.net>, ·····@alum.mit.edu
says...
John Foderaro has this attitude that he expressed as follows:
"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..."
You've take a quote out of context and then make a large set of unfounded
conclusions from it. If you read some of the other messages I've
written on this subject you'll see that my philosophy on language design
is dominated by the needs of the end users.
Let me restore the context of the quote so we can really understand what
I was saying. You'll find the quote in question at the end of this
context block:
=========
>> 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.
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.
==========
I wrote the 3 points above in response to someone who was stating that
making the CL reader case-insensitive by default shielded them from
having to confront a mixed case symbol, which they find distateful.
My point 1 was that it didn't really shield them given that we can escape
characters. Point 2 is that people's style preferences can differ widely
and thus there's lots more to confront, confuse and disgust a reader than
merely mixed case symbols. In Point 3 (as well as points 1 and 2) I was
speaking not as an employee of Franz but as one lisp programmer giving
code to another Lisp programmer. This was the context of the original
message where the original poster was saying that if a mixed case lisp
got out there then programmers would be exchanging code and he would then
be confronted with mixed case symbols. For example if you post something
on the newsgroup asking for a program to solve the Rubik's cube and I
send you one you may look at in horror and find that I've written
functions with names like SolveCube (which of course is legal in ANSI
cl). At point you say "no thanks, It's not what I want". This is the
appropriate way to respond if someone gives you something that doesn't
match your tastes.
So in context the commment makes a lot more sense.
As for the rest of your comment I can only say that you are 100% wrong
about me and about Franz.
I'm getting pretty sick of hearing the phrase "break the standard".
First, we can't break the standard. Kent (or someone) already pointed
that out. Second, people that buy our Lisp get many images, some ansi
some not. It's been this way for a long time. People that don't want
to experiment with case sensitivity can steer clear of the Modern
images. We have said we will continue to support ansi mode
***forever***. Third, this whole thing started because I (yes, I made
the decision) trimmed the distribution of the "wrong" (from the point
of view of this forum) image to save space in the Trial edition for
UNIX. It was not some plot by a "corrupt" company to screw people.
On Thu, 09 Nov 2000 00:44:43 GMT, David Bakhash <·····@alum.mit.edu>
wrote:
>John Foderaro has this attitude that he expressed as follows:
>
> "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..."
>
>Basically, you're dealing with someone who values the dollar more than
>anything else.
That is an interesting interpretation. My interpretation is he's
talking about freedom of speech. If I want to speak, I have the right
to say what I want. If you don't like it, you can disagree. If I'm
speaking on behalf of someone paying me (i.e., my employer), then I
have to be careful to speak as they would want me to speak.
How you arrived at your intepretation shows your bias, more than
anything else.
>Secondly, you're dealing with someone whose ego is
>obviously out of control if he thinks his way is better than the
>standard's, and he's gonna just say "screw the standard".
A baseless comment.
>Thirdly,
>you're dealing with someone who's unmistakably used the term "my
>code". Is ACL _really_ his code? How many of us have reported bugs
>to Franz? How many of us have provided patches and suggestions? How
>many software engineers have worked on ACL? Now it's _his_ code?
He wasn't speaking of the code of ACL. He was speaking generally of
code that he would make available publically. By definition, ACL code
doesn't fall in that category.
>It's bad enough to have to deal with a corrupt company, but to deal
>with someone like this, who _should_ understand the power he has, and
>thus the responsibility, but instead makes out like there's no
>standard or legacy involved, and tells people to screw off because he's
>got his loyal customers by the balls, has made and continues to make
>more than enough money, and enjoys the power of being able to change
>the behavior of a popular Lisp implementation without regard for the
>standard
You seem to feel that us offering the option of case sensitivity is a
slap in your face. In find this an interesting reaction. I can
assure you that neither John nor Franz intends it thus. I have known
John for almost 20 years, btw. Your characterization of him is way
off base. Second, he was merely expressing opinions, his own. He
doesn't speak for Franz every time he writes. Oh, I guess I should
say I'm not representing the company, too. I'm speaking as a private
person now.
>Now it's _his_ Lisp, and he'll have it his way. "You don't
>agree? Then screw off." is what I'm hearing loud and clear. He
>doesn't need you anymore, and if *you* don't stay, well, enough will,
>and he's ready to take on heaps of new clients who will appreciate his
>better judgment.
Kevin Layer
Franz Inc.
Kevin Layer <·····@known.net> writes:
> How you arrived at your intepretation shows your bias, more than
> anything else.
That is right. One gathers information from which he or she forms an
opinion, or otherwise stated, a bias. Given the information that I
have gathered over time, I have formed such an opinion. I'd rather
not discuss *all* the reasons I have for my opinions on this forum, as
it's simply too sensitive.
> >Secondly, you're dealing with someone whose ego is
> >obviously out of control if he thinks his way is better than the
> >standard's, and he's gonna just say "screw the standard".
>
> A baseless comment.
Really? Someone who, after dozens of back-and-forths seemed to dodge
obvious questions, all the while spouting what amounted to "what the
standard says doesn't matter so much."
> >It's bad enough to have to deal with a corrupt company, but to deal
> >with someone like this, who _should_ understand the power he has, and
> >thus the responsibility, but instead makes out like there's no
> >standard or legacy involved, and tells people to screw off because he's
> >got his loyal customers by the balls, has made and continues to make
> >more than enough money, and enjoys the power of being able to change
> >the behavior of a popular Lisp implementation without regard for the
> >standard
>
> You seem to feel that us offering the option of case sensitivity is a
> slap in your face. In find this an interesting reaction. I can
> assure you that neither John nor Franz intends it thus. I have known
> John for almost 20 years, btw. Your characterization of him is way
> off base. Second, he was merely expressing opinions, his own. He
> doesn't speak for Franz every time he writes. Oh, I guess I should
> say I'm not representing the company, too. I'm speaking as a private
> person now.
you seem to think that the John you know is the John I know, or the
John that affects me, or the community I care about. Well, let me
tell you flat out that I DON'T CARE what you think of John. I never
intended to change your opinions of him -- especially as a friend. I
was merely voicing my current interpretation of the situation, as best
I could. It is true that such things can be libel, and I hope that
readers don't get the impression that I have any more information
about John Foderaro than I have, based on reading his posts.
I believe that somewhere in your company the sense of responsibility
is disintegrating under the weight of other forces.
I appreciate that you guys provide an excellent Lisp to use, for free,
and that you have undergone extra effort to add additional features to
that implementation which allow users more flexibility in how they
read (and #'read) and write code. This does not somehow excuse you or
your co-workers for breaking with the standard.
Tell me this, Kevin. Is it unrelated that companies fear you guys?
Many of them despise you guys, some your very own customers? I can
openly and honestly say, as for your direct compeditors, that the
sentiment of their customers is _exactly_ the opposite? Using the
language of John Foderaro in my past 4 years of working with Common
Lisp and companies which use Common Lisp, this has been my
overwhelming experience. Do you think that I don't draw correlations?
Or that I view this attack on the standard as anything but an
additional bias? Tell me why I should not?
Do you think that I also didn't take note of the fact that franz
provided their Common Lisp, free of charge (as far as I know) to both
MIT and BU, where I used it for my research, and fully enjoyed it?
And that I recall getting support from you while in grad school? Do
you think I don't notice how good your stuff is? Don't you notice,
when you review the download forms, my name on one of them? Go look.
I'm there, and I've answered the same questions so many times I think
I can get past that form with my eyes closed. Do you think that just
because I'm completely UNhappy with the way you guys approach certain
business decisions, that I discount the technical merits in your
product, or the generosity towards academic institutions? I'm happy
to tell people that I think your Lisp is great, that I used it for my
research in grad school, and all that jazz. But the bottom line for
me with Franz is not a pretty one.
I beg that you not pull a John Foderaro and say something like:
"I'm so happy to have received your post, because it finally explains
all the hostility ... and that this issue is the trigger but not the
true cause of the ..."
It's not. I think that intentionally breaking with the standard in
such a profound way is abysmal -- especially when someone takes the
time to figure out how you can achieve what you want without such
tremendous consequences.
I second what KMP said; if :ansi-cl is among your *features* in Modern
mode, then I'll seriously question your ethics, and would find that
inexcusable.
Try to be considerate of a document into which much thought has been
donated, and a lot of study has gone speaking as someone in the
relative newcomers camp. Being able to count on the standard across
ANSI CL implementations is a big deal for me. If you didn't notice,
it is for a lot of people, many of whom want to see a smooth,
conforming change towards the same goals that you guys might have.
dave
In article <··············@cadet.dsl.speakeasy.net>, ·····@alum.mit.edu
says...
First let me say that I've very proud of our lisp but it isn't my lisp by
a long shot. There are a whole bunch of very talented people who worked
on it. The only reason my name has even come up so much is that I saw a
posting and thought that I'd reply to it to start a dialog which
hopefully would turn into a resolution.
I think that I've responded to every message that was directed to me
(although there may be one or two I missed, it's hard to keep in sync
with two different newsreaders at home and work). There were some
flames directed at me and of course I ignored them. You don't flame
someone if you want to seriously send them any information. The intended
use of a flame is to vent hostility in the writer and to amuse everyone
else but the flamee.
This one-to-many communication medium is flawed. We've gotten calls
from people who got the wrong impression from reading the newsgroup.
One to one communcation is far more effective. Please feel free to give
me a call at 510 548 3600 or email to jkf at franz.com.
-john foderaro
franz inc.
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182791388451168@naggum.net>
* John Foderaro <···@unspamx.franz.com>
| You don't flame someone if you want to seriously send them any
| information. The intended use of a flame is to vent hostility in
| the writer and to amuse everyone else but the flamee.
Let me rephrase this: If someone is angry at you, you ignore them,
because anger is with the sender and has nothing whatsoever to do
with you, what you have done to them, or most importantly of all:
what you could do to reduce or remove that anger. Instead, engage
in passive-aggressive behavior to ensure that people get ever more
infuriated by your attitude and actions. This is a winner, John!
This attitude problem tells me one thing above and beyond anything
else: John Foderaro never makes mistakes, especiall not ones he is
willing to admit could piss people off. If anyone is angry at you,
it's their problem, and you are entirely free to piss them off more
and more, because John Foderaro is _right_ and the whole goddamn
world can go fuck itself if anyone disagrees, is insulted by your
attitude (which it is impossible not to be considering your selfish
arrogance), or wants to change your mind. On top of that, you are
blabbering about Kent being selfish and that that's horrible, which
tells me that you aren't a very honest or even introspective person.
People who aren't primarily concerned with their own interests _and_
aware of the extent to which they are, are dangerous, because they
think they actually speak for and on behalf of somebody else,
somebody "higher" than themselves, which sanctifies their position,
although _they_ themselves (almost) never want anybody else to speak
for or on behalf of them without _their_ consent and influence. All
the tragedy in the world that has been perpetrated by people who
selfishly (in the short-sighted, narrow-minded way) _wanted_ to
think they were just acting in somebody else's interest has told me
one thing: People who think selfishness and looking out for #1 is
the problem are dishonest people nobody should trust. Once they get
beyond that stupid holier-than-thou attitude and realize that it is
_which_ interests you hold as your own that is the issue, there is
hope, both of _including_ them in a community (which means a lot of
people who have usefully similar interests acting together in each
their own interests, always free to leave if theirs differ too much
from the community's, and in having that community work to solve its
real (and not imagined) problems because somebody "unselfishness"
prompts them to think about people who are _not_ in the community.
(John argues about "target audience", but invalidates the whole
concept by rejecting acting in your own interests, obviously not
seeing the glaring contradiction that by excluding those who are not
in the target audience by means we shall never know, he is acting in
a very selfish manner, himself.)
Moreover, reacting in this passive-agressive way is a sure-fire way
to get people who respond to legitimate concerns while your attitude
problem prevents reasonable communication with you, to consider you
an asshole on the personal level, removing any desire to take _you_
seriously enough to discuss anything technical with ou, as you have
done your very best already to tell people that if they don't agree
with you, you can basically just ignore them, _especially_ if they
get angry for so being ignored in the first place.
I flame people to get them to realize that they have done something
wrong. _Very_ few fail to get this message, but those who do fail,
get this notion that they are right _because_ they are being flamed,
and I just added John Foderaro to that list. The smart ones, in
contrast, figure out that even if they would like to believe they
have done nothing wrong, that belief _may_ be wrong and they _can't_
ignore the incoming signal that they may be doing something wrong in
somebody else's eyes. Now I get the signal that John Foderaro does
_nothing_ wrong, so please don't flame him because he can't take it.
Your first comment was that I was your friend and you were "shell-
shocked". I'm sorry to say that won't consider you a friend after
this, because nowhere along the line did you ever pause even to
_consider_ what you had done to "shell-shock" _me_. You shattered a
trust I had very precariously built in you, in Allegro CL, and in
Franz Inc, with a few really stupid moves, and _you_ get sore when I
call attention to this fact. How incredibly _inconsiderate_ of my
and other people's feeelings and reactions you are, John. How
_selfish_, in your terminology, most probably, since you don't seem
to distinguish between inconsiderate behavior towards others and
being concerned with your own interests. You prove this, too, sadly.
No _friend_ has ever insulted me so much as you have in the past few
days -- but I'm sure you don't even realize it, because you don't
care what anybody else thinks at all. There is nothing more to say
to you after this, because if a person is so pig-headed and arrogant
and just plain stupid he doesn't even realize that when people care
deeply about something, they _will_ get angry at each other if some
action or decision or comment poses a threat to that which has been
precariously built over many years, such as a community consensus on
a specification (which you don't share, anyway), even if that threat
is only perceived by one person. The most intelligent course of
action is to try to reduce that perception of a threat, not escalate
it like you do with your "I'm never wrong, you're just nuts because
you want upper-case, and that's insane" attitude.
Ironically, the blanket rejection of people who get angry includes
John Foderaro, who still harbors hatred and other forms of strong
animosity towards both people and decisions in the group of people
who defined the Common Lisp language a really long time ago. If we
take his word for it, that must mean that _he_ did not intend, and
probably _never_ intended, to seriously send the committee members
any information but only wanted to vent his own hostility towards
their decisions. I have had people who side with his view tell me
in private communication that they think people who want all upper-
case symbol names _are_ nuts. Sure, _that's_ going to help you get
a good standard and community consensus for a compromise! The jury
is still out, I guess, but my impression after watching John in
action consistently refusing to get any point of view but his own,
is that _he's_ nuts, not for wanting something other than other
people have wanted, but for never relenting enough to make room for
them so they _wouldn't_ have to fight him and he them. It's just
like watching Israel and Palestine, the most unintelligent peoples
to engage in hostilities after WWII. Even beliggerent, supposedly
legandarily impatient _me_ have room for people being a lot smarter
and knowledgeable and experienced and competent and what not than
myself in some specific areas, they only need to show me what they
are, and trust that I have some such areas,too. John Foderaro
doesn't have that space for other people's competence with differing
views that makes it possible to work within a community setting. I
cannot trust someone who does not even understands _what_ people are
objecting to in what he has done to be able to make any _correct_
decisions, either.
| This one-to-many communication medium is flawed.
*laugh* Right, John! Right! You just can't handle it, but that
doesn't make it anywhere near _flawed_. One-to-many communication
media have always been hard to master, and very few really do, but
that lies solely with the communicator, not the media. But sure,
blame the medium -- that's so _frighteningly_ consistent behavior!
| We've gotten calls from people who got the wrong impression from
| reading the newsgroup.
Really? So the damage control team has discussed your damaging
behavior and you're now receding into oblivion because "the medium
is flawed" and people get "the wrong impression" from what you're
saying? There's _still_ no relation between what you have done and
people's reactions, apparently. That's just _too_ pathetic.
| One to one communication is far more effective.
That's right, John, at least 3000 years of propaganda machinery and
the _very_ successful techniques developed by thoroughly evil people
like Joseph Goebbels and less evil but still as manipulative people
in the advertising and popular culture to make hundreds of millions
of people behave exactly same way are using techniques that are not
as effective as one-to-one communication. This has _nothing_ to do
with your communication skills, of course. You don't make mistakes
at _all_, John, do you?, especially none that would cause people to
laugh in disbelief, be insulted by your very, very low opinion of
people in general or feel strong animosity towards your willingness
to destroy their trust in the language they love and the tools they
really would want to use. So of course it's obvious to you that if
we only communicated with people one to one, we would have much more
_effective_ communication in politics and sales and entertainment
and just about everything. Let's shut down _all_ the mass media and
the churches and the public meetings, too! Clearly, it is much more
_effective_ to have each person talk to each other person on a one
to one basis because there doesn't have to be any consistency to
worry about and if you say something that is actually wrong, you can
probably fool whoever you told it to. Not to mention that nothing
would be embarrassing, anymore, since if you give "wrong
impressions" when you clearly state your opinions, surely you will
continue to do so in one-to-one communication, only nobody else will
be there to share with the hapless victim of what you told them.
Matter of fact, one-to-many communication media are much, much more
_effective_ than one-to-one communication, both to influence people
and make people change their minds. What's required, however, is a
lot less ego investment in what is being said. This requires that
people are fairly intelligent or willing to think more before they
act, as really stupid people tend to think that if someone changes
their mind, that'a a drawback and a problem you can pull out of the
hat if you want to hurt them later because it is somehow shameful to
have been wrong in the past. The shameful thing, however, is to be
wrong in the _present_ when you have sufficient information to know
what's right and act accordingly. When you don't want to do that,
and lots of people see it, of course one-to-many communication is a
serious problem.
I would have been impressed if you had been able to express regret
that you angered people so much, had at least been able to exercise
sufficient introspection and observational skills to realize that
_you_ have pissed someone off who once considered you a friend, too,
so much so that he is unlikely to want to deal with you again, and
actually consider you a liability to his future dealings with Franz
Inc because of your rabidly anti-standard, anti-community stance and
utter unwillingness to listen enough to contrary opinions to even
understand what people are objecting to.
The saddest part of this is that I cannot trust technical arguments
from you after this, either, because I have seen what happens when
you make mistakes and never, ever admit it: It's everybody else's
fault, the whole communication medium is _flawed_, for crying out
loud, and _nothing_ is learned from a negative process. My trust in
people relies on their processes of learning and fixing mistakes,
not in what they specifically think is right, and I have _no_ trust
in your mistake-fixing processes at this time, John. _None_.
I will support Franz Inc _despite_ John Foderaro's influence after
this, but if he is not curtailed and limited from destroying more of
the trust I still have in the company and their products, I shall
need to look elsewhere pretty soon.
What would make _me_ happy? I have decided to post that separately
to avoid the stupid attitude problem that pissing me off gives me no
right to have technical opinions, which John Foderaro harbors.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <nkjem0jhqcr.fsf@tfeb.org>
David Bakhash <·····@alum.mit.edu> writes:
> Tell me this, Kevin. Is it unrelated that companies fear you guys?
> Many of them despise you guys, some your very own customers? I can
> openly and honestly say, as for your direct compeditors, that the
> sentiment of their customers is _exactly_ the opposite?
I feel this is an unjustifiably nasty comment. I have dealt with
Franz as a customer for a long time (more than 10 years) and I don't
think I've met anyone who thinks like this, and I can certainly say
from my own experience that some of their competiitors have been
significantly worse to deal with than they are (including being
significantly more arrogant). Certainly I have never met anyone who
*fears* them: why would you fear them? I think there are a whole load
of (mostly non-technical, though some technical) things Franz do
badly wrong, but I see no reason for this kind of sentiment at all.
--tim (for the record my company does have a (very small) commercial
involvement with Franz, and I am writing this as a private
individual)
Tim Bradshaw <···@tfeb.org> wrote:
>David Bakhash <·····@alum.mit.edu> writes:
>
>> Tell me this, Kevin. Is it unrelated that companies fear you guys?
>> Many of them despise you guys, some your very own customers? I can
>> openly and honestly say, as for your direct compeditors, that the
>> sentiment of their customers is _exactly_ the opposite?
>
>I feel this is an unjustifiably nasty comment. I have dealt with
>Franz as a customer for a long time (more than 10 years) and I don't
>think I've met anyone who thinks like this, and I can certainly say
>from my own experience that some of their competiitors have been
>significantly worse to deal with than they are (including being
>significantly more arrogant). Certainly I have never met anyone who
>*fears* them: why would you fear them?
I could have written something similar ... in French!
>I think there are a whole load
>of (mostly non-technical, though some technical) things Franz do
>badly wrong, but I see no reason for this kind of sentiment at all.
>
>--tim (for the record my company does have a (very small) commercial
> involvement with Franz, and I am writing this as a private
> individual)
--
Francis Leboutte
www.algo.be +32-(0)4.388.39.19
Tim Bradshaw <···@tfeb.org> writes:
> I have dealt with Franz as a customer for a long time (more than 10
> years) and I don't think I've met anyone who thinks like this, and I
> can certainly say from my own experience that some of their
> competiitors have been significantly worse to deal with than they
> are (including being significantly more arrogant).
Okay. So then we have different experiences. I see where you're
coming from, and neither disbelieve nor discount your experience, and
actually I'm happy that you're happy.
> Certainly I have never met anyone who *fears* them: why would you
> fear them?
First off, I didn't say I feared _them_. I do worry about the impact
that they have on the Lisp community, though. But you really want an
explaination of fear for a business?
Okay, Tim. Here's a first shot at an example of how Company might
come to fear ACL.
Suppose Company was in the business of developing software. Company
chose Common Lisp as its primary development language, and Franz's ACL
as the specific implementation. Company noticed that ACL provided
many of the extensions necessary for Company's development needs, such
as networking, multiprocessing, etc. Company understood the basic
pricing scheme concepts.
After a few years of development, deliveries of various products,
Company suddenly notices that Franz has decided that to run a server
application, they will charge _not_ for the single seat, as they used
to, but for each person accessing the server, and at the VAR pricing
(which is far from cheap). Oh, but unfortunately, Company doesn't
know exaclty how many people will access that server. No big deal;
Franz will assume a few hundred, if not more. Do you think that's
something to at least worry a little about, given that you're already
a Franz customer? I'm just happy they changed this pricing thing
_before_ I ever purchased anything from them.
As far as I know, Franz is the _only_ Lisp vendor I'm aware of that
prices this way, with respect to servers. I get sickened that other
vendors might follow along with this pricing approach. Tell me, Tim.
Do I have your consent in feeling this way?
As I've said it once before here, some months back. I priced ACL
against a competing Common Lisp. The prices were an ORDER OF
MAGNITUDE different. In a free market, they can sell it for as much
as they want. And in an open forum, i'll openly admit my utter
disgust with this pricing, and since I do small jobs for small- and
mid-sized companies, I feel that if there's a company out there that's
going to potentially change the direction of Common Lisp away from the
ANSI Standard, I can better believe that don't want it to be Franz.
dave
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey3r94irbn3.fsf@cley.com>
> Suppose Company was in the business of developing software. Company
> chose Common Lisp as its primary development language, and Franz's ACL
> as the specific implementation. Company noticed that ACL provided
> many of the extensions necessary for Company's development needs, such
> as networking, multiprocessing, etc. Company understood the basic
> pricing scheme concepts.
> After a few years of development, deliveries of various products,
> Company suddenly notices that Franz has decided that to run a server
> application, they will charge _not_ for the single seat, as they used
> to, but for each person accessing the server, and at the VAR pricing
> (which is far from cheap). Oh, but unfortunately, Company doesn't
> know exaclty how many people will access that server. No big deal;
> Franz will assume a few hundred, if not more. Do you think that's
> something to at least worry a little about, given that you're already
> a Franz customer? I'm just happy they changed this pricing thing
> _before_ I ever purchased anything from them.
Well, I don't see why this company *fears* the vendor. It's probably
made a mistake in not making sure it has an alternative offering it
can move to, but that's not the vendor's fault. I also don't think I
understand the licensing. This company signed a license with the
vendor for a product. It can continue to use that product under the
terms of that license. If the vendor chooses to require a new license
with dramatically worse terms for a new version of the product, then
the company should sit on the old version, find a different vendor,
and move. That happens all the time.
The situation under which I can understand fear is where the vendor
has a monopoly. I can understand fearing Microsoft: if they do
something bad to the licensing of windows then a lot of people who
want to be in the consumer applications marked have no choice but to
keep using it.
But I can't see a market where you *have* to use Lisp: there are other
languages, and people do develop applications in them. If you choose a
language where there is only one realistic vendor, then you should
make that decision with open eyes -- at some point the vendor *is*
going to try and squeeze as much money out of you as they can without
causing you to reimplement. Of *course* they are going to do that,
this is capitalism! Why should they not?
--tim
From: Lars Magne Ingebrigtsen
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <m3ofzmheos.fsf@quimbies.gnus.org>
Tim Bradshaw <···@cley.com> writes:
> But I can't see a market where you *have* to use Lisp: there are other
> languages, and people do develop applications in them.
Yes.
> If you choose a language where there is only one realistic vendor,
> then you should make that decision with open eyes -- at some point
> the vendor *is* going to try and squeeze as much money out of you as
> they can without causing you to reimplement. Of *course* they are
> going to do that, this is capitalism! Why should they not?
I think you've already answered this above.
A vendor may attempt (and succeed in doing) a short-term price gouge.
It does not make long-term business sense to do so.
I think you'll find that most people here believed that Franz was in
this for the long haul. Perhaps they were wrong. We'll see.
--
(domestic pets only, the antidote for overdose, milk.)
·····@gnus.org * Lars Magne Ingebrigtsen
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey3em0ir7i1.fsf@cley.com>
* Lars Magne Ingebrigtsen wrote:
> I think you've already answered this above.
> A vendor may attempt (and succeed in doing) a short-term price gouge.
> It does not make long-term business sense to do so.
> I think you'll find that most people here believed that Franz was in
> this for the long haul. Perhaps they were wrong. We'll see.
yes, I agree with this, but that's just another decision -- if you
decide to use some tool, you need to take into account the possibility
that the vendor of your tool might behave dumbly and drive themselves
out of business -- people do that all the time. I'm *not* saying
Franz are doing this, but it's something you need to take into account
when choosing any programming language. Again, I don't see this as a
reason for *fear*, it's just a decision you need to make.
--tim
From: Lars Magne Ingebrigtsen
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <m3itpuhbue.fsf@quimbies.gnus.org>
Tim Bradshaw <···@cley.com> writes:
> yes, I agree with this, but that's just another decision -- if you
> decide to use some tool, you need to take into account the possibility
> that the vendor of your tool might behave dumbly and drive themselves
> out of business -- people do that all the time.
Sure. One should, in business negotiations, ideally behave as the
counterpart is a mad criminal. In real life, that's a mighty
difficult standard to live up to. Most people don't have brains that
work that way.
> I'm *not* saying Franz are doing this, but it's something you need
> to take into account when choosing any programming language. Again,
> I don't see this as a reason for *fear*, it's just a decision you
> need to make.
To make my bid for the Analogy Of The Year Competition: One should
always have some trepidation when venturing into an unknown cave. Who
knows -- there may be monsters in there. What David has done is place
a poster outside a particular cave, saying "There be monsters here".
You seem to be saying that it's wrong to do so, since, well, any cave
may have monsters. I think it's a service to the community.
(And if you're in a cave that has a monster in it, you should damn
well be afraid, or get the hell out of there. Or carry a bazooka.)
=> Error: Out of bounds analogy.
--
(domestic pets only, the antidote for overdose, milk.)
·····@gnus.org * Lars Magne Ingebrigtsen
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182957090890974@naggum.net>
* Lars Magne Ingebrigtsen <·····@gnus.org>
| Sure. One should, in business negotiations, ideally behave as the
| counterpart is a mad criminal. In real life, that's a mighty
| difficult standard to live up to. Most people don't have brains that
| work that way.
But that is why we have lawyers. Some people do not understand that
the need for lawyers is just like the need for plumbers -- if you do
not call on them in time, you can get into very serious problems --
but few are prepared to understand _when_ the need for lawyers arise.
It is in my view unwise to deal with a counterpart as if he might be a
criminal -- then you are yourself outside the realm of the law because
the law is not your common ground. Same with following specifications
and standards.
#:Erik
--
ALGORITHM: a procedure for solving a mathematical problem in a finite
number of steps that frequently involves repetition of an operation.
ALGOREISM: a procedure for solving an electoral problem in a finite
number of steps that frequently involves repetition of an operation.
From: Seth Gordon
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3A116E27.F09CF2BC@kenan.com>
Lars Magne Ingebrigtsen wrote:
> Sure. One should, in business negotiations, ideally behave as the
> counterpart is a mad criminal. In real life, that's a mighty
> difficult standard to live up to. Most people don't have brains that
> work that way.
I'm reminded of a remark by Fred Pohl(?) in the _SFWA Writer's Handbook_,
which goes something like this:
"The proper way to negotiate a contract is to assume that you and the nice
person across the table from you are going to drop dead tomorrow, and your
heirs will hate one another's guts."
--
"The big dig might come in handy ... for a few project managers
whom I think would make great landfill." --Elaine Ashton
== seth gordon == ·······@kenan.com == standard disclaimer ==
== documentation group, kenan systems corp., cambridge, ma ==
From: Rob Warnock
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <8usvpf$hgclc$1@fido.engr.sgi.com>
Seth Gordon <·······@kenan.com> wrote:
+---------------
| I'm reminded of a remark by Fred Pohl(?) in the _SFWA Writer's Handbook_,
| which goes something like this:
|
| "The proper way to negotiate a contract is to assume that you and the nice
| person across the table from you are going to drop dead tomorrow, and your
| heirs will hate one another's guts."
+---------------
Or as my old boss John Alderman (back at DCA in Atlanta in the 1970's)
used to say [paraphrased]:
"If you don't trust the person, then don't do business with them.
The contract is there to protect the two parties against everyone
*else* who might want to meddle in your affairs."
-Rob
-----
Rob Warnock, 31-2-510 ····@sgi.com
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182904933425343@naggum.net>
* David Bakhash <·····@alum.mit.edu>
| After a few years of development, deliveries of various products,
| Company suddenly notices that Franz has decided that to run a server
| application, they will charge _not_ for the single seat, as they used
| to, but for each person accessing the server, and at the VAR pricing
| (which is far from cheap). Oh, but unfortunately, Company doesn't
| know exaclty how many people will access that server. No big deal;
| Franz will assume a few hundred, if not more. Do you think that's
| something to at least worry a little about, given that you're already
| a Franz customer? I'm just happy they changed this pricing thing
| _before_ I ever purchased anything from them.
You're looking at a very strange situation and getting it all wrong.
Franz Inc has always demanded royalties for commercial deployment of
their software. The developer license terms have always been just
that: _developer_ licenses. What happened was that they didn't know
what to charge for the evolving server-based applications market, and
for a long time didn't charge anything, despite the very clear text in
the license agreement that you should pay them for commercial use of
their product. Now, did Franz Inc _sue_ you for this violation? Did
they become completely unreasonable and irrational when faced with a
new condition? No. Neither. Many users (me, included) observed that
the license terms had changed for them, but that was only because they
were abusing a loop-hole that it wouldn't take a whole lot of work to
see was just that: a loop-hole. You could argue until you're blue in
the fact that Franz Inc were changing their license conditions, but
the facts remain that (1) you were not licensed to do what you did, so
got something for free, which they have not demanded back payment for,
and (2) when they started to set up a price schedule for this, they
made the same "mistake" they have made on many occasions, namely to
give you a half-offending price up front and fail to understand why
you walk away instead of negotiate.
| As far as I know, Franz is the _only_ Lisp vendor I'm aware of that
| prices this way, with respect to servers. I get sickened that other
| vendors might follow along with this pricing approach. Tell me, Tim.
| Do I have your consent in feeling this way?
You would have had my consent in feeling this way half a year ago,
when I was trying to recover from the serious blow that their first
demand at unlimited server access would have on my work and on our
business. However, despite a very current, very disappointing case,
reasoning with people at Franz Inc have been successful, even if time-
consuming (we don't fit into any of their models, making the situation
hard for us all).
I think Franz Inc have good negotiators. That means you have to look
out for #1 and be aware of what you want to do and why. This may not
be the ideal situation for Common Lisp, but lots of people make the
choice that they would rather stay with Franz Inc and Common Lisp, so
it can't be _wrong_, only unsuitable to your current needs. There is
nothing wrong with that, either. Sometimes, a product simply isn't
for you. Like, at my current target shooting skill level, I'm still
not better than my $500 gun, and it would be a waste of money to go
for a $1000 gun. If and when I outperform my gun, I would upgrade.
If you only produce small tools for small businesses, chances are you
aren't making enough of a difference for them to be better than the
tools you can get at a lot lower prices. This should not piss you off
if you are a rational individual. It should tell you that as your
demands increase and the value of the tool increases with them, you
have an additional vendor to go to; you're not stuck in the low end of
the market, having to change the programming language, which happens
all too often to the many inferior languages.
I'm a very big proponent of professional tools for professionals.
That's probably because I make such tools, myself, so I know what it
takes to succeed in a very small and well-defined area, giving me the
opportunity to understand just how much work it is to do it in a large
area like confomring to a standard and building an environment around
it. (And how easy it is to get lazy and how important it is _not_ to
be lazy in the face of such challenges.) When I was but an egg, I
thought that the price of a software tool should be proportional to my
own value -- except I didn't think of it in those terms then -- and
thus wanted free tools because my time was basically free, too. Now
that my time very far from free, either for me nor my employer, I can
no longer afford to work for free just to lower the price of the tool
because it would cost more to do so than to buy an expensive tool.
I'll make a simple statement and claim that the relationship between
your own value and the price of your tools will remain fairly constant
throughout your carreer, when you look at it in retrospect, mind you.
#:Erik
--
ALGORITHM: a procedure for solving a mathematical problem in a finite
number of steps that frequently involves repetition of an operation.
ALGOREISM: a procedure for solving an electoral problem in a finite
number of steps that frequently involves repetition of an operation.
> * David Bakhash <·····@alum.mit.edu>
> | After a few years of development, deliveries of various products,
> | Company suddenly notices that Franz has decided that to run a server
> | application, they will charge _not_ for the single seat, as they used
> | to, but for each person accessing the server, and at the VAR pricing
> | (which is far from cheap). Oh, but unfortunately, Company doesn't
> | know exaclty how many people will access that server. No big deal;
> | Franz will assume a few hundred, if not more.
Amusingly enough (?), this exact scenario happened to my previous company some
time ago. We were properly licensed for all our development copies as well as
our commercial use. Then we got a big contract; Franz caught a whiff of it,
and suddenly tried to force us into a major new pricing model.
Given that we were making a web server application with potentially millions
of users, Franz's proposed pricing wound up being _orders_ of magnitude more
than our previous arrangement with them. That would have bankrupted us and
killed the deal, so under our time pressure Franz consented to merely hijack
us for as much as they could get away with, which at least allowed us to
continue in business.
But the conclusion at our company was that sole-sourcing Lisp from Franz in a
commercial setting was a disaster, given that Franz was more interested in
extracting as much blood as possible during our moment of weakness, rather than
maintaining long-term relationships. (This, after 10+ years of using Franz
lisp by the principals!)
So: as much as I admire their technical accomplishments, in my view it is
a serious business mistake to rely on Franz for Common Lisp. Use something
like the open source CMUCL instead, which has 95% of Common Lisp, has a much
better/faster compiler than Franz, and has no license issues.
On 11 Nov 2000 04:15:33 +0000, Erik Naggum <····@naggum.net> wrote:
> What happened was that they didn't know
> what to charge for the evolving server-based applications market, and
> for a long time didn't charge anything, despite the very clear text in
> the license agreement that you should pay them for commercial use of
> their product.
We had been paying them under the original license terms, which admittedly
did not anticipate server-based applications. After basing a whole company
on this lisp with this pricing model, Franz changed it from under us the
moment they could get away with it, during a critical period when we couldn't
afford to switch to an alternate vendor.
> Did they become completely unreasonable and irrational when faced with a
> new condition?
In our experience: yes, they did.
> However, despite a very current, very disappointing case,
> reasoning with people at Franz Inc have been successful, even if time-
> consuming (we don't fit into any of their models, making the situation
> hard for us all).
Due to business realities, we couldn't afford the time to negotiate with
Franz. Which made us hostage to their unreasonable demands, and they took
full advantage of it before we could recover from the shock.
I could not in good faith recommend Franz to any commercial enterprise,
and I'd say that if you feel compelled to use it, that you also invest enough
resources in being able to quickly switch to an alternate vendor in case
Franz attempts to blackmail you.
-- Don
_______________________________________________________________________________
Don Geddis http://shop.goto.com ······@goto.com
VP of Technology, GoTo Shopping Phone 650-403-2220
1820 Gateway Drive, Suite 300, San Mateo, CA 94404 Fax 650-403-2201
······@Goto.Com (Don Geddis) writes:
> > * David Bakhash <·····@alum.mit.edu>
> > | After a few years of development, deliveries of various products,
> > | Company suddenly notices that Franz has decided that to run a server
> > | application, they will charge _not_ for the single seat, as they used
> > | to, but for each person accessing the server, and at the VAR pricing
> > | (which is far from cheap). Oh, but unfortunately, Company doesn't
> > | know exaclty how many people will access that server. No big deal;
> > | Franz will assume a few hundred, if not more.
>
> Amusingly enough (?), this exact scenario happened to my previous
> company some time ago. We were properly licensed for all our
> development copies as well as our commercial use. Then we got a big
> contract; Franz caught a whiff of it, and suddenly tried to force us
> into a major new pricing model.
That's very closely in-line with my findings. Probably not a nice
place to be, and so if I were, say a VC, and a software or service
company were using Lisp, I'd be very impressed. If they said they
were using Franz, I'd be very *worried*, unless they somehow managed
to get a piece of paper, signed and notarized, which clearly stated
that there be some basic, fair pricing controls.
> But the conclusion at our company was that sole-sourcing Lisp from
> Franz in a commercial setting was a disaster, given that Franz was
> more interested in extracting as much blood as possible during our
> moment of weakness, rather than maintaining long-term relationships.
> (This, after 10+ years of using Franz lisp by the principals!)
again, this is a bug in their business model. Do they actually think
that this information wouldn't come out? How long did they think they
could get away with such things! This is probably why John Foderaro
prefers one-to-one interactions; it's because eventually, in an open
forum people communicate information and the truth comes out.
> So: as much as I admire their technical accomplishments, in my view it is
> a serious business mistake to rely on Franz for Common Lisp. Use something
> like the open source CMUCL instead, which has 95% of Common Lisp, has a much
> better/faster compiler than Franz, and has no license issues.
Yes. I'm not so concerned with speed, as I mostly design
database-intensive applications where Lisp or Perl don't really make
all that much of a difference. That's why I like the commercial
Lisps. Then again, with CLORB and some of the other free CL stuff
that's coming out, maybe CMUCL isn't such a bad idea. But (thank god)
there are a few good companies out there for Common Lisp that arn't in
the business of hanging their customers by their ankles until their
pockets are empty.
> I could not in good faith recommend Franz to any commercial
> enterprise, and I'd say that if you feel compelled to use it, that
> you also invest enough resources in being able to quickly switch to
> an alternate vendor in case Franz attempts to blackmail you.
Gosh. I guess that even if you're dealing with the best of companies,
it's best to have this stuff pass by your legal department. But with
a company that has a reputation of doing this, it's probably best to
just concede to the fact that there's a long-term safety
vs. short-term efficacy tradeoff, and personally, I tend to lean
toward safety. It's part of caring about your company, your
co-workers, and your principles.
dave
--
p.s. One thing I can just imagine right now are all the people that
feel exactly the way you do, and have similar experiences, but
they're so entangled in their current mess that they don't dare
speak. I think that while you'll certainly end up taking heat
for your openness, a lot of people are feeling vicarious relief.
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey3n1f6rbct.fsf@cley.com>
* Don Geddis wrote:
> I could not in good faith recommend Franz to any commercial enterprise,
> and I'd say that if you feel compelled to use it, that you also invest enough
> resources in being able to quickly switch to an alternate vendor in case
> Franz attempts to blackmail you.
Other than the emotive use of the term `blackmail' this seems like
good, sensible advice, when choosing *any* vendor. If you commit to a
single source then they're going to try to get money out of you at
some point. I don't see why people think this is so wrong!
--tim
Tim Bradshaw <···@cley.com> writes:
> * Don Geddis wrote:
>
> > I could not in good faith recommend Franz to any commercial
> > enterprise, and I'd say that if you feel compelled to use it, that
> > you also invest enough resources in being able to quickly switch
> > to an alternate vendor in case Franz attempts to blackmail you.
>
> Other than the emotive use of the term `blackmail' this seems like
> good, sensible advice, when choosing *any* vendor. If you commit to a
> single source then they're going to try to get money out of you at
> some point. I don't see why people think this is so wrong!
while I agree with you that cautionary meansures are never a bad
thing, I am seriously starting to question _your_ ethics, and given
this information, would _not_ want to do business with any company
where you were anything but a programmer.
Anyway, Tim, I hope that Franz sends you a lolly pop for sucking up to
them so hard during this discussion. But they probably won't, since
Don's response was a confirmation to my "hypothetical" scenario that
_you_ requested.
Now, Tim, are you one of those people who believes that people can do
bad things, just as long as they don't do them to you? And that you
will even support these people as far as to say "Well, of _course_ you
should have watched your back -- didn't you know you were dealing with
a corporation?" Well, that's what you just did.
If someone leaves their front door unlocked, and subsequently gets
robbed, I might say "well, give me a break -- there's tons of theives
out there!" But what I'm hearing is that you would go the extra step
to say "Well, these theives are waiting for you to leave your door
unlocked so they can take everything you've got. I don't see why
people think this is wrong!"
Believe it or not, Tim, just as there are people who can be relied on
for honesty, fairness, and good intent, there are companies that do
their very best to operate under such principles. And guess what?
They can make money too. In fact, they can make a LOT of money, and a
lot of it is based on their clients' knowledge of their proven track
record not just with respect to product offering and delivery, but
also business ethics.
It's like this, Tim. I liked you a lot before this statement. You've
been one of the most helpful guys on this list. I _really_
appreciated your input with the safe Lisp packages (re: conduit.lisp),
and that you provided your code and expertise for the general public.
But if this comment above represents what you're like (and I don't
think it does, or at least I _hope_ it doesn't), then I should tell
you that there are people in the technical community (plenty of them)
that not only value technical expertise, but also ethics -- and not
just with respect to actions, but also intent.
dave
From: Michael Livshin
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <s3y9yqwt7m.fsf@bigfoot.com>
David Bakhash <·····@alum.mit.edu> writes:
> Now, Tim, are you one of those people who believes that people can do
> bad things, just as long as they don't do them to you? And that you
> will even support these people as far as to say "Well, of _course_ you
> should have watched your back -- didn't you know you were dealing with
> a corporation?" Well, that's what you just did.
>
> If someone leaves their front door unlocked, and subsequently gets
> robbed, I might say "well, give me a break -- there's tons of theives
> out there!" But what I'm hearing is that you would go the extra step
> to say "Well, these theives are waiting for you to leave your door
> unlocked so they can take everything you've got. I don't see why
> people think this is wrong!"
Dave, you apperently assume that the behavior of a corporation is as
consistent/predictable/dependable as the behavior of a human. this is
a fallacy.
--
(only legal replies to this address are accepted)
Specifications are for the weak and timid!
-- Klingon Programmer
Michael Livshin <········@yahoo.com> writes:
> Dave, you apperently assume that the behavior of a corporation is as
> consistent/predictable/dependable as the behavior of a human. this is
> a fallacy.
No. You have similarly misunderstood. I don't _assume_ behavior in
any way. In fact, I don't even assume the bahavior of most of the
people I know to be human.
Behind any corporation are people who are responsible for the actions
of the corporation, and the general direction they tend to go. I
understand the very difficult positions and situations to some extent,
but probably not well enough to be doing it. I still believe,
however, that corporations have an ethical responsibility.
Unfortunately, ethics is a relative term. Consider that if you tell
someone you love her, care for her, will be there by her side forever,
then dump her after you got what you wanted, with no written marital
stuff, no public disclosure or statements, then yeah, she can't sue
you, and you can walk away, and still be considered a mindful,
law-abiding citizen. But she'll still hate your guts.
My point in these silly analogies is to try to show that there's more
to this whole thing than just money, and even law, and justice as it
is defined. I don't demand anything of Franz. I implore it. If
they, or any company I care about for whatever reason, does something
I consider good, then I endorse it. And if a company acts against the
best interest of something I care about, such as in the case of Franz
and the Common Lisp Standard and the Common Lisp community, then I
will argue against it.
If it helps you to understand this, note that GM and Microsoft are two
very large companies. But despite that they are companies, comprised
of thousands, or tens of thousands of people, can you see how they
differ?
Suppose that I view corporate entities a bit like human ones. Does
that bother you? Do you have a hard time understanding this? Would
you like me to point you to the many aspects of our economy that
derive law from this very analogy?
dave
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfwhf5e5o7u.fsf@world.std.com>
David Bakhash <·····@alum.mit.edu> writes:
> Behind any corporation are people who are responsible for the actions
> of the corporation, and the general direction they tend to go.
I believe this is the fallacy that Michael Livshin was referring to.
A corporation is a legal entity with the legal status of a person. It
lives on regardless of whether everyone in the corporation is fired
and replaced tomorrow with new people. It is sometimes a useful
fiction to deal with a corporation as if you can depend on the same
folks being there on every new day, but it's important to understand
formally that you have no legal right to this expectation. Deals made
with individuals are deals made with individuals; deals made with
companies are deals made with pieces of paper.
I worked at Symbolics long enough to watch the entire management of
the company replaced, and ended up with divided loyalties. I loved
the company but what WAS the company in the end? It was laying off me
and my friends, it was mismanaging money enough that it did not stay
in business, and it was in every sense not the company it started out
to be. Finally it was liquidated and sold to a new company with
almost the same name. That company is again different people but
holds many of the same pieces of paper as the old company. i once
again have warm feelings for that company, though I mostly don't do
business with them for pragmatic reasons. Still, my point is that the
identity of the company is characteristically different than the
identity of an individual.
There is an old story about a wooden ship whose planks begin to rot.
For each rotting plank, I replace it with an aluminum one. Eventually
all the planks are replaced. The question is whether it is still the
same ship. (And does your change if I tell you I saved the old rotted
wooden planks and constructed another ship from them?) I think the
law would construe identity one way--certainly the insurance policy of
the ship would be on the maintained, aluminum one. eBay or the
Smithsonian might view the wooden ship as the "real" ship for
collector's purposes. It's point of view.
By contrast, every day you're inhaling and exhaling carbon atoms but
there is never any question under contemporary technology of who "you"
are; you cannot be subdivided, transferred, liquidated, etc. You're
atomic and your identity does not change.
I claim it follows from the differences in their nature and
capabilities that their behavior also legitimately differs.
> ... Suppose that I view corporate entities a bit like human ones. Does
> that bother you? ...
No. There's a whole science of "branding" and "image making" that
intends you to do this for the purpose of manipulating you in this
way. Whether that's good or bad is subjective. But if, for example,
Pan Am goes out of business the name does not go away; someone sells
it to someone else because it has value exactly for the reasons you
cite. HOWEVER, is its name predictive of how it will behave or of
promises it has made? No. It's under no legal obligations once its
sold. It may be predictive of your wish for it to behave in a
consistent way, and its continued value in the market may hinge on its
willingness to offer you what you perceive (but cannot demand), but
the only sense that that's predictive is that usually companies won't
do things that hurt their image...unless, of course, they have
something else to gain that will compensate.
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey3zoj5oygi.fsf@cley.com>
* David Bakhash wrote:
> Behind any corporation are people who are responsible for the actions
> of the corporation, and the general direction they tend to go.
I think that Kent has explained some of what is wrong with this point.
I'd like to add that the (at least in UK law, and I am reasonably
certain in US law too) the people who are responsible for the actions
of a company (the directors and some others) have legal obligations
which they must fulfil. If they don't they can be sued, personally
(they are not protected by the limited liability of the company).
Those obligations can significantly affect their behaviour as
directors.
> If it helps you to understand this, note that GM and Microsoft are two
> very large companies. But despite that they are companies, comprised
> of thousands, or tens of thousands of people, can you see how they
> differ?
Yes, this is trivial. Microsoft is a monopolist, GM is not.
Monopolies inherently behave really badly to their customers: that's
why there is antitrust legislation. And I've explained in another
article that no Lisp vendor can be a monopolist.
--tim
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfwitpu5ph7.fsf@world.std.com>
David Bakhash <·····@alum.mit.edu> writes:
> If someone leaves their front door unlocked, and subsequently gets
> robbed, I might say "well, give me a break -- there's tons of theives
> out there!" But what I'm hearing is that you would go the extra step
> to say "Well, these theives are waiting for you to leave your door
> unlocked so they can take everything you've got. I don't see why
> people think this is wrong!"
The analogy is flawed. In this case, it isn't thieves but people you
know and have written a contract with, said contract having specific
terms.
Lest we confuse ourselves in analogyland, let me just say that I
believe the Franz contract contains verbiage to the effect that you
can use the product for a year at the current royalty rate but that
they reserve the right to charge you the current market rate on a
subsequent year. And since they don't say what the current market
rate will be, you are effectively saying "do to me as you will" by
signing. I've had occasion to walk away from use of this technically
fine product over this contract issue. I and the company I was doing
business with simply don't sign contracts with people where the net
effect of the wording is "the cost to me is potentially unbounded to
keep using this product beyond some known point in the future". But
if I did sign such a contract, I'm hard pressed to say that their
exercise of that option would be "unethical".
I think you're selling Tim short to not allow him to even entertain this
discussion long enough at an intellectual level to get all the issues
out on the table.
I'll offer you a different analogy: Suppose you write a book and sell
it to a publisher for not much money, thinking it's not very
interesting. Then suppose sales skyrocket. You wrote a contract, you
lose out. But I'm told US copyright law is funny and anticipates this
situation; unless you go to special efforts to screw yourself, after
some number of years, the copyright reverts to you anyway for one more
block of years, exactly so that you can renegotiate price with the
knowledge of how the book is received. So you demand more money. Are
you unethical? After all, someone was already making good money off
of your earlier decision to charge less than the market would have
paid...
Part of our sense of ethics here comes from the question of who the
"little guy" is. We don't want to see a person brought to their knees
by a publisher so we root for him. But suppose it's Tom Clancy or
someone with clout. Now our perception of who the "little guy" is
changes, and we start to feel that the little guy is the publisher, so
maybe we're not as mad at the publisher for trying to make sure they
make enough money to publish OTHER books that we might want that don't
do as well.
I suspect that people's views of this situation with the Franz
contract vary according to whether they perceive Franz as the big guy,
feeding off of little programmers, or whether they perceive Franz as
the helpless little vendor, with programmers leveraging all their good
work to make products that don't benefit them. I suppose there's room
in there for both views.
But I also think the key is to read contracts thoroughly in advance
and not to sign contracts that leave future behavior or cost vague, or
at least not to assume when you do sign those contracts that all of
the vagueries will be resolved in your favor. Contracts, like
language standards, offer rights and responsibilities. Whatever is
not a right or a responsibility in a contract is, to my understanding
of contract law, simply imagined. You might still get redress of your
concern later, but you make things a lot harder on yourself because
only what is spelled out clearly is what's going to come for free
later at enforcement time.
At a different level, I think a lot of this comes down to the question
of whether what Franz is selling is a commodity. I want Lisp to be a
commodity. But I think Franz thinks it's selling something special.
Not a machine-made sweater, but a hand-made one. They are not engineers
but artists. The individual products and relationships matter to them,
not just the sheer aggregate number. Can this work? I don't know.
I suspect the makers of machine-made sweaters probably felt the same way
when the number of customers was small. But I doubt mass-produced items
could ever have succeeded without the loss of caring about the individual
customer and the introduction of caring more about a mass market. I think
that's what it takes to accept the loss of ability to capitalize later
on a given successful company's royalty stream. Vendors of C or C++
don't make their money by taxing Apache or Google or eBay, they make their
money by assuming lots of people will try to make more Apaches and Googles
and eBays. Most such people will fail, but the revenue stream from people
trying is enough. And it simplifies all of the contracts not to have to
fear all that complication about later pricing changes. Franz doesn't
seem to want to be selling a language, but a "solution". A lot of people
say solutions sales command a higher profit. So maybe that's good because
it keeps them in revenue to keep alive and kicking. But their solution sale
comes in a box that to most of us says "I'm trying to look like a
language" not "I'm trying to look like a business solution" and that's
syntactically confusing to the marketplace, I think. Honestly, I think
that's the problem we're really undergoing. The Lisp vendors don't all
have the same business model, but they have similar packaging, and that
leads to confusions of expectations and a difficulty of doing apples to
apples comparisons of the product offerings. Or so it seems to me.
My bottom line, though, is that I think most or all of the players
here are acting ethically and I wish people would take this whole
ethics challenge stuff out of the discussion. There are some legitimate
gripes among people being exchanged, and painful as it is, I think it's
good to air them and see how people feel. But legitimate gripes can happen
among well-meaning people, and we don't have to villify each other in order
to say our expectations were not met. Let's just keep to discussions of
what our needs and expectations are, and hopefully keep focused on what we
can do constructively in the future to win better.
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey3vgttoxj0.fsf@cley.com>
* Kent M Pitman wrote:
> Lest we confuse ourselves in analogyland, let me just say that I
> believe the Franz contract contains verbiage to the effect that you
> can use the product for a year at the current royalty rate but that
> they reserve the right to charge you the current market rate on a
> subsequent year. And since they don't say what the current market
> rate will be, you are effectively saying "do to me as you will" by
> signing. I've had occasion to walk away from use of this technically
> fine product over this contract issue. I and the company I was doing
> business with simply don't sign contracts with people where the net
> effect of the wording is "the cost to me is potentially unbounded to
> keep using this product beyond some known point in the future". But
> if I did sign such a contract, I'm hard pressed to say that their
> exercise of that option would be "unethical".
This is exactly the point I am trying to make. Business is done by
contracts, and you need to read (or get a lawyer to read) any contract
you might sign. And if it is unacceptable to you, then *don't sign
it*, try and arrange a better one. And if all that fails, then rather
than assuming that the other party is out to get you, assume that
either there isn't enough common ground between you to do business or
that they are too stupid to see what the common ground is. That's
more likely to be right.
> But I also think the key is to read contracts thoroughly in advance
> and not to sign contracts that leave future behavior or cost vague, or
> at least not to assume when you do sign those contracts that all of
> the vagueries will be resolved in your favor. Contracts, like
> language standards, offer rights and responsibilities. Whatever is
> not a right or a responsibility in a contract is, to my understanding
> of contract law, simply imagined. You might still get redress of your
> concern later, but you make things a lot harder on yourself because
> only what is spelled out clearly is what's going to come for free
> later at enforcement time.
Yes.
> My bottom line, though, is that I think most or all of the players
> here are acting ethically and I wish people would take this whole
> ethics challenge stuff out of the discussion. There are some legitimate
> gripes among people being exchanged, and painful as it is, I think it's
> good to air them and see how people feel. But legitimate gripes can happen
> among well-meaning people, and we don't have to villify each other in order
> to say our expectations were not met. Let's just keep to discussions of
> what our needs and expectations are, and hopefully keep focused on what we
> can do constructively in the future to win better.
In so far as I'm a player, and since it is my ethics that were called
into question, I certainly am trying to ensure that I and my company
act ethically towards our customers. And almost all of the examples
of behaviour that seems unethical that we have come across can be
explained by stupidity as well, so I prefer to believe this
explanation. Quite apart from anything else, it's much less
personally painful to believe that the people you fail to do business
with are fools than that they are devils (:-).
--tim
Tim Bradshaw <···@cley.com> writes:
> In so far as I'm a player, and since it is my ethics that were
> called into question, I certainly am trying to ensure that I and my
> company act ethically towards our customers.
I believe that. Unfortunately, though, many companies do, including
Microsoft. What irritates me, for example about Bill Gates, is that
when he gets slapped, he wonders why, and makes out as if he's this
innocent person.
As I've followed MS through the years, I've seen them do so many
things that have disgusted me. I, like you, understand the
motivations for that behavior, though, both as a business and as
individual persons who must take responsibility for it (e.g. Gates).
But what irritates me is the refusal to understand why what they're
doing is wrong, and the sheer suprise as being flamed for bad
practices.
Monopolies have a special responsibility. There's nothing wrong with
being a monopoly, and even maintaining that position. It's just that
when you're at that point, you must not behave in certain ways that
would be sound, given that position.
Please don't think that I'm implying that Franz is a monopoly (surely
someone will). They don't have a monopoly on Common Lisp, but if they
did, I'd have a problem with it. Realize that the existence of free
OSs, e.g. Linux, BSD, etc., don't prevent MS from being a monopoly.
Likewise, the free and other commercial implementations of CL don't
prevent Franz from getting to a point where they somehow "define" the
new de-facto standard on CL should be. Again, I'm happy that any
vendor add extensions. But after reading John Foderaro's explaination
and justification for breaking with the standard, I was not convinced.
dave
From: Will Deakin
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3A0FBEF3.2F5E6D72@pindar.com>
David Bakhash wrote:
> Monopolies have a special responsibility. There's nothing wrong with
> being a monopoly, and even maintaining that position. It's just that
> when you're at that point, you must not behave in certain ways that
> would be sound, given that position.
I disagree -- there *is* something wrong with being a monopoly for the
very reasons you give. There is no `special responsibility' -- a company
that is a monopoly has a duty to its owners and employees to use this
position to make the most of its position.
The only way round this is to ensure that there is sufficient
competition to ensure that there are realistic alternatives -- or that
there is sufficient regulation to ensure that the monopoly does not
abuse its position.
On Sat, 11 Nov 2000 18:32:36 GMT, Kent M Pitman <······@world.std.com> wrote:
> My bottom line, though, is that I think most or all of the players
> here are acting ethically and I wish people would take this whole
> ethics challenge stuff out of the discussion.
I'm curious: assuming that we agree that Franz has acted legally during all
this time, is there any action they could have taken that you would be willing
to label "unethical"? Or is "ethical business" simply a synonym for "legal
business" to you?
I used different terminology in my report, because I assumed that some legal
behavior could yet still be deemed "unethical".
-- Don
_______________________________________________________________________________
Don Geddis http://shop.goto.com ······@goto.com
VP of Technology, GoTo Shopping Phone 650-403-2220
1820 Gateway Drive, Suite 300, San Mateo, CA 94404 Fax 650-403-2201
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182956634432949@naggum.net>
* David Bakhash <·····@alum.mit.edu>
| while I agree with you that cautionary meansures are never a bad
| thing, I am seriously starting to question _your_ ethics, and given
| this information, would _not_ want to do business with any company
| where you were anything but a programmer.
What makes you think anyone wants to do business with _you_, David?
What is the principle that drives your ethics? I think it's "be nice
to people" or something equally sappy. Business ethics is not like
that. You don't survive if you're nice, and you are exploited if you
are too nice. I think you feel that you are being screwed because you
are too na�ve and did not expect reality to be so harsh. This will do
you absolutely no good in the long run. It is somewhat sad that you
had your first brush with this reality with a decent company. I've
had mine with real scumbags I had to defeat in court even to get paid
and then there's the insanely power-crazed people who have supposedly
been tasked with collecting money for the government with tactics that
makes _any_ organized crime outfit look like the boy scouts. Franz
Inc are not _easily_ "defeatible" in negotiations, but they also do
not want to lose their customers. If the customers fail to grasp that
they have power in such negotiations, who could possibly be blamed for
this if not the customer's incompetent and inexperienced management?
If the customer fails to realize that the world will always change in
unexpected ways and is unprepared to deal with it, blaming anyone else
is not going to win them any support. If the customer makes the
choice not to negotiate, but accepts the initial terms because it
would "cost too much" to negotiate, then that's sound business sense
_or_ a moronic na�vit�. We all have to deal with the unexpected at
the most inconvenient times in our lives -- and you're judged by how
well you do in precisely such situations. E.g., Franz Inc faced a new
reality where server-based applications took over from shipping boxes
with products, especially since they had priced the latter and not the
former, but they did have the foresight to have been able to determine
the conditions under which they could set new terms. Since their many
customers had agreed to this, this is all a question of being able to
deal with licenses and contracts. I have found (in my work) that it
does not matter _what_ you do, if you cannot deal with legal issues
like contractual requirements, intellectual property rights, etc. To
stay within the law so you can actually win in court is not trivial,
but being able to use power of the legal system is such a _pacifier_
in dealing with business people.
When it comes to ethics, which you invoke a little too often for even
my comfort, there is the very, very _unethical_ behavior of accusing
someone falsely for something which they have not in fact done, but
which you attribute to them because it would make your black-and-white
ethics fit the world a little better. In my view, there is nothing
worse than the willingness to engage in false accusations which have
as their main effect to simplify the accuser's ethical world-view.
Franz Inc has displayed a staggeringly cavalier attitude towards the
standard, not just via John, but the standard is a _specification_ and
the ability to program faithfully and completely to one specification
is fundamental to trusting people to implement and execute any other
specification, such as contract law, license terms, etc. The law is
both the standard and the programming language of society, and once
you start to think you can do anything you want because you're smarter
than the specification or that the specification is _wrong_, you have
moved yourself outside of a world of responsibility. The funny thing,
relative to what you keep arguing about, David, is that Franz Inc's
attitude to the standard is a much, much more serious signal that they
don't really give a damn about specifications they cannot be forced to
follow, but with the ones they _can_ be forced to keep, like the law
and good business practices, they do comply a lot better. That's why
I think their inability and/or unwillingness to base their operation
first on compliance with the standard is a sign that what we see in
the business area may be early symptoms of a deep-rooted disrespect
for the society in which they are based. Anti-community attitudes do
not start with the most serious aspects, but rather must be found in
the seemingly insignificant end of the spectrum. The question must be
whether they prioritize winning through building community consensus
over short-range wins by exploiting community divisiveness, such as
with this case issue.
Yes, I'm worried, but only because so many other people seem to be
missing the point, sometimes entirely. To make Franz Inc behave well
in the long run and remain one of, if not the, best Common Lisp
vendor, requires work on our part, too. Just as the idiots who did
not keep Microsoft in check have contributed very strongly to their
very, vary bad business ethics and products alike. After all, the
customer _is_ always right, especially when he gets what he wants but
is just too stupid to realize it in time.
#:Erik
--
ALGORITHM: a procedure for solving a mathematical problem in a finite
number of steps that frequently involves repetition of an operation.
ALGOREISM: a procedure for solving an electoral problem in a finite
number of steps that frequently involves repetition of an operation.
Erik Naggum <····@naggum.net> writes:
> * David Bakhash <·····@alum.mit.edu>
> | while I agree with you that cautionary meansures are never a bad
> | thing, I am seriously starting to question _your_ ethics, and given
> | this information, would _not_ want to do business with any company
> | where you were anything but a programmer.
>
> What makes you think anyone wants to do business with _you_,
> David?
And where did I ever say -- or even _imply_ -- that anyone wanted to
do business with me? This is a misguided assumption. I'm looking at
this in the following way, and I hope that this helps...
> Business ethics is not like that. You don't survive if you're
> nice, and you are exploited if you are too nice.
Here's my point. In order to make it, unfortunately, I have to
disagree with view (not totally, but that there is a middle ground,
and you don't have to be cut-throught to your customers to be
successful). Suppose one creates a software company, and he feels
that he can run it such that it operates on non-cut-throught
principles (a simplification, but let's just say, because I'm not sure
how to word this).
Now, if he chose to use Common Lisp, and considers a Lisp vendor that
undermines his ability to guarantee to operate his business in this
way, then he must reject it, and consider alternate approaches, unless
he can somehow reach terms with that vendor that prevent this
undermining.
I apologize that those are the best terms that I can put it in.
Remember that we're talking about a software development tool
(specifically, a compiler, IDE, debugger, programming environment,
profiler, etc.).
Now, to spare writing a duplicate followup to KMP's post above, I'll
recognize that Franz considers itself as a solutions provider, not
just another CL implementation, or at least that that's a
justification for their practices. I am still considering this
aspect, and I'm happy KMP has posted it.
> I think you feel that you are being screwed because you are too
> na�ve and did not expect reality to be so harsh. This will do you
> absolutely no good in the long run. It is somewhat sad that you
> had your first brush with this reality with a decent company.
This is not the first time that I have been labeled as na�ve. But I
try very hard to view this as idealistic, and as long as there are
companies that create excellent products, respect the communities and
standards that define and shape their products, treat their customers
well, and still thrive, I will try to remain optimistic. I am sorry
that this is termed na�ve, but whatever it _is_, I want to stay that
way, and I want to deal with individuals as well as companies that
care about the same thing.
> When it comes to ethics, which you invoke a little too often for
> even my comfort, there is the very, very _unethical_ behavior of
> accusing someone falsely for something which they have not in fact
> done, but which you attribute to them because it would make your
> black-and-white ethics fit the world a little better. In my view,
> there is nothing worse than the willingness to engage in false
> accusations which have as their main effect to simplify the
> accuser's ethical world-view.
It's really hard to have read this. I'll say it (in fact repeat it).
I am not one way with respect to Franz. I have always, in online and
offline discussions, discussed ACL as a fine product. I explained
that Franz was extremely helpful to my research. If I see things as
black-and-white, then that's a serious problem with me. If I don't
but you see _me_ as black-and-white, then that's also a serious
problem, and that's _our_ problem (or mine, I guess, if you refuse to
meet me halfway).
> The funny thing, relative to what you keep arguing about, David,
> is that Franz Inc's attitude to the standard is a much, much more
> serious signal that they don't really give a damn about
> specifications they cannot be forced to follow, but with the ones
> they _can_ be forced to keep, like the law and good business
> practices, they do comply a lot better.
I think this all started when I implied that the two things might be
coupled.
dave
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3183048663153512@naggum.net>
* David Bakhash <·····@alum.mit.edu>
| And where did I ever say -- or even _imply_ -- that anyone wanted to
| do business with me? This is a misguided assumption. I'm looking at
| this in the following way, and I hope that this helps...
You missed the point. Why should anyone _care_ who you want to do
business with if they don't consider the reverse point, that somebody
has to do business with you, too, for business to be transacted? If
you make a point about your willingness to do business with someone,
it behooves you to say something about your _ability_ to do same.
I fail to see your "cut-throat" example as relevant, too, because I
have no idea what you mean by "cut-throat" practices. You aren't a
customer of theirs and have made a point out of that, so I can't quite
see how you feel you didn't have a choice. It is not as if people do
not have choices in general, either.
| I am sorry that this is termed na�ve, but whatever it _is_, I want to
| stay that way, and I want to deal with individuals as well as
| companies that care about the same thing.
That is not what is termed na�ve. What _is_ na�ve is that you don't
stop to consider or recognize when your "idealism" (if that is indeed
what it is) is no longer a viable basis for your actions.
#:Erik
--
ALGORITHM: a procedure for solving a mathematical problem in a finite
number of steps that frequently involves repetition of an operation.
ALGOREISM: a procedure for solving an electoral problem in a finite
number of steps that frequently involves repetition of an operation.
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey38zqpqdwe.fsf@cley.com>
* David Bakhash wrote:
> while I agree with you that cautionary meansures are never a bad
> thing, I am seriously starting to question _your_ ethics, and given
> this information, would _not_ want to do business with any company
> where you were anything but a programmer.
I would not normally respond to a personal attack like this, but since
I work for a company where I am things other than a programmer I feel
slightly compelled to respond.
> Anyway, Tim, I hope that Franz sends you a lolly pop for sucking up to
> them so hard during this discussion. But they probably won't, since
> Don's response was a confirmation to my "hypothetical" scenario that
> _you_ requested.
I don't see that I have sucked up to anyone. What I have described is
the precautions I think a company should take before considering the
purchase of a service from another company, and the eventualities it
should consider when doing so. Note carefully that I have *not*
suggested that you should buy such a service, nor have I suggested
that you should not. And I'm not about to do that in a public forum
(or in fact by email to anyone I don't know personally).
> Now, Tim, are you one of those people who believes that people can do
> bad things, just as long as they don't do them to you? And that you
> will even support these people as far as to say "Well, of _course_ you
> should have watched your back -- didn't you know you were dealing with
> a corporation?" Well, that's what you just did.
I certainly think that people might do bad things to my company. This
is something we are careful to consider at all times. For instance we
buy Suns and we have a significant commitment to them. We've
considered this quite carefully: we pay a premium for these machines
over PCs (probably double) in return for which we get better
reliability and good support (which more than counterbalances the
higher initial cost). We believe Sun to be in a competitive
marketplace and therefore unlikely to crank up prices too far. If
they do so we have a number of options to change platform, either to
another workstation vendor (probably HP) or to PCs running Linux, and
we are aware (broadly, as we don't think it likely that Sun will do
this) of the costs that would incur. We would not, for instance,
consider basing our systems on Windows machines, because we would then
be completely dependent on Microsoft who are clearly a monopolist, and
in addition the costs of changing platform would be very much higher.
> Believe it or not, Tim, just as there are people who can be relied on
> for honesty, fairness, and good intent, there are companies that do
> their very best to operate under such principles. And guess what?
> They can make money too. In fact, they can make a LOT of money, and a
> lot of it is based on their clients' knowledge of their proven track
> record not just with respect to product offering and delivery, but
> also business ethics.
I'm not aware that anyone's honesty has been called into question
(about pricing anyway, which seems to be what you are complaining
about). There are a lot of factors which affect how companies behave
towards each other and what they charge for their products, and what
sorts of contracts they will demand. Occasionally it's because they
are controlled by unpleasant people, but it's *much* more often the
case that it's for some other reason. Perhaps they don't understand
the market they are in very well -- this was true of almost every
software vendor in the early days of the web, and many of them still.
perhaps they don't understand the value of their product very well,
and radically overestimate it. Perhaps they *do* understand the value
of their product very well -- what does Purify cost?. Perhaps they
think that your company is very much more risky than theirs and are
unwilling to tie their risk to yours, causing them to want lots of
money up front. None of these decisions to do with business ethics,
yet they can all result in pricing strategies which you may find
unacceptable or strange.
I've worked (as a contractor) for a very large company which is often
held up as having been a paradigm of fairness and reliability. They
did this by choosing a market which they understood *really well* and
which they knew was willing to pay high prices for service and
support, and being selective about their customers. It's my guess
that almost all these paradigm companies are doing this trick of
understanding and selecting their customers carefully. Companies
which are not so good at this are not so nice: they can't afford to
be.
So I think you should cut people some slack. Assume they are stupid
not malicious: it's generally nearer the truth. When you read the
terms of the contract and realise it's hopeless[1] it's much safer to
assume that they *don't understand* not that they are some evil entity
trying to drive you out of business. Explain what the issues are, and
if you can't reach an understanding in some reasonable time then
they're too stupid to deal with, and you can just walk away.
Apart from anything else, a Lisp vendor can't hold a monopoly: it's
just a programming language, you can always choose another if you
can't reach an agreement. But the vendor can't, so they have a *much*
higher interest in the Lisp market existing than you do: they *will go
out of business* if it dies. Lisp probably has a value to your
company (or mine) which is less than that, and which you can
calculate, and you want to try and arrange a contract based on that
estimate of value. One of the classic problems with Lisp companies is
that they vastly overestimate what the value of their product is to
their customers, and vastly misunderstand their market, and so they
try and charge enormous and unjustifiable premiums for their product
in terms of royalties and so on[2]. But that's not because they're
malicious, it's because they're *stupid*.
Well, this is quite long enough now. If you don't understand what I'm
trying to say, I guess you never will.
--tim
Footnotes:
[1] and for God's sake *read the contract*, I really can not
sympathise with people who don't read contracts carefully and then
complain about them any more than I can sympathise with those who
don't read language standards carefully and then complain.
[2] In fact I'm very slowly writing an article about this though I
suspect I may never finish it as there are confidentiality issues
I may not be able to get around.
From: Robert Monfera
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3A0D840D.C7D59E14@fisec.com>
Don Geddis wrote:
> Given that we were making a web server application with potentially
> millions of users, Franz's proposed pricing wound up being _orders_ of
> magnitude more than our previous arrangement with them.
Let's be clear:
1. What was the "previous agreement"? A contract? Did it include or
exclude server use?
2. If it included server use, why could not you stick to it? If it
excluded it, then it's like developing for a long time (committing to a
vendor) and just hoping that licensing terms will be acceptable.
3. Is the pricing of the server product less fair than the desktop
product pricing (for example, are royalties higher relative to the
income)?
4. If royalties were (perceived) high, did you have the chance to
migrate to another implementation in a short time?
When working with Franz on a licensing agreement, one of my obvious
requests was to receive information on the terms of application
delivery. I figured we better not rely extensively on Franz-only
features until there is an actual deployment contract.
The general royalty terms did not look unreasonable to us, so I don't
know why Franz does not simply put it on their web page and include a
*binding* deployment fee schedule even in the development license.
Robert
I wrote:
> > Given that we were making a web server application with potentially
> > millions of users, Franz's proposed pricing wound up being _orders_ of
> > magnitude more than our previous arrangement with them.
On Sat, 11 Nov 2000 17:39:13 GMT, Robert Monfera <·······@fisec.com> wrote:
> Let's be clear:
> 1. What was the "previous agreement"? A contract? Did it include or
> exclude server use?
Yes, there was an original contract. It was clearly not written with server
use in mind, so it was a matter of interpretation how do deal with server
implementations under the contract. Prior to beginning our business, we
_explicitly_clarified_ (although, unfortunately, only verbally...) with our
Franz sales rep that we would be developing a web server, and put forth our
interpretation of the contract in that situation. It was approved by our sales
rep, and we operated in that way for more than a year.
> 2. If it included server use, why could not you stick to it? If it
> excluded it, then it's like developing for a long time (committing to a
> vendor) and just hoping that licensing terms will be acceptable.
Once we landed a large contract, Franz suddenly claimed that our existing
interpretation was no longer correct, and they wished to renegotiate to
"clarify" the situation (since the existing contract had a large grey area with
regards to server implementations).
> 3. Is the pricing of the server product less fair than the desktop
> product pricing (for example, are royalties higher relative to the
> income)?
For the first 1+ year that we operated a server business, Franz received
in the neighborhood of $10K/year from us. Their new proposal was about four
orders of magnitude larger.
> 4. If royalties were (perceived) high, did you have the chance to
> migrate to another implementation in a short time?
We received the new demands from Franz when we had a deadline of about three
weeks for our new contract (which, unfortunately, Franz knew about). That was
too little time to complete the conversion to a new platform. If we had more
like two months, we would have happily said goodbye to Franz forever, and
switched to a different implementation.
The time pressure, together with the dramatic change in pricing, put us in
quite a bind.
> I figured we better not rely extensively on Franz-only
> features until there is an actual deployment contract.
We had already been delivering our product for about a year. Just not at
any significant scale.
-- Don
_______________________________________________________________________________
Don Geddis http://shop.goto.com ······@goto.com
VP of Technology, GoTo Shopping Phone 650-403-2220
1820 Gateway Drive, Suite 300, San Mateo, CA 94404 Fax 650-403-2201
There's an old story about the person who wished his computer were as easy to
use as his telephone. That wish has come true, since I no longer know how to
use my telephone. -- Stroustrup
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <nkj1yweuas0.fsf@tfeb.org>
······@Goto.Com (Don Geddis) writes:
>
> For the first 1+ year that we operated a server business, Franz received
> in the neighborhood of $10K/year from us. Their new proposal was about four
> orders of magnitude larger.
>
4 orders of magnitude on 10,000 is 100,000,000: do you mean that?
--tim
Tim Bradshaw wrote:
>
> ······@Goto.Com (Don Geddis) writes:
>
> >
> > For the first 1+ year that we operated a server business, Franz received
> > in the neighborhood of $10K/year from us. Their new proposal was about four
> > orders of magnitude larger.
> >
>
> 4 orders of magnitude on 10,000 is 100,000,000: do you mean that?
>
> --tim
Maybe he meant binary orders of magnitude. 160,000 is still pretty
impressive, though. I assume for that amount of money, you get
incredible, 24x7, engineers-fly-to-you service, right?
(not saying that Franz's support isn't good for the price right now -
I'm trying to imagine how much better it would have to get to justify
$160K/year, much less $100M)
--
Remove obvious stuff to e-mail me.
Bob Bane
From: Kaelin Colclasure
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <wuu294vmov.fsf@soyuz.arslogica.com>
Bob Bane <····@removeme.gst.com> writes:
> Tim Bradshaw wrote:
> >
> > ······@Goto.Com (Don Geddis) writes:
> >
> > >
> > > For the first 1+ year that we operated a server business, Franz received
> > > in the neighborhood of $10K/year from us. Their new proposal was about four
> > > orders of magnitude larger.
> > >
> >
> > 4 orders of magnitude on 10,000 is 100,000,000: do you mean that?
> >
> > --tim
>
> Maybe he meant binary orders of magnitude. 160,000 is still pretty
> impressive, though. I assume for that amount of money, you get
> incredible, 24x7, engineers-fly-to-you service, right?
>
> (not saying that Franz's support isn't good for the price right now -
> I'm trying to imagine how much better it would have to get to justify
> $160K/year, much less $100M)
I spoke to Tom at about the time all of this would have been going
down, and he warned me to look carefully at the licensing arrangements
on Franz's software. So I did -- I thought. I also clarified with our
sales rep our deployment requirements and got a verbal indication of
what our deployment costs would be -- I thought.
Many months later, just after committing to ~$40K worth of development
licenses from Franz the issue of live deployment was raised again. By
Franz. And the price sheet we were presented at that time -- one
entirely different from the pricing sheets we had previously based
decisions on -- increased our projected deployment costs by
approximately an order of magnitude.
That's a zero tacked on -- and no, that does not get you 24x7 support.
For some added perspective, that made ACL more expensive than all the
other third-party software we licensed (including Oracle Enterprise
Server), and the hardware we run it on, *combined*.
Our production servers will be running Lispworks until Franz does a
reality check on their pricing. Ah, and how many man/months did we
lose porting our application between ACL and Lispworks? I really don't
want to think about it.
-- Kaelin
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey3d7fsnld1.fsf@cley.com>
* Kaelin Colclasure wrote:
> Many months later, just after committing to ~$40K worth of development
> licenses from Franz the issue of live deployment was raised again. By
> Franz. And the price sheet we were presented at that time -- one
> entirely different from the pricing sheets we had previously based
> decisions on -- increased our projected deployment costs by
> approximately an order of magnitude.
It would be interesting to try and estimate the cost of *writing* a CL
system, or as much of one as you need to do the job you need to do (it
doesn't need to be general purpose). The quote about all sufficiently
complex systems having a little Lisp system inside cuts both ways: a
crappy homegrown lisp system might be all you need to get you through
the night, and if the price of the non-crappy system you can buy is
sufficient this might be a good approach. And the cost of taking one
of the public systems and industrialising them for use by a project
might be even lower.
--tim
From: Bulent Murtezaoglu
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <87bsvbu965.fsf@kapi.internal>
>>>>> "TBr." == Tim Bradshaw <···@cley.com> writes:
TBr.> [...] And the cost of taking one of the public systems and
TBr.> industrialising them for use by a project might be even
TBr.> lower.
This is a very interesting thought. I wonder if anyone has played with the
numbers on this?
BM
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey3d7fqpfw7.fsf@cley.com>
* Bulent Murtezaoglu wrote:
>>>>>> "TBr." == Tim Bradshaw <···@cley.com> writes:
TBr.> [...] And the cost of taking one of the public systems and
TBr.> industrialising them for use by a project might be even
TBr.> lower.
> This is a very interesting thought. I wonder if anyone has played with the
> numbers on this?
Well, clearly if at least one of the figures that has been mentioned
in this thread is correct, it would be be cheaper to implement a CL
system from scratch than pay the fees mentioned -- much cheaper! But
time isn't money in software development: probably no amount of money
you can spend would get the development time of a CL system (or the
industrialising of an extant free CL) below about six months. And
that's the value of Lisp, in fact: about six months is how long it
takes to write the slow, poorly-specified and buggy Lisp system which
will, nevertheless, serve the needs of the project it was written for,
and buying a lisp System buys a lead of about six months on the
competition.
--tim
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3183773728658586@naggum.net>
* Tim Bradshaw <···@cley.com>
| Well, clearly if at least one of the figures that has been mentioned
| in this thread is correct, it would be be cheaper to implement a CL
| system from scratch than pay the fees mentioned -- much cheaper!
Do we have any realistic concept of how much programmer time it would
take to build a (complete and fully ANSI conforming) Common Lisp
system from scratch? 10 years? 100 years? I think we are closer to
the latter figure than the former.
The problem is that building core technologies and infrastructure
takes about an order of magnitude more time and effort than building
applications. Not just because the specifications are more complex,
but because we're dealing with languages, where the kinds of user
input the system has to deal well with covers an enormous domain.
This is why it is paramount that an implementation be faitful to the
specifications for the language and the environment. Creating a
system that does what its developers think is cool is not that hard,
but making one that accomodates other people of different attitudes
and desires well is what's worth buying. (That's a not very subtle
hint to Franz Inc and John Foderaro, too.))
#:Erik
--
ALGORITHM: a procedure for solving a mathematical problem in a finite
number of steps that frequently involves repetition of an operation.
ALGOREISM: a procedure for solving an electoral problem in a finite
number of steps that frequently involves repetition of an operation.
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <nkjlmuce2b8.fsf@tfeb.org>
Erik Naggum <····@naggum.net> writes:
> Do we have any realistic concept of how much programmer time it would
> take to build a (complete and fully ANSI conforming) Common Lisp
> system from scratch? 10 years? 100 years? I think we are closer to
> the latter figure than the former.
I think somewhere between the two is plausible, at least (and the
higher of the two claimed licence costs *would pay* for 100 man
years). But what I was trying to get at was that it probably takes a
good deal less to do a ninety-something percent conforming CL, like
CLISP say, and really a whole lot less to do a 20% `Greenspun' CL
which might be all a specific project needs.
The problem I think is that not only (as you said) does building core
technologies and infrastructure take about an order of magnitude more
time and effort than building an application, but that a great deal of
that work is involved in going from 90% to 100% of the way there, I
think.
I care a lot about that final 10%. But probably I could actually live
with a 90% solution, or even a 20%, project-specific, solution. And
certainly if the 100% solution is *sufficiently* expensive it could
easily be a more lucrative option to live with the horrible solution.
This is really the worse-is-better argument I think.
--tim
From: Joe Marshall
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <snok2boa.fsf@content-integrity.com>
Tim Bradshaw <···@tfeb.org> writes:
> Erik Naggum <····@naggum.net> writes:
>
> > Do we have any realistic concept of how much programmer time it would
> > take to build a (complete and fully ANSI conforming) Common Lisp
> > system from scratch? 10 years? 100 years? I think we are closer to
> > the latter figure than the former.
>
> I think somewhere between the two is plausible, at least (and the
> higher of the two claimed licence costs *would pay* for 100 man
> years).
Two is a severe underestimate.
You could *probably* spend ten `lisp god' years and come up with
something that conforms to the standard enough that you could claim
ANSI compliance. You wouldn't actually *be* compliant, but you might
fool a few people. You would be missing some major functionality,
though.
If you wish to hire mere mortals, (you'll need a god or two to counter
the tendency of mortals to do truly stupid things), you are talking
about *at least* fifty man-years for semi-compliance, and I wouldn't
be surprised at 100.
What would this cost? This is an *extremely* rough estimate, but I
doubt I'm off by an order of magnitude. Running a company costs about
$150K per employee year these days. Lisp gods tend to cost a tad more
than HTML grunts, but let's be optimistic. A hundred man-year effort
would be in the ballpark of 15 megabucks. Is that *really* the
licence cost they were asking?
> But what I was trying to get at was that it probably takes a
> good deal less to do a ninety-something percent conforming CL, like
> CLISP say, and really a whole lot less to do a 20% `Greenspun' CL
> which might be all a specific project needs.
I have my doubts about this. If you are looking for something the
quality of a student project, then, sure, you could whip something
together (3 undergrads, and 1 semester might make 20% of a lisp ---
the easy part, anyway).
But if you want to build a product, you need a solid foundation. The
easy 20% of a lisp is a start, but it is nowhere near enough.
> The problem I think is that not only (as you said) does building core
> technologies and infrastructure take about an order of magnitude more
> time and effort than building an application, but that a great deal of
> that work is involved in going from 90% to 100% of the way there, I
> think.
You are right. (Although I think the core infrastructure takes at
least 2 orders of magnitude more effort.)
> I care a lot about that final 10%. But probably I could actually live
> with a 90% solution,
Probably, but you wouldn't be very happy with it.
> or even a 20%, project-specific, solution.
Since I don't know what you could live with, I can't say for sure, but
I'd be *very* surprised if this were true.
Consider: Would Java or Visual Basic provide 20% of the functionality
you need? It probably would for me. Unfortunately, that's nowhere
near enough.
> And certainly if the 100% solution is *sufficiently* expensive it
> could easily be a more lucrative option to live with the horrible
> solution.
Certainly. It would be more lucrative to become a certified Microsoft
Weenie and write Active X objects in Visual Basic that plug into the
Microsoft .NET platform to `deliver B2B e-commerce solutions on the
information superhighway'.
> This is really the worse-is-better argument I think.
Yes, and I agree with Gabriel's observations. Nonetheless, I find the
worse-is-better approach to be extraordinarily distasteful, and I'd
rather be an idealistic pauper.
-----= 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! =-----
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <nkjwvdwgcmd.fsf@tfeb.org>
Joe Marshall <···@content-integrity.com> writes:
> > I think somewhere between the two is plausible, at least (and the
> > higher of the two claimed licence costs *would pay* for 100 man
> > years).
>
> Two is a severe underestimate.
I didn't say two years I said `between the two' meaning `between the
two estimates Erik gave' or `between 10 and 100'.
>
> What would this cost? This is an *extremely* rough estimate, but I
> doubt I'm off by an order of magnitude. Running a company costs about
> $150K per employee year these days. Lisp gods tend to cost a tad more
> than HTML grunts, but let's be optimistic. A hundred man-year effort
> would be in the ballpark of 15 megabucks. Is that *really* the
> licence cost they were asking?
The *claim* was 4 orders of magnitude on 10,000, which is 100,000,000.
I think I also disagree about the times to produce less-conforming
systems -- for instance how much time did CLISP get, or Corman Lisp,
or kcl? Even for the commercial products you can bound the time spent
simply by looking at employee count and company age, and you get
reasonable-looking estimates, especially if you try and remove people
working on other things than the core Lisp.
As for 20% solutions, well everyone and his dog has an embeddable
scheme system: these things just don't take that long to do. Many of
them are what I'd consider at the 20% level.
--tim
From: Joe Marshall
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <itpf3m6j.fsf@content-integrity.com>
Tim Bradshaw <···@tfeb.org> writes:
> Joe Marshall <···@content-integrity.com> writes:
>
> > > I think somewhere between the two is plausible, at least (and the
> > > higher of the two claimed licence costs *would pay* for 100 man
> > > years).
> >
> > Two is a severe underestimate.
>
> I didn't say two years I said `between the two' meaning `between the
> two estimates Erik gave' or `between 10 and 100'.
Oops. Guess I should have read that more carefully. My apologies.
> > What would this cost? This is an *extremely* rough estimate, but I
> > doubt I'm off by an order of magnitude. Running a company costs about
> > $150K per employee year these days. Lisp gods tend to cost a tad more
> > than HTML grunts, but let's be optimistic. A hundred man-year effort
> > would be in the ballpark of 15 megabucks. Is that *really* the
> > licence cost they were asking?
>
> The *claim* was 4 orders of magnitude on 10,000, which is 100,000,000.
I seem to be concentrating all my mistakes today in this one message;
at least I hope I am.
Again, my apologies.
> I think I also disagree about the times to produce less-conforming
> systems -- for instance how much time did CLISP get, or Corman Lisp,
> or kcl?
I don't know.
> Even for the commercial products you can bound the time spent
> simply by looking at employee count and company age, and you get
> reasonable-looking estimates, especially if you try and remove people
> working on other things than the core Lisp.
To some extent this is true, but a lot of commercial lisps got their
start in academia. You have to consider the amount of development
done beforehand.
> As for 20% solutions, well everyone and his dog has an embeddable
> scheme system: these things just don't take that long to do. Many of
> them are what I'd consider at the 20% level.
Yes, but I haven't seen an embeddable scheme system that comes even
close to doing all the things I need. How many of these embeddable
scheme's support huge heaps, generational scavenging, multiple
threads, CLOS, foreign functions, persistent objects, and network
code?
Of course your needs differ from mine.
-----= 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! =-----
Joe Marshall <···@content-integrity.com> writes:
>
> Yes, but I haven't seen an embeddable scheme system that comes even
> close to doing all the things I need. How many of these embeddable
> scheme's support huge heaps, generational scavenging, multiple
> threads, CLOS, foreign functions, persistent objects, and network
> code?
>
None, I expect. I think we're probably agreeing here -- I'm not
really trying to argue that no one ever needs a full, conformant, CL,
just that there is a substantial region where very much lesser systems
will suffice, if the license for the full conformant system is
sufficiently expensive, or if the (lack of) licensing terms may expose
the project to very large financial uncertainty. And that once one of
these lesser systems `takes hold' in a project, it's not necessarily
the case that the conformant system offers a huge advantage *for that
project*, even if it's better in some overall sense that you can use
it in all projects.
Anyway, I'm not trying to win any battles here...
--tim
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3183984553414192@naggum.net>
* Tim Bradshaw <···@tfeb.org.is.currently.broken>
| And that once one of these lesser systems `takes hold' in a project,
| it's not necessarily the case that the conformant system offers a huge
| advantage *for that project*, even if it's better in some overall
| sense that you can use it in all projects.
Worse than this, it would probably be easier for the bean-counters
among us to favor adding code to the homegrown system at each and
every step than to consider what all those steps would cost.
| Anyway, I'm not trying to win any battles here...
I think we're looking at the threshold-crossing problem. How much do
you really _have_ to commit to in order to make a conforming Common
Lisp your development system of choice? I think Franz Inc are doing a
world of wonder at the high end of the market, and I don't really see
the huge problems with licensing or pricing at that end, and I think
they are doing a marvelous job in the very low end of the market, that
of Trial editions (barring that default Modern cruft, obviously), but
going from "Hey, wow, this is _cool_!" to "One Allegro CL Enterprise
development license and server license to go, please" is amazingly far
and probably so far that any good engineer can figure out a much less
expensive way to make _each_ step on his way, but I'm not convinced
that he woulud end up spending any less real money in the end -- which
leads us to the other problem -- Franz Inc wants too much up front in
the default arrangement. (This can be negotiated away, of course, but
you have to have enough chutzpah/gall/guts/balls/etc to red-line large
portions of a fairly strict license and the message I get from people
is that they are _not_ thrilled to have to do this.)
What worries me most about all of this is the _combined_ impression of
their not caring _that_ much about the specification of ANSI Common
Lisp, which means that programmers can no longer use the standard
reference works or the standard textbooks, they can no longer just
plug into the general Common Lisp community, use open source, etc, and
the tendency towards specialization of their market to committed, very
large-scale projects. I feel _myself_ falling outside their markets.
#:Erik
--
Solution to U.S. Presidential Election Crisis 2000:
Let Texas secede from the Union and elect George W. Bush their
very first President. All parties, states would rejoice.
From: Kaelin Colclasure
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <wulmu9w73a.fsf@soyuz.arslogica.com>
Erik Naggum <····@naggum.net> writes:
[...]
> I think we're looking at the threshold-crossing problem. How much do
> you really _have_ to commit to in order to make a conforming Common
> Lisp your development system of choice? I think Franz Inc are doing a
> world of wonder at the high end of the market, and I don't really see
> the huge problems with licensing or pricing at that end, [...]
Well I suppose it all depends on what you consider the "high end" of
the market. If it's measured in developer head-count, I don't know of
any "high-end" organizations that're outfitting their masses of
developers with Common Lisp environments. If it's measured by the
means and will to invest significant $$$ per developer, then anybody
with a commercial license for ACL is "high-end" considering the price
of the popular alternatives (which has trended dramatically downward
over the last several years).
In my opinion, Franz has observed their only major competitor going
through some organizational turmoil, while at the same time their
customers are starting to push Common Lisp into new application
domains, and have concluded that:
a) The time is ripe for Common Lisp to be "modernized" to better
support those new domains.
b) They can exercise monopoly-style licensing tactics to fund the
resources necessary to accomplish the above.
-- Kaelin
From: Rob Warnock
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <8vhpa6$tgi2$1@fido.engr.sgi.com>
Joe Marshall <···@content-integrity.com> wrote:
+---------------
| Yes, but I haven't seen an embeddable scheme system that comes even
| close to doing all the things I need. How many of these embeddable
| scheme's support huge heaps, generational scavenging, multiple
| threads, CLOS, foreign functions, persistent objects, and network code?
+---------------
Rice University PLT's DrScheme/MrEd/MzScheme <URL:http://www.cs.rice.edu/
CS/PLT/packages/drscheme/> comes awfully close [at least, for what I do]:
- Multiple threads (well-integrated with I/O, so threads can do
"blocking reads" that don't block other threads), semaphores,
and multiple global namespaces so that code compiled at runtime
(e.g., input from a user or the net) can be isolated from the rest
of the system.
- A reasonably decent class-based object system (C++/Java-like though,
so only single-inheritance).
- Easy access to foreign functions in C or C++, including runtime
linking of DSOs/DLLs (though no runtime-compilable FFI)
- An entirely-adequate TCP/IP network facility.
- A form of persistent objects through the "SrPersist" add-on package
(accesses relational databases with an ODBC driver).
Plus, it has a object-based GUI system (MrEd) which is portable across
Windows 95/98/NT/2000, MacOS, and Unix/X; a pedagogical teaching environment
(DrScheme) with some serious debugging tools (MrSpidey); and the "mzc"
compiler compiles Scheme to native code via C if you want (otherwise,
by default it compiles, with pretty heavy optimization, to an internal
tree code).
One of the more blatant drawbacks, to my taste, is that it still relies
on the Boehm-Demers conservative garbage collector (for ease of interfacing
with C/C++, they say), which while on some platforms supports a form
of generational scavenging, isn't nearly as efficient as a full-blown
generational copying collector (with a fixed nursery, as per Ungar).
But other than that, it's stable, robust, well-supported, and generally
quite usable. While not tiny (~750KB text+data), MzScheme is certainly
one reasonable choice for "embedding". (And "scripting", but that's
another story...)
-Rob
-----
Rob Warnock, 31-2-510 ····@sgi.com
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <nkjvgtggcf7.fsf@tfeb.org>
Joe Marshall <···@content-integrity.com> writes:
>
> But if you want to build a product, you need a solid foundation. The
> easy 20% of a lisp is a start, but it is nowhere near enough.
>
In case I've been misunderstood, I'm not talking about building a
*Lisp* product, I'm talking about building some other product using
Lisp. People do this quite frequently with hacky, horrible
sub-common-lisps with some success. I'm writing this with a
well-known example...
--tim
From: Joe Marshall
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <em033m2n.fsf@content-integrity.com>
Tim Bradshaw <···@tfeb.org> writes:
> Joe Marshall <···@content-integrity.com> writes:
>
> >
> > But if you want to build a product, you need a solid foundation. The
> > easy 20% of a lisp is a start, but it is nowhere near enough.
> >
>
> In case I've been misunderstood, I'm not talking about building a
> *Lisp* product, I'm talking about building some other product using
> Lisp. People do this quite frequently with hacky, horrible
> sub-common-lisps with some success. I'm writing this with a
> well-known example...
I understand.
I'm using the same well-known example, but an enormous amount of
effort went into it.
-----= 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! =-----
From: Kaelin Colclasure
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <wuofzbvm9a.fsf@soyuz.arslogica.com>
Tim Bradshaw <···@cley.com> writes:
> It would be interesting to try and estimate the cost of *writing* a CL
> system, or as much of one as you need to do the job you need to do (it
> doesn't need to be general purpose). The quote about all sufficiently
> complex systems having a little Lisp system inside cuts both ways: a
> crappy homegrown lisp system might be all you need to get you through
> the night, and if the price of the non-crappy system you can buy is
> sufficient this might be a good approach. And the cost of taking one
> of the public systems and industrialising them for use by a project
> might be even lower.
"Industrializing" CMUCL (or a variant thereof) is a very interesting
proposition. A robust, maintainable, open-source Common Lisp
implementation with solid community support behind it would
be... well, a dream come true.
I'm much more interested in expending time and resources contributing
to a complete open-source CL than in cobbling together yet another
howegrown Lisp. I'm not dismissing the validity of your point -- but
in this particular case we chose Common Lisp in the first place
because we needed flexibility and speed (both fast development and
good performance).
Internally we've discussed funding various projects to bring CMUCL up
to par with our requirements. The CMUCL maintainters, however, are
just as backlogged with work as everyone else.
-- Kaelin
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <nkj7l5yzzwg.fsf@tfeb.org>
Kaelin Colclasure <······@everest.com> writes:
>
> "Industrializing" CMUCL (or a variant thereof) is a very interesting
> proposition. A robust, maintainable, open-source Common Lisp
> implementation with solid community support behind it would
> be... well, a dream come true.
>
> I'm much more interested in expending time and resources contributing
> to a complete open-source CL than in cobbling together yet another
> howegrown Lisp. I'm not dismissing the validity of your point -- but
> in this particular case we chose Common Lisp in the first place
> because we needed flexibility and speed (both fast development and
> good performance).
>
My `meta' point was really that people should look very carefully at
what the benefits & costs of various options are. As far as I can see
almost no one does this, and those who do tend to try and do it with
accountants who can't do estimation because they're obsessed by
stationary costs or something, so they end up with huge, rigid, over
precise, models implemented as enormous spreadsheets several months
too late to be any use, when what they need is a model which can be
evaluated on a calculator and the back of an envelope, today.
I think if you can do these kinds of estimation you find quite
interesting things out, some of which are quite far from the received
wisdom.
--tim
From: Marc Battyani
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <8v9d2a$oea$1@reader1.fr.uu.net>
"Kaelin Colclasure" <······@everest.com> wrote in message
···················@soyuz.arslogica.com...
> I spoke to Tom at about the time all of this would have been going
> down, and he warned me to look carefully at the licensing arrangements
> on Franz's software. So I did -- I thought. I also clarified with our
> sales rep our deployment requirements and got a verbal indication of
> what our deployment costs would be -- I thought.
>
> Many months later, just after committing to ~$40K worth of development
> licenses from Franz the issue of live deployment was raised again. By
> Franz. And the price sheet we were presented at that time -- one
> entirely different from the pricing sheets we had previously based
> decisions on -- increased our projected deployment costs by
> approximately an order of magnitude.
>
> That's a zero tacked on -- and no, that does not get you 24x7 support.
> For some added perspective, that made ACL more expensive than all the
> other third-party software we licensed (including Oracle Enterprise
> Server), and the hardware we run it on, *combined*.
>
> Our production servers will be running Lispworks until Franz does a
> reality check on their pricing. Ah, and how many man/months did we
> lose porting our application between ACL and Lispworks? I really don't
> want to think about it.
Why do you want to go back to ACL?
Did you noticed a degradation of the performance with LW or is it you just
prefer ACL?
If there is a performance degradation, can it be compensated by a more
powerful hardware for a reasonable cost?
Marc
From: Kaelin Colclasure
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <wug0knve2p.fsf@soyuz.arslogica.com>
"Marc Battyani" <·············@fractalconcept.com> writes:
> Why do you want to go back to ACL?
> Did you noticed a degradation of the performance with LW or is it you just
> prefer ACL?
> If there is a performance degradation, can it be compensated by a more
> powerful hardware for a reasonable cost?
I really don't want to provoke yet another thread on LW vs. ACL. They
both have their merits, and should be evaluated in the context of the
application one has in mind. And of course in terms of bang for the
buck.
My personal bias -- I'll take CMUCL over either of them if it turns
out to be a viable alternative. And not principally because of cost,
but because of empowerment. If I need a feature / fix badly enough I
am empowered to do it myself or pay some talented hacker to do it for
me. I'm not at the mercy of a vendor's release schedule or market
positioning.
Sigh. Time is the enemy.
-- Kaelin
From: Marco Antoniotti
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <y6cem071ysu.fsf@octagon.mrl.nyu.edu>
Kaelin Colclasure <······@everest.com> writes:
...
> Our production servers will be running Lispworks until Franz does a
> reality check on their pricing. Ah, and how many man/months did we
> lose porting our application between ACL and Lispworks? I really don't
> want to think about it.
Ahem. I believe that is *your* problem. :)
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
From: Kaelin Colclasure
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <wud7frvddj.fsf@soyuz.arslogica.com>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Kaelin Colclasure <······@everest.com> writes:
>
> > Our production servers will be running Lispworks until Franz does a
> > reality check on their pricing. Ah, and how many man/months did we
> > lose porting our application between ACL and Lispworks? I really don't
> > want to think about it.
>
> Ahem. I believe that is *your* problem. :)
:-) Yes, well as I suspect many mundane application developers do, we
found it expedient to use multiprocessing, write a number of FFI's to
external libraries, etc. And we make use of CORBA -- which Franz
specified but only Harlequin implemented in its contemporary form.
If the rest of the industry had the good sense to stay inside the Lisp
world we could have too. And we'd probably be running CMUCL right
now... Or a Lisp Machine! (Schwing!)
-- Kaelin
From: Kenny Tilton
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3A10EDCA.68B85679@nyc.rr.com>
> For the first 1+ year that we operated a server business, Franz received
> in the neighborhood of $10K/year from us. Their new proposal was about four
> orders of magnitude larger.
100 million? It's late, maybe my math is off...
kenny
From: Robert Monfera
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3A0CB566.6E2DEF9B@fisec.com>
David Bakhash wrote:
> Tell me this, Kevin. Is it unrelated that companies fear you guys?
> Many of them despise you guys, some your very own customers? I can
> openly and honestly say, as for your direct compeditors, that the
> sentiment of their customers is _exactly_ the opposite?
Your post just proves that usenet bears every kind of messages without a
blink. As a self-proclaimed open and honest person, please name the
customers you represent (including yourselves). It's NIL, isn't it?
Robert
From: Robert Monfera
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3A0618EA.B29DB165@fisec.com>
John Foderaro wrote:
> 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
In article <·················@fisec.com>, ·······@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
....
))
> 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.
From: Marco Antoniotti
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <y6c1ywp9ghc.fsf@octagon.mrl.nyu.edu>
John Foderaro <···@unspamx.franz.com> writes:
> In article <·················@fisec.com>, ·······@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
--
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
In article <···············@octagon.mrl.nyu.edu>, ·······@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.
> 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.
From: Marco Antoniotti
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <y6c1ywn3itk.fsf@octagon.mrl.nyu.edu>
John Foderaro <···@unspamx.franz.com> writes:
> In article <···············@octagon.mrl.nyu.edu>, ·······@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 =============================================================
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
In article <···············@octagon.mrl.nyu.edu>, ·······@cs.nyu.edu
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.
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey3snp595ou.fsf@cley.com>
* Robert Monfera wrote:
> 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.
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182478168230749@naggum.net>
* Robert Monfera <·······@fisec.com>
| 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.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfwk8ah63xt.fsf@world.std.com>
Robert Monfera <·······@fisec.com> writes:
> 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 <·······@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.
In article <···············@world.std.com>, ······@world.std.com says...
>
> 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?
From: w.deakin
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3A06E0ED.6016BA05@pindar.com>
John Foderaro wrote:
> 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
In article <·················@pindar.com>, ········@pindar.com says...
> 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.
From: w.deakin
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3A07D26A.4B4EF01C@pindar.com>
John Foderaro wrote:
> 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.
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfw4s1kf58f.fsf@world.std.com>
"w.deakin" <········@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.
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.
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfwn1fc6jr2.fsf@world.std.com>
Kent M Pitman <······@world.std.com> writes:
> "w.deakin" <········@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.
On Tue, 7 Nov 2000 10:26:08 GMT, Kent M Pitman <······@world.std.com>
wrote:
>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.
To me this feels like a flimsy excuse to bash franz. I and others
have shown that it takes mere seconds to make the ansi image.
Kevin Layer
Franz Inc.
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfw3dh3kpkp.fsf@world.std.com>
Kevin Layer <·····@known.net> writes:
> On Tue, 7 Nov 2000 10:26:08 GMT, Kent M Pitman <······@world.std.com>
> wrote:
>
> >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.
>
> To me this feels like a flimsy excuse to bash franz. I and others
> have shown that it takes mere seconds to make the ansi image.
Not at all. I have no desire whatsoever to bash Franz. I said in
another post that I like Franz product technically and I like the
Franz people personally. I don't know how much more clear I can be.
However, the fact is that if you distribute a trial version that is not
ANSI CL when it comes up, I personally consider that to not be something
I want to take responsibility for having directed an impressionable newbie
toward and I will simply not do it. Do not take this personally. I am
not looking for an excuse to bash anyone. But I have consistently been
harsh toward other vendors who have made similar things ever since the days
of Gold Hill and their "lexical variable free subset of Common Lisp" and
other things more recent that have been absent from CLISP and GNU CL.
Indeed, I got really huffy at Harlequin while I worked there about the
way Liquid CL came up in CLTL1 mode--I was adamant that this was
inappropriate. (I don't know if they ever fixed it, but I hope they did.
Fortunately, it's not the implementation they distribute to newbies. Even
so, I think utterly wrong to distribute to customers even though the claim
was made to me that it could be reconfigured to ANSI-compliant form easily.
I prefer the idea of distributing multiple images and having one be the
ANSI CL one that can e used directly.)
When it comes to trial editions, I want one that is being ANSI first
because newbies are too impressionable and I don't want them
immediately exposed to lots of non-compliancies while they are still
shopping for a vendor. And right now, I know LW is that so I'll at
least point to that. I feel bad, in fact, recommending only one, so
I'll probably re-explore Corman CL and some of the other up and coming
Lisps just to make sure I'm not singling someone out. It will be good
for me to review this situation again... I feel out of touch with the
other implementations, and I know lots of new work has gone into some of
them that merits a fresh look.
To be clear, I didn't say I wouldn't ever recommend the Franz
product--just that I won't point newbies at the Franz trial edition.
This is not personal. This is not about companies. This is about
product presentation, pure and simple. I think my criterion is clear
and understandable. And I also think it's fair both to companies
and to the user base.
Given a choice between you distributing a trial edition which is not
ANSI but can morph to one and one that is only ANSI and cannot morph
back to your so-called "Modern" mode, I would prefer the latter. I
would say the same for any vendor. As to full releases, I think it's
appropriate to ship both (disk space being cheap these days) but I'd
want the installer to be clear to people about what they're getting so
no one was surpised.
You cannot recommend our lisp because we don't distribute an ansi
image, even though it takes a few seconds to make one. This makes no
sense to me at all.
> You cannot recommend our lisp because we don't distribute an ansi
> image, even though it takes a few seconds to make one. This makes no
> sense to me at all.
If it was equivalent, why didn't you do it the other way around, i.e.,
distribute an ANSI version by default with the option to build the system in
"modern" mode? Could it be that you know that it actually wasn't an
equivalent situation?
Bottom line, the system as distributed ISN'T ANSI. You seem to acknowledge
this by telling us that if only we rebuild the image, it will be ANSI. In
fact, he image, as distributed, is so far from the standard in a fundamental
area that it - to a prudent and somewhat observant user - could not be
considered ANSI compliant.
People are completely within their rights for noticing and informing others
of what can only be seen as a (possibly gratuitous) break with the standard.
It's your right to complain about this, but you don't help your case much.
Were you guys actually dumb enough to think everyone would appreciate this
"improvement"? People use standards because they are - well, standard.
Changing a product to be non-compliant is seen by users who want a standard
to be a "not good thing". If you want to distribute a standard compliant
image and give users the right to recompile it in "modern" mode, people
would probably reconsider their irritation.
faa
"Kevin Layer" <·····@known.net> wrote in message
·······································@4ax.com...
> You cannot recommend our lisp because we don't distribute an ansi
> image, even though it takes a few seconds to make one. This makes no
> sense to me at all.
From: Will Deakin
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3A092CC5.276F4935@pindar.com>
Kevin Layer wrote:
> You cannot recommend our lisp because we don't distribute an ansi
> image, even though it takes a few seconds to make one. This makes no
> sense to me at all.
With respect: in the context of somebody who is unfamiliar with common
lisp, I would hope that with the wit read this statment, and an
opportunity to reflect would make the inherent syllogism obvious.
Best Regards,
Will Deakin
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182670917871449@naggum.net>
* Kevin Layer -> Kent Pitman
| You cannot recommend our lisp because we don't distribute an ansi
| image, even though it takes a few seconds to make one. This makes
| no sense to me at all.
It's because it takes a few seconds _extra_ that makes the difference.
Again, why can't you just make that image while installing if it's
only a few seconds and nothing to it? If this is no big deal,
what's the big deal to you that causes you not to do this?
I find it hard to believe that you, too, get into a hyper-sensitive
defensive mode where the most important thing of all is not to admit
to any form of wrong-doing. That's why John is being flamed to
crisp. That's why Microsoft gets such a harsh treatment, too. You
have to open up and listen to criticism of what you do, even if you
think it isn't wrong at first. Otherwise, you're telling people
that their views are disregarded by you, and that's not what Franz
Inc has been known for, is it?
I'm not sure you understand just how much of Franz Inc's credibility
is at stake, here, or whether you're comfortable telling the world
that the USENET community in comp.lang.lisp makes no difference to
you at all.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
On 08 Nov 2000 11:15:17 +0000, Erik Naggum <····@naggum.net> wrote:
>* Kevin Layer -> Kent Pitman
>| You cannot recommend our lisp because we don't distribute an ansi
>| image, even though it takes a few seconds to make one. This makes
>| no sense to me at all.
>
> It's because it takes a few seconds _extra_ that makes the difference.
>
> Again, why can't you just make that image while installing if it's
> only a few seconds and nothing to it? If this is no big deal,
> what's the big deal to you that causes you not to do this?
There is no installation procedure to augment. bunzip the files, and
you're done. We wanted the installation to be done when you unpacked
the files. Simplicity is good. Initially, the disitribution included
both images (ansi and modern). The size was much too large for
download.
>
> I find it hard to believe that you, too, get into a hyper-sensitive
> defensive mode where the most important thing of all is not to admit
> to any form of wrong-doing. That's why John is being flamed to
> crisp. That's why Microsoft gets such a harsh treatment, too. You
> have to open up and listen to criticism of what you do, even if you
> think it isn't wrong at first. Otherwise, you're telling people
> that their views are disregarded by you, and that's not what Franz
> Inc has been known for, is it?
>
> I'm not sure you understand just how much of Franz Inc's credibility
> is at stake, here, or whether you're comfortable telling the world
> that the USENET community in comp.lang.lisp makes no difference to
> you at all.
Erik, I'm taking this orders of magnitude less seriously than you.
That doesn't mean I don't care what people think. I do. The fact is,
we distributed a Modern image with Trial. It takes a few seconds to
build an ansi image.
Now, if we had only given out a Modern image and no ability to build
the ansi image, then I'd take more seriously complaints from people
that didn't want to use the Trial.
Kevin Layer
Franz Inc.
From: Janis Dzerins
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <87vgtyidnv.fsf@asaka.latnet.lv>
Kevin Layer <·····@known.net> writes:
> On 08 Nov 2000 11:15:17 +0000, Erik Naggum <····@naggum.net> wrote:
> >
> > I find it hard to believe that you, too, get into a hyper-sensitive
> > defensive mode where the most important thing of all is not to admit
> > to any form of wrong-doing. That's why John is being flamed to
> > crisp. That's why Microsoft gets such a harsh treatment, too. You
> > have to open up and listen to criticism of what you do, even if you
> > think it isn't wrong at first. Otherwise, you're telling people
> > that their views are disregarded by you, and that's not what Franz
> > Inc has been known for, is it?
> >
> > I'm not sure you understand just how much of Franz Inc's credibility
> > is at stake, here, or whether you're comfortable telling the world
> > that the USENET community in comp.lang.lisp makes no difference to
> > you at all.
>
> Erik, I'm taking this orders of magnitude less seriously than you.
>
> That doesn't mean I don't care what people think. I do. The fact is,
> we distributed a Modern image with Trial. It takes a few seconds to
> build an ansi image.
Some of us are still concerned about the other question -- how the
"modern" mode is achieved in Allegro CL. Can it be done without
breaking standard (as I understand that's what Erik tried to tell)?
I think that moving to "modern" lisp is a normal and natural thing to
do. The only problem is how it is done. Do we do it all together? Or
have someone make it and give out to the rest to use it (and then
fight to death if someone finds that it could be done better or some
other way)?
I wonder why the way the case-sensitive-lower mode is implemented was
not given out to community for examination, just like Allegro CL 6.0
streams implementation?
That's what I as a Franz Inc. may-be-customer am worried about.
> Now, if we had only given out a Modern image and no ability to build
> the ansi image, then I'd take more seriously complaints from people
> that didn't want to use the Trial.
Is it really impossible to build "modern" image from ANSI image? (I
read that winblows version is ANSI and one can build modern from
that.)
Janis Dzerins
--
Ever feel like life was a game and you had the wrong instruction book?
On 08 Nov 2000 19:20:20 +0200, Janis Dzerins <·····@latnet.lv> wrote:
>I wonder why the way the case-sensitive-lower mode is implemented was
>not given out to community for examination, just like Allegro CL 6.0
>streams implementation?
The idea that every thing we do has to be previewed to the community
is untenable. It would be a lot of work. Also, I don't see others
doing it, for good reason. We did it with the streams implementation
because there was demand to see the spec early and we wanted feedback.
We have a beta program to elicit feedback about the entire package.
Each release (beta or not) comes with extensive release notes to help
guide users into new and changed functionality.
More importantly, the issue in question is not a new issue, as far as
I know. So, your comment doesn't even apply to this situation.
Kevin Layer
Franz Inc.
From: Janis Dzerins
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <87zoja73fr.fsf@asaka.latnet.lv>
Kevin Layer <·····@known.net> writes:
> On 08 Nov 2000 19:20:20 +0200, Janis Dzerins <·····@latnet.lv> wrote:
>
> >I wonder why the way the case-sensitive-lower mode is implemented was
> >not given out to community for examination, just like Allegro CL 6.0
> >streams implementation?
>
> The idea that every thing we do has to be previewed to the community
> is untenable. It would be a lot of work. Also, I don't see others
> doing it, for good reason. We did it with the streams implementation
> because there was demand to see the spec early and we wanted feedback.
OK. Now, that you have got feedback about your modern mode
implementation (even if you have not requested one), does it change
something?
> More importantly, the issue in question is not a new issue, as far as
> I know.
For me it is. But I'm just a newcomer here and want to understand why
things that are happening are happening.
In another post you said that it _is_ possible to build modern image
from ANSI image -- that was just your decision to make modern the
default one. And that, as I understand, won't change until next
release. Are there anything else related to the topic that will change
in the next release?
> So, your comment doesn't even apply to this situation.
I was just wondering.
Janis Dzerins
--
Ever feel like life was a game and you had the wrong instruction book?
In reply to Janis Dzerins <·····@latnet.lv>:
It would be premature to say what we will do next time. After all,
this release is just a little more than a week old.
Kevin Layer
Franz Inc.
In article <··············@asaka.latnet.lv>, ·····@latnet.lv says...
> I wonder why the way the case-sensitive-lower mode is implemented was
> not given out to community for examination, just like Allegro CL 6.0
> streams implementation?
>
This was done 15 years ago. Did comp.lang.lisp exist back then?
The readtable-case problem is something recent (I think that I first
heard about it 6 months ago standing outside the train station in Oslo).
I hope that it gets resolved in a way that makes everyone happy.
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <nkjvgtynxu0.fsf@tfeb.org>
John Foderaro <···@unspamx.franz.com> writes:
> This was done 15 years ago. Did comp.lang.lisp exist back then?
>
Yes I think so, though it might have been called net.lisp or
something (when was the great renaming?). Somewhere I have the post
announcing the creation of the newsgroup. From you, in fact!
--tim
From: Janis Dzerins
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <87vgty73ad.fsf@asaka.latnet.lv>
John Foderaro <···@unspamx.franz.com> writes:
> The readtable-case problem is something recent (I think that I first
> heard about it 6 months ago standing outside the train station in Oslo).
> I hope that it gets resolved in a way that makes everyone happy.
Are you going to participate in the resolving process?
Janis Dzerins
--
Ever feel like life was a game and you had the wrong instruction book?
In article <··············@asaka.latnet.lv>, ·····@latnet.lv says...
> Are you going to participate in the resolving process?
>
I'll have some input into the resolution and will review the final
solution. There are a lot of constraints to the solution, both due to
our own desire to be able to import ANSI code into Modern mode, plus
those things that the users want for new programs they are writing.
From: Marco Antoniotti
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <y6caeb9dv7n.fsf@octagon.mrl.nyu.edu>
John Foderaro <···@unspamx.franz.com> writes:
> In article <··············@asaka.latnet.lv>, ·····@latnet.lv says...
> > Are you going to participate in the resolving process?
> >
>
> I'll have some input into the resolution and will review the final
> solution. There are a lot of constraints to the solution, both due to
> our own desire to be able to import ANSI code into Modern mode, plus
> those things that the users want for new programs they are writing.
Are these new users aware of the current debate?
Will you (as Franz) be willing to accommodate an "agreed upon"
solution (where "agreed upon" means that all the implementors feel its
doable and "right" - for a given definition of "right") to this
problem which may not be completely compatibible with "Modern" mode?
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
In article <···············@octagon.mrl.nyu.edu>, ·······@cs.nyu.edu
says...
We definitely want input from people who plan on using it so that it
work best for them. We use it ourselves and its critical that we be
able to develop code in Modern mode and then deliver in Modern or ANSI
mode. It would more than double our workload if we all had to run one
compiler to build a modern mode version and another to build an ANSI
mode version.
Since it is an externally visible interface we have to be careful about
compatibility issues. We can always get around that by creating a new
mode and leaving the old mode working as it is for a few years so that
users have some time to upgrade their code.
Lest there being any confusion: We're talking about Modern mode here.
ANSI mode is not going to change.
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfwr94l9klq.fsf@world.std.com>
John Foderaro <···@unspamx.franz.com> writes:
> Lest there being any confusion: We're talking about Modern mode here.
> ANSI mode is not going to change.
But if we could eliminate the effective need for Modern mode, by the
creation of a portable library, for example, that would be good.
Surely you have no special desire to maintain two separate universes
if they could be consolidated...?
I think this is the issue that's plaguing many of us. Why is it necessary
to distribute separate images to accomodate this need? Why is it necessary
to split the community? We're hoping it's not necessary. We're not
convinced it is necessary. This discussion is about your showing us the
technical issues that lead you to believe you're right and all of us are
wrong. I've opened a new thread to talk about the technical problems.
I hope we'll begin the discussion anew there with a different tone.
I certainly welcome a calmer tone to the whole discussion and I've
replied in the other thread.
I'd like to take this slowly and give interested people a chance to try
out the Modern mode if they're curious. Then it won't be just people at
Franz arguing for it and providing examples from their work.
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <nkjitpwgemb.fsf@tfeb.org>
Kent M Pitman <······@world.std.com> writes:
>
> But if we could eliminate the effective need for Modern mode, by the
> creation of a portable library, for example, that would be good.
> Surely you have no special desire to maintain two separate universes
> if they could be consolidated...?
>
It seems to me that this would be hard. Although I disagree violently
with the way modern mode happens at the moment, I think that if it is
the case that (symbol-name 'car) is "car" there really is going to be
some problem having unification. I realise that you (Kent) perhaps
don't want that to be the case, but I can't see a way around it.
However, I do like the idea of being able to `copy' packages, which I
think you mentioned, and I've thought of. The problem I can see with
this is that the compiler (or interpreter) may have all sorts of
places where it says (if (eq x 'car) ... ...), and that's not going to
work, instead it would have to test some property of the symbol which
could be copied. If it could be made to work it would be way cool
though. Did the `package universe' business on Symbolics do anything
like that, I never really understood it, except that I always ended up
in the wrong universe.
--tim
From: Erik Naggum
Subject: A possible solution (was: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.)
Date:
Message-ID: <3182855319020600_-_@naggum.net>
* Tim Bradshaw <···@tfeb.org>
| It seems to me that this would be hard. Although I disagree violently
| with the way modern mode happens at the moment, I think that if it is
| the case that (symbol-name 'car) is "car" there really is going to be
| some problem having unification. I realise that you (Kent) perhaps
| don't want that to be the case, but I can't see a way around it.
I do not think there will be a problem. Franz Inc has pointed out a
number of issues inherent in assuming the case of symbols and I think
this is a good starting point for what a proposal must address to make
Common Lisp "unspecified-case". Most of these issues have to with a
single global value that affects everything. That is bad engineering,
so let's remove that problem-causing solution from our solution space
and focus on how designed-in flexibility and tolerance would look.
| However, I do like the idea of being able to `copy' packages, which I
| think you mentioned, and I've thought of. The problem I can see with
| this is that the compiler (or interpreter) may have all sorts of
| places where it says (if (eq x 'car) ... ...), and that's not going to
| work, instead it would have to test some property of the symbol which
| could be copied.
I do not see any problems with this, either. We merely need to
rethink how we represent the name of a symbol. Unbeknownst to most
people, Allegro CL _already_ contains both lower-case and upper-case
symbol names in a clever way wherein converting case just moves an
internal string pointer in most cases. This _should_ be done in the
symbol object itself, not via string pointer hackery, meaning that
each symbol would have an upper-case version and a lower-case version
of its print name. The global setting that affected the symbol naming
would then cause the appropriate symbol name to be retrieve, and the
need to make truly global changes and different images would vanish.
That global setting may then be as flexibly local as readtable-case.
But most importantly, very little work needs to be done to intern and
other internal symbol-aware functions to ensure that the duplication
takes place hidden from user view. In a transition period, you don't
neve need to store more than the upper-case version of the symbol in
the symbol, using, say, a symbol-indexed hash table with a maximum
size to store the converted lower-case names to save on that space.
This means that a lower-case Lisp may be built on top of a conforming
ANSI Common Lisp by shadowing-importing a few external symbols from
the COMMON-LISP package, and any vendor can easily roll these into the
standard image. As I see this, we wouldn't even have to violate the
standard globally in any way.
The only point that needs addressing is how to specify the reader
"mode" in a per-file manner. Kent Pitman's in-syntax macro is a good
starting point. Franz Inc's named readtables features is another good
feature. In addition to *readtable*, the new special variable that
controls symbol-case must be bound across load, etc, too.
We need to think outside the box to solve this issue, or outside the
typecase, as the case may be (all bad puns unfortunately intended :).
#:Erik
--
ALGORITHM: a procedure for solving a mathematical problem in a finite
number of steps that frequently involves repetition of an operation.
ALGOREISM: a procedure for solving an electoral problem in a finite
number of steps that frequently involves repetition of an operation.
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <nkj7l6eiu35.fsf@tfeb.org>
Kevin Layer <·····@known.net> writes:
> You cannot recommend our lisp because we don't distribute an ansi
> image, even though it takes a few seconds to make one. This makes no
> sense to me at all.
It may only take a few seconds if you know what you're doing, but how
many people will do it? My experience of teaching people Lisp is that
students will download things but are very unlikely to be clueful
enough to do anything other than run the resulting program. Even if
they read the documentation they may well not see the point of
generating an ANSI image. In fact it may well be the case that
*teachers* are in this situation too: in quite recent history I've had
to install a private copy of ACL 5.0.1 to replace the unpatched 5.0
which wouldn't run my sample code (the institution in question had a
license, they just hadn't got around to installing the distribution
after a year).
So I suspect that very many people will end up not running an ANSI
image unless the installation process builds one.
On the other hand I'm not working from much data and my sample is
skewed towards students, and since I've already complained about
people doing this (the mydogspot example) I shouldn't draw very strong
conclusions.
--tim
From: Will Deakin
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3A09407A.92C07915@pindar.com>
Tim wrote:
> On the other hand I'm not working from much data and my sample is
> skewed towards students, and since I've already complained about
> people doing this (the mydogspot example) I shouldn't draw very strong
> conclusions.
True. However, to reiterate what I believe to be the crucial point here:
*if* one of the target audiences for the free download *is* students --
and I hope that it is -- then these are the people who are least likely
to be able to carry out the conversion from modern (sic) to ANSI lisp!
On Wed, 08 Nov 2000 12:00:58 +0000, Will Deakin <········@pindar.com>
wrote:
>Tim wrote:
>> On the other hand I'm not working from much data and my sample is
>> skewed towards students, and since I've already complained about
>> people doing this (the mydogspot example) I shouldn't draw very strong
>> conclusions.
>True. However, to reiterate what I believe to be the crucial point here:
>*if* one of the target audiences for the free download *is* students --
>and I hope that it is -- then these are the people who are least likely
>to be able to carry out the conversion from modern (sic) to ANSI lisp!
I don't agree students are less capable, considering the actual task.
How many people these days can't copy/paste text? And, if they can't
should they be using sharp instruments like a computer?
Kevin Layer
Franz Inc.
From: Will Deakin
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3A0A7796.AC17DB17@pindar.com>
Kevin Layer wrote:
> I don't agree students are less capable, considering the actual task.
> How many people these days can't copy/paste text?
(sigh) this is not what this is about, and I would hope that you can see
this.
Could I ask what experience you have of the education process? My
experience suggests that it does not help to have execute an opaque
and/or arcane process at the outset. This tends to either be not carried
out -- potentially leading to problems in the future -- or divert the
focus from the task at hand to that of answering the question `why would
I want to do this?'
> And, if they can't should they be using sharp instruments like a
> computer?
As a smart remark often helps, I would complement you on the particular
smartness of this remark.
Best Regards,
Will
-- who is also guilty of spending too much of his time being smart
On Thu, 09 Nov 2000 10:08:22 +0000, Will Deakin <········@pindar.com>
wrote:
>> And, if they can't should they be using sharp instruments like a
>> computer?
>As a smart remark often helps, I would complement you on the particular
>smartness of this remark.
It's called a j-o-k-e.
On 08 Nov 2000 11:25:34 +0000, Tim Bradshaw <···@tfeb.org> wrote:
>Kevin Layer <·····@known.net> writes:
>
>> You cannot recommend our lisp because we don't distribute an ansi
>> image, even though it takes a few seconds to make one. This makes no
>> sense to me at all.
>
>It may only take a few seconds if you know what you're doing, but how
>many people will do it? My experience of teaching people Lisp is that
>students will download things but are very unlikely to be clueful
>enough to do anything other than run the resulting program. Even if
>they read the documentation they may well not see the point of
>generating an ANSI image. In fact it may well be the case that
>*teachers* are in this situation too: in quite recent history I've had
>to install a private copy of ACL 5.0.1 to replace the unpatched 5.0
>which wouldn't run my sample code (the institution in question had a
>license, they just hadn't got around to installing the distribution
>after a year).
You make it sound like they have to paw through lots of documentation.
There is a readme.txt file, which contains one thing, instructions for
building an ansi image.
We get questions about trial (and previously lite) all the time. Even
though we say we don't support it, we answer most, if not all, of the
questions.
I hope there aren't people that are confused by it and don't ask
someone (us or this forum).
>So I suspect that very many people will end up not running an ANSI
>image unless the installation process builds one.
And of this potential number of people, how many will notice?
If someone downloads the lisp for a class, I could imagine them using
the lisp and never even noticing what is being discussed here.
Again, my hope is they'll find the readme.txt and make a choice.
>On the other hand I'm not working from much data and my sample is
>skewed towards students, and since I've already complained about
>people doing this (the mydogspot example) I shouldn't draw very strong
>conclusions.
Kevin Layer
Franz Inc.
From: Hannah Schroeter
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <8ubq3v$d59$1@c3po.schlund.de>
Hello!
In article <··································@4ax.com>,
Kevin Layer <·····@known.net> wrote:
>You cannot recommend our lisp because we don't distribute an ansi
>image, even though it takes a few seconds to make one. This makes no
>sense to me at all.
Why not make the one delivered image ANSI compliant and have a procedure
of a few seconds to make a modern image from that?
Kind regards,
Hannah.
On 8 Nov 2000 16:05:35 +0100, ······@schlund.de (Hannah Schroeter)
wrote:
>Hello!
>
>In article <··································@4ax.com>,
>Kevin Layer <·····@known.net> wrote:
>>You cannot recommend our lisp because we don't distribute an ansi
>>image, even though it takes a few seconds to make one. This makes no
>>sense to me at all.
>
>Why not make the one delivered image ANSI compliant and have a procedure
>of a few seconds to make a modern image from that?
What we did is done. We will certaining take into consideration the
issues raised here for the next release.
Kevin Layer
Franz Inc.
From: Marco Antoniotti
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <y6chf5ie9m6.fsf@octagon.mrl.nyu.edu>
Kevin Layer <·····@known.net> writes:
> You cannot recommend our lisp because we don't distribute an ansi
> image, even though it takes a few seconds to make one. This makes no
> sense to me at all.
I believe there are two points in KMP comments.
1 - You cannot generate a "Franz Modern" image from the ANSI image.
2 - A novice reads the 'readme.txt' file, does not care/understand
about all this nonsense about generating an ANSI image, fires up
the "Franz Modern" image, tries to load some ANSI code which
assumes uppercase (e.g. in the package definition) and s/he gets
frustrated.
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
On 08 Nov 2000 11:01:21 -0500, Marco Antoniotti <·······@cs.nyu.edu>
wrote:
>
>Kevin Layer <·····@known.net> writes:
>
>> You cannot recommend our lisp because we don't distribute an ansi
>> image, even though it takes a few seconds to make one. This makes no
>> sense to me at all.
>
>I believe there are two points in KMP comments.
>
>1 - You cannot generate a "Franz Modern" image from the ANSI image.
This is not true. Btw, John Foderaro said this too, but he had
assumed we didn't distribute a particular file needed to do the
conversion properly.
>2 - A novice reads the 'readme.txt' file, does not care/understand
> about all this nonsense about generating an ANSI image, fires up
> the "Franz Modern" image, tries to load some ANSI code which
> assumes uppercase (e.g. in the package definition) and s/he gets
> frustrated.
This is a possibility. The question is, will they get frustrated
without contacting us, or not? Given they got the Lisp from us and
they have our email address (from the getting the license file). I
think it's unlikely.
Kevin Layer
Franz Inc.
From: Marco Antoniotti
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <y6c7l6ddsm6.fsf@octagon.mrl.nyu.edu>
Kevin Layer <·····@known.net> writes:
> On 08 Nov 2000 11:01:21 -0500, Marco Antoniotti <·······@cs.nyu.edu>
> wrote:
>
> >
> >Kevin Layer <·····@known.net> writes:
> >
> >> You cannot recommend our lisp because we don't distribute an ansi
> >> image, even though it takes a few seconds to make one. This makes no
> >> sense to me at all.
> >
> >I believe there are two points in KMP comments.
> >
> >1 - You cannot generate a "Franz Modern" image from the ANSI image.
>
> This is not true. Btw, John Foderaro said this too, but he had
> assumed we didn't distribute a particular file needed to do the
> conversion properly.
Good! This is out of the way then.
You can go
"Franz Modern" => ANSI
and
ANSI => "Franz Modern"
I know how to go the first route, how do you do the second one?
>
> >2 - A novice reads the 'readme.txt' file, does not care/understand
> > about all this nonsense about generating an ANSI image, fires up
> > the "Franz Modern" image, tries to load some ANSI code which
> > assumes uppercase (e.g. in the package definition) and s/he gets
> > frustrated.
>
> This is a possibility. The question is, will they get frustrated
> without contacting us, or not? Given they got the Lisp from us and
> they have our email address (from the getting the license file). I
> think it's unlikely.
Maybe.
If the person is a novice, s/he may have downloaded the trial example
under the direction of somebody else (e.g. my case) who has written an
ANSI package which s/he needs to run for her/his
genomics/bioinformatics experiments. The package breaks
unexpectedly. This person does not call you. The person calls me, who
in turn need to call other people who are maintaining ANSI packages I
have no control over.
It's legacy.
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
In article <·················@pindar.com>, ········@pindar.com says...
>
> 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
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182633961883425@naggum.net>
* John Foderaro <···@unspamx.franz.com>
| No matter which Common Lisp you use, you are using a Common Lisp
| that has extended the ANSI standard.
Nobody argues against this. It's the decision to _break_ the
standard that is under attack, not the decision to extend it.
Why don't you get it?
| So we have extended Common Lisp to support a Modern mode.
But lie about the readtable-case, ignore requests to change it, and
consequently break the standard. It's the breaking that is wrong,
not the extending. What does it _take_ to make you realize what the
issue is, John?
| You don't have to use this extension just like you don't have to
| use any other extension.
Not so. If I want that extention, I must accept that readtable-case
is no longer working. That's the crucial difference.
| case sensitivity is and always has been a very sensitive topic
| for reasons I don't understand.
Well, it is apparently very sensitive to you, while others tend to
think that you're highly irrational for it, since it isn't to them:
They just invoke the proper functions to get it, and that's it. To
you, it's apparently a major issue of language design fundamentals.
Is it that you don't understand why people don't accept your views?
Well, it _could_ be because you don't care what theirs are.
| 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 why _do_ you break readtable-case?
| So there will always be people who hate case sensitivity and see
| no need for it.
No, John, that is just not the case. Case sensitivity is an option
in ANSI Common Lisp today. I want that, but I also want the option
of case insensitivity, and it's _you_ who don't wamt to give it to
me (unless I take unfair advantage of my superior knowledge of the
system and nuke an internal variable). It is you who hate case
internal and see no need for it. Don't blame others for this.
| Those people can just build the ANSI image.
And if they wanted lower-case symbol names, too? Sorry, John, but
you've just plain lost it. I want _both_ lower-case symbols _and_
case insensitivity, but you're the beliggerent jerk who don't want
me to have that, and you break the standard so I can't get it.
| 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.
Well, I suppose I should be happy that you have finally _noticed_
the feedback, but I'm not. You're asking people to vote on whether
you should uphold a standard or not. That's somewhat like voting to
dismantle the entire government and go into anarchy. If you're for
anarchy, just do it. There's no need to have any vote on it first.
Just publicly declare that Franz Inc is no longer in the business of
selling a _conforming_ Common Lisp system, and nobody would bitch at
you, anymore. They probably wouldn't buy from you, either, but
that's at least an _honest_ and principled exchange of ideas. What
you're doing now is lie to us all, break the standard gratuitously
and signal that you consider conformance a question of public polls.
| - john foderaro
| modern mode cult leader
Geez. You really think this cult crap is funny.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfwlmux64sm.fsf@world.std.com>
John Foderaro <···@unspamx.franz.com> writes:
> >> 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"
On Mon, 6 Nov 2000 00:04:24 GMT, Kent M Pitman <······@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?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfwaebd43j7.fsf@world.std.com>
Paolo Amoroso <·······@mclink.it> writes:
> On Mon, 6 Nov 2000 00:04:24 GMT, Kent M Pitman <······@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.
From: Christian Nyb�
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <87r94psys2.fsf@siteloft.no>
Kent M Pitman <······@world.std.com> writes:
> 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
From: Rob Warnock
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <8uan6p$7kks4$1@fido.engr.sgi.com>
Christian Nyb� <·····@eunet.no> wrote:
+---------------
| Kent M Pitman <······@world.std.com> writes:
| > 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.
+---------------
And according to the O'Reilly XML Pocket Reference, p.18, so is XML:
Elements are case-sensitive: <Para>, <para>, and <pArA> are
considered three different element types.
-Rob
-----
Rob Warnock, 31-2-510 ····@sgi.com
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfw1ywnkoy7.fsf@world.std.com>
····@rigden.engr.sgi.com (Rob Warnock) writes:
> Christian Nyb� <·····@eunet.no> wrote:
> +---------------
> | Kent M Pitman <······@world.std.com> writes:
> | > 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.
> +---------------
>
> And according to the O'Reilly XML Pocket Reference, p.18, so is XML:
>
> Elements are case-sensitive: <Para>, <para>, and <pArA> are
> considered three different element types.
I tried unsuccessfully to locate the definitional point of this in the XML
1.0 2nd edition standard last night. Can someone find it for me?
I did find a place where it says:
This specification does not constrain the semantics, use, or (beyond syntax)
names of the element types and attributes, except that names beginning with
a match to (('X'|'x')('M'|'m')('L'|'l')) are reserved for standardization in
this or future versions of this specification.
(I find it curious that they have to reserve all possible mixings of cases,
since I doubt they'll ever use but one, and it seems overly invasive not
to leave at least some ability to do this to users. Maybe they don't really
trust that they'll stay case-sensitive.)
I couldn't find the criterion for matching a GI with its semantics. It does
say somewhere it doesn't do case-folding, but then elsewhere I vaguely remember
thinking that the way it manages "packages" (things with :'s) is that it
maintains separate identifiers and later maps them to the same semantics, so
the fact that it doesn't do case-folding wouldn't seem to prohibit it from
mapping multiple casifications to the same meaning either. I couldn't find
any of this on last night's look, though, so this paragraph should be taken
only as a set of questions, not a set of assertions about XML.
I spent a lot of time studying the last XML draft before the standard,
and then they screwed it all up and changed it in numerous ways for
the final thing, so I have some cached knowledge that is wrong and
I've never taken the trouble to update. I also really think they
broke some stuff they were close to having right, and I'm kind of sad
with the outcome, all in all. I still believe strongly in XML, mostly
for it's being standard, not for its being "The Right Thing". So I'll
live with its case-sensitivity if that's what it has. And since it gets
parsed/unparsed so often, I might even agree it's the right decision for them.
I just want to find the definitive reference to be sure.
I don't like trusting secondary references.
From: Gareth McCaughan
Subject: Case sensitivity of XML -- was Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <slrn90jssp.kh.Gareth.McCaughan@g.local>
Kent M Pitman wrote:
> I tried unsuccessfully to locate the definitional point of this in the XML
> 1.0 2nd edition standard last night. Can someone find it for me?
Section 2.12 "Language identification" says "Note that these
values, unlike other names in XML documents, are case insensitive".
That's all I could find. I think generally it's supposed to be
implicit, the principle probably being that case-insensitivity
shouldn't be assumed unless it's explicitly stated.
(This is the version of the spec labelled "1.0" and "10-Feb-98".)
Oh, there's something else: under "match" in section 1.2 "Terminology",
it says "Two strings or names being compared must be identical.
Characters with multiple possible representations in ISO/IEC 10646 ...
match only if they have the same representation in both strings. ...
No case folding is performed."
--
Gareth McCaughan ················@pobox.com
sig under construc
>>>>> "Kent" == Kent M Pitman <······@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.
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 <·······@lynda.com>
(defun whee (n e) (subseq (let ((c (cons e e))) (nconc c c)) 0 n))
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfwitq163po.fsf@world.std.com>
Graham Hughes <·······@lynda.com> writes:
> >>>>> "Kent" == Kent M Pitman <······@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.
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182483955225808@naggum.net>
* Kent M Pitman <······@world.std.com>
| 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
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
Kent M Pitman <······@world.std.com> writes:
> I also don't think there's evidence of convergence on case sensitivity.
> 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/>
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182480942936160@naggum.net>
* ········@hex.net
| 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, <····@naggum.net> and <····@NAGGUM.NET> name the
same mailbox, but <····@NAGGUM.NET> and <····@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
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
Erik Naggum <····@naggum.net> writes:
> * ········@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
From: vsync
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <86zojd74ji.fsf@piro.quadium.net>
········@hex.net writes:
> 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))
From: Hallvard B Furuseth
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <HBF.20001106tnoo@bombur.uio.no>
Erik Naggum <····@naggum.net> writes:
> 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
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182486032037306@naggum.net>
* Hallvard B Furuseth <············@usit.uio.no>
| 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. :)
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
From: Joe Marshall
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <4s1j3ht1.fsf@content-integrity.com>
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! =-----
In article <············@content-integrity.com>, Joe Marshall
<···@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.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
From: O-V R:nen
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <867l6f7k6i.fsf@urd.pop.k-net.dk>
Rainer Joswig <······@corporate-world.lisp.de> writes:
> 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?
From: Richard Fateman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3A08430D.34A3AC51@cs.berkeley.edu>
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
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfwg0l37a61.fsf@world.std.com>
Richard Fateman <·······@cs.berkeley.edu> writes:
> 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.
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey38zqv8p1s.fsf@cley.com>
* Richard Fateman wrote:
> 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
From: Hallvard B Furuseth
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <HBF.20001108ncu5@bombur.uio.no>
Tim Bradshaw <···@cley.com> writes:
> 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:
Yes, this thread keeps reminding me of the wars about 'long long'.
--
Hallvard
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.
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).
From: Joe Marshall
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <itpz1vyo.fsf@content-integrity.com>
John Foderaro <···@unspamx.franz.com> writes:
> 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?)
-----= 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! =-----
In article <············@content-integrity.com>, ···@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? 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"?
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <nkjy9yvinb3.fsf@tfeb.org>
John Foderaro <···@unspamx.franz.com> writes:
> 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
In article <···············@tfeb.org>, ···@tfeb.org says...
> 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.
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfwem0n78hp.fsf@world.std.com>
John Foderaro <···@unspamx.franz.com> writes:
> 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.
On Tue, 7 Nov 2000 21:55:14 GMT, Kent M Pitman <······@world.std.com>
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.
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfwlmuvs7bt.fsf@world.std.com>
Kevin Layer <·····@known.net> writes:
> ... 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.
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182636053404235@naggum.net>
* Kevin Layer <·····@known.net>
| 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.
Why not do that as part of the installation, then?
But note that you have to add my little patch to the "mlisp", too,
in order to get readtable-case to work and your system to stop lying
about what it actually does.
| Not to mention that this is in a **free** product. One that we
| provide to the community at great effort and expense.
This is all uniformly appreciated, without reservations, and perhaps
much more than you think. It's _because_ it is highly valued by the
community that this ruckus has erupted. If it was just some more
"free" trash on the market, nobody would care what you had done.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
In article <···············@world.std.com>, ······@world.std.com says...
> I *do* think language designers are and should be selfish.
Wow. This whole discussion has been worth it just to see you say that.
It is so wrong that I can't even express the magnitude in words, but it
at the same time it explains so much about why you did what you did
with respect to Common Lisp standard.
Allow me to give you the benefit of my 27 years of doing language design
and describe how the process is done:
1. The key is to know the target group for the language. You have to
know
their needs and limitation. You are writing the language for them
and not to satisfy your own ego, so what they want is paramount.
2. Eliminate all your personal prejudices. The best solution for the
target
audience may involve you doing things that you personally don't like.
Despite the fact that I don't like java, I recently wrote a mixed
lisp-java language that uses java semantics at the core in order to
satisify a key delivery need. I could have said "screw java" and
come up with something that made me happier but would have failed
to be useful to very many people.
3. Think about the future. You don't want your language to be
obsolete in a few years. An example of this is Java using Unicode
throughout even though the only wide character OS commonly used in the US
is NT (and I'm not familiar with what Apple's OS does).
The key is *not* be selfish. Even in a committee setting you
are representing the wishes of a large community who have wants,
needs and experiences different from your own.
I rememeber back when the original case debates were going on
and I would send messages saying that what Franz Lisp did would
satisfy both the case sensitive and insensitive camps (for those
who don't know what Franz Lisp did is very similar to a readtable-case
with two settings; :preserve and :downcase). I would also send
messages from polls of the Franz Lisp community (that had email)
and they overwhelmingly asked for a case sensitive capability.
You would argue "I don't like to see mixed case symbols." "I can't
distinguish mixed case symbols by pronounciation". It was
always "I","I", "I". This made me thing "Ok, it's no
big deal if you don't like it. You don't have to use it in your
personal code." I didn't realize that you had this selfish philsophy
and that it didn't matter that lots of people wanted case sensitivity,
you were going to vote based soley on how you felt, and screw
tne community. This was before x3j13 and it was just you and
a bunch of friends doing the voting.
Well at least I known now that there was nothing I could have done
and no amount of people I could have put forward to convince
you to vote for case sensitivity. Basically it was a lost cause
the moment you guys formed a committee.
regarding this:
(defun car (x) (CAR x))
(defun cdr (x) (CDR x))
(defun cons (x y) (CONS x y))
I don't know if you're just pulling my leg with this or if you're
serious.
We're not doing academic research, we're developing and delivering
a serious lisp system designed to be run in real applications some
of which run 24/7. Sure one can embed any language inside
a lisp system even another lisp, this time case sensitive.
There's a cost ot that embedding in space and maybe even speed in
some cases. If we are trying to compare a lisp based solution
to problem X vrs a C based one and the LIsp based one is N megabytes
bigger just so we can claim that it's 100% ANSI compatible at the core,
we are going to look like idiots.
Let's not get so hung up on standards that we forget that the
purpose of the Lisp language is to do real work. That's how
we measure success.
Clearly we are in these camps
1. those who hate mixed case symbols.
2. those who hate anything non-ANSI (that doesn't help them in their
current project).
3. everyone else
Let's just leave it at that. People shouldn't worry about seeing
a massive change in code due to this. Modern mode has been there 15
years.
I can't imagine why things should change in the next 6 months
(except that this whole discussion has gotten people curious).
one more thing:
> 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
If you want to see the "ferociously detailed specs", they are slightly
more than one page of html. Don't blink or you might miss it.
http://www.franz.com/support/documentation/6.0/doc/case.htm#portability-1
From: Chris Page
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <B62E0D87.3EC7%page@best.com>
in article ··························@news.dnai.com, John Foderaro at
···@unspamx.franz.com wrote on 2000.11.07 5:11 PM:
> In article <···············@world.std.com>, ······@world.std.com says...
>
>> I *do* think language designers are and should be selfish.
>
> Wow. This whole discussion has been worth it just to see you say that.
> It is so wrong that I can't even express the magnitude in words, but it
> at the same time it explains so much about why you did what you did
> with respect to Common Lisp standard.
I can't speak for Kent, but I read his statement to mean "selfish on behalf
of the community the designer represents", which I certainly agree with.
I don't think anyone would disagree that a language designer always has some
personal bias, and is always a member of the community (or communities) that
they represent. And that's fine, too. In fact, without a personal
investment, a designer cannot do a good job.
--
Chris Page
let mailto = concatenate( "page", ·@", "best.com" );
From: Thomas A. Russ
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ymir94m1jex.fsf@sevak.isi.edu>
John Foderaro <···@unspamx.franz.com> writes:
> Let's not get so hung up on standards that we forget that the
> purpose of the Lisp language is to do real work. That's how
> we measure success.
Somehow I don't equate "doing real work" with "rewriting my
standards-compliant code" just because a new version of the compiler
shipped. I would much prefer to add functionality rather than have to
introduce vendor-specific work-arounds into legacy code.
Now, I'm not against vendors adding implmentation specific extensions,
so long as they are identified as such, and so long as they don't break
standards compliant code.
Our Loom system currently runs in LispWorks, Allegro v 5 and below, MCL,
CMUCL, Liquid Common Lisp v4.2 and below. It already has what I
consider way too much conditionalization to handle implementation
differences and (occasional) implementation-specific bugs. I grumble
about some of these lacks, but at least in most cases the differences
were either mistakes or due to a lack of resources to fully implement
things.
I really don't need to have additional work foisted upon me because
products are purposely made not compliant with the standard.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
I agree completely. If you've got a working system then that's great
and there's no reason for you to change. Whenever you do any kind of
porting work you've got to ask what is the cost and what is the benefit.
It sounds like in your case the benefit to going to Modern mode is zero
so the cost is irrelevant.
John Foderaro <···@unspamx.franz.com> writes:
> I agree completely. If you've got a working system then that's great
> and there's no reason for you to change. Whenever you do any kind of
> porting work you've got to ask what is the cost and what is the benefit.
> It sounds like in your case the benefit to going to Modern mode is zero
> so the cost is irrelevant.
Not _quite_ irrelevant; if by using a particular Lisp implementation,
the user is _forced_ to go to "MODerN MODe," then even if the benefit
is zero, there is still the cost of porting the code.
--
(concatenate 'string "cbbrowne" ·@hex.net")
<http://www.ntlug.org/~cbbrowne/>
Rules of the Evil Overlord #24. "I will maintain a realistic
assessment of my strengths and weaknesses. Even though this takes some
of the fun out of the job, at least I will never utter the line "No,
this cannot be! I AM INVINCIBLE!!!" (After that, death is usually
instantaneous.)" <http://www.eviloverlord.com/>
In article <··············@441715.i-did-not-set--mail-host-address--so-shoot-me>,
········@hex.net says...
> Not _quite_ irrelevant; if by using a particular Lisp implementation,
> the user is _forced_ to go to "MODerN MODe," then even if the benefit
> is zero, there is still the cost of porting the code.
>
But all implementations today support ANSI mode and I would imagine
that they would continue to support ANSI mode as long as there
were people interested in that mode.
True new implementations could be written that are modern only
but as we've seen, new implementations of Common Lisp are rare.
From: Marco Antoniotti
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <y6c66ls50pk.fsf@octagon.mrl.nyu.edu>
John Foderaro <···@unspamx.franz.com> writes:
> In article <··············@441715.i-did-not-set--mail-host-address--so-shoot-me>,
> ········@hex.net says...
> > Not _quite_ irrelevant; if by using a particular Lisp implementation,
> > the user is _forced_ to go to "MODerN MODe," then even if the benefit
> > is zero, there is still the cost of porting the code.
> >
>
> But all implementations today support ANSI mode and I would imagine
> that they would continue to support ANSI mode as long as there
> were people interested in that mode.
>
> True new implementations could be written that are modern only
> but as we've seen, new implementations of Common Lisp are rare.
What if an ANSI(-like) solution were to be found that would solve your
perceived case sensitivity and at the same time make "Modern" mode
useless and irrelevant?
Would Franz scrap Modern mode?
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
From: Kent M Pitman
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <sfwitpsvh5y.fsf@world.std.com>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> What if an ANSI(-like) solution were to be found that would solve your
> perceived case sensitivity and at the same time make "Modern" mode
> useless and irrelevant?
>
> Would Franz scrap Modern mode?
I have the oddest feeling that they've defined the problem to be such
that changing ANSI is an essential element of the solution.
In the ANSI CL discussions, we tried to avoid such things by clearly
separating problem descriptions from proposed solutions, and by discarding
any who said the problem was that the solution wasn't implemented.
I have the impression Franz simply is unwilling to say to any customer
that they made any accomodation at all to the standard. If that's the case,
I don't think a solution is possible since they've defined the problem to
BE the standard. If that's not the case, they have yet to state what the
problem is. That's why I started this thread, but so far I've seen no
plainly stated problem description.
John Foderaro <···@unspamx.franz.com> writes:
> I rememeber back when the original case debates were going on
> and I would send messages saying that what Franz Lisp did would
> satisfy both the case sensitive and insensitive camps (for those
> who don't know what Franz Lisp did is very similar to a readtable-case
> with two settings; :preserve and :downcase). I would also send
> messages from polls of the Franz Lisp community (that had email)
> and they overwhelmingly asked for a case sensitive capability.
I'm probably a lot younger than you both but this seems like two
veterans redoing a war from 20 years past. Both Franz-Lisp and MACLISP
are dead I'm afraid.
But it seems you were more tolerant in those times. From:
." $Header: ch4.n 1.4 83/07/27 15:11:44 layer Exp $
.Lf cvttointlisp
.Se
The reader is modified to conform with the Interlisp syntax.
The character % is made the escape character and special meanings for
comma, backquote and backslash are removed.
Also the reader is told to convert upper case to lower case.
.Lf cvttofranzlisp
.Se
The reader is modified to conform with franz's default syntax.
One would run this function after having run cvttomaclisp, only.
Backslash is made the escape character, and super-brackets are
reinstated. The reader is reminded to distinguish between upper and
lower case.
.Lf cvttomaclisp
.Se
The reader is modified to conform with Maclisp syntax.
The character / is made the escape character and the special meanings
for backslash, left and right bracket are removed.
The reader is made case-insensitive.
.Lf cvttoucilisp
.Se
The reader is modified to conform with UCI Lisp syntax.
The character / is made the escape character, tilde is made the comment
character, exclamation point takes on the unquote function normally
held by comma, and backslash, comma, semicolon become normal
characters.
Here too, the reader is made case-insensitive.
Sorry for the troff-isms. I don't have a compatible roff to convert to
ASCII handy. BTW, what is UCI Lisp? Never heard of it in Lisp history.
> Well at least I known now that there was nothing I could have done
> and no amount of people I could have put forward to convince
> you to vote for case sensitivity. Basically it was a lost cause
> the moment you guys formed a committee.
I don't think X13 was founded as a conspiracy to spread case
insensitivity.
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
In article <··············@localhost.localdomain>, ···@bewoner.dma.be
says...
> .Lf cvttointlisp
> .Se
> The reader is modified to conform with the Interlisp syntax.
> The character % is made the escape character and special meanings for
> comma, backquote and backslash are removed.
> ...
This looks like a document I wrote many years ago. I think that it
might have been processed by a lisp program (which expanded ".Lf" to the
appropriate troff/nroff to display a "Lisp Function").
>> what is UCI Lisp? Never heard of it in Lisp history.
UCI is University of California at Irvine I believe. I don't remember
much about it.
From: Christopher J. Vogt
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3A0AC62E.23F2BAE@computer.org>
John Foderaro wrote:
>
> In article <··············@localhost.localdomain>, ···@bewoner.dma.be
> says...
> > .Lf cvttointlisp
> > .Se
> > The reader is modified to conform with the Interlisp syntax.
> > The character % is made the escape character and special meanings for
> > comma, backquote and backslash are removed.
> > ...
>
> This looks like a document I wrote many years ago. I think that it
> might have been processed by a lisp program (which expanded ".Lf" to the
> appropriate troff/nroff to display a "Lisp Function").
>
> >> what is UCI Lisp? Never heard of it in Lisp history.
>
> UCI is University of California at Irvine I believe. I don't remember
> much about it.
[pulling out my "The New UCI Lisp Manual" by James R. Meehan, 1979] The abstract says:
"This manual describes the PDP-10 LISP 1.6 system developed at Stanford University, the University of California at Irvine, and the Rutgers University. It is
intended to unify the Stanford LISP Manual (SAILON 28.7), the UCI LISP Manual (Tech Report 21, October 1973), and the Rutgers/UCI LISP Manual (April 1978)."
John Foderaro <···@unspamx.franz.com> writes:
> In article <··············@localhost.localdomain>, ···@bewoner.dma.be
> says...
> > .Lf cvttointlisp
> > .Se
> > The reader is modified to conform with the Interlisp syntax.
> > The character % is made the escape character and special meanings for
> > comma, backquote and backslash are removed.
> > ...
>
> This looks like a document I wrote many years ago. I think that it
> might have been processed by a lisp program (which expanded ".Lf" to the
> appropriate troff/nroff to display a "Lisp Function").
>
It was a quote from the franz lisp manual ;-)
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182670171755106@naggum.net>
* John Foderaro <···@unspamx.franz.com>
| In article <···············@world.std.com>, ······@world.std.com says...
|
| > I *do* think language designers are and should be selfish.
|
| Wow. This whole discussion has been worth it just to see you say that.
| It is so wrong that I can't even express the magnitude in words, but it
| at the same time it explains so much about why you did what you did
| with respect to Common Lisp standard.
Wow. This whole discussion has been worth it just to see you admit
that you bear serious grudges against Kent, John. I have wanted you
to come out and say that for a long time so I could trash it as the
most insipid, stupid, childish attitude problem I have ever come
across. Get the fuck over it, John!
| 1. The key is to know the target group for the language. You have
| to know their needs and limitation. You are writing the language
| for them and not to satisfy your own ego, so what they want is
| paramount.
Selfish does not mean "satisfy your own ego", it means looking out
for your own needs. If you want "egotistical", say that, instead.
Whether your needs are disregarding other people's needs or not is a
question of how smart you are, not how selfish you are. In other
words, whether the "self" whose needs you are concerned with is just
you, a community to which you belong, or even some greater group you
consider yourself and your vested interests in. You, for instance,
disregard people's needs for conformance to the standard in a stupid
way that alienates people. I wouldn't call that selfish, because
you have clearly destroyed parts of your own credibility and your
chances of success, so you're not exactly looking out for your own
needs, are you? Quite the contrary, but it isn't _unselfish_ in
that nice, biblical sense just because you're self-_destructive_.
| 2. Eliminate all your personal prejudices. The best solution for
| the target audience may involve you doing things that you personally
| don't like.
Such as actually conforming to a community standard, John?
| 3. Think about the future. You don't want your language to be
| obsolete in a few years.
If someone doesn't want this and looks out for his own needs, you
brand him selfish and satisfying his own ego. Can you please make
up your mind? The "selfish" you're trying to force into Kent's
mouth is "stupid, short-sighted, ignorant, disrespectful". He
didn't quite say that, did he? Why do you have to demonize him?
| The key is *not* be selfish. Even in a committee setting you are
| representing the wishes of a large community who have wants, needs
| and experiences different from your own.
If they are _different_ from your own, you have a problem. If you
can manage to find a way to make theirs your own or yours theirs or
transcend the particular needs with a more abstract solution, you
have built a group who can look out for their own needs (and thus
are _selfish_) and who have the right to disregard others, namely
those who are not part of the target audience, which is also what
you favor.
I would imagine someone who argues to fervently against selfish to
look out mostly for the people who are _not_ in his target audience,
because otherwise, you are clearly guilty of satisfying your own ego
at their expense, right? So we need to consider the needs of the
Russian coal miners on Svalbard when designing Common Lisp if we
shall not fall prey to John Foderaro understanding of ethics.
| You would argue "I don't like to see mixed case symbols." "I can't
| distinguish mixed case symbols by pronounciation". It was always
| "I", "I", "I".
And you _seriously_ think you're any better, John? You've gone out
of your way to talk about _your_ desire for a case-sensitive,
lower-case Lisp, and you are far worse than Kent in disregarding any
input you receive, because you defend yourself as if you're this
halo-wearing hero who unselfishly looks out for his target audience.
But you're the selfish one here, John, in _your_ definition of that
term: stupidly, short-sightedly, ignorantly, disrespectfully
screwing those who don't agree with you and thus aren't in your
target audience.
| I didn't realize that you had this selfish philsophy and that it
| didn't matter that lots of people wanted case sensitivity, you were
| going to vote based soley on how you felt, and screw tne community.
Kent doesn't have _your_ selfish philosohy, John. That's what you
would have done if you were looking out for your own needs. I know
Kent well enough to say that is not that stupid, short-sighted, or
arrogant. I know you well enough to say that the only thing that
keeps you from doing that kind of thing is to consciously ignore
your own needs, because when _you_ are looking out for your personal
needs, _you_ become the "Kent" you hate so much.
| Well at least I known now that there was nothing I could have done
| and no amount of people I could have put forward to convince you to
| vote for case sensitivity. Basically it was a lost cause the moment
| you guys formed a committee.
You have "known" this for years, John. It has always been false.
That's the tragedy of your position.
| Clearly we are in these camps
|
| 1. those who hate mixed case symbols.
| 2. those who hate anything non-ANSI (that doesn't help them in their
| current project).
| 3. everyone else
I find you in the "hate" group, and everybody else outside it.
The camps are these, as I see it:
1 Those who hate upper-case-mode and the standard.
2 Those who want lower-case-mode and the standard.
3 Those who don't care either way.
You're in camp 1. I'm in camp 2.
| I can't imagine why things should change in the next 6 months
| (except that this whole discussion has gotten people curious).
You could relax your hatred toward Kent and the rest of the
committee and you could ask friends for help in getting over your
personal grudges, and then you could ask someone at Franz Inc to
help you in the damage control that now nees to be done, because
everybody who has read this exchange from you now know for certain
that John Foderaro will only very grudgingly implement anything from
the standard, and it shows in Allegro CL, too: Excellent stuff all
over the place, except all these idiotic little bugs that crop up if
you expect the standard to be _fully_ implemented.
| If you want to see the "ferociously detailed specs", they are slightly
| more than one page of html. Don't blink or you might miss it.
|
| http://www.franz.com/support/documentation/6.0/doc/case.htm#portability-1
Your code examples break if *print-case* is not :upcase.
This is just too shoddy work to publish, John.
Whenever someone accuses someone else of being selfish as a line of
attack, look out for _their_ personal desires and how they screw
people to get them. It is their belief that _they_ are not selfish
and thus allowed to screw people, that causes them to screw so many.
Here's my collected wisdom on holier-than-thou folks: You are only
safe among people who admit to their interests. If someone says he
has no vested interests in what he is doing and he's trying to get
into political power or shape some community, run for your life: He
is capable of _unlimited_ atrocities. Only to the extent that he
_has_ vested interests and knows them well, can you predict a man's
behavior and rely on his word. Only if he admits to his interests
can you change his mind, too. A man who has no selfish interests is
impossible to reason with, because he doesn't say what he wants.
So, what _are_ your interests, John? What would make _you_ happy?
So far, it only seems you are happy if you can trash Kent and the
standard, no matter what you fail to accomplish in the process.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
From: Tim Bradshaw
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ey34s1j8k6n.fsf@cley.com>
* John Foderaro wrote:
> 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.
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
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182635693865782@naggum.net>
* John Foderaro <···@unspamx.franz.com>
| 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.
So why _did_ you force people into case sensitivity when you could
so easily have retained the functionality of readtable-case and
given them the freedom they want?
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
Erik Naggum <····@naggum.net> writes:
> * John Foderaro <···@unspamx.franz.com>
> | 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.
>
> So why _did_ you force people into case sensitivity when you could
> so easily have retained the functionality of readtable-case and
> given them the freedom they want?
This can only be due to ulterior motives (which, however, are probably
not too hard to guess at, and I have some theories).
Franz's inability to meet your proposal, which seems to me like an
excellent middle ground, is a clear sign that while they have a fine
Lisp, they are operating in a complex business environment in which
there are other forces at work, surrounded by which it's hard to not
be corrupted. It's not too far different from a computer bug.
There's a bug in their business practice, or perhaps several, and this
case issue is merely a manifestation of that bug.
dave
From: Joe Marshall
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <wvefzazk.fsf@content-integrity.com>
John Foderaro <···@unspamx.franz.com> writes:
> In article <············@content-integrity.com>, ···@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
-----= 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! =-----
On 07 Nov 2000 17:13:51 -0500, Joe Marshall
<···@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.
From: Thomas A. Russ
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <ymisnp31p8m.fsf@sevak.isi.edu>
John Foderaro <···@unspamx.franz.com> writes:
> 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 ···@isi.edu
In article <···············@sevak.isi.edu>, ···@sevak.isi.edu says...
>
> 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.
John Foderaro <···@unspamx.franz.com> wrote:
>In article <···············@sevak.isi.edu>, ···@sevak.isi.edu says...
>>
>> 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.
I hope I'll never be asked to help to convert the legacy application at
which I'm thinking... More than 100.000 lines, some of them written by
amateur programmers using Golden CL about 15 years ago (on DOS)...
Possible, surely . Feasible, maybe : who will do it, who will pay?
Seriously now, I don't see any reason why this application should be
converted to modern mode.
--
Francis Leboutte
www.algo.be +32-(0)4.388.39.19
On Wed, 08 Nov 2000 12:08:36 +0100, Francis Leboutte
<··········@algo.be> wrote:
>John Foderaro <···@unspamx.franz.com> wrote:
>
>>In article <···············@sevak.isi.edu>, ···@sevak.isi.edu says...
>>>
>>> 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.
>
>I hope I'll never be asked to help to convert the legacy application at
>which I'm thinking... More than 100.000 lines, some of them written by
>amateur programmers using Golden CL about 15 years ago (on DOS)...
>Possible, surely . Feasible, maybe : who will do it, who will pay?
>Seriously now, I don't see any reason why this application should be
>converted to modern mode.
Who is asking you to convert, if you don't want to? Case sensitivity
has been with Lisp since the 70's. We will never stop providing ansi
mode.
Kevin Layer
Franz Inc.
John Foderaro <···@unspamx.franz.com> writes:
> 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.
I don't know. My main experience with mixed-case identifiers was
a few years ago when I for a short period did some programming with
MacApp (Object Pascal) on the mac, and as far as I recall, even
'a very controlled manner' of MixedCase is often ambiguos (for
instance, if some constituent is an abbreviation, some programmers
love to write that constituent of the identifier ALLCAPS), so I
remember spending totally uneccesary time correcting compilation
errors because of wrong case in identifiers.
--
(espen)
From: vsync
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <868zqulqx3.fsf@piro.quadium.net>
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> I don't know. My main experience with mixed-case identifiers was
> a few years ago when I for a short period did some programming with
> MacApp (Object Pascal) on the mac, and as far as I recall, even
> 'a very controlled manner' of MixedCase is often ambiguos (for
> instance, if some constituent is an abbreviation, some programmers
> love to write that constituent of the identifier ALLCAPS), so I
> remember spending totally uneccesary time correcting compilation
> errors because of wrong case in identifiers.
heh. this happens in Java a lot, too. ironically enough, one of the
things that always trips me up is any method with "uppercase" in it.
i can never remember whether "case" is initial-capsed or not.
--
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))
vsync <·····@quadium.net> writes:
> heh. this happens in Java a lot, too. ironically enough, one of the
> things that always trips me up is any method with "uppercase" in it.
> i can never remember whether "case" is initial-capsed or not.
LOL :-)
But, when thinking of it, I'm not all that happy with hyphens either.
I have great difficulties remembering that there is 1 hyphen in
SLOT-BOUNDP and two in SLOT-EXISTS-P...
--
(espen)
From: vsync
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <86n1fa9g3c.fsf@piro.quadium.net>
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> vsync <·····@quadium.net> writes:
>
> > heh. this happens in Java a lot, too. ironically enough, one of the
> > things that always trips me up is any method with "uppercase" in it.
> > i can never remember whether "case" is initial-capsed or not.
>
> LOL :-)
>
> But, when thinking of it, I'm not all that happy with hyphens either.
> I have great difficulties remembering that there is 1 hyphen in
> SLOT-BOUNDP and two in SLOT-EXISTS-P...
This is why tab completion is your friend.
--
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))
Joe Marshall <···@content-integrity.com> writes:
> 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.
Fortunately, Emacs has a macro called "downcase-region."
> 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.
Which unfortunately forces this more towards the "ee cummings" school
of typography.
I somewhat prefer using "capitalize-region," which takes a middle
road:
> 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.
Summing up, we have:
a) The 3l33t DoodZ r00l perspective; it looks like Wired Magazine...
b) Something out of ee cummings or Joyce's Ulysses
c) The Marketing Collateral Style
All of which is there to get rid of the traditional:
d) SHOUTING MODE
> 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.
Kudos to Franz for showing us The Way...
--
(concatenate 'string "cbbrowne" ·@hex.net") <http://www.ntlug.org/~cbbrowne/>
"My soul is more than matched; she's overmanned; and by a madman!
Insufferable sting, that sanity should ground arms on such a field!
But he drilled deep down, and blasted all my reason out of me! I think
I see his impious end; but feel that I must help him to it. Will I,
nill I, the ineffable thing has tied me to him; tows me with a cable I
have no knife to cut. Horrible old man!
[...] Oh, life! 'tis now that I do feel the latent horror in thee!"
--Moby Dick, Ch 38
From: Erik Naggum
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <3182667112881283@naggum.net>
* Christopher Browne
| Fortunately, Emacs has a macro called "downcase-region."
It also downcases literal strings, comments, filenames, etc.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
Erik Naggum <····@naggum.net> writes:
> * Christopher Browne
> | Fortunately, Emacs has a macro called "downcase-region."
>
> It also downcases literal strings, comments, filenames, etc.
Yes. The Modernist position is that they _should_ be downcased.
Next issue?
:-)
--
(concatenate 'string "cbbrowne" ·@hex.net") <http://www.ntlug.org/~cbbrowne/>
"We're thinking about upgrading from SunOS 4.1.1 to SunOS 3.5."
-- Henry Spencer
In article <···············@octagon.mrl.nyu.edu>, ·······@cs.nyu.edu
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
On 04 Nov 2000 16:37:59 -0500, Marco Antoniotti <·······@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 for
download.
Kevin Layer
Franz Inc.
From: Marco Antoniotti
Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
Date:
Message-ID: <y6c3dh6pbb5.fsf@octagon.mrl.nyu.edu>
Kevin Layer <·····@known.net> writes:
> On 04 Nov 2000 16:37:59 -0500, Marco Antoniotti <·······@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.
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