[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