[wg-camlp4] Changes to the parsetree

[Gabriel Scherer]

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?

On Wed, Apr 10, 2013 at 2:51 PM, Alain Frisch <alain.frisch at lexifi.com> wrote:
> On 03/26/2013 08:56 PM, Leo White wrote:
>>>
>>> On 03/25/2013 03:05 PM, Leo White wrote:
>>>>
>>>> Another small clean-up I'd like would be to change "ptype_params" from
>>>> "string loc option list" to "core_type list" and the first part of
>>>> "pci_params" from "string loc list" to "core_type list".
>>>
>>>
>>> Would you change the parser to accept arbitrary types (instead of _ and
>>> type variables), and enforce the previous
>>> constraint in the type-checker?
>>
>>
>> It might be better to get a syntax error there as it's probably
>> a common beginner mistake. On the other hand, if the error from the type
>> checker is nice and clear then it shouldn't be a problem. Either way, we
>> might as well support extensions and attributes there.
>
>
> I think we should keep the Parsetree type as close as possible (at
> reasonable costs) to the set of ASTs that can be produced by the parser.
> This will reduce the risk of generating Parsetree fragments which cannot be
> pretty-printed (as source code) faithfully.
>
> So, if we want to move from "string loc list" to "core_type list" (which
> will give attributes for free on parameters), we should accept arbitrary
> types in the parser and fail in the type-checker.  (There is no real
> drawback for the end-user.)  The problem is that this  introduces conflicts
> in the grammar.  The simpler way I've found to address them without changing
> the parser too much is to add the variance prefixes (+ and -) as new
> constructors in core_type (with corresponding grammar rules), but this is
> not very nice.
>
> Leo: do you have an opinion on what to do?
>
> -- Alain
>
> _______________________________________________
> wg-camlp4 mailing list
> wg-camlp4 at lists.ocaml.org
> http://lists.ocaml.org/listinfo/wg-camlp4