[wg-camlp4] Changes to the parsetree

[Gabriel Scherer]

> By representing type parameters as core_types in the Typedtree they can include a
> reference to the corresponding type_expr. For consistency they should be
> represented as core_types in the Parsetree as well.

I certainly miss some information for a better understanding, but I
don't see what the argument is here. The typetree structure is adapted
to type-checking and therefore different from the bare AST structure,
I get that. Why should we change the AST structure to make it more
adapted to type-checking, when precisely we're trying to make more
suitable to purely syntactic manipulations? I'd rather say that the
parsetree should be suited to syntactic representation, and the
typetree to representation of type information.

(I see an argument for keeping the type-checker as simple as possible,
begin a critical and more fragile part of the compiler, and if that
was necessary decide to make the parsetree a bit more complex for this
reason. In that case, however, it doesn't look like using core_type in
the parsetree would make the type-checker much more readable or
robust.)

Hongbo: I am personally wary of use of polymorphic variants for large
ASTs as they tend to result in error messages and inference behavior
that are hard to understand, and require a fair amount of type
annotations to be tamed. I've done designs with and without
polymorphic variant, and my experience has been that keeping simple
algebraic datatypes is often a better choice on the long run (it's a
compromise between safety and simplicity). I'm curious about how your
own experiment with polymorphic variants in Fan has been going on, but
maybe it's not reasonable for the core parsetree representation.

On Wed, Apr 10, 2013 at 9:34 PM, Leo White <lpw25 at cam.ac.uk> wrote:
>> I think that having additional constructors in core_type that are
>> semantically meaningless (the variance annotations) will not help
>> third-party extension writers either. What are the reasons for having
>> the whole core_type in place where type variables are expected?
>
> In addition to the reasons Alain gave, type parameters should be
> core_types because, in the Typedtree, they have a corresponding
> Types.type_expr. Although they are syntactically always a Ptyp_var or
> Ptyp_any, after constraints have been taken into account they represent
> a general type expression.
>
> For example:
>
>   type 'a t constraint 'a = 'b list
>
> is morally equivalent to:
>
>   type 'b list t
>
> By representing type parameters as core_types in the Typedtree they can include a
> reference to the corresponding type_expr. For consistency they should be
> represented as core_types in the Parsetree as well.
>