Subject: Re: was: newline and concatenate. length of a lisp function From: Erik Naggum <erik@naggum.net> Date: Thu, 26 Jul 2001 00:10:47 GMT Newsgroups: comp.lang.lisp Message-ID: <3205095043611228@naggum.net> * kaz@ashi.footprints.net (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. #:Erik -- 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.