[wg-camlp4] Negative field report: extension points unsuited for (matches p when e)

[Alain Frisch]

On 05/14/2013 12:49 PM, Leo White wrote:
>> Possible syntaxes:
>>
>>   [%sh (seq: Line.present); (source: Line.present)]
>
> This won't work, because you need to be able to replace Line.present
> with an arbitrary type expression.

Well, it would work with this syntax, wouldn't it?

>>   < seq: Line.present; source: Line.present > [@sh]
>
> This isn't an extension node, so may be silently ignored.
>
>>   [%sh] * < seq: Line.present; source: Line.present >
>
> This doesn't make it clear that "< seq: Line.present; source:
> Line.present >" is not actually an object type, but an argument to the
> sh extension.

 From a superficial reading, it seems that this is really an object 
type, where some fields are implicit.

>> But, in that specific case, is the syntactic sugar worthwhile at all? Reading the shcaml documentation
>> (http://www.eecs.harvard.edu/~tov/code/shcaml/doc/),  I can see this syntax used only in inferred types, and not
>> documented.  Do the users really need to write those types?
>
> I don't really know about that specific example. It looks a bit like the
> syntax extension was never really deployed for users.
>
>> Can you give other examples of these extensions which would benefit from the ability to use type expressions as
>> arguments of extensions or attributes?
>
> Not off the top of my head, but I would have thought that extension
> nodes in type expressions would often want to be built from other type
> expressions, and there is no easy way to do that at the moment.

We should probably wait for more widely used examples of extensions 
which would benefit from "type expressions" as arguments.  Of course, 
it's always possible to write:

   [%sh ((): type_expr)]

>
>> Just to be sure that I understand your proposal correctly, you would support:
>>
>>    expr
>>    expr : core_type
>>    : core_type
>>
>> Do you have concrete examples where the second form would be nice? (Adding parentheses makes it a valid expression
>> anyway.)
>
> I see two uses:
>
> i) Type extensions that take some arguments that are not types:
>
>    [%foo true: 'a list] list

Do you know any actual such extensions?   One can also imagine 
extensions expecting several types are arguments, or a combination of 
types, patterns, etc.  All can be encoded, with more or less syntactic 
overhead inside expressions.  Hard-coding better support for some 
specific cases should be motivated by real examples.

>> of "local structure items":
>>
>>    let [%local STR] = () in e
>> ====>
>>    let module LOCAL001 = struct STR let res = e end in
>>    LOCAL001.res
>>
>> to allow, for instance:
>>
>>   let [%local exception M] = () in
>>   ....
>>
>>   let [%local type t = {x: int; y: string}] = () in
>>   ....
>>
>
> I suspect that this specific extension is a very unusual case, and it
> would be better integrated into the language proper.

( http://caml.inria.fr/mantis/view.php?id=5955 )


-- Alain