[racket] Optimizations at the library level.
Noel Welsh wrote at 08/31/2010 04:36 PM:
> In general this is a huge problem (equivalent, I think, to the "sufficiently smart compiler" problem, which itself is equivalent to solving AI).
>
What Noel said. Though, it might be a useful thing for the Racket
interpreter (compiler) to have hooks of some kind for pluggable
optimizations. Useful both for practical use and for increasing how
Racket can be used as a language research platform.
As a user, would be nice if I could get a matrix library without special
compiler optimizations by doing:
(require (planet foo/matrix))
Or, if I indicated that I wanted the special compiler optimizations
provided by the module, like:
(require/hooks (planet foo/matrix))
then special optimization code from the foo/matrix module can hook
itself into a compiler phase for my using module. In this example,
perhaps in a phase after macro expansion and with all (current)
references resolved. (I'm thinking of hooks covering only intra-module
stuff for the using module, no access into other modules.)
I don't know how feasible it would be to provide these hooks in a
particular version of Racket. Regarding keeping such hooks from
encumbering evolution of future versions of Racket, would it suffice for
the compiler to not be obligated to call the hooks and, if it does call,
to announce its version when calling the hooks? The hook code would be
responsible for doing the right thing (or nothing) for that particular
Racket version. So, in this example, when a new version of Racket comes
out, the foo/matrix would likely run without requested hook
optimizations until the developer of foo/matrix looks at any changes
made to the internal representations exposed by the hooks in that
version of Racket, and makes any necessary changes to the
optimizations. Importantly, Racket would make no commitment to maintain
the representations between versions, nor to even to document any of the
representations.
It's fortunate that Matthew has seemingly infinite time for all the work
that people would like him to do. :)
I still like the idea of doing the matrix optimizations in pure Racket
with internally-optimizing ADTs with lazy operations, rather than with
syntax extension mini-language, an entire front-end language, or
compiler hooks.
--
http://www.neilvandyke.org/