[nem-bug] [Nemerle 0000795]: Inconsistent tuple type unification

[feedback at nemerle.org]

A NOTE has been added to this issue.
======================================================================
<http://nemerle.org/bugs/view.php?id=795> 
======================================================================
Reported By:                Evin Robertson
Assigned To:                
======================================================================
Project:                    Nemerle
Issue ID:                   795
Category:                   Compiler (type engine)
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
======================================================================
Date Submitted:             11-27-2006 03:44 CET
Last Modified:              11-28-2006 08:06 CET
======================================================================
Summary:                    Inconsistent tuple type unification
Description: 
public class A
{
}

public class B : A
{
}

public class C
{
    public F(x : int) : int * B
    {
        (x, B());
    }

    public G() : int * A
    {
        def (y, b) = F(1);
        (y, b);
    }

    public H() : int * A
    {
        F(1);
    }
}

Observed result: G() compiles fine, but H() gives an error:
pairunify.n:22:5:25:6: error: expected (int * A), got (int * B) in
function return type: the types A and B are not compatible [simple unify]

It doesn't seem like taking apart a tuple and putting it back together
again should be required for this to compile.  Because tuples are
immutable, (int * B) should be considered a subtype of (int * A).

======================================================================

----------------------------------------------------------------------
 nazgul - 11-27-06 08:09 
----------------------------------------------------------------------
> It doesn't seem like taking apart a tuple and putting it back together
again should be required for this to compile. Because tuples are
immutable, (int * B) should be considered a subtype of (int * A).

Tuples in Nemerle are invariant. This is a limitation of .NET generics :(

----------------------------------------------------------------------
 Evin Robertson - 11-28-06 05:22 
----------------------------------------------------------------------
How about adding implicit conversions for the tuple types?  The following
seems to work:

[Record]
public struct MyTuple['p0, 'p1]
{
    public field0 : 'p0;
    public field1 : 'p1;

    public static @: ['f0, 'f1, 'g0, 'g1]
      (f : MyTuple['f0, 'f1]) : MyTuple['g0, 'g1]
      where 'f0 : 'g0 where 'f1 : 'g1
    {
        MyTuple(f.field0 : 'g0, f.field1 : 'g1)        
    }
}


public class A
{
}

public class B : A
{
}

public class C
{
    public F(x : int) : MyTuple[int, B]
    {
        MyTuple(x, B());
    }

    public H() : MyTuple[int, A]
    {
        F(1);
    }
}

----------------------------------------------------------------------
 nazgul - 11-28-06 08:06 
----------------------------------------------------------------------
Yeah, I thought about it also yesterday. It makes much sense for small
tuples, which we represent as .NET structs, so the implicit conversion
performance cost won't be large. The type inference would have the problem
with these conversions in many cases, but in general it seems to be a good
solution.

Issue History
Date Modified  Username       Field                    Change              
======================================================================
11-27-06 03:44 Evin Robertson New Issue                                    
11-27-06 08:09 nazgul         Note Added: 0001523                          
11-28-06 05:22 Evin Robertson Note Added: 0001528                          
11-28-06 08:06 nazgul         Note Added: 0001529                          
======================================================================