[m-dev.] Existentially quantified types.

[Fergus Henderson]

On 22-Feb-2001, Ralph Becket <rbeck at microsoft.com> wrote:
> :- typeclass d(T) <= c(T) where [
>     some [T2]
>         func g(int) = T2 => d(T2)
> ].
> -------------------------
> In this case the particular T2 I get back from calling g may depend
> on the int argument.  That would suggest that the type of g is
> better expressed by
> 
>     func g(int) = (some [T2] T2 => d(T2))
>
> If I'm right, then there's some substance to the argument that the
> current syntax is a little misleading (although more convenient where
> T2 appears in multiple places...)

Consider the case when g/1 is written as a predicate, with the output
argument first.

Or consider

	:- some [T] pred p(T, int, T).
	:-          mode p(out, in, out) is det.

You could argue that the current syntax is a bit misleading,
but I don't see any better alternative.

In general, the type in an existentially quantified pred or func
declaration can depend on any of the input arguments.  You should
not read the current syntax as implying otherwise.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  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
--------------------------------------------------------------------------