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

Ralph Becket rbeck at microsoft.com
Mon Jul 23 19:55:02 AEST 2001

I have an idea that I believe will make higher order programming
with funcs less painful that it is at present.  It's a bit rough
at the moment, so discussion is welcome.

We currently have the useful rule that

	:- func foo(T1, ...) = T.

implies the following mode in the absence of any explicit declarations:

	:- mode foo(in(@T1), ...) = out(@T).


	@(func(U1, ...) = U) = (func(in(@U1), ...) = out(@U) is det)
and	@T                   = ground    % for all other T

I propose that the second clause for @ be changed to recurse over
known data types so that, for instance, the following would work:

:- type t(T) ---> [] ; [func(T) = T | t(T)].

:- func f(t(T), T) = list(T).    % No need for explicit modes.

We can extend the idea to get a simple version of parametric modes
for funcs as follows: if we call a func or pred with an argument
whose type we know, but whose inst is ground after the call, then
we can use the @ operator on its type to refine its inst and recover
any func mode information.  For this to work we have to forbid the
return of any ground func object that does not have the inst that @ 
would construct for its type (that is, if X has type func(T1, ...) = T
but its inst I is not the same as @(func(T1, ...) = T) then we forbid 
inst transitions of the form I >> ground.  I contend that this is a
sensible restriction because it doesn't make sense to keep hold of a
func object and throw away the inst data required to use it.

I believe this proposal is orthogonal to polymorphic modes and would
make the current library usable for collections of funcs, for example,
without having to make *any* changes to the library code.

What do people think?

- 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

More information about the developers mailing list