[wg-camlp4] [Caml-devel] Keeping attributes in .cmi files?

[Alain Frisch]

On 09/19/2013 11:07 AM, Jacques Garrigue wrote:
> Now, if I understand correctly, you are just reusing syntactic categories, but there is no semantics.

Indeed. In important point, though, is that the default mapper class 
(Ast_mapper) traverses attributes and extension nodes.  I.e., unless it 
decides otherwise, a ppx rewriter would typically applies its rewriting 
to the arguments of attributes and extension nodes he's not aware of. 
This allows, for instance, to benefits from the services of a 
conditional compilation (or macro expander) ppx filter in the arguments 
of attributes to be processed by other ppx filters.

> This creates a problem if you want to keep them in the .cmi.
> Clearly, just dumping the syntax tree seems a bit verbose.
> You should at least drop the locations.

I expect arguments of attributes to be rather small fragments of syntax, 
so I don't see any real problem here.  Are you concerned by the size of 
.cmi file on disk, the time to read them?

About locations: we could indeed turn all locations into Location.none 
before saving the attributes in the .cmi.

> Is it important to keep the format compatible with the syntax tree ?

Internally (for ppx filters), it's useful that attributes are indeed 
real fragments of the Parsetree, so that an attribute's parameter can be 
injected in the Parsetree easily if needed.  We could turn to a 
different representation for the .cmi, but this would require to 
duplicate a big data type, and I don't see the benefits.

> You could also write this
> @@invariant (function A (true, _) | A (_, true) | B (_ :: _) -> true | _ -> false)
> can we see this just a short-hand?

What would be the translation for [@foo: type_expr]?

Of course, one could simplify the internal representation of "payloads" 
(attribute and extension node arguments) to a single case in the 
internal representation, and keep alternative syntaxes only as sugar, 
but what is the benefit?

> OK, but it makes it a bit harder to see the interactions with the type system.
> If we keep them in types, I'm afraid of the interaction with unification.
> Or do you just want a way to keep another version of the type definitions?

I think it would only make sense to keep attributes in type expressions 
within declarations (type definitions, and maybe also value definitions, 
e.g. to be able to specify some properties of individual parameters of a 
function).  *If* we represent them in the internal type algebra, this 
could be a special kind of node which would be ignored by the 
unification (or dropped from the representation as soon as a type is 
instanciated).



Alain