Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: [Caml-list] productivity improvement
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-10-17 (23:45)
From: Alessandro Baretta <alex@b...>
Subject: Re: [Caml-list] Re: Camlp4 optimizations (was: productivity improvement)

Jeffrey Palmer wrote:

> However, the (obvious) problem with this approach, from a C++ 
> perspective, is that it is not supported by the language. This stuff 
> was basically "discovered", rather than designed, and if you've ever 
> tried to use these techniques, this becomes VERY clear. The syntax is a 
> disaster. An in-language mechanism for this type of macro expansion (a 
> la lisp/scheme macros) would simplify this immensely.
> Is this approach implementable in ocaml? The C++ template mechanism has 
> complete access to the C++ type system, which makes it significantly 
> more useful than the standard preprocessor. I seem to remember an 
> earlier posting (today) indicating that this type information isn't 
> available in ocamlp4.

I'm sorry to have to point out that this is false. The 
template rewriting mechanism knows absolutely nothing about 
typing. You can give the C++ compiler a template it will 
placidly accept, while at the same time giving you all sorts 
or typing errors at template instantiation time. This means 
that if you write a template library in C++ you'll know if 
it is type-correct (with respect to C++ *very weak* typing 
rules) only when you try to use it in some other project. 
This is equivalent to the non-typing of assembly language, 
which yields all sorts of runtime errors to the users. As 
far as C++ templates go, you have to consider as users the 
programmers who will use the template library. Template 
instantiation plays the part of running an assembled program.

Besides, what kind of access to the type system can a 
*generic* program have? If it depended on specific features 
of specific types it would no longer be generic, would it not?

The golden rule of C : Use functions, not macros.
The golden rule of C++: Use classes, not templates.

The Java developers knew both rules. They made a mess anyway.

> Does anyone know of any strongly-typed languages where this type of 
> macro expansion/partial evaluation is available?  (I seem to remember 
> GHC providing a hook mechanism for term rewriting during optimization, 
> but I don't think that's quite the same...)

Ocaml. Macro expansion == Syntax extension.
Macro processor == Camlp4.

Keep in mind that Camlp4 builds the complete abstract syntax 
tree of an ocaml program you parse with it. It later feeds 
the tree to the compiler. Once Camlp4 has built the syntax 
tree you can apply any program transformation you care to, 
in order to optimize your program. Of course, before 
applying such "program-rewriting-at-compile-time" 
techniques, you should prove them to be correct.


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: