Re: [Caml-list] partial eval question

[William Chesters <williamc@paneris.org>]

Yann Regis-Gianas writes:
 > I agree with you that constant folding, inlining and unrolling are well known 
 > by common compilers. However, when you want to _control_  these 
 > optimisations, this is more difficult with standard optimizers since they are 
 > black-boxes.

That's a strength as well as a weakness.  In reasonably simple cases
it "just works" and is less effort, more readable, more maintainable.

 > By adding the multi-stage evaluation into a programming language, we obtain 
 > one general,  transparent and simple tool. Why should we develop or learn the 
 > usage of many special-purpose optimizers ?

Partial/abstract evaluation is a pretty general purpose optimiser.
Half seriously: Metaml improves on C++ templates by making the
metalanguage the same as and more tightly integrated with the object
language.  Partial evaluation can almost be seen as going a step
further and having the compiler infer the tightest meta/object
boundary.  Perhaps if there was a way of telling the partial evaluator
"specialise this code block by value of parameter i / type of
parameter j / whatever" (*) it would handle all the everyday tasks for
which metaml is designed, and require considerably less effort and
expertise.

(*) to get this effect with good current compilers you have to isolate
the block in a function, turn up the inlining sufficiently, and use
"if" branches to trigger specialisation

 > By adding the multi-stage evaluation into a programming language,
 > we obtain one general, transparent and simple tool.

It's not simple or transparent, and for many tasks it isn't necessary.
Perhaps it's a good general tool for the generation of code for
numerics etc.---it may help specialist library writers.

For everyday programming I think one has to remember that heavyweight
attempts to achieve generality are often not worth it.  Simple
things can be done by the compiler or just written out by hand.
Complex things look nasty when hand-optimised, but if you try to do
them "better and more generally" using metaprogramming, you are likely
to take much longer, and end up with something which is hard to
decipher and disappointingly doesn't generalise in quite the way you
want.

There is little point in trading the "complexity" of prolix,
irritating but basically straightforward hand-specialised code for the
genuinely challenging complexity of a meta-programming system.  (It
really does become extremely complicated when you start taking into
account the detailed requirements of real world problems.)

The most viable option is often to settle on a reasonably general and
extensible conceptual framework (at the level of conventions rather
than anything more formal) and implement just the bits of it that you
actually need for your particular problem, encapsulated in a
consistent way.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners