A couple of quick follow-ups on point 3 below that I should've caught
before sending this:
* 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).
* 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
-Brad
On Wed, 17 Dec 2014, Brad Chamberlain wrote:
>
> 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
>
------------------------------------------------------------------------------
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
