Subject: Re: was: newline and concatenate. length of a lisp function
From: Erik Naggum <>
Date: Thu, 26 Jul 2001 00:10:47 GMT
Newsgroups: comp.lang.lisp
Message-ID: <>

* (Kaz Kylheku)
> What makes you believe that it's *never* interpretive?

  I do not believe that.  Why do you invent such stupid claims to ask me to
  refute when nobody have said anything remotely like it?

> It's more likely than not to be implemented that way---as a function
> which scans the string and carries out the formatting actions described
> therein.

  How do you wind up with that "more likely" conclusion?  Geez.  This is
  how those arrogant ignorants who claim to know how to implement Lisp turn
  out to be college drop-outs after a few overdoses of Scheme.  Smart
  people do that string traversal at compile-time and generate the most
  efficient code that can be known at compile-time.  This is not hard.
  This is _not_ C's printf and like-minded idiocy.

  Take a look at the formatter macro the next time you feel the urge to
  tell people how they "most likely" implement format.  A constant string
  as format's second argument is a bloody obvious candidate for a compiler
  macro to turn into a macro call to formatter.

> Since my comment was performance related, I had a likely common
> implementation in mind, which could be possibly quite inefficient for
> catenating strings.

  How do you know that it is "likely common"?  How much experience do you
  have evaluating implementation techniques for such things?  None, right?
  You are just guessing and making up statistics about commonality as you
  go.  This is _dishonest_ of you.  It would have been honest to admit you
  made it up with no supporting evidence at all.  This is _so_ annoying and
  it happens all the time to people who have very little clue.

> Of course, I realize that (format nil "~A~A" x y) could be recognized as
> an idiom, and translated into a direct catenation operation.

  Well, _that_ is fairly unlikely to be optimized away, as ~A does not only
  print the characters of strings, but does a lot more work than that.
  However, ~% and ~& do print only newlines.  Please do not tell me that
  '(#\Newline) is better than ~%.

> I also realize that the performance of the catenation of two strings
> might not even matter.

  That is most probably true, but if it does not matter, the most
  perspicuous solution should be chosen.  In this case, that would actually
  be writing to a string stream with several format calls, as the amount of
  stuff to put into that "string" _will_ grow without bound over time.

> Sorry if I upset anyone!

  I would have been much happier if you were sorry you had jumped to
  conclusions from completely absent information, which would be the
  _cause_ people would be upset.  We have been over this "interpreter"
  misconception _enough_ times already.  Just grow a clue: If it would be
  slow, somebody has already made it more efficient than you can think of.
  People who just make random noise from their own lack of experience about
  what other people with such experience would have done need to be refuted
  and corrected -- over and over again, because the very idea that somebody
  might have more experience and _might_ have solved their obvious problem
  simply does not occur to these people, unfathomable as that really is.

  There are so many completely bogus reasons _not_ to use good solutions in
  Common Lisp that never apply to any other language.  Why is this?  Is it
  fear of having to know more about Common Lisp than other languages?  Look
  at what people do in Perl, Java, og C++, for crying out loud!  And format
  is supposed to be slow and cryptic?  Gimme a _break_!  When talking to an
  SQL database!  Sheesh.

  Ignorance of the language is no excuse.  Sorry for repeating myself.

  There is nothing in this message that under normal circumstances should
  cause Barry Margolin to announce his moral superiority over others, but
  one never knows how he needs to behave to maintain his belief in it.