Opened 12 years ago
Last modified 7 years ago
#1815 new defect
Type variables cannot be (explicitly) unified even though the compiler can unify them
| Reported by: | Owned by: | somebody | |
|---|---|---|---|
| Priority: | high | Milestone: | Future |
| Component: | Frontend | Version: | trunk |
| Keywords: | Cc: |
Description
Even though a type unification is obvious the compiler does not
always accept a type specified by a function that's called.
In the Side note in the code of #1814 this issue is shown. In the
eq function a type variable A is defined and used for
element. It has to be of the same type as Element, otherwise
the call to equalityFunction will fail (and a compilation error
occurs if that's attempted). A currentElement is rejected by
the compiler since next returns Element. This causes the
internal type Element to potentially have to propagate to any
uses outside of the package where a polymorphic function exists
that uses eq.
Mainly I would like A to be valid here so that this propagation
does not occur.
Additionally, it seems more reasonable that naming it Element
would fail since that type variable is free and there is no
indication in the written code that the unification occurs, but
that is less important.
Change History (9)
comment:1 by , 11 years ago
| Milestone: | 1.9.0 → 1.9.1 |
|---|
comment:2 by , 10 years ago
| Milestone: | 1.9.1 → 1.9.2 |
|---|
This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).
comment:3 by , 10 years ago
| Milestone: | 1.9.2 → 1.9.3 |
|---|
Milestone changed to 1.9.3 since 1.9.2 was released.
comment:8 by , 8 years ago
| Milestone: | 1.11.0 → 1.12.0 |
|---|
Milestone moved to 1.12.0 due to 1.11.0 already being released.
comment:9 by , 7 years ago
| Milestone: | 1.12.0 → Future |
|---|
The milestone of this ticket has been reassigned to "Future".
If you think the issue is still valid and relevant for you, please select milestone 1.13.0 for back-end, code generation and run-time issues, or 2.0.0 for front-end issues.
If you are aware that the problem is no longer present, please select the milestone corresponding to the version of OMC you used to check that, and set the status to "worksforme".
In both cases, a short informative comment would be welcome.
Postponed until 1.9.1