Mercury Bugs - mercury
View Issue Details
0000089mercuryBugpublic2009-02-18 21:212014-02-21 17:04
Assigned Tojuliensf 
PrioritynormalSeverityminorReproducibilityhave not tried
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000089: existentially quantified data constructors and inst subtyping do not work together
DescriptionThe 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
TagsNo tags attached.
has duplicate 0000310closed juliensf The compiler crashes when using existentially typed data types along with instantization states. 
Attached Files? inst_subtype_exists.m (1,287) 2009-02-18 21:21

2013-06-07 16:58   
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.

Issue History
2009-02-18 21:21juliensfNew Issue
2009-02-18 21:21juliensfFile Added: inst_subtype_exists.m
2009-12-17 07:22juliensfStatusnew => confirmed
2013-06-07 16:58juliensfNote Added: 0000538
2013-06-07 17:12juliensfAssigned To => juliensf
2013-06-07 17:12juliensfStatusconfirmed => assigned
2014-02-21 17:04juliensfRelationship addedhas duplicate 0000310