1: you need to keep it avalible on the internet, you need to rent some
space & bandwitdth

2: you need to keep backups and keep track of them, for all versions
of your software that is encumbered with gpl, to the best of my
knoledge

3: if you fail to do 1 and 2 you could get sued by some one else and
draged through the legal system, always fun.

A quick aside look at freebsd getting turned into OS X.  Apple did the
right thing (darwin) and kept parts closed source, which is there
right under the bsd licence.  

Also the GPL does not realy hurt big companys, they see an idea they
have the resources to copy it with out touching the source.  The
people the gpl hurts are small businesses that do not have the
resources to reimplement everything by denying them the ability to
recoup there investment and/or protect any trade secretes that are
used in their derived work.  This hurts people who could use the
product and the businesses that could make them.  I would even say it
hurts open source because it deprives them of a source of good
commericaly viable ideas to build projects around, producte with an
installed base give open source cloning projects a much better chance
at success.

One last thing, if I add enough value to get people to pay me money
even when there is a free version avalable, am I not entitled to the
fruits of my labor?

Good night

Good night

    Erik>   But it might box the result when returning it, unless the function call
    Erik>   is inlined or declared in to return unboxed results.  E.g., Allegro CL

I was leaving that as an exercise for the reader. :-)

The ability to pass unboxed values across function calls OTOH requires
something else:  The receiving site needs to know to expect an unboxed
value (either in an unboxed register, or inside the normal registers,
if there is no partitioning), and the function itself must know that
all possible receiving sites can handle that unboxed value.  Unless
you can pass the information "value is unboxed" dynamically to a
receiving site, and all receiving sites the implementation produces
are able to deal with this (which will introduce quite a bit of
overhead into function calls everywhere, for little gain), you need
some closed-world assumption, i.e. either all receiving sites must be
known at compile-time, or it must be ensured that all receiving sites,
including future receiving sites are capable of dealing with an
unboxed value return.

There are various ways of achieving that closed world.  Inlining is
one obvious candidate.  Another possibility is folding all cooperating
functions into one flet/labels form, from which no closures escape.

CMU CL allows a nice syntax for this via its block-compilation
declarations, which allows certain functions in the block to be
declared as external entry points, and all other functions as purely
internal functions.  I.e. in the following code, only the return value
of baz needs to be returned re-boxed, all other values can be passed
around in unboxed form:

(declaim (optimize (speed 3) (debug 0) (space 0) (safety 0)))

(declaim (start-block baz))

(declaim (type (function ((unsigned-byte 32)) (unsigned-byte 32)) foo bar))
(defun foo (x)
  (declare (type (unsigned-byte 32) x))
  (logxor x #xF1F1F1F1))

(defun bar (x)
  (declare (type (unsigned-byte 32) x))
  (logxor #x7E7E7E7E (foo x)))

(defun baz (x y)
  (declare (type fixnum x y))
  (bar (+ x y)))

(declaim (end-block))

Other implementations provide other ways of "closing the world", in
order to allow optimizations like unboxed argument/result passing to
happen.

Regs, Pierre.

However, there is a subtle snag here; Raymond's example uses
(unsigned-byte 32) values, and Allegro CL only does unboxed arithmetic
on (signed-byte 32).  This isn't a big problem for someone who knows
how to use signed values as if they are unsigned values (i.e. the most
negative 32-bit number, when converted, looks like #x80000000, and the
machine integer representation for -1 in unboxed (signed-byte 32)
representation becomes #xffffffff.

But why only one choice?  Why not allow both (signed-byte 32) _and_
(unsigned-byte 32)?  The problem is in the range overlap in deciding
the type upgrade.

Background:
The compiler always tries to do regular boxed arithmetic whenever
the types assigned to calculations are within fixnum range, because
that is still most efficient.  If the fixnum range is exceeded, but
the calculation remains within the "unboxed integer" range, then most
of the calculation can be done efficiently, but the final result must
be "boxed" by testing for fixnum and either shifting (for values in
fixnum range) or boxing into a bignum (for values too large for
a fixnum).  We use a runtime primitive called fixnum-or-bignum
to do this.  The final type upgrade is when the range of the calculation
exceeds even this unboxed integer range, and thus the compiler has to
generate generic code (in the generic sense, not in the CLOS sense).
In summary, there are three integer gradations: fixnum, then unboxed, and
then generic.

So consider the following function:

(deftype positive-fixnum () '(mod #.most-positive-fixnum))

(defun foo (x y)
  (declare (optimize speed) (positive-fixnum x y))
  (+ x y 10))

Each variable has a declaration of positive-fixnum, or in
normalized form: (integer 0 #.most-positive-fixnum).
There can actually be two additions implied here, but because
addition is associative I'll only describe the final calculation
result, which can be given a type of
(integer 10 #.(+ (* most-positive-fixnum 2) 10))

Now, the above type does not fall within the fixnum range, so it must
be upgraded.  Question: does it fall within (unsigned-byte 32) range,
or (signed-byte 32) range?  Answer: Yes!

This ambiguity would cause extra work for the compiler, to keep
track of what choice it has made, or to possibly keep two possible
compilation strategies, so as to know how to box the final result,
either using fixnum-or-bignum, or using unsigned-fixnum-or-bignum
instead.  It should be possible to do this, but we chose not to,
because that would have made such compilations much more complex, and
introduced many possible bugs.  Also, the decision to only track one
type allowed us to use the same unboxed-compilation mechanism
as we use for doing unboxed floating-point values.  It also allowed us
to encode some of the low-level bit patterns representing gc states
into two-bit patterns, with four states each (lisp-value, single-float,
double-float, and (signed) machine-integer).  This is useful for our
immediate-args concept, where unboxed arguments can be passed between
lisp funxtions.

Whether we made a correct decision to choose (signed-byte 32) over
(unsigned-byte 32) is debatable; I have little hard data, and only
a general sense, but I believe that the pros and cons are relatively
balanced; on the one hand, the obvious inadequacy of our choice is
that foreign interface communications are slightly harder to make
efficient (although since a 32-bit C compiler doesn't know the
difference between receiving an int or an unsigned int as an argument,
one could just lie to the foreign interface)
but on the other hand, most people don't create unsigned positive-fixnum
types, and instead tend to work with fixnum type declarations whenever
they want to say "this is a small number".  Since fixnum is a signed
type, we chose to stay with the signed version rather than the unsigned,
as a philosophical balance to match the fixnum type.

The conclusion is the same as the start: a user should ask and
investigate.

And what else it the lawyer going to say, "this has wholes you could
drive a truck through" perhaps?  He/she has a legal responability to
represent his clients best interests.

  I see.  You think this all a game of insulting eachother the most.

| > | [Skipped ad-hominem attacks]
| >   Well, gee, your own are apparently OK, while you have a problem with
| >   mine. That kind of double standard _really_ annoys me.

| I have tried hard not to make any such attack in the current thread.
| I apologize if there is anything that could be construed as such in
| my messages.

  Oh, for crying out loud, please quit the pathetic lying, you numbnut.

| If you are only ready to help people better than yourself,

  Geez.  Where did _this_ crap come from, numbnut?

| you'll find that the only people whom you accept to help are those who
| don't need your help.

  Precisely.  People who _need_ help should not get it for free.  They
  should pay for it.  In an exchange of helpfulness where each party gives
  help for free, the only "payment" one may get is that of having saved
  someone else a little time who might save oneself a little time later on
  in return.  If you help people who _need_ to be helped, you do them a
  major disservice -- you rob them of their only opportunity to learn by
  working through some problem, you make them jump further than they should
  and then they fill in the gaps with guesswork and assumptions that take a
  lot of time to untangle, and they will keep asking for the same kind of
  help over and over.  Like that "ab talebi" numbnut.

| You seem to me to react like you take perfection as a granted ideal
| such that ethical behaviour consists in destroying whatever is imperfect.

  Wrong.  Striving for perfection I do take for granted.  There are people
  who do not want this and who strive for imperfection, instead.

| I think that that on the contrary, perfection is an unreached ideal
| such that ethical behaviour consists in building more perfect things.

  You are too unware of your thinking processes to realize how it is _you_
  who fail to live up to this.

| I do not feel "betrayed" - nobody owes me anything.

  _Really_?  Who do you think you are kidding?  If the language is flawed
  and other people should implement the things you "want", you spell it out
  as betrayal and being owed something.  It is pretty damn obvious.

| I feel like there is a room for improvement,

  Yeah, right.  "Flawed" means it is unusable as is, which you are also
  quite explicit saying.  "Improvement" means it is usable now and could be
  more usable.  The latter is _not_ your position.

| Whereas you are only very rude and quick to ignore or dismiss arguments
| (rather than actually attack them) once you decided that someone was a
| bad person.

  Wrong, but you are both a bad person and incredibly unaware of your
  thinking processes, so your arguments are also utter bunk.

| Indeed, if I manage to avoid characters altogether (and thus not use any
| character-based library), or else use non-portable extensions (and lose
| some interoperability) I can avoid double-buffering. This is a worthwhile
| engineering tradeoff to consider. But I argue that this is a current flaw
| in the language.

  You keep saying that, and refuse to back it up with anything that has
  been requested of you.  I find this interesting.  You also managed to
  answer almost every paragraph in what I wrote, _except_ this one:

  So if I understand you right, you think it is perfectly OK for a vendor
  to use internal, implementation-specific features to implement a common
  or standard specification (or, in case you are not quite up that level of
  quality, just fix things your way), that is perfectly OK, but if you do
  it yourself, it is _not_ OK?  Just _why_ is it that you cannot do this
  yourself?  What makes it so important to you that somebody else do the
  dirty work that you do not want to do yourself?

  Why did you not respond this?  Would it be too revealing if you did?

| I didn't say you did. I tried to clarify and argue my opinion, which from
| your post I construed to be opposite to yours.

  Oh, cut the crap!  What is an "opposite opinion"?  Are you really such a
  numbnut that you cannot even see that there are many axes along which to
  construe opposite positions here?  All I say is that your stupid line
  about the language being flawed is a load of crap and that your use of
  characters in the MD5 algorithm is fantastically misguided, so you just
  _have_ to run into problems, which you blame on the language instead of
  your sorry excuse for a brain and your own incompetence at your task.

| I do not want to access implementation-dependent aspects of the
| character.  I want to access protocol-dependent aspects of the character,
| in an implementation-independent way.

  Numbnut.

| Sometimes, the protocol and the implementation agree, and then I like to
| be able to take advantage of it; sometimes they do not, and I find it a
| pity that it makes reuse of code designed to manipulate characters a
| nuisance.

  So use the _bytes_, you insufferable numbnut.

| I know many flaws in my code (it notably does much more consing ...

  Oh, christ!  Are you really so stupid?  Do you not even understand that
  the issue here is the character type you complain about?  Do you again
  think that there is only one axis along which to move from worse to
  better?  How annoyingly stupid is it possible for somebody to be?  Geez,
  some people!  Look, numbnut, it is your attitude that your use of the
  character type for something it is clearly not suited for is perfect and
  that the language is flawed because your code certainly cannot take any
  improvement that is the problem, here.  Your code is bogus, crappy, a
  load of shit, a misconceptualization, an abstraction inversion, what have
  you, and you are too incredibly incompetent to realize it.  That is all.

| Well, the fact that something implementation-dependent has to be done for
| efficiency is precisely what an "abstraction inversion" is about when you
| try to do it portably.

  Efficiency _is_ implementation-dependent, you insufferable numbnut.

| I argue it's a flaw in a language;

  Yeah, you and that other doofus, whatshisname tail-call "elimination",
  think the language is flawed because you numbnuts cannot figure out how
  to write better code and have deeply rooted psychological problems with
  doing what it takes to get what you want.

| A lot of useful code is written in LISP, C, C++, Java, OCAML, SML,
| Python, Perl, etc., that is written in a portable way and provide
| portable interfaces efficiently.

  This is really, _really_ wrong, numbnut.  These languages are only
  portable across a very specific platform type: 32-bit machines.  Give
  them something else and they are no longer "portable" at all.  Of course,
  _you_ live in a world of only 32-bit hardware, but Common Lisp does not.

| Indeed. *Having to do it* is the wrong, and *doing it* is the right that
| hopefully fixes that wrong.

  You do not _have_to_ do it, you numbnut.  You choose to do it because you
  want better efficiency, and you choose to do it your way because you are
  incompetent and much too arrogant.

| >   Have you ever wondered how all these implementations sprung into
| >   being from nowhere when people like you do not want to implement
| >   things they say they want?

| Uh? My post was precisely about code I was publishing.

  Grow a brain, numbnut.  Lots of people have done lots of implemenation-
  specific work to make the world of supremely usable _portable_ Common
  Lisp possible for you to complain about.

| I admit I should be back to coding -- wasted more than enough time
| posting on USENET.

  Another stupid choice of yours.

| >   It is not a question of picking one implementation and sticking with it,
| >   but of actually using an implementation to get what you want.

| Maybe you should explain the difference.

  Oh, please do not play worse of an idiot than you are!  You can use
  multiple implementations to their fullest without choosing one and
  stikcing with it.  How hard can this be to grasp, numbnut?

| >   interface that does not expose the implementation-dependent features
| In the case of modular integers that's easy.
| In the case of doing the Right Thing(tm) with characters, that's difficult.

  You are only seriously confused about what the Right Thing is, numbnut.

| For other flaws in CL (modularity, concurrency, etc.),
| I doubt it is possible.

  Of course you do.  You cannot even get simple type choices right.

| >   You seem to believe that as soon as it is necessary to do something
| >   like this, you have found a flaw in the language.
| Yes. It might not be a big flaw (depending on what it is),
| but it is a flaw nonetheless.

  The flaw is located in your pathetic excuse for a brain, numbnut.  It is
  not in the language.

| In as much as I might not always be precise enough in what I say,
| you read everything with negative prejudice and then become rude.

  A numbnut who resorts to "always", "never", "nothing" and "everything"
  has lost his touch with reality and prefers a vastly simplified, hugely
  exaggerated world which is much simpler for this limited brain capacity
  to deal with.  You are _obviously_ wrong.  Stupid exaggerations always
  are.  I am rude to idiots, numbnuts, and arrogant ignorants like you.

| It's still a flaw.

  Are you going to put that on yout tombstone when you leave us alone?  It
  seems that numbnuts like you who have to defend themselves when they are
  wrong about something will go into a mental state where they will never
  admit to being wrong and will continue to spout some idiotic nonsense
  just to keep from admitting it.  This seems to be a pretty common trait
  in the entire "tunes" project, by the way.

While I may not agree with Francois-Rene Rideau's statements,
he definitely know how to argue his points like an adult.

Your response is childish however and is an embarrassment
to this forum.  

Why do I even bring this up?  Well I asked readers a
month or so ago that if they wanted to raise the
intellectual level of this forum that they should
speak up when something clearly anti-intellectual was
posted.  Since this is not a moderated forum this is
the only way for posters to get feedback.  Feedback
is important.

If you have been reading this news group for a while one thing you
should relize by now is that Erik follows through.  I do not know if
Erik will respond to this, but if he does he will finish it.  I do not
think you will get your desired end you will not muzzle anybody who is
worth a dam with this junk.  In fact this is an invatation to a
responce from Erik that you are preaching against.  Then you will
respond and he will respond ... and you have a lot more of the
behavior that you preach against because of your direct action.  This
is not what I consider smart.  It almost looks like you are setting
your self up to set your self up as the innocent victim in this so you
can claim some false moral high ground in this.

In the worse case when you have a choice between assholes and censors
you should always choose assholes, they make better neighbors.  I am
not saying Erik is an asshole, just to be clear.

I'm sure that there exist postings that you would consider
unacceptable.  For example someone might start posting
multi-megabyte CMU CL distributions.  You might speak up
and say "hey, this is not the place for that kind of
posting".  You would not be a censor.  Nothing you could do
could stop the postings.  You would merely be stating your opinion.

For all you know, he could be playing a character in order to deliberately
tick you off, and possibly be deriving pleasure from grating on your
nerves.

Also understand that some people find overboard postings extremely
entertaining, and would miss them dearly if some people's censorship
fantasies were realized.

http://groups.google.com/groups?q=g:thl1251669294d&hl=en&selm=
87itf1a2fh.fsf_-_%40piracy.red-bean.com

  John Foderaro, can you _please_ shut up?  Your contributions to this
  forum are fantastically predictable, exceptionally boring, utterly
  useless, nothing more than childish whining, all of them sorry, pathetic
  attempts to take revenge over once having lost a debate over your very
  silly IF* macro.  If you really want to raise the intellectual level in
  this newsgroup, _quit_ the idiotic holier-than-thou act and just _do_
  what you profess that only _other_ people should do: Post intelligent
  articles.  I do not think you actually _can_ do that, anymore, which is
  why you keep _whining_ instead of _doing_, and which is why _you_ chose
  to become an uintelligent moralistic asshole when you were criticized for
  being unable to argue your case properly.  Attacking your critics does
  not make _you_ more intelligent, any more than any of the other morons on
  this newsgroup have come out of such attacks with the face actually
  saved.  And just like every other pathetic moralistic loser on USENET,
  you crawl out of the woodwork when a discussion is basically over.

  Grow up, John Foderaro.  _You_ are still unable to deal with conflict in
  a mature way and there is _nothing_ you can teach anyone in this area,
  and your extremely annoying and pathetic attacks on me are getting old.

FR> I purported to support the (maybe illusive) idea that there is a usable
FR> portable Common LISP language.

It is most definitely possible to write portable Common Lisp code that
is efficient in one implementation.  It is very difficult, and possibly
impossible, to write Common Lisp code that is portably efficient.

X3J13 have made a few half-hearted attempts to make it more likely
that common idioms will generate efficient code, most notably by
giving some guarantees on the fixnum range and by making it possible
to write array-frobbing code using fixnums.

I don't think there is any portable language that enables the writing
of portably efficient code.

MS> A few mails like "buddy where is my fuckking feature!!!" would
MS> piss me off royally.

An Emacs Lisp function that replies ``I am not currently interested in
commercial consulting'' does wonders.  You'll never hear from them
again.

The problem (I find) is with nice people who submit code for inclusion
in a future version, and get offended when you refuse on stylistic grounds.

  Well, try submitting something that uses standard if, when, unless, or
  loop, to people who believe in a certain "Lisp Coding Standard" document
  and get chided for using standard Common Lisp.  It is certainly rejection
  on stylistic grounds, but so irrational that future attempts to deal with
  such people is tainted with an unanswered "why bother?".  In many cases,
  stylistic grounds are indeed irrational as seen from the receiver, and
  the most rational thing in the world by the person arguing them, but it
  is probably fair to assume that the submitter of a thus rejected patch is
  in his right to consider the argument irrational, and probably the person
  who argues with them.  On the other hand, the inability to continue to
  use a style that the code alrady uses may just be irrationally stubborn
  or ignorant, but it depends a little on how the style evolved.  If it is
  the kind of style that deprecates standard features in favor of a bogus
  "invention" of the writer, that writer is trying to build a community all
  of his own, explicitly rejecting the community that the suggester would
  like to belong to.  I find such behavior offensive and good grounds never
  again to submit code to such people.  Fortunately, there are usually only
  single individuals who are so beyond reach.

  Do you think this is because of the implementations or the language?  I
  think it is because of the implementations and the lack of pressure from
  their users to be (more) efficient.

  If you write code that is explicit in all its assumptions, a compiler
  _should_ be able to produce optimal machine code.

I'm consulting for a company right now that is using clisp a lot.  It
seems to be quite efficient in many ways, but since it's byte
compiled, it's hard for it to be compared apples to apples with
non-byte-compiled implementations.  Using a system-defined operator
means jumping to C code, which gets really optimized stuff that a user
just can't write (because whole point of the byte code interpreter is
that you can't get to the C level).  So, for example, as nearly as I
can tell, a call to a standard CL string-manipulation operator ends up
enormously faster compared to an open-coded inline loop doing calls to
CHAR on carefully type-declared strings, not because it does anything
gross and awful with those calls but because unless the system
literally recognizes that what you are doing is an idiom for a
system-defined function, it can't go out-of-frame and write C code
(where the optimizations you expect could happen).

I think similar issues come up with cache and prefetch issues that may
make things below the abstraction level not visible.  And with
vendor-specific OS-level facilities like threads that may (depending
on shallow/deep binding tradeoffs, just for example) optimize some things
at the expense of others.  ("No free lunch.")

I ran into this problem in doing Fortran->Lisp translation
  http://world.std.com/~pitman/Papers/Fortran-to-Lisp.html
and it effectively came down to the same: if the compiler is restricted
to working from a certain abstraction level up, anything that tickles
the layer below that is going to sometimes work unoptimally.

I think this is, at its core, the reason for Gabriel's "worse is better"
paper series.

Some virtual machines are kept from exploiting this.

Erik Naggum:

EN>   Well, try submitting something that uses standard if, when, unless, or
EN>   loop, to people who believe in a certain "Lisp Coding Standard" document
EN>   and get chided for using standard Common Lisp.

I was thinking of a person who rewrote a quick hack of mine in what he
described as ``clean and elegant object-oriented Perl.''  He got badly
offended when I refused to maintain his code, and suggested that he
may want to distribute it himself.

EN>   that writer is trying to build a community all of his own,
EN>   explicitly rejecting the community that the suggester would like
EN>   to belong to.

Yes, I think that's a fair description.  I explicitly reject the
community that believes in such a thing as ``clean and elegant
object-oriented Perl.''

Erik Naggum:

EN>   Do you think this is because of the implementations or the language?

To a great extent, it is unavoidable in any portable language.

The difference, however, is that most modern implementations of, say,
C, are pretty much identical from the programmer's point of view.  In
most cases, C code that is efficient under both gcc/x86 and
SunPro/Sparc will be efficient on all (modern) platforms.

On the other hand, there is much more variety in implementation
strategies for Common Lisp, which makes it much more difficult to
write code that is efficient ``often enough.''  Let alone the issue of
byte-compiled vs. native implementations (already mentioned by Kent),
there are the issues of (off the top of my head) shallow vs. deep
binding, buffered vs. unbuffered streams, size of fixnums, ability to
work on full-word integers, ability to use a ``known call convention''
for functions with a proclaimed type, implementation of catch/throw,
etc.

I hope we all agree that this liberty of implementation is a good
thing; but it means that, in practice, writing portably efficient CL
code is next to impossible.  (I am emphatically not speaking of
portable CL code that is efficient in a single implementation.)