Yes, it's [MetaOCaml] a run-time optimizer with type safe assurance. It can do
partial evaluation to generate some optimized code.
Let me stress once again how narrow this view is. MetaOCaml goes well
beyond partial evaluation. For example, MetaOCaml, as a general code
generation framework, was used to derive optimal (in the number of
multiplications) FFT kernels. Partial evaluation will not give you
that.
Code generation is a very promising technique in High-Performance
computing. Most of the tools used in practice -- FFTW, ATLAS, SPIRAL
-- are all off-line tools. They generate a large number of candidate
codes and choose the best performing. What's important is to quickly
generate a large number of very tedious programs. Assurance of
correctness are important: a programmer, especially a domain expert,
will not want to even look at the generated code let alone debug it.
I see MetaOCaml target the same area.
To my limited knowledge, FFTW used techniques more like Camlp4.
If you take a look at the history of Template Haskell, they finally
step back from type checking everything to give up type checking some
quasi-quotations.
This is a mistaken impression. While Template Haskell as a whole will
remain untyped for a long time -- after all, Template Haskell can
generate data and type class _declarations_, whose typing is far from
clear -- there is a definite push towards MetaOCaml-like type safety
for expressions.
http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal
see especially
Part B: Add new MetaML-style constructs for strongly-typed metaprogramming.
If this is implemented, TH becomes quite like MetaML.
There are two problems here, first you object language is not only
ocaml,
We don't want to sacrifice too much experssivity for type safety, this
is especially important in macros. In common lisp, there is also a
kind of macros called "Anaphoric macros" which you will find painful
to do in Scheme.
That is not a very good argument since R5RS macros in Scheme were
intentionally limited in their expressivity. The macro system was
designed to be just enough expressive for the special forms
introduced in the Report. (Later on the system was found to be quite
more expressive than its designers have anticipated.)
The anaphoric macros are easily expressible in the system of our JFP
2011 paper (staging with a very limited delimited control). No
subversions of hygiene are needed.
That depends on how you define 'easily expressible' ;-)