|
|
There are two approaches to fix this, both of which have problems:
(1) The polymorphism pass should process the inst table and add type-info related
arguments into any bound functors that correspond to constructors with existentially quantified type
variables. This seems like the cleanest approach except for the fact that we cannot always tell whether
an inst should be transformed like this. Consider:
:- type foo(T) ---> a(T) ; b(T) ; c(T).
:- type bar ---> some [T] a(T) ; nil.
:- inst a ---> a(ground).
Should the inst 'a' have an extra argument added or not. It depend on the type, which we won't
know until we try to unify the inst against that of some term. (This is essentially a language design
issue, at the moment functors in insts do not have types associated with them, so we cannot tell
whether the above should be transformed or not -- indeed, it may be used with both foo/1 and bar/0,
in which case having polymorphism transform the insts won't work at all.)
(2) The second approach is to get the mode check to look at var-functor unifications and if the
functor has introduced type-info related arguments, to add them to the inst on the LHS.
I've implemented the fix for the incorrect generation of the error message in this bug and it indeed
fixes the problem. Unfortunately, a later part of the mode analyser then aborts (for more ore less the
same reason). The issue with this is approach is that it is likely that we are going to have to replicate
it in several different places. |
|
inst_subtype_exists.m (1,287) 2009-02-18 21:21