For certain kinds of code, in particular code that does a lot of
low-level bit-twiddling (such as MD5) or code that does a lot of heavy
numerical computation (such as atomic bomb simulations) it is probably
true.  It may also be true for code that is very heavily I/O
dominated.

However for a large amount of code which spends its time doing more
typical pointer-chasing and structure manipulation, I think it is
quite possible to write code which is portably efficient in CL.  Code
I write which is of this kind has typically fairly small variations
between implementations - perhaps a factor of two or so, not including
CLISP which can often lose badly to native-compiled implementations
(although it can do surpsigingly well). Profiling (on more than one
implementation) doesn't show any awful bottlenecks, and in human terms
performance is pretty good.

Now of course this could be because I write uniformly dreadful code
but machines are so quick it runs OK, but I think that it's not that
bad.

So I think that with some exceptions (and these exceptions are largely
present in any language: ask someone who writes atomic bomb
simulations for a living aout portability and it's quite informative)
it is very possible to write portable, efficient, CL.

Adding the extended loop macro has fragmented the
Common Lisp community more than any other macro.
The people who use it write code that the people who
dislike it can't even read.  
Was it morally wrong to add the extended loop macro
to Common Lisp?  

I don't think so.  Lisp is a language you can evolve
to suit your needs.  When you write a macro or even
a function you separate people into those who
know and understand it and those that don't.  

I think the problem is not that macros (or whatever facility else)
fragment the community but more what follows from there. If both camps
can tolerate each others preferences all goes well - if one camp tries to
shut up the other camp by postulating them evil, dumb or simply "not
understanding ones" *then* the things stop being manageable.

I particularily like Common Lisp because it is a language that often chooses
to include multiple ways of thinking about something if no final consensus
has been reached. You are perfectly welcome to invent new things if you do
not try forcing others that _their_ approach is not permitted to use.

I _always_ hated people that are trying to _forbid_ me doing things the way
I liked it and I prefer not working with them anymore instead of being a
slave drone.

The irony is that in reality "intolerance" is intolerable. ;-)

ciao,
Jochen

  But it is fairly unlikely that C code compiled for both IA32 and SPARC
  will be "efficient" in the same way.  If you optimize too much for one of
  them, it is no longer "efficient" in the other.

  I also wonder what "efficient" means to you, and how you determine when
  you have achieved it.  It is not an absolute term.

  As for the use of byte-compiled implementations or code, I completely
  fail to see what their impact on this discussion is.  If you want your
  code to be "efficient", whatever it means, you choose a natively-compiled
  implementation, not a byte-code interpreter, so whatever efficiency
  issues may be perturbed by the existence of a such an implementation
  appear to me completely irrelevant to those who actually seek efficiency.

when you see
    (with-slot-frobbers (x 'slota 'slotb)
               ...)

  you will either know what with-slot-frobbers does
or you won't.

In article <slrn9u6rci.q89.m...@oscar.eng.cv.net>,
 m...@oscar.eng.cv.net (Marc Spitzer) wrote:

Raf

--

Forget how they're applied.  In code, you see a lot of
 (this (that (the-other)))
where this, that, and the-other are variously functions or macros.
The question of whether macros should expand the language [community]
or fragment it is no different sociologically than the question of
whether functions or even variables should.  Every name you introduce
that is nonstandard risks dividing the community, but on balance adds
potential power to someone at the same time.

If you'd had a CAR*, we'd be fighting over that.  It's not a macro issue.

  If a Common Lisp programmer insists on using C's standard library names
  for his string functions instead of the standard Common Lisp ones _and_
  argues that those who use the standard functions are nuts, I think there
  would probably be the same kind of uniform rejection of this stupidity as
  what appears to be building towards the limited IF* crowd, not primarily
  because of the specific idiotic new "feature" that nobody needs or wants,
  but because of the sheer irrationality of the whole endeavor and because
  of the incredible _arrogance_ exuded by those who thus reject the whole
  community they _pretend_ or may even helplessly _want_ to be members of,
  but are in fact rejecting completely.  It is that initial rejection of
  the community, the pretentious arrogance of one who thinks he knows so
  much better than everybody else, and the holier-than-thou attitude when
  criticized that comes from both of the former attitude problems, that
  _really_ ticks people off.  It is no longer about some stupid invention
  of a macro or a function or a new sub-language, it is about the lack of
  willingness to yield in traffic as opposed to a willingness to run into
  people on purpose because one thinks one is a superior to others -- it is
  the _exact_ same process that makes people become criminals.

  It is actually a good thing to have lots of people argue vociferiously
  for and defend a community standard because it shows that the community
  comes before the person, but it is a really _bad_ thing to have someone
  argue vociferiously _against_ community standards, especially when the
  only reason for doing so is that those very few who argue against it
  subjugate community interests to their own ego, even more so when it has
  become badly bruised in a battle over its anti-community tactics.

  At issue is not the specific new "features", whether they be macros,
  functions, or anything else, it is simply a rejection of someone who has
  decided to be an outlaw and force his own way regardless of consequences
  instead of trying to work within the law to make people agree with him
  how to make a better world -- probably because he realizes that it would
  in fact not _be_ a better world if he did not rule everything in it.

  I have long had an interest in law and the philosophy of law, but with it
  comes an interest in why people choose to abide by or violate a law, or
  even ethics.  Everybody has their own ethical standards which come into
  conflict with the law or at least other people's ethics at various points
  in their lives.  The really _big_ question is whether you are the kind of
  person who realizes that the only thing the law and ethics _really_ say
  is what is _wrong_ or you are the the kind of person who (mistakenly)
  believes that law and ethics tell people what is _right_.  The latter go
  on to be quite the intolerable moralists who want people to follow a
  specific path (i.e., whatever path they have chosen, and the two usually
  become conflated) or else they are doomed sinners upon which all evil can
  be hurled in a "defensive" action.  The former find it interesting how
  people choose among a very large number of ways to go about their lives,
  but may also be intolerant of those who, by breaking law and ethics and
  taking both in their own hands, make it harder or impossible for others
  also to choose their own ways.  It is threfore quite illuminating how our
  perpetrator continues to argue that he is within the law and community
  ethics when he does something he can have no doubts at all the community
  has resoundingly _rejected_.  The lack of willingness to stop doing,
  indeed, the insistence on _continuing_ what the community has disapproved
  of is precisely what defines the criminal mind.

  Law and ethics are wisely set up by lots of smart people working very
  slowly to ensure that proper procedure is followed, resulting in both
  being _vastly_ smarter than the average joe, in order to ensure that
  _very_ different people can live together under the same rules without
  needing special privileges for particular groups, which was the general
  situation before these intricate procedures were followed.  "Equality
  before the law" is definitely not in the _personal_ interest of most
  people, who would rather get a break than be held responsible for their
  actions.  (Punishment also does not work on those who do not understand
  what happened to them, only the threat of punishment does, although it
  can take an initial actual punishment for some people to "get it", but
  without real punishment, there is no threat, so this is a very hard
  problem to resolve.)

  What defines a community is in part its process of agreeing on its laws
  and ethics and other standards.  We have a language standard that should
  have united us.  Because of some lunatics who value being rebels higher
  than a working community, this is not quite so, and we still have to
  fight battles over what the community standards-setting procedures are.
  In essence, it will be fought over whether some nutcase can publish a
  "Coding Standard" document where he ridicules and undermines the standard
  that the community has in fact agreed upon and which thus rejects the
  community _and_ get away with it through stubbornness and sheer tenacity,
  or whether the community rejects this nutcase and moves on, despite the
  everpresent lack of _total_ agreement with any community standard.

  Some people will always disagree with some part of what has been agreed
  upon for a large population, and there are many reasons for this, but the
  real question is not what people disagree with, not with what they do
  when they disagree, not with how they plan to "convert" people to their
  ways, but with whether they wish to maintain a respect for that community
  standard or seek to destroy that respect and thus obliterate what holds
  the community together.

  This is not about some language feature or another, which, typically and
  predictably, the perpetrator will continue to whine that it is.  This is
  about how we wish to hold a community together.  There is no doubt that
  this insipid if* macro stunt is fragmenting the community like nothing
  else, despite the perpetrator's propagandistic lies about loop, which is
  the object of another of his destructive machinations.  The _only_ issue
  is whether the perpetrator can manage to stop fragmenting the community
  when he realizes that that is precisely what it does.  So far, all we
  have seen is an _increasing_ arrogance and even more stubbornness in his
  fight against the community.   Clearly, this nutcase/perpetrator values
  his protest _much_ higher than that which he knows that he is destroying
  in the process.  That kind of destructive attitude cannot be tolerated.

  If the nutcase/perpetrator had been willing to back down early, this
  would never have gotten to be such an issue.  It has become an issue only
  because he does _not_ back down.  Now he cannot back down because he
  would lose his personal prestige doing so, wrecking his "standing" among
  whoever still supports him.  This is pretty pathetic, but that is how
  things evolve when you are _wrong_ and are prevented from realizing it in
  time for personal and highly irrational reasons.  We must expect the
  perpetrator to protest his innocence too much and continue to pester the
  Common Lisp community with his bogus claims about the standard and how
  the language and the community should welcome his stupid stunt.

  Finally, if* has already become a symbol for the clueless rebels, but the
  likelihood that whoever initially thinks that stupid macro is a good idea
  will stick to it as they see what they are buying into by using this
  symbol of anti-standard, anti-community, childish rebellion against
  authority, will also decrease, hopefully further isolating the rebels.

  I have used an Emacs Lisp function to transform if* into an if, cond,
  when, or unless form as deemed appropriate through some simple measures,
  but it needs tweaking to make it work better.  It reverts the form to the
  bogus if* form when saving the file, unless it has been modified so as
  not to affect patches and other updates to the code from people who have
  yet to rid the code of the bogosity.  It should probably also realize
  when the if* nonsense is really trying to macroexpand a case, typecase or
  any of the other numerous much better ways of expressing things than an
  overly verbose and poorly formatted list of elseifs.

And again for the more common kinds of programs (in C as well as Lisp)
that do complex data structure bashing and lots of pointer chasing,
and other operations which don't map trivially onto machine
operations, the performance tends to be dominated by algorithms rather
than by some low level question of implementation.

Of course there are counterexamples - md5 might be one (though I
question its portability in C since it depends very much on integer
sizes and so on).  But I've written a fair amount of CL and by *far*
the overwelming problems with my programs are algorithmic deficiencies
and just plain bad design, with the sole exception of I/O.  I/O is a
sore point, because it's traditionally been rotten in Lisp, although I
think the situation is much better now.  However I would be *really*
surprised if I/O is portably good in any language: this is the kind of
thing that serious people spend a *lot* of time tuning per platform.
For small machines, of course, the problem has mostly gone away (even
in Lisp) since the machine is almost always I/O (and memory-bandwidth)
starved to the extent that it's hard for a program to not beat the
disk.  For large machines where I/O is closer to keeping up you have
to tune *extensively* anyway.

 However suppose you were given the power today to tell me that I can no
longer use if*.  Would you tell me that?

 .. and unrelated to that here's an editorial opinion (not directed
specifically at any one person):

 You talk about "community standards" and that's a very politically
correct term that doesn't raise anyone's shackles.   However I think
that Marc Spitzer hit the nail on the head when he talked about the "morality"
of writing a macro.  We can make the definition that if it was
immoral of me to write the if* macro then if* is an immoral macro.
Now I hope that people are starting to get bothered by such
a declaration.  Is it the case that the ANSI spec laid down the laws
as to what's a legal and non-legal Common Lisp program but now
some people are saying that legal Common Lisp programs are divided
between moral and immoral programs?  The decision as to what's moral
is made by self appointed people who read the scriptures (ANSI spec)
and come to their own interpretation and feel they can speak for the members
of the congregation (er.. I mean common lisp community).
Shall we anoint a Pope?  I know of one militant Common Lisp fundamentalist
who's been terrorizing non believers here for years who would love to
be able to force his will on others in the name of the community.
 The beauty of morality arguments over proofs is that contradictions
are just fine.  You can say "Thou shalt not write control flow macros
that duplicate what's in Common Lisp" and claim that if* is immoral
and at the same time say that when and unless are perfectly find macros
and in fact divinely inspired.  

- Should you be forced not to use IF*?
  No - definitely not! But at the _same_ emphasis _you_ cannot force
  others to use it or even to use it explicitely!
- If IF* a good idea for inclusion into a standard
  To answer this question we would have to discuss (again...) what the
  merits of IF* are. For building a community standard I think it is
  ok to include it if a significant amount of people use it and as long
  as a reference implementation is made public. (At least the latter is
  already done)

Note that my opinion of the latter point is because I think it is better to
include a facility used by a significant subset of the community over
disciminizing them by explicitely not including it. Note too that this does
_not_ imply including the attitude to forbid use of IF, WHEN , UNLESS
instead of IF*.

We have to realize that the topic IF* is not only yet another control-macro
but also the try to enforce the not-usage of some other facilities!

Now you can claim that it was the whole point of IF* was to replace the
other constructs and without that it would not much sense - if that is true
then the answer if IF* (seen at a whole) is _not_ morally tolerable because
it would include discriminating others style of programming.

ciao,
Jochen

Now you can claim that it was the whole point of IF* to replace the other
constructs and without that it would not make much sense to use it. If that
is true, then the answer if IF* (seen at a whole is _not_ morally tolerable
is simply answered, because it would include discriminating others style of
programming.

ciao,
Jochen

 What you may mistake for arrogance is my policy (which I've stated before)
of not responding to messages flaming me.  Someone who flames is just
trying to boost their own ego and isn't really interested in a serious
discussion.  The fact it that most of your messages directed at me
(such as this last one) contain numerous personal insults (and don't start
with the line about "I only insult people's behavior not the people
themselves".  No one has ever bought that argument).
 I will break my rule and answer your last letter.  You'll then respond with
posts full of insults for the next few months which I'll happily ignore.

 ok.. let's see if we can find the key points of your letter:

 I don't know what your problem is.  It certainly isn't about
some insignificant macro that most people couldn't care less about.

 I can't force anyone to program in any style unless I hire them to
work for me and we agree that a certain programming style is part
of the contract.

 I'm not telling anyone here how to program.  I simply codified my own
personal programming style.  I could have written "I don't use
if, when and unless for secret reasons that I'll never reveal"
and maybe that would have reduced the contraversy.   Frankly
I thought that people could handle reading opinions different
than their own.

You can't force anything on other peopre here, on USENET. And why
would you want that?

I won't comment on morality.

As long as argumentation goes -- Erik out-argumnts you hands down. I
don't take any sides here. I like seeing the brain-at-work in his
posts. Will we see a _real_ reply with quotes of the poster you reply
to any time soon? Or will they be this "nothing personal in here, just
my opinion; I have the rights to express my opinion, right?" stuff you
picked up recently?

I actually liked your posts before this "I'll help you get rid of
Erik" duty you have taken on yourself. I have learned a lot of things
from your open-source software as well. Thank you for that.

--
Janis Dzerins

The normal way to do what you did, btw, is to make a new package.

In my software at HyperMeta, Inc., I don't like a few operators
(DEFPACKAGE and ASSOC) so I changed them (mostly upward-compatibly, but
in the case of DEFPACKAGE, technically there is a possibility of
obscure clashes).  I just made another package called COM.HYPERMETA.CL
that has my versions of these.  No one will use it by accident; anyone
using my software can feel free to import either CL's versions or
mine.  I don't expect to get heat from this approach because I'm not
fighting other people's uses.  I just made my own space to play in
non-invasively.  People who don't want the extra DEFPACKAGE options I
offer, or who don't want to use SETF of ASSOC, can just ignore my
extensions.

Also, I *do* regard my changed package as a new language.  I don't know why
you don't think of CL+IF* as a new language.  Maybe you're worried it will
lose you the support of CL users, and as an empirical thing, it may.  But
if so that isn't because of your being a new language, it's because you
made a bad choice that people don't want to flock toward.  Like you,
I expect people to flock toward my changes, but if they don't, I'm not
going to hide behind "it's just CL".  I'll say it's because they didn't
like the trivially different language I made.

Incidentally, I have another language, COM.HYPERMETA.LISP which is
much less trivially different -- that is, contains a lot of other junk
/ goodies (depending on yourpoint of view). I just went in two stages,
first changing CL non-invasively, then adding other stuff as
extensions to that, in case people cared to only go one of the two
steps.  Or there are ways they can pick and choose from only the parts
of COM.HYPERMETA.LISP they like... but it's easier with my DEFPACKAGE. ;-)

Why should I even distribute it? Well, the people using ACL can use it
off the shelf and those that use other Lisp may be able to port it or at least
may be curious how something was done.  

The cost to me to ensure that it works in all the various conforming CL's
out there would probably mean that I'd just not distribute anything.

If I merely added the definition of if* to all my source files it would
add nearly nothing to making the code easier to run on other Common Lisps.

I know that this sounds like I'm lazy or selfish but remember back
to what Erik said about not distributing code any more because he finds
the people receiving it are ungrateful and just complain.

I've got three choices (and yes technically it's Franz's choice but
in the case of code I've written I think they would go along with
what I wanted).
1. I could not opensource the code
2. I could opensource what I've written which is ACL only
3. I could make it work on all lisps and open source that.

well 3 is out, since I don't have the time, knowledge or energy to
coordinate such an effort, and it may not be the best thing for
the code.

So I could either do 1 or 2.  If people are offended that I chose 2
I can always do 1.  That's very easy to do.  Would that benefit
the community more?

In the case where you're shadowing ANSI defined functions then you
are indeed defining a new language.

if*'s a better name than shadowing 'if' since emacs doesn't have to
be very clever to distinguish 'if' from 'if*' and indent each correctly.  
Also you can give someone some code and the if* macro and they can run it.  
They don't have to go through shadowing 'if' in a package to use it.
If I were to publish code using a shadowed 'if' that had the 'if*'
keywords it would totally baffle the newbies and even old timers
would dislike it.

 (setq x '())                    => ()
 (setf (assoc 'a x) (cons 'a 4)) => (a . 4)
 x                               => ((a . 4))
 (setf (assoc 'a x) (cons 'a 5)) => (a . 5)
 x                               => ((a . 5))
 (setf (assoc 'a x) (cons 'b 1)) => (b . 1)
 x                               => ((b . 1) (a . 5))

I also add the more useful functions, like this one:

 (association 'a x)          => 5
 (setf (association 'a x) 6) => 6
 (association 'a x)          => 6
 x                           => ((b . 1) (a . 6))
 (setf (association 'c x) 0) => 0
 x                           => ((c . 0) (b . 1) (a . 6))
 (decf (association 'c x) 3) => -3
 x                           => ((c . -3) (b . 1) (a . 6))

Getting the value and not the cell makes things like INCF/DECF more useful.

I have functions for the other-style ALIST, too.  But then, the point
is that I spent a bit over six months full-time just writing all kinds
of support for things I was tired of not having...  (So you'll forgive
me if I don't just post the lot of it on some free software site, btw;
I've burned through that many months' salary worth of savings and credit
card buildup, and now have to figure out how to make some money back on
all that investment.  I promise it's not all as trivial as SETF of ASSOC,
though...)