I didn't have much time to look at this today, but I'll add a couple quick
comments.
> * test/users/biesck/test_recursive_iterator.chpl seems to indicate that
> the current 'type select' construct supports dynamic type selection for
> class variables (assuming it's working as intended). I had forgotten
> this. I'm not sure that this changes any of my overall opinions on this
> thread, but it suggests that deprecating the 'type select' statement
> would remove functionality until such time as we'd implemented the
> '.dynType' capability (or whatever alternative technique we might want
> for reasoning about the dynamic type of an object).
A simple test suggests that both `type select` and `select .type` currently
match on the static type of the variable:
class A { proc f() { writeln("method: A"); } }
class B : A { proc f() { writeln("method: B"); } }
var v1: A = new B();
var v2: B = new B();
checktype(v1);
checktype(v2);
proc checktype(x) {
x.f();
select x.type {
when A do writeln("select x.type: A");
when B do writeln("select x.type: B");
}
type select x {
when A do writeln("type select: A");
when B do writeln("type select: B");
}
}
proc foo(x: B) {}
foo(v1);
// foo(v2); // doesn't compile
I'm not sure yet why test_recursive_iterator.chpl works the way it does,
but for what it's worth, its behavior is unchanged when `type select` is
replaced with `select tree.type`.
So, it seems we need something like .dynType, or we could decide that .type
should give the dynamic type of a class variable.
* If I change all other 'type select x' statements in current tests to
> 'select x.type', I get some other failures/differences which I believe
> are due to coercion firing in a different way for the two constructs.
> This could either be considered a bug in how 'select' is implemented
> on type expressions, or might be a better behavior to support, but
> in either case, it suggests that pulling the plug on 'type select'
> requires a bit more caution than I'd hoped for. See, for example,
> trivial/deitz/test_type_select1.chpl
Interesting; I'm not sure how I feel about this yet, but I'll toss out a
couple thoughts.
- Changing `select x.type` to match the `type select` coercion behavior
breaks the simple "equality operator" specification of the select statement.
- `type select`s behavior mirrors that of function resolution, which makes
some sense, but it seems a bit confusing when there's an `otherwise` clause
present:
var x: bool = true;
type select x {
when int do ..
otherwise ..
}
With this behavior, there's no way to check whether you truly have an int,
versus something that can be coerced into an int. (Today you could use
`select x.type` to achieve this, but not if we change the behavior of
`select x.type` to match `type select`. You could also use `if x.type ==
int`, of course.)
- If `type select` didn't exist, and `select x.type` remained unchanged,
one could achieve the `type select` behavior with something like:
record Inty {}
proc ==(type t, b: Inty) { return isIntType(t) || isBoolType(t); }
const inty = new Inty();
select x.type {
when inty do writeln("inty");
}
Not great, but at least it's possible. (Maybe there's a more elegant way to
achieve this... I'm still new.)
Or you could get part of the way there with query expressions:
select x.type {
when int(?sz) do ..
}
This doesn't match on bool, of course, but it avoids enumerating all of the
int sizes.
-- Sean
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
