Newsgroups: comp.lang.lisp,comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!fas-news.harvard.edu!newspump.wustl.edu!news.ecn.bgu.edu!psuvax1!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!ix.netcom.com!netcom.com!NewsWatcher!user
From: hbaker@netcom.com (Henry Baker)
Subject: Re: curried vs. tupled
Message-ID: <hbaker-1503950833040001@192.0.2.1>
Sender: hbaker@netcom7.netcom.com
Organization: nil
References: <3jplaj$61k@cantaloupe.srv.cs.cmu.edu> <hbaker-1103950901230001@192.0.2.1> <3k3fef$3b8@tools.near.net>
Date: Wed, 15 Mar 1995 16:30:37 GMT
Lines: 51
Xref: glinda.oz.cs.cmu.edu comp.lang.lisp:17092 comp.lang.scheme:12321

In article <3k3fef$3b8@tools.near.net>, barmar@nic.near.net (Barry
Margolin) wrote:

> In article <hbaker-1103950901230001@192.0.2.1> hbaker@netcom.com (Henry
Baker) writes:
> >Sorting usually involves passing a comparison function, but very often
> >the comparison function is constant and large efficiency gains can be
> >made by specializing the sort function.  Wouldn't it be much better to
> >write sort like this:
> >
> >Scheme: ((sort <) list)
> >Common Lisp:  (funcall (sort #'<) list)
> >
> >rather than having the compiler try to figure all of this out?
> 
> The compiler optimization techniques required to recognize that this can be
> optimized are not much simpler than those required to recognize
> 
> (sort #'< list)

I disagree.  I'm interested in 100% accurate analysis and optimizations.
The Lisp 'optimizers' I have seen are usually syntactically based, and
it is usually very easy to trick them into making serious errors, because
they do not have a deep understanding of the code they are trying to optimize.
They make lots of assumptions -- e.g., that cons cells won't be destroyed
by the program as it is running -- that are _usually_ true, but not always
true.  This means that higher levels of optimization are often attended by
system crashes that are difficult to find the source of.

> Many compilers already have recognizers for common patterns like this.  And
> Common Lisp even makes such optimization techniques available to the user,
> with the DEFINE-COMPILER-MACRO feature.

Ditto.

----

There is a place for 'heuristic' optimization -- particularly when the
underlying language is not well designed for an application, and the programmer
is going to apply an optimization only to _his_ program, which he presumably
understands very well.  However, such ad hoc optimizations are not useful
as _generic_ optimizations in a wide-spectrum system language, because the
optimization then has to work in _every_ case.

The whole point of currying the search function is a way of the
programmer telling the compiler that preprocessing a (constant) pattern
is ok in _every_ case -- there are _no_ exceptions.

-- 
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
