Hi Sean --
Today I actually took the time to write some code before sending a
response which led to some interesting observations:
1) My code yesterday had a syntax error in it by using 'otherwise do'
where I should have simply used 'otherwise'. (Minor, thanks to
Mike Noakes for pointing it out)
2) It seems that when a single Chapel program has two type select
statements, it doesn't work.
3) Much more interestingly, the "replace 'type select' with 'select'
on type expressions" that I proposed yesterday seems to simply
work out of the box. This suggests to me that we probably could
and should just retire 'type select' as a syntactic construct and
solve the union type select question separately.
I've just pushed some tests that capture item 2 and 3. Item 2 is probably
a "five-minute fix (TM)" (the .future file suggests a strategy), but if we
retire type selects, it's also moot.
>> 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).
I don't think we should let the fear of breaking code deter us (though we
should do our normal thing and preserve the existing form with a warning
for the first release to support the new form, if at all possible). In
particular, my sense is that this feature isn't used often. That sense
would seem to be supported by observation 2 above.
Taking your other notes out of order:
> 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 thought about this yesterday, but then didn't let myself get hung up in
it because I decided that there's no real point of having a union which
has two fields of the same type. Do you think there is? (I think I can
construct an artificial argument, but since I don't think I believe in it,
I'll leave it to others to do so).
> 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.
Yeah, that starts to feel like mixing metaphors to me.
> I do like the dynType idea for the subclass case though.
Me too. Though I don't relish implementing it. Though it is intriguing
in that, if we had support for it, it suggests we could create the dynamic
dispatch mechanism used by Chapel method dispatch using Chapel itself
(which is satisfying, whether or not we did so).
Back to your other comment:
> 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.
I'm not sure I love it either. In particular, it seems to me that U.x
ought to be the expression that results in the read of the 'x' field
rather than a way of naming the 'x' field. Specifically, it seems to mix
an execution-time-value expression (U.x) with a compile-time identifier
type of context ("what is the name of the active field?").
Oh but wait. I see now that you've got U.x rather than u.x, so one could
think of this as some sort of reference to the namespace of type U rather
than access to value 'u'. Sorry to have missed that the first time
around. I think that makes this much more acceptable to me, though it
still feels like a pretty specialized case (in that we don't support R.x
or C.x to refer to field names of classes or records, nor do I think we'd
want to since ultimately, this syntax should be used to refer to static
members of such types...).
One other thought here is that, in a different context, someone on the
team was suggesting we should have support for first-class symbol
names/identifiers in the language and maybe if we did so that would
suggest a unifying solution here as well (since, in effect, it's the
namespace that we're trying to reason about here).
Mostly, though, I hope nobody will come up with a compelling
counterargument to my "each field in a union should have a unique type and
woe to the user who does otherwise" claim. :)
If that claim doesn't hold up, one other (lame, but simple) fallback would
be to have a way to query the number of the active field in a union and
then to "index" into a union using that field number. E.g., consider:
var U {
var x: int;
var y: int;
var z: real;
}
var i = u.activeFieldNum;
if (i == 1 || i == 2) then
var myint = u.getField(i);
This seems problematic, though, because in general 'i' won't be able to be
a param (compile-time-known value) which means that the result type of
getField() won't be able to be known at compile-time (which is going to
make it hard to implement, I believe). Which, I suppose, is why 'type
select' was supposed to be the panacea here even though it seems nobody
ever bothered to work out the important details.
-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
