[Caml-list] Re: Call for collaboration on the future of camlp4

[Hongbo Zhang <bobzhang1988@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4415 bytes --]

On 9/20/12 5:36 AM, oleg@okmij.org wrote:
> 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 cautiou*/s 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.
>
>


[-- Attachment #2: Type: text/html, Size: 5974 bytes --]