[mercury-users] invalid universal quantification example confuses me

Fergus Henderson fjh at cs.mu.OZ.AU
Mon Jul 9 22:00:31 AEST 2001


On 09-Jul-2001, Terrence Brannon <tmbranno at oracle.com> wrote:
> I'm still not completely clear on this section of the manual.
> 
> Fergus Henderson writes:
>  : On 05-Jul-2001, Terrence Brannon <tmbranno at oracle.com> wrote:
>  : > The manual does state:
>  : > 
>  : >   If a type variable in the type declaration for a polymorphic predicate
> 
> Ok, is the below an example of "a type variable in the type
> declaration for a polymorphic predicate" :
> 
> :- pred distance(P1, P2, float) <= (point(P1), point(P2)).

That *contains* two examples of "a type variable in the type
declaration for a polymorphic predicate", namely "P1" and "P2".

>  : >   or function is universally quantified, this means the caller will
>  : >   determine the value of the type variable, and the callee must be
>  : >   defined so that it will work for all types which are an instance of
>  : >   its declared type. 
> 
>  : > :- pred bad_foo(T).
>  : > bad_foo(42).
>  : > % type error
> 
> Ok, so applying the remainder of the paragraph to this errant code:
> 
> 1 - the callee is bad_foo/1 per the last email msg
> 2 - the caller is something like:
> 
> main ---> { bad_foo(42) }.
> 
> 3 - Please state the following:
> 
>   a - how is the caller determining the type of the type variable and
>   what is the outcome of this process? I am guessing that the caller
>   is determining that the type of the type variable is integer. 

The caller determines the *value* of the type variable.
Your guess that the value of this type variable is "integer" is
almost correct -- actually it is "int", not "integer".
The value of the type variable is determined by the constraints
placed on it; in this case, the argument of bad_foo is unified
with an int literal, which constrains that argument to have
type "int".

>   b - since bad_foo/1 doesn't do anything with its input argument, why
>   is it failing this requirement: "the callee must be defined so that
>   it will work for all types which are an instance of its declared
>   type."

bad_foo/1 *is* doing something with its argument;
it is unifying it with the int literal 42.
This requires that the argument have type "int".
It will happen to work for this particular call from main/2,
but the compiler rejects the definition of bad_foo/1 because
it won't work for all types which are an instance of its
declared type.  If main/2 was written differently, e.g. as

	main ---> { bad_foo("oops") }.

then you'd be able to see the problem more clearly --
the argument would have type "string", but the callee bad_foo/1
would try to unify that with the value 42, which has type "int".

-- 
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-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the users mailing list