>
> But, since that time, I've found myself thinking we should abandon the
> 'type select' syntax and just extend normal select statements to support
> type expressions as well.
I agree; this seems like a good change to make, with no obvious downsides
(apart from breaking existing code).
Given the previous union example:
> union U {
> var x : int;
> var y : string;
> }
> var u: U;
> u.x = 5;
trying to determine the active field of u by `select`ing on u.type is
awkward at best, as you said. We could select on something like
u.activeField:
select u.activeField {
when U.x do
when U.y do
}
which is akin to selecting on enums, as though u.activeField returns a
value of type `enum U { x, y }`. I'm not sure that I love this idea, but I
can't think of anything better that fits with chapel's syntax. Maybe
someone else has some thoughts.
Having u.dynType give the type of the active field is problematic in the
case of multiple fields with the same type, e.g. `union A { var x: int; var
y: int; ... }`. I suppose one could say that U.x is the dynType of a U var
with the x field active, but that feels a bit unnatural.
I do like the dynType idea for the subclass case though.
- Sean
On Tue, Dec 16, 2014 at 7:31 PM, Brad Chamberlain <[email protected]> wrote:
>
>
> Hi Sean --
>
> This gets asked about just frequently enough that I think people would
> greatly value it if you were to provide it, yet not so often that we ever
> seem to get around to it ourselves. I.e., we'd love to see this developed
> and contributed back.
>
> That said, I feel unclear myself about what the right direction to pursue
> is for this case. And, to be perfectly honest, I also find myself second
> guessing the current specification and syntax of type selects.
>
> Starting with your proposal:
>
> union U {
>> var x : int;
>> var y : string;
>> }
>> var u : U;
>> u.x = 5;
>>
>> type select u {
>> when U.x do writeln("x");
>> when U.y do writeln("y");
>> }
>>
>
> This feels a little funny to me given the current definition of type
> select because I would expect the expressions following the 'when' clauses
> to evaluate to type expressions (e.g., 'int' and 'real') rather than the
> variables that I think of U.x and U.y to refer to. Also, if we think of
> type select as accessing the type of the expression (i.e., u.type) then it
> seems like that should evaluate to the union type 'U' itself rather than
> one of the field types -- to do otherwise feels non-orthogonal. Both in
> the sense of "What if I wanted to query whether the type of u was a union
> or an int?" and "type selects should be equivalent to chained conditionals
> on 'expr.type'."
>
> Since the time that we originally specified and implemented type selects,
> I've been having second thoughts about whether we made the right decisions.
> So the big caveat here is that what follows is my personal opinions and
> others on the team may disagree. I think we may want to kick this around
> on chapel-developers a bit and consider pushing it to chapel-users to see
> if we get different viewpoints there -- especially if we don't reach an
> easy consensus here.
>
> If I were to keep the 'type select' syntax, I would tend to expect it to
> behave as follows. Given:
>
> type t = typeFunction();
>
> var x: typeFunction();
>
> proc typeFunction() type {
> if (coinFlipIsHeads()) {
> return int;
> } else {
> return real;
> }
>
> I'd want the user to write this:
>
> type select t { // type alias OK
> when int do writeln("i");
> when real do writeln("r");
> otherwise do writeln("?");
> }
>
> type select x.type {
> when int do writeln("i");
> when real do writeln("r");
> otherwise do writeln("?");
> }
>
> The reason is because it feels healthy to me to either always expect a
> type expression or a value/variable expression in this context rather than
> permitting both; yet if we were to only support the value/variable case
> (the second), it wouldn't permit us to make queries on type aliases like
> 't'. Seems broken.
>
> But, since that time, I've found myself thinking we should abandon the
> 'type select' syntax and just extend normal select statements to support
> type expressions as well. That is, given that today we can write things
> like:
>
> if (t == int) {
> } else if (t == real) {
> } else {
> }
>
> and
>
> if (x.type == int) {
> } else if (x.type == real) {
> } else {
> }
>
> It seems natural to write "type selects" as simply:
>
> select t {
> ...
> }
>
> select x.type {
> ...
> }
>
> I.e., conditionals-on-exprs:selects-on-exprs are analogous to
> conditionals-on-types:selects-on-types.
>
>
> Unions cause problems in this case too, though, because given:
>
> union U {
> var x: int;
> var y: string;
> }
>
> var u: U;
> u.x = 5;
>
> there's a question as to whether u.type refers to the union (which seems
> most natural) or to the "active" field. That is, if the former is
> true, I couldn't write:
>
> select u.type {
> when int do
> when real do
> otherwise
> }
>
> but if the latter is true, I wouldnt' be able to distinguish between a
> variable that's a union and one that's something else.
>
> And that's where I pause and wonder whether we need some additional
> mechanism to talk about the currently active/dynamic type. Another place
> where such a concept could be useful would be to query the dynamic (vs.
> static) type of a subclass. Maybe the same concept could be used for
> both? I.e., I'm imagining something like:
>
> select u.dynType { // not sure I like 'dynType' as the name...
> when int do ...
> when real do ...
> otherwise ...
> }
>
> where we might also be able to use this in cases like:
>
> class C { ... }
>
> class D: C { ... }
>
> var myC: C = if (coinFlipIsHeads()) then new C() else new D();
>
> select myC.dynType {
> when C do
> when D do
> }
>
>
> It's worth noting that the original type select cases I mentioned at the
> top of this can be completely resolved statically while these two cases
> would require dynamic information and some sort of code manipulation to map
> the type expressions to some sort of runtime expression (given that we
> don't have dynamic representation of most types).
>
> And now I've gotta run home -- hope this is useful food for thought and
> sorry that there's not a clearer path here... I'm interested in what you
> think.
>
> -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
