[m-rev.] for review: combined higher-order types and insts

[Julien Fischer]

Hi Mark,

On Fri, 5 Feb 2016, Mark Brown wrote:

> On Thu, Feb 4, 2016 at 2:41 PM, Julien Fischer <jfischer at opturion.com> wrote:

>> On Sun, 31 Jan 2016, Mark Brown wrote:
>>
>
>>> +Combined higher-order types and insts are currently only permitted
>>> +as direct arguments of functors in discriminated unions.
>>
>>
>> So the following would not (currently) be legal?
>>
>>     :- type job(T) ---> job(T).
>>     :- type job == job(pred(int::out, io::di, io::uo) is det).
>
> That's right. In fact, there's three reasons:
>
>  - it occurs on the right hand side of an equivalence type
>  - it occurs as the argument of a type constructor
>  - it occurs somewhere not inside a du functor definition.
>
> All of these things are logical extensions of what is currently done,
> and there are also others. I'll leave further analysis to the thread
> on the developers list.

I think there needs to be a more direct mention of this limitation in
the reference manual (e.g. in the current implementation combined
higher-order type and insts and equivalence types don't play well
together, or perhaps simply some examples of things that are not
currently legal.)

>> You also lacking (invlaid) test cases for when the arguments of combined
>> higher-order types and insts do not all of modes specified or when the
>> determinism as been omitted etc.  For example:
>>
>>     :- type job ---> job(pred(int::in, io::di, io) is det).
>>
>> or:
>>
>>     :- type job ---> job(pred(int::in, io::di, io::uo)).
>
> See attached diff.

That's fine.

> Some of the errors are not very pertinent, because the parser allows
> for the type '::'/2 to be defined. Should it?
>
> E.g., prior to my change the following was accepted:
>
>  :- type (A :: B) == {A, B}.
>  :- type in == int.
>  :- type f ---> f(pred(int::in)).

See other mails in this thread.

BTW, were you intending to commit the change that enabled variable
bindings in interactive debugger queries at some point?
(http://www.mercurylang.org/list-archives/reviews/2015-May/017956.html).

Julien.