Hi -
One of the many bugs I've been reporting lately has to do with I/O,
but I narrowed down the problem (or at least one problem) to
something that appears to be wrong with function resolution/record
default methods.
I've created a test case that shows the problem in
test/users/ferguson/recordassignstring.chpl
The code is this:
record Point {
var x:int;
var y:int;
}
var p = new Point(1,2);
var s = p:string;
var q:Point = s;
I'm getting an error message about string.x not existing. That's because
the compiler-generated assignment method for Point takes in a *totally generic*
right-hand-side, which is probably the problem. Can't it at least check that
the right-hand-side is a subtype or supertype of Point?
The spec does say "In record assignment, each field of the record on the
left-hand
side of the assignment is overwritten with the value in the like-named field
of the record on the right-hand side as if by assigment". It does NOT say that
this assignment operation only applies to compatible types (which I think it
should).
That is, I don't think you should be able to say:
record A { var x: int; }
record B { var x: int; }
var a = new A(1);
var b = new B(2);
b = a;
... but right now you can. At least we should not resolve b = a if b has fields
that aren't in a. However, I'm NOT voting that we complicate function
resolution with that -
I'd rather have it check to see that b is a subtype of a. I've
never been a fan of the 'record assignment copies individual fields' thing.
By the same token, I don't see that record = class instance has any worth at
all.
If an advanced user wanted that kind of thing, they could write it with the
fielderator.
Are there any usage patterns or example programs which benefit from this
strange semantic?
Lastly, I think it's confusing that in this one way we have a structural type
system,
where the rest of the Chapel type system is nominative. In particular, if
records
really are structural, I'd expect the following to work (when appended to the
above code):
proc something(r: A) {
writeln("In something ", r);
}
something(a);
something(b);
... but it does not (because function resolution is already complicated
enough!).
Thanks,
-michael
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
