[wg-camlp4] Pending issues

Leo White lpw25 at cam.ac.uk
Wed Feb 13 12:06:12 GMT 2013


>> A related question is related to the current work on runtime types. 
>> Attributes on type declarations could be kept in the runtime 
>> representation of the declarations, allowing libraries to interpret
>> them as they want.  (LexiFi's version of OCaml has been extended with 
>> attributes on type declarations precisely to do that.)  Having 
>> attributes defined as general expressions, however, means that those 
>> libraries would need to link with compiler-libs, or at least be
>> compiled against some of its .cmi, in order to be able to analyze the
>> Parsetree. I don't see it is as a big problem, and it would also be
>> possible to restrict which expressions are reflected in runtime types
>> (e.g. to structured constants).  Comments are welcome!
>
>I think it is usualy a bad idea to need to link against compiler-libs.
>Doing so almost certainly prevent you from being able to compile
>against different version of the compiler. This ast should be
>fixed once and be provided in the stdlib. I would also prefer to
>restrict that kind of annotation to a small subset of the expression
>language avoiding as much as possible duplication. This would simplify
>the code using those annotations. Maybe only list, Variant, record and
>string literals/identifiers would be sufficient. Maybe also let in ?

I agree that we should avoid making people link against compiler-libs where 
possible. However, I think that having a fixed AST and only supporting a 
subset is too restrictive.

An alternative would be to provide a standard library module that could be 
used to handle simple ASTs, but still support using Parsetree directly for 
more complicated AST handling.

For example the "Ast" module might provide functions like:

getIdent: Ast.expression -> string option

which would return a string of an identifier if the expression was a simple 
identifier.

This way we don't restrict changes to Parsetree, or the possible 
expressions within an attribute, but we do allow people to get basic 
information out of an expression without linking against compiler-libs.




More information about the wg-camlp4 mailing list