Hongbo Zhang wrote:
> Meta-ocaml is orthogonal to camlp4 as well, but I did not see any hope
> that it will be pushed into ocaml compiler,
> since the main purpose of meta-ocaml is to do some run-time
> optimization, without a native jit compiler support, It does
> not make sense.
I believe you might be short-changing MetaOCaml. First of all, why
MetaOCaml needs JIT? It is already possible in MetaOCaml to generate
code at run-time, to compile it and link-in. The new code is generated
by the OCaml compiler itself, and works as if it were part of the
original code. Such run-time optimization can indeed be useful (e.g.,
profile-based optimization). I don't see why we need JIT if we already
have the original compiler itself.
However viewing MetaOCaml as a run-time optimizer misses a
lot. MetaOCaml is a code generator with certain assurances of
correctness -- it generates code that one would not write by hand. The
recent example of generating code for stencil computations in
high-performance computing
Yes, it's a run-time optimizer with type safe assurance. It can do
partial evaluation to generate some optimized code. With the help
of compiler-library, I can do byte-code eval(not native eval), I
agree
it would be useful to have a native eval, but this requires
non-trivial
changes to the compiler which I don't expect it will be realized in
a
short term.
http://okmij.org/ftp/meta-programming/HPC.html#stencil
was quite illustrative: MetaOCaml has generated code for edge
cases that human really did not want to write (and did not actually
write). Edge cases are really tedious and really difficult to get
right; automation is of great help. The generated code can be
printed-out and used in a project as any other code. MetaOCaml can be
used to generate libraries of specialized high-performance code.
> Personally, I prefer common lisp's macros to scheme. It's painful
> to play with racket's macros as well
Well, it is painful for some people to use typed languages
too. Untyped languages offer so much freedom, some think. What is
often forgotten is that the benefit of the type system is not in what
code you can write, but what code you cannot. Likewise, a syntax
extension should be evaluated not only on what it allows but also on
what it prevents.
Well, as I said, it's a personal taste. People are too
cautious about
the safety the code generated, if you take a look at other
languages,
like D, they even use "string concatenation" to generate code,
we manipulate
the Ast instead of strings, and finally it's type
checked, in practice, it works
pretty well and I wrote tens of thousands of
code on top of camlp4, none of the bugs
can be detected by type checking. 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. 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. To overcome the un-hygenic problem, if you have a look
at the book "let over lambda",
there's best practice to avoid such problems. And you take a look at
the compiler of opa,
they override the module Stream to make use of the syntax extension
what camlp4 can provide,
that's the beauty of syntax meta-programming, instead of a bug.
I really appreciate that ocaml's type checker can finally type check
the generated code, but do
we really need to type check the macros? Would the cost be too high?
As I general remark: it is not clear why so much fixation on
camlp4. Other people have tried extensible syntaxes. For example:
- Felix
Some ideas of Felix are neat that we should borrow from.
- Notation of Coq
This is built on top of Camlp5
- Stratego
http://strategoxt.org/
In particular, see
http://strategoxt.org/Sdf/SdfLanguage
Stratego could do program transformations in concrete syntax. Maybe
that would be a better approach? Maybe Stratego would satisfy all our
needs?
Well, this is definitely not true. The beauty of Camlp4 is that it
is a growing macro system instead of
only a program transformation tool.
Thanks for your message.