[mercury-users] Higher order stuff... [embarrasment]

[Ralph Becket]

Ooops - just found out that it was a convoluted bug in my code and
the type inference seems to be doing just the right thing.
Apologies...

--
Ralph Becket      |      MSR Cambridge      |      rbeck at microsoft.com 

> -----Original Message-----
> From: Ralph Becket [mailto:rbeck at microsoft.com]
> Sent: 20 March 2000 17:06
> To: Mercury Users Mailing List (E-mail)
> Subject: [mercury-users] Higher order stuff, type inference and
> ambiguity
> 
> 
> I've been hacking away and the following line
> 
> ArgSpace = array(list__map(map__lookup(TypeObjsMap), TypeSigList))
> 
> led to this collection of errors:
> 
> naffplan.m:637: In clause for function `naffplan:qualify_op_spec/2':
> naffplan.m:637:   in argument 1 of functor `array/1':
> naffplan.m:637:   in argument 1 of functor `list:map/2':
> naffplan.m:637:   in unification of argument
> naffplan.m:637:   and term `map:lookup(TypeObjsMap)':
> naffplan.m:637:   type error in argument(s) of functor `map:lookup/1'.
> naffplan.m:637:   argument has type `((func PropName) = T)',
> naffplan.m:637:   functor `map:lookup/1' has overloaded type
> naffplan.m:637:   { (map:lookup((tree234:tree234(K, V)))) :: 
> pred(K, V),
> naffplan.m:637:   (map:lookup((tree234:tree234(K, V)))) :: 
> ((func K) = V) },
> naffplan.m:637:   variable `TypeObjsMap' has type 
> `(tree234:tree234(Type,
> (list:list(Obj))))'.
> 
> I've been bitten by this one a couple of times before.  The problem is
> that map__lookup/3 is a predicate and map__lookup/2 is a 
> function.  Now,
> there is sufficient information later on in the clause containing the 
> offending line to show that the only consistent typing results from
> taking map__lookup(TypeObjsMap) as a function.
> 
> It seems to me (as a non-expert on type inference) that 
> provided there is
> only one sensible assignment of types to values then the 
> compiler should
> settle on that one as being what you intended.
> 
> Is my problem above a special case of a much harder problem or is this
> an undesirable behaviour to want or is it just a hole in type 
> inference
> in the compiler?
> 
> Cheers,
> 
> Ralph
> 
> --
> Ralph Becket      |      MSR Cambridge      |      
> rbeck at microsoft.com 
> --------------------------------------------------------------
> ------------
> 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
> --------------------------------------------------------------
> ------------
> 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------