> A simple test suggests that both `type select` and `select .type` currently
> match on the static type of the variable:
Aha... you are right. I jumped to conclusions because I thought that
test_recursive_iterator.chpl failed when I converted it to 'select .type',
but I must have made some other mistake in converting it or diagnosing
what happened. When I saw that it was attempting to do dynamic dispatch
(and passing its testing), I assumed the worst; it turns out that the type
select in the iterator is falling into the no-op 'otherwise' clause right
off tha bat, and that the output being generated is from the writeln of
root which itself prints the children. Sorry about that.
OK, that redoubles my call to retire 'type select' in favor of 'select
.type'. I think we still need to think about the coercion vs. equality
issue, but consider that fine-tuning (either in the language spec or the
implementation) rather than a show-stopper for proceeding.
Minor, but note that in your code, I think you commented out the wrong
case as not compiling:
> proc foo(x: B) {}
> foo(v1);
> // foo(v2); // doesn't compile
> but for what it's worth, its behavior is unchanged when `type select` is
> replaced with `select tree.type`.
Yeah, somehow I got that wrong last night. Perhaps I forgot 'tree.type'
when I rewrote it...
> So, it seems we need something like .dynType, or we could decide that .type
> should give the dynamic type of a class variable.
I think that, ultimately, we'll want to be able to query either, so we'll
need some new feature whether or not we choose to redefine '.type' in this
way. For example, I think one might want to be able do the following
(ignoring syntax which I chose for clarity, not because I like it):
class C { ... }
class D : C { ... }
var c: C = new D(...);
var myC: c.static_type = new ...;
var myD: c.dynamic_type = new D(...);
> * 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.
I hadn't spent any time yesterday thinking about which case did which. If
you'd asked me which I'd expect, I'd have said the non-coercing case
because it seems to provide more precision and be more like the nested
if-else. I'm happy today to realize that 'select x.type' is the one that
gives that behavior (because it also suggests retiring 'type select' and
updating tests that rely on the coercion behavior. My suspicion is that
none of them rely on it for deep/important ways, it's just how they were
written).
> - `type select`s behavior mirrors that of function resolution, which makes
> some sense,
I view this more as an offshoot of the technique that was used to
implement it, not anything deep.
> - 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.)
It doesn't seem right to me that x.type would match against a variable
expression 'inty' in your example above. My suspicion is that if one
wanted this behavior, they could either use function calls, or we could
put in some "can coerce to type" introspection capabilities (that we've
wanted in other situations as well, to move code out of the compiler and
into the modules, permitting users to create their own coercion rules).
> 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.
This feels attractive, but also like extra credit.
I think we're converting... You mentioned being interested in doing
something to get started and this seems like a nice stepping stone toward
the original proposal to do type selects for unions. Would you like to
own the task of removing type select and replacing it with 'select .type'?
In my mind, the steps are:
* recap the proposal to deprecate 'type select' and rationale briefly in a
new email to either chapel-developers (or chapel-users?) to see if there
are any objections for those who haven't been bothering to read these
long messages.
* sign and submit the Apache contributors agreement (see "developer
resources" on the sidebar at chapel.cray.com for the link)
* rewrite all tests and module code that use 'type select' to use 'select
.type'. test to make sure nothing is lost. The only case that I can
imagine being slightly nontrivial to test would be the use of 'type
select' in modules/standard/NewString.chpl -- in particular, you'd need
to make sure to test the tests that use this module. Information
about using our test system can be found in
doc/developer/bestPractices/TestSystem.txt. If this discussion has
turned up any new issues that aren't captured in current tests, it
would be nice to write new tests to capture them.
* pull 'type select' from the parser and dead code eliminate anything
downstream from that that's possible (I'm guessing it's mostly in
the front end).
* put together a pull request with these changes (the developer resources
link for a link to how we work with github and create pull requests)
-Brad
------------------------------------------------------------------------------
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
