[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