limbo array/list pick adt assignment discrepancies, pick adt leakage, and (pick) adt assignment

[GoogleCodeExporter]

just tested with the latest inferno from hg (333:85e747cf56ef).

i ran into problem 1 quite some time ago.  now that i looked closer
i found a few other things.  i'll dive into the compiler to see if
i can come up with a patch in a few days.

# problem 1

cannot assign array of ref pickadt to an array of ref adt.  the
same with lists instead of arrays does work.  you can go through a
"direct tuple" representation though.  or is the assignment unsafe?
i doubt it.

$ limbo -gw testpa0.b
testpa0.b:24: type clash in 'a' of type array of ref A = 'b' of type array
of ref A.B
$

# problem 2

pick adt members leak across adt's.  testpb0.b and testpb1.b are
identical except that adt C's pick member is called D in testpb0.b
and B in testpb1.b (the same as A's pick member).  the case for
arrays is already denied, but the case for lists is wrongly (i
think) allowed in testpb1.b.

$ limbo -gw testpb0.b
testpb0.b:25: type clash in 'la' of type list of ref C = 'lb' of type list
of ref A.B
testpb0.b:29: type clash in 'a' of type array of ref C = 'b' of type array
of ref A.B
$

$ limbo -gw testpb1.b
testpb1.b:29: type clash in 'a' of type array of ref C = 'b' of type array
of ref A.B
$

# problem 3

you can assign across ref adt and direct ref tuple when their member
types are the same (and the other way around), but you cannot directly
assign across compatible adt's.  probably intentional.  but compatible
pick adt's _cannot_ be assigned through a tuple with compatible
types.  it feels like a mismatch.

perhaps adt's shouldn't be assignable to matching tuples.  or perhaps
pick adt's should also be assignable to matching tuples.  the latter
makes more sense to me:  it's nice that you can assign different
but matching adt's, but that you have to go through the trouble of
"casting" it through a tuple.  the same holds for pick adt's.

# testpc0.b assigns a ref adt A to a ref adt B through a tuple with the
same types.  works.
$ limbo -gw testpc0.b
$

# testpc1.b does the same, but with the adt's being pick adt's.  it fails.
$ limbo -gw testpc1.b
testpc1.b:27: type clash in 'la' of type list of ref A.B = 'lt' of type
list of ref (int, int)
testpc1.b:33: type clash in 'a' of type array of ref A.B = 't' of type
array of ref (int, int)
$

hope this makes sense.

Original issue reported on code.google.com by mechiel@ueber.net on 22 Jul 2009 at 3:38

Attachments:

• testpa0.b
• testpb0.b
• testpb1.b
• testpc0.b
• testpc1.b

[GoogleCodeExporter]

i've looked at this (on and off) since it appeared.
it does make sense.
the compiler is quite particular about some of these distinctions,
including list contexts as opposed to arrays,
and in a few cases i need to think carefully why that should be.

Original comment by Charles....@gmail.com on 2 Aug 2009 at 11:27

• Changed state: Checking

[GoogleCodeExporter]

the definition of compatibility needs to be made more precise.
some of these examples should then be acceptable.
the compiler has a plausible primitive for type promotion and balancing in some
of these cases, but in a few it is not yet applied.

Original comment by Charles....@gmail.com on 5 Aug 2009 at 6:58

• Changed state: Accepted