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

[Jacques Garrigue]

On 2013/09/19, at 21:16, Alain Frisch <alain.frisch at lexifi.com> wrote:

> 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.

But what are the scoping rules?
Do you mean that the annotations are actually open terms? Interesting.

>> 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?

Both, as they are connected. Also the fact that this might keep some unnecessary details.

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

Yes, the reason is not only the size, but also that they make the md5 of the cmi fragile.

>> 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]?

No, I was just trying to understand the semantics. It is clear that types need to be handled differently.

> 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?

A more uniform semantics ?
Again, I do not say that this should be the representation used, but saying that the two are equivalent clarifies the semantics.

>> 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).

Dropping on instantiation might work.
Ignoring during the unification does not seem to be a good solution, because what remains becomes nondeterministic.
Keep in mind that all this is pretty fragile, as typedecl relies on unification too…

	Jacques