Mercury Bugs - mercury | |||||
View Issue Details | |||||
ID | Project | Category | View Status | Date Submitted | Last Update |
0000184 | mercury | Bug | public | 2011-02-03 17:28 | 2016-06-30 11:46 |
Reporter | mgiuca | ||||
---|---|---|---|---|---|
Assigned To | juliensf | ||||
Priority | normal | Severity | crash | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Platform | OS | OS Version | |||
Product Version | |||||
Target Version | 15.11 | Fixed in Version | |||
Summary | 0000184: Unresolved polymorphism in typeclass crashes mmc | ||||
Description | The following program causes a software error in mmc (I believe I am using the HLC grade -- is there any way to check this?): :- module compileerror. :- interface. :- func test = int. :- implementation. :- import_module list. test = f([]). :- typeclass myclass(T) where [ func f(T) = int ]. :- instance myclass(list(T)) <= myclass(T) where [ f(_) = 4 ]. Uncaught Mercury exception: Software Error: map.lookup: key not found Key Type: parse_tree.prog_data.prog_constraint Key Value: constraint(qualified(unqualified("compileerror"), "myclass"), [type_variable(var(1), kind_star)]) Value Type: set_ordlist.set_ordlist(hlds.hlds_data.constraint_id) Stack dump not available in this grade. There are two factors which cause this. First, the instance for list has a constraint on T -- this can be any constraint but it doesn't crash unless there is a constraint on T. Second, I am calling 'f' with a type with unresolved polymorphism (the empty list has type list(T) and I have not bound the type variable T). Had I written f([] : list(int)) and added an instance myclass(int), it would compile successfully. What I would have expected is to receive a warning due to unresolved polymorphism, along the lines of: compileerror.m:005: In function `test'/0: compileerror.m:005: warning: unresolved polymorphism. compileerror.m:005: The variable with an unbound type was: compileerror.m:005: V_2: list.list(T) compileerror.m:005: The unbound type variable will be implicitly bound to the compileerror.m:005: builtin type `void'. Then I suppose this would cause an error, since `void' is not an instance of myclass: compileerror.m:011: In clause for function `test'/0: compileerror.m:011: unsatisfiable typeclass constraint: compileerror.m:011: `compileerror.myclass(void)'. This would then communicate to the user the folly of passing a list with an unspecified type to a method which really needs the list elements to have a concrete instance of myclass. | ||||
Additional Information | It seems as though the problem is that things are happening in the wrong order inside the compiler. With minor changes, I can cause the "unresolved polymorphism" warning to occur, so I think the problem is that mmc is trying to choose a "type dictionary" or "vtable" for the elements-of-the-list type *before* it assigns the type `void'. I figure that if it assigned the type `void' earlier, then it would cause the above more user-friendly error instead. For what it's worth, this situation does cause the following error in GHCI for Haskell: Ambiguous type variable `a' in the constraint: `MyClass a' arising from a use of `f' at compileerror.hs:2:7-10 Probable fix: add a type signature that fixes these type variable(s) | ||||
Tags | No tags attached. | ||||
Relationships | |||||
Attached Files |
Notes | |||||
|
|||||
|
|
Issue History | |||||
Date Modified | Username | Field | Change | ||
---|---|---|---|---|---|
2011-02-03 17:28 | mgiuca | New Issue | |||
2015-10-31 20:54 | juliensf | Target Version | => 15.11 | ||
2016-06-30 11:46 | juliensf | Note Added: 0000889 | |||
2016-06-30 11:46 | juliensf | Status | new => resolved | ||
2016-06-30 11:46 | juliensf | Resolution | open => fixed | ||
2016-06-30 11:46 | juliensf | Assigned To | => juliensf |