I support this proposal, too.
On 12/20/14, 4:29 PM, "Brad Chamberlain" <[email protected]> wrote: > >My 2 cents: > >I'm biased because I worked with Sean to develop this proposal, but I >very >much like the idea of replacing 'type select' with 'select .type'. It >feels much more aligned with the rest of the language and removes a >special syntactic case that doesn't seem necessary to me. > >We will still have open questions w.r.t. determining which field of a >union is "active", but we had those already anyway. > >-Brad > > >On Fri, 19 Dec 2014, Sean Billig wrote: > >> Proposal: >> ========= >> The `type select` statement should be removed in favor of `select >>x.type`, >> which works today and provides nearly the same functionality. >> >> >> Rationale: >> ========= >> - The `type select` statement is basically redundant. For example: >> >> var x = 5; >> type select x { >> when int do writeln("int"); >> when real do writeln("real"); >> } >> >> can instead be written as: >> >> var x = 5; >> select x.type { >> when int do writeln("int"); >> when real do writeln("real"); >> } >> >> This works in 1.10.0, and maybe in earlier releases. >> >> - Due to a bug in the current implementation of `type select`, >> there can be only one `type select` statement in a given scope. >> >> >> Caveats: >> ======== >> - The behavior of the two statements isn't identical. >> `type select` uses the function resolution mechanism to choose the >> matching `when` clause, while `select` uses the equality operator (==). >> For example: >> >> var x: bool = true; >> type select x { >> when int do writeln("int"); >> otherwise writeln("other"); >> } >> >> This will print "int", because a variable of type `bool` can be >>implicitly >> converted to an `int`, following the function resolution rules. >> >> On the other hand, the `select x.type` variant: >> >> select x.type { >> when int do writeln("int"); >> otherwise writeln("other"); >> } >> >> will print "other", because x.type is `bool`, and `bool == int` >>evaluates >> to false. >> >> The `type select` behavior can be achieved using functions. For example: >> >> proc f(a: int) { writeln("int"); } >> proc f(a) { writeln("other"); } >> f(x); >> >> or via some hypothetical future type-coercion introspection abilities: >> if isImplicitlyConvertibleToInt(x) then writeln("int") else >> writeln("other"); >> >> Plan: >> ===== >> If there are no major objections to this proposal, `type select` will >> become a syntax error in the next release of chapel (with an error >>message >> suggesting `select .type`). In the following release, the parser won't >> recognize `type select`, and will generate a generic syntax error. >> >> Does anyone have any arguments against removing `type select`? >> Are there any use-cases that `type select` covers that can't >> be handled another way? >> >> Thanks, >> Sean >> > >-------------------------------------------------------------------------- >---- >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 ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
