[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue: FUNCTION-COMPOSITION (Version 1)



    Date: Thu, 30 Jun 88 06:23:24 PDT
    From: vanroggen%aitg.DEC@decwrl.dec.com

      From: masinter.pa@Xerox.COM
      Date: 29 Jun 88 23:55:32 PDT

      I'd rather see a portable implementation circulated, frankly.
  
      Why should these be in the standard?

    To allow and encourage compiler optimizations that would otherwise
    be difficult to do.

Right. These are easy to write correctly in a portable way, but the
portable way is not nearly as efficient as what coudl be non-portably
provided... And I doubt anyone would spend any effort to optimize them
if they weren't part of the core language.

But as alluded to in the proposal, this would also get us a foothold
 from which to be able to suggest flushing the -IF-NOT functions and
:TEST-NOT keywords. Those functions provide not only clutter in the
form of size, but it's a pain to try to coherently explain
 - the default value of the :TEST and :TEST-NOT parameters, which
   cannot be independent
 - the effect of providing both the :TEST and :TEST-NOT
I'll be submitting a proposal to make that cleanup, and that proposal
might fly on its own, but it would go better (I think) if it had support
 from a reasonably concise alternative mechanism (particularly COMPLEMENT).

Also, I bet the reason there are not :TEST-AND and :TEST-OR arguments 
is not that ANDing and ORing predicates is less useful than NOTing them,
but rather that NOT takes one argument and the rest take more and no one
wanted to worry about :TEST-AND '(FOO BAR) or :TEST-AND (LIST #'FOO #'BAR)
which would have had to cons a needless list. This proposal provides a
way to specify things so that no consing is necessary in many cases
-- :TEST (CONJOIN #'FOO #'BAR) -- Stack consing might occur, or inlining
might completely unroll the need for a list at all...

Aside to Jeffrey, I like COMMUTE as an addition to the set of things I
had listed, by the way, but I didn't really like PERMUTE as described.
It is a nice idea conceptually but the fact that its permuation argument
is evaluated means that it can be opaque to such optimization when the
argument is not constant, and the result may be suprisingly less
efficient than the programmer may expect in those cases.