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

[Alain Frisch]

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.

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

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

> 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

An expression in a type can be useful for conditional compilation:

   type flags =
     | Foo
     | Bar [@if os = "Windows"]
     | Baz

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.


Alain