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

[Fergus Henderson]

On 24-Jul-2001, Ralph Becket <rbeck at microsoft.com> wrote:
> > 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.

It can't be an error because of the final insts in the callee's mode,
it would have to be an error because of the initial insts.

But I think I get the idea.  For higher-order function types,
you want `ground' to mean that the function has the usual mode
and determinism.

Unlike the earlier proposals, this is a semantic change to the meaning of
`ground', rather than just some syntactic sugar on mode declarations.
(I guess you'd also want to change the meaning of `unique', `any', and
`dead' in the same way.)

One consequence of this change is that higher-order functions with
non-standard mode or determinism would become very much second-class or
even third-class objects.  If you have a list of such terms, for example,
you wouldn't be able to even call list__length on it.

Still, it may well be worth paying that price, in order to make
higher-order functions that do have standard modes and determinism be
truly first-class objects.

Currently, h.o. functions can be put in collections, and can be gotten
back out of them, but you can't call the resulting term without an inst cast.
With your proposal, h.o. functions with the standard mode/determinism
could be put in collections, gotten back out of them, and called without
any inst casts, while h.o. functions with non-standard mode/determinism could
not even be put in collections unless you use an inst cast.

The proposed change to the semantics of `ground' seems a bit non-orthogonal
to me, so I'm a little nervous about the consequences.  But from a practical
perspective it does look like this change would be a significant improvement.
So I give it a tentative thumbs up.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------