Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!paperboy!hsdndev!husc6!soi!chip From: chip@soi.UUCP (Chip Morris) Newsgroups: comp.lang.scheme Subject: Re: Why memq vs memv vs member, etc.? Message-ID: Date: 17 May 91 15:05:19 GMT References: <1991May10.230057.15591@Think.COM> <1991May15.172635.18635@Think.COM> Organization: Software Options Inc., Cambridge, Mass. Lines: 55 barmar@think.com (Barry Margolin) writes: >In article chip@soi.UUCP (Chip Morris) writes: >>I agree with Mr. Margolin on the style and generality of his proposal. >>However, I just finished speeding up a large Common Lisp application >>in which using MEMQ was much faster than using MEMBER >>(with a :TEST of #'EQ) was quite significant. The overhead of the >>additional parameters, especially keyword parameters, was alone enough >>to make a difference. Gag. What I MEANT was with default :TEST, which is, of course #'EQL. Yes, Lucid (and others) do detect and optimize out such idioms. My point was not my (uninspired) optimization, which was a preface to the next paragraph, but to raise a small issue concerning the tradeoff between style, generality and efficiency. I meant to cite Lucid to show that in the presence of a good compiler one could write a recursive program and still get the kind of efficiency one would want. >Scheme designers expect the compiler to optimize away much of the >overhead. And so they should. The question is, can a language supply us with a suitably general, regular style and still permit the kind of analysis that frees the programmer from worrying overmuch about efficiency in the small, when, in the last stages, it becomes important? >I guess the only problem with optimizing out the explicit passing of >the eq argument is that Scheme doesn't prohibit user programs from >redefining standard procedure names as Common Lisp does. Perhaps one must grudgingly admit an analysis advantage to Common Lisp's otherwise distressingly assymetrical treatment of the function position. >And Schemers don't even have a valid excuse of "oh, the function position >is special", because one of the fundamental tenets of Scheme is that the >function position of a form is evaluated just like other positions. I think that a Schemer's valid excuse should be "oh, my program doesn't change the meaning of EQ, CAR, etc." And maybe s/he should be able to rely on analysis tools to assert this to a compiler in the bulk of cases where it can be deduced. A laudible goal for a language design is that "simple" programs can be analyzed as such and efficiently compiled. To what extent does this conflict with conceptual regularity and generality? To consider another example, isn't Scheme's somewhat unbridled treatment of first-class continuations something of an analysis nightmare? -- Chip Morris, Senior Engineer Software Options, Inc., 22 Hilliard St., Cambridge MA 02138 (617) 497-5054 chip@soi.com