| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0000089 | mercury | Bug | public | 2009-02-18 21:21 | 2014-02-21 17:04 | ||||||||
| Reporter | juliensf | ||||||||||||
| Assigned To | juliensf | ||||||||||||
| Priority | normal | Severity | minor | Reproducibility | have not tried | ||||||||
| Status | assigned | Resolution | open | ||||||||||
| Product Version | |||||||||||||
| 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 type-info. | ||||||||||||
| Tags | No tags attached. | ||||||||||||
| Attached Files |
| ||||||||||||
 Relationships |
||||||
|
||||||
 Relationships |
| Notes |
|
|
juliensf (administrator) 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. |
| 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 |