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

[Mark Brown]

Hi Julien,

On Fri, Feb 5, 2016 at 9:39 AM, Julien Fischer <jfischer at opturion.com> wrote:
>
> 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.)

Okay.

>> 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.

In that case, I think I can produce better error messages for the new
types when they are not quite used correctly. I'll try that shortly.

>
> 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).

It needs more testing, and you didn't really answer my question about
how to do that. ;-)

Are the interactive tests expected to be run via tools/bootcheck at
all? I can only figure out how to run them on an already installed
compiler.

If you're thinking that it would be a good idea to fork the next
release before adding the new language features, then I agree,
provided that it really is happening soon.

Cheers,
Mark
-------------- next part --------------
diff --git a/doc/reference_manual.texi b/doc/reference_manual.texi
index 4cd5c1e..97f4468 100644
--- a/doc/reference_manual.texi
+++ b/doc/reference_manual.texi
@@ -4657,8 +4657,24 @@ bad(job(p)).                    % Error: p does not have required mode
 @dots{}
 @end example
 
-Combined higher-order types and insts are currently only permitted
+As a new feature, combined higher-order types and insts are only permitted
 as direct arguments of functors in discriminated unions.
+So the following examples currently result in errors.
+
+ at example
+% Error: use on the RHS of equivalence types.
+:- type p == (pred(io::di, io::uo) is det).
+:- type f == (func(int::in) = (int::out) is semidet).
+
+% Error: use inside a type constructor.
+:- type jobs ---> jobs(list(pred(int::out, io::di, io::uo) is det)).
+
+% Error: use in a pred/func declaration.
+:- pred p((pred(io::di, io::uo) is det)::in, io::di, io::uo) is det.
+:- func f(func(int::in) = (int::out) is semidet, int) = int.
+ at end example
+
+Future versions of the language may allow these forms.
 
 @node Modules
 @chapter Modules