2019-08-26 09:20 AEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000089mercuryBugpublic2014-02-21 17:04
Reporterjuliensf 
Assigned Tojuliensf 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusassignedResolutionopen 
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
type-info.
TagsNo tags attached.
Attached Files

-Relationships
has duplicate 0000310closedjuliensf The compiler crashes when using existentially typed data types along with instantization states. 
+Relationships

-Notes

~0000538

juliensf (administrator)

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.
+Notes

-Issue History
Date Modified Username Field Change
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
+Issue History