|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000089||mercury||Bug||public||2009-02-18 21:21||2014-02-21 17:04|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0000089: existentially quantified data constructors and inst subtyping do not work together|
|Description||The attached program reports and error when compiled with mmc -C.|
The appears to be the result of two insts that should unify not unify because
one of them includes a component that corresponds to an introduced
|Tags||No tags attached.|
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.
|2009-02-18 21:21||juliensf||New Issue|
|2009-02-18 21:21||juliensf||File Added: inst_subtype_exists.m|
|2009-12-17 07:22||juliensf||Status||new => confirmed|
|2013-06-07 16:58||juliensf||Note Added: 0000538|
|2013-06-07 17:12||juliensf||Assigned To||=> juliensf|
|2013-06-07 17:12||juliensf||Status||confirmed => assigned|
|2014-02-21 17:04||juliensf||Relationship added||has duplicate 0000310|