[m-dev.] Suggestion: default func-type/mode correspondence.

[Ralph Becket]

> From: Fergus Henderson [mailto:fjh at cs.mu.OZ.AU]
> Sent: 23 July 2001 20:40
> 
> On 23-Jul-2001, Ralph Becket <rbeck at microsoft.com> wrote:
> >
> > Can you give an example where a mode problem could arise?
> 
> See attached.
> The first one, func.m, shows how the problem can arise with
polymorphic types.
> The second, func3.m, shows how it can arise with abstract types.
> The current implementation correctly rejects func.m, reporting a mode
error,
> but incorrectly allows func3.m, generating incorrect code.

In func.m you have

main -->
	{ baz(foo, F) }, % *1*
	io__write_int(F(42)), nl.

:- func foo(int) = int.
foo(X) = X + 1.

:- func bar(int::out) = int::in is det.
bar(X) = X + 1.

:- pred baz(T::in, T::out) is det. 
baz(X, Y) :-
	Y = ( if univ_to_type(univ(bar), Y0) then Y0 else X ). % *2*

Under my proposal *1* would be okay (passing a higher order func
object foo/1 with the standard inst as an (_ >> ground) parameter to
baz/2 (if we ever get it back again we'll get it with the standard 
inst for its type.)

*2* would be an error because bar/1 does not have the standard inst
but is being passed as an (_ >> ground) or (_ >> dead) parameter to 
univ/1.

In func3.m you have the same problem in the definition of
sub__baz/1:

:- func bar(int::out) = int::in is det.
bar(X) = X + 1.

:- func sub__baz(id(t)::out) is det.
sub__baz(id__mkid(bar)). % *3*

:- func id__mkid(T::in) = id(T)::out is det.
id__mkid(X) = id(X).

:- type id__id(T) ---> id(T).

...

*3* is the same problem: bar/1 does not have the standard inst, but
is being passed as an (_ >> ground) argument to id__mkid/1.

The motivation for my proposal is to simplify the common case by
only requiring awkward and pervasive mode declarations for the
uncommon case.

The mode system can be useful in places, but at the moment it's
frequently an obstacle to abstraction.  I find it very hard to
reproduce or experiment in Mercury with work done in other 
functional languages because it's so hard to make collections 
of higher order values workable.

- Ralph
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------