[wg-camlp4] A new branch to experiment with extension points

Leo White lpw25 at cam.ac.uk
Tue Mar 5 13:54:15 GMT 2013


>>>  type t =
>>>    | A [@id expr] [@id expr]
>>>    | B [@id expr] [@id expr] of ...
>>
>> I agree that we need a special syntax for variant constructor
>> attributes. How about:
>>
>> type t =
>>   | A with id, id(expr)
>>   | B of ... with id(expr), id
>
>This is a case where the standard syntax for attributes works well (if 
>we put attributes before constructor arguments).  What's the argument in 
>favor of a dedicated syntax?  (I like the fact that all attribute 
>syntaxes look similar.)

My argument was based on the assumption that we were going to provide a 
"with" attribute syntax for type definitions (for convenience and to 
distinguish attributes on a type definition from attributes on a whole set 
of recursive type definitions). I have since noticed that using the same 
syntax for both would conflict.

>What do you call lighter?  It uses fewer non-alphanumeric symbols, but 
>it becomes more compact only with 4 attributes:
>
>A with id(expr), id(expr), id(expr), id(expr)
>
>A [@id expr] [@id expr] [@id expr] [@id expr]

I meant lighter in an aesthetic sense. It is easier for people to read code 
that uses alphanumeric characters. 

I think the "[@id expr]" syntax is more appropriate within expression and 
type expressions, but for "larger" constructs like structure items a 
keyword based solution would be preferable. However, other than by adding a 
keyword, I have not been able to come up with a suitable syntax that 
wouldn't conflict with some existing structure item.

>How does type-conv distinguish attributes on the last constructors from 
>attributes on the type itself?  

It turns out that type-conv only allows "with" for type definitions and 
record labels -- which don't conflict.



More information about the wg-camlp4 mailing list