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

[Jacques Garrigue]

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

> On 09/19/2013 02:25 AM, Jacques Garrigue wrote:
>> On the principle, I have nothing against keeping attribute in .cmi files, since they are not supposed to change.
>> But to be honest I have not followed the discussion on attributes, and the inclusion in trunk was kind of sudden.
> 
> I announced my intention to integrate the branch to caml-devel in the trunk on Jul. 22 ("Landing extension_points?"), nobody complained, and I did the merge more than one month later (Aug. 29).  The branch itself has been created on Feb. 28, extensively discussed on the wg-camlp4 list during the first months.  Then for some months, the branch has been stable and the discussion more quiet.

OK, I'm not of the wg-camlp4 list, which explains my surprise.

> As I explained, nothing is frozen yet and the goals of landing the branch early are to avoid tricky conflicts in the future (considering that there are a lot of changes to the Parsetree) and to gather more feedback (this goal, at least, is achieved :-)).

Sure, it's always difficult to discuss something that is not available in trunk.

>> I am a bit concerned by the fact the syntax tree is now completely mutually recursive:
>> an attribute appearing in a type may contain a structure.
>> What is the rationale behind that ?
> 
> The intention is to allow greater flexibility in the content of attributes (while still keeping a fixed syntax to enable editor support and allow interactions between tools).   It is not clear exactly what will be needed for specific use cases, and allowing structure + patterns (with an optional guard) + type expressions cover a lot of possibly useful syntax fragments (in particular, structures cover both the empty case and expressions).
> 
> Allowing expressions as arguments is useful to support scenario where type declaration need to be annotation by code, such as the "sexp_drop_if" attribute in sexplib.  Since expression can already contain structures, I just found more convenient to allow arbitrary structures.  Of course, a specific tool or extension can put arbitrary constraints of what is exactly supported as the attribute argument.

OK, I see why you can want arbitrary things.
Now, if I understand correctly, you are just reusing syntactic categories, but there is no semantics.
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.
Is it important to keep the format compatible with the syntax tree ?

>> And for pattern attributes in types ?
>> Does it mean that you want to include whole structures in .cmi files ?
>> Wouldn't it be better to restrict attributes to type expressions, constants, and identifiers/paths ?
>> Should all nodes allow all attributes ?
> 
> It's just easier and more uniform if the argument of attribute can always be the same, independently on the attribute target (and we use the same definition for the content of extension nodes).  I don't see any technical problem with it, this is just uninterpreted syntax.  What are your concerns?
> 
> Just as an example, a pattern in a type could be useful to specify "invariants" (used to generate assertions or proof obligations).
> 
> type t =
>    | A of bool * bool
>    | B of int list
>    [@@invariant? A (true, _) | A (_, true) | B (_ :: _)]
> 
> type s = (char [@invariant? 'a'..'z']) list

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

I say this because having 3 categories with no semantics can be confusing.

> It's hard to predict exactly how attributes and extension nodes will be used, so I think it's better to be quite general, considering that it doesn't bring any additional complexity.

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?

	Jacques