I'd just like to add some more support for removing `type select`. Longer term I think it could be valuable in looking at changing unions to a ML/Haskell/rust style tagged union. Going down this route could help with the syntax questions as well. But that is probably a topic for another thread.
-Kyle On 12/17/14, 3:50 PM, "Brad Chamberlain" <[email protected]> wrote: > >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.clk >>trk >> _______________________________________________ >> 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.clkt >rk >_______________________________________________ >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
