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

[Fergus Henderson]

On 23-Jul-2001, Ralph Becket <rbeck at microsoft.com> wrote:
> 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).
> 
> where
> 
> 	@(func(U1, ...) = U) = (func(in(@U1), ...) = out(@U) is det)
> and	@T                   = ground    % for all other T

What should happen if `T' is an abstract equivalence type that is defined
	(a) in the same module as `foo'
or	(b) in some other module
as being equivalent to a higher-order function type?

I would not be suprised if the current compiler gets that wrong,
e.g. allowing mode-incorrect code to compile and crash at runtime.

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

This might be a good idea.  But I don't see how to make the same thing work for
abstract types, unfortunately.

	:- func g(t(T), T) = set(T).    % Explicit modes needed here,
					% because `set/1' is an abstract type.

If we make things easier with concrete types but not with abstract types,
then that will encourage people to use concrete types rather than
abstract types, and so I'm not sure that it would be a win overall.

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

This is not safe in the presence of univ__to_type and friends.

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

How can you forbid that, when for polymorphic procedures the exact type
their arguments is not know until runtime?
Are you suggesting a run-time check??

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