[m-dev.] Confused about existentially quantified types

Ralph Becket rbeck at microsoft.com
Fri Nov 17 02:41:44 AEDT 2000


The reference manual states that the following is wrong

:- some [T] pred foo(T).

foo(123).
foo('a').
foo("bar").

because the types on the RHS are not unifiable.  However,
existentially quantified types are used in the store
module

:- some [S] pred store_new(store(S)).

to ensure that stores cannot be confused (that is, there
is no guarantee that separate calls to store_new/1 will
generate stores of the same type).

These two things seem to be in opposition: the first requires
that whatever type foo/0 returns it must always be the same
whereas the second says that you can't rely upon this.

This means that I can't write

:- some [T] pred something(T) => a_thing(T).

something(thing1).
something(thing2).
something(thing3).

where thing[123] all have different types but satisfy the
typeclass constraint.  Instead I have to jump through a hoop:

:- type some_thing ---> some [T] s(T) => a_thing(T).

:- some [T] pred something(some_thing).

something('new s'(thing1)).
something('new s'(thing2)).
something('new s'(thing3)).

It seems I haven't grokked part of the existential types
story.  Can someone explain?

[BTW, if you accidentally omit the `new ' then the error messages
aren't very helpful...]

Ta,

Ralph

--
Ralph Becket      |      MSR Cambridge      |      rbeck at microsoft.com 
--------------------------------------------------------------------------
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