digitalmars.D - Extend D's switch statement?
- Yuxuan Shui (3/3) Jul 08 2015 I think it will be useful to extent switch statement to support
- Martin Nowak (5/8) Jul 08 2015 Hardly anyone wants switch to be a better if-else ladder.
- Vlad Levenfeld (5/14) Jul 08 2015 I would really like to see tuples become part of the language,
- Timon Gehr (25/32) Jul 08 2015 I don't think this is what is being asked for.
- Yuxuan Shui (2/33) Jul 08 2015 Yes, this is what I meant.
- Martin Nowak (15/32) Jul 08 2015 Very interesting. How would you deal with collisions?
- Martin Nowak (5/8) Jul 08 2015 Apparently called 'Minimal Perfect Hashing'.
- Dmitry Olshansky (6/28) Jul 08 2015 In the worst case just if-else chain collided items per hash value?
- Martin Nowak (4/8) Jul 10 2015 There is a readymade tool (gperf) to generate code for perfect hash
- Dmitry Olshansky (4/12) Jul 10 2015 Does it work for any UDTs? I guess strings only.
- rsw0x (3/5) Jul 08 2015 all of kenji's proposals are pretty much gold, has there ever
- Meta (3/8) Jul 08 2015 The tuple syntax was implemented and never pulled. I don't know
- ketmar (7/14) Jul 09 2015 at least part of it was implemented by Kenji himsef, and then blocked du...
- rsw0x (3/8) Jul 09 2015 I see this happen a lot, it's always what might be instead of
- Timon Gehr (8/17) Jul 09 2015 I think most of the compiler source code for the ideal solution occurs
- Timon Gehr (10/15) Jul 09 2015 E.g.
- Vlad Levenfeld (3/20) Jul 09 2015 Couldn't this could be detected at compile-time and temporary
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (7/31) Jul 10 2015 Yes, but there needs to be a complete aliasing analysis, e.g.
- Vlad Levenfeld (6/38) Jul 10 2015 Yeah true. I really wish we had this. I've got .tuple and
- Timon Gehr (3/26) Jul 10 2015 Oh, it certainly is simple to fix, it's just that we don't want this
- Vlad Levenfeld (4/33) Jul 10 2015 Why not? Tuple handling seems like it should be a 1st class
- Timon Gehr (4/37) Jul 10 2015 ..?
- Vlad Levenfeld (3/5) Jul 10 2015 Ok, I misunderstood. What's broken, if the temporaries are
- ketmar (4/8) Jul 08 2015 no, you can do that* with some template programming. so there is no=20
- Idan Arye (2/10) Jul 08 2015 http://dlang.org/phobos/std_algorithm_comparison.html#.predSwitch
- Timon Gehr (3/11) Jul 08 2015 The compiler complexity introduced by this change is trivial.
- Martin Nowak (7/10) Jul 08 2015 Except trivial doesn't mean it's cheap. Would probably take 1-2 days to
- Timon Gehr (3/13) Jul 09 2015 I just noted that increased compiler complexity is absolutely not a
I think it will be useful to extent switch statement to support any type that implements opEquals and opHash. Is there any technical difficulties to implement this?
Jul 08 2015
On Wednesday, 8 July 2015 at 07:15:27 UTC, Yuxuan Shui wrote:I think it will be useful to extent switch statement to support any type that implements opEquals and opHash. Is there any technical difficulties to implement this?Hardly anyone wants switch to be a better if-else ladder. https://issues.dlang.org/show_bug.cgi?id=5862 Many would like it to support pattern matching though. http://wiki.dlang.org/DIP32#Various_places_that_you_can_use_unpacking_and_pattern_matching
Jul 08 2015
On Wednesday, 8 July 2015 at 08:31:42 UTC, Martin Nowak wrote:On Wednesday, 8 July 2015 at 07:15:27 UTC, Yuxuan Shui wrote:I would really like to see tuples become part of the language, maybe with automatic unpacking when they are passed as function args (if the function doesn't explicitly require a tuple in that position).I think it will be useful to extent switch statement to support any type that implements opEquals and opHash. Is there any technical difficulties to implement this?Hardly anyone wants switch to be a better if-else ladder. https://issues.dlang.org/show_bug.cgi?id=5862 Many would like it to support pattern matching though. http://wiki.dlang.org/DIP32#Various_places_that_you_can_use_unpacking_and_pattern_matching
Jul 08 2015
On 07/08/2015 10:31 AM, Martin Nowak wrote:On Wednesday, 8 July 2015 at 07:15:27 UTC, Yuxuan Shui wrote:I don't think this is what is being asked for. switch(x){ case a: ...; break; case b: ...; break; default: break; } -> switch(x.toHash()){ case a.toHash(): if(x!=a) goto default; ...; break; case b.toHash(): if(x!=b) goto default; ...; break; default: break; } (a and b are known at compile time here, and so are their hash values. Hash collisions between e.g. a and b would need to be dealt with of course.)I think it will be useful to extent switch statement to support any type that implements opEquals and opHash. Is there any technical difficulties to implement this?Hardly anyone wants switch to be a better if-else ladder. https://issues.dlang.org/show_bug.cgi?id=5862
Jul 08 2015
On Wednesday, 8 July 2015 at 17:30:59 UTC, Timon Gehr wrote:On 07/08/2015 10:31 AM, Martin Nowak wrote:Yes, this is what I meant.On Wednesday, 8 July 2015 at 07:15:27 UTC, Yuxuan Shui wrote:I don't think this is what is being asked for. switch(x){ case a: ...; break; case b: ...; break; default: break; } -> switch(x.toHash()){ case a.toHash(): if(x!=a) goto default; ...; break; case b.toHash(): if(x!=b) goto default; ...; break; default: break; } (a and b are known at compile time here, and so are their hash values. Hash collisions between e.g. a and b would need to be dealt with of course.)[...]Hardly anyone wants switch to be a better if-else ladder. https://issues.dlang.org/show_bug.cgi?id=5862
Jul 08 2015
On 07/08/2015 08:06 PM, Yuxuan Shui wrote:Very interesting. How would you deal with collisions? You can already do some nice things during compile time, e.g. creating perfect hash functions and lookup table, but it doesn't seem to be possible to achieve what you suggest. Please file an enhancement request in bugzilla (https://issues.dlang.org/) so we don't loose this idea. Keep in mind though that this is mostly syntax sugar for the code above, still requires some specing, has a somewhat uncommon use case, and competes for our limited development time. So don't expect anyone to jump on this, we have a lot of much higher priority stuff to deal with. It would become a lot more useful if you'd find out how to (perfectly?) hash all the case labels to indices of a compact jump table. How are tags of case classes implemented in scala?switch(x.toHash()){ case a.toHash(): if(x!=a) goto default; ...; break; case b.toHash(): if(x!=b) goto default; ...; break; default: break; } (a and b are known at compile time here, and so are their hash values. Hash collisions between e.g. a and b would need to be dealt with of course.)Yes, this is what I meant.
Jul 08 2015
On Wednesday, 8 July 2015 at 21:26:55 UTC, Martin Nowak wrote:It would become a lot more useful if you'd find out how to (perfectly?) hash all the case labels to indices of a compact jump table.Apparently called 'Minimal Perfect Hashing'. https://en.wikipedia.org/wiki/Hash_function#Minimal_perfect_hashing Maybe we could also use something similar to speed up druntime's string switching support.
Jul 08 2015
On 09-Jul-2015 00:26, Martin Nowak wrote:On 07/08/2015 08:06 PM, Yuxuan Shui wrote:In the worst case just if-else chain collided items per hash value? Given that in this case it may use the full range of size_t I won't expect high collision rates. -- Dmitry OlshanskyVery interesting. How would you deal with collisions? You can already do some nice things during compile time, e.g. creating perfect hash functions and lookup table, but it doesn't seem to be possible to achieve what you suggest.switch(x.toHash()){ case a.toHash(): if(x!=a) goto default; ...; break; case b.toHash(): if(x!=b) goto default; ...; break; default: break; } (a and b are known at compile time here, and so are their hash values. Hash collisions between e.g. a and b would need to be dealt with of course.)Yes, this is what I meant.
Jul 08 2015
On 07/09/2015 12:26 AM, Dmitry Olshansky wrote:In the worst case just if-else chain collided items per hash value? Given that in this case it may use the full range of size_t I won't expect high collision rates.There is a readymade tool (gperf) to generate code for perfect hash switches. http://linux.die.net/man/1/gperf
Jul 10 2015
On 10-Jul-2015 16:43, Martin Nowak wrote:On 07/09/2015 12:26 AM, Dmitry Olshansky wrote:Does it work for any UDTs? I guess strings only. -- Dmitry OlshanskyIn the worst case just if-else chain collided items per hash value? Given that in this case it may use the full range of size_t I won't expect high collision rates.There is a readymade tool (gperf) to generate code for perfect hash switches. http://linux.die.net/man/1/gperf
Jul 10 2015
On Wednesday, 8 July 2015 at 08:31:42 UTC, Martin Nowak wrote:Many would like it to support pattern matching though. http://wiki.dlang.org/DIP32#Various_places_that_you_can_use_unpacking_and_pattern_matchingall of kenji's proposals are pretty much gold, has there ever been any work on reviewing/implementing this?
Jul 08 2015
On Wednesday, 8 July 2015 at 23:33:09 UTC, rsw0x wrote:On Wednesday, 8 July 2015 at 08:31:42 UTC, Martin Nowak wrote:The tuple syntax was implemented and never pulled. I don't know about pattern matching.Many would like it to support pattern matching though. http://wiki.dlang.org/DIP32#Various_places_that_you_can_use_unpacking_and_pattern_matchingall of kenji's proposals are pretty much gold, has there ever been any work on reviewing/implementing this?
Jul 08 2015
On Wed, 08 Jul 2015 23:33:07 +0000, rsw0x wrote:On Wednesday, 8 July 2015 at 08:31:42 UTC, Martin Nowak wrote: =20DIP32#Various_places_that_you_can_use_unpacking_and_pattern_matchingMany would like it to support pattern matching though. http://wiki.dlang.org/=20 all of kenji's proposals are pretty much gold, has there ever been any work on reviewing/implementing this?at least part of it was implemented by Kenji himsef, and then blocked due=20 to "this isn't a best solution, and if we'll adopt it, we will not able=20 to adopt an ideal solution when it will come". so far, the ideal solution=20 isn't here (and it's unlikely to arrive), and non-ideal is rejected.=20 double win!=
Jul 09 2015
On Thursday, 9 July 2015 at 12:38:11 UTC, ketmar wrote:at least part of it was implemented by Kenji himsef, and then blocked due to "this isn't a best solution, and if we'll adopt it, we will not able to adopt an ideal solution when it will come". so far, the ideal solution isn't here (and it's unlikely to arrive), and non-ideal is rejected. double win!I see this happen a lot, it's always what might be instead of what actually exists and someone was willing to produce.
Jul 09 2015
On 07/09/2015 02:54 PM, rsw0x wrote:On Thursday, 9 July 2015 at 12:38:11 UTC, ketmar wrote:I think most of the compiler source code for the ideal solution occurs in at least one of Kenji's rejected pull requests. AFAICS, it's mostly a matter of convincing the guy who wrote std.typecons.Tuple and the guy who does not want to break some (easily replaceable) usages of the comma operator and the identifier "_". :-)at least part of it was implemented by Kenji himsef, and then blocked due to "this isn't a best solution, and if we'll adopt it, we will not able to adopt an ideal solution when it will come". so far, the ideal solution isn't here (and it's unlikely to arrive), and non-ideal is rejected. double win!I see this happen a lot, it's always what might be instead of what actually exists andsomeone was willing to produce.Someone is often willing to produce awkward language quirks, so I think being critical of new additions has some value.
Jul 09 2015
On 07/09/2015 04:17 PM, Timon Gehr wrote:On 07/09/2015 02:54 PM, rsw0x wrote:E.g. "Note: Cannot swap values by tuple assignment. int x = 1, y = 2; {x, y} = {y, x}; // Lowered to: // x = y, y = x; assert(y == 2); assert(x == 2);" No, please.... someone was willing to produce.Someone is often willing to produce awkward language quirks, so I think being critical of new additions has some value.
Jul 09 2015
On Thursday, 9 July 2015 at 16:08:37 UTC, Timon Gehr wrote:On 07/09/2015 04:17 PM, Timon Gehr wrote:Couldn't this could be detected at compile-time and temporary variables created?On 07/09/2015 02:54 PM, rsw0x wrote:E.g. "Note: Cannot swap values by tuple assignment. int x = 1, y = 2; {x, y} = {y, x}; // Lowered to: // x = y, y = x; assert(y == 2); assert(x == 2);" No, please.... someone was willing to produce.Someone is often willing to produce awkward language quirks, so I think being critical of new additions has some value.
Jul 09 2015
On Thursday, 9 July 2015 at 22:50:37 UTC, Vlad Levenfeld wrote:On Thursday, 9 July 2015 at 16:08:37 UTC, Timon Gehr wrote:Yes, but there needs to be a complete aliasing analysis, e.g. int* x, y; // ... {*x, *y} = {*y, *x}; It's probably safer to create the temporaries by default and elide them when the elements are provably non-aliasing.On 07/09/2015 04:17 PM, Timon Gehr wrote:Couldn't this could be detected at compile-time and temporary variables created?On 07/09/2015 02:54 PM, rsw0x wrote:E.g. "Note: Cannot swap values by tuple assignment. int x = 1, y = 2; {x, y} = {y, x}; // Lowered to: // x = y, y = x; assert(y == 2); assert(x == 2);" No, please.... someone was willing to produce.Someone is often willing to produce awkward language quirks, so I think being critical of new additions has some value.
Jul 10 2015
On Friday, 10 July 2015 at 09:07:21 UTC, Marc Schütz wrote:On Thursday, 9 July 2015 at 22:50:37 UTC, Vlad Levenfeld wrote:Yeah true. I really wish we had this. I've got .tuple and TypeTuple and .expand proliferating throughout the code I write, and I've got a bunch of helper functions for converting between them.... it would be really awesome to get rid of that and unify everything with this DIP32.On Thursday, 9 July 2015 at 16:08:37 UTC, Timon Gehr wrote:Yes, but there needs to be a complete aliasing analysis, e.g. int* x, y; // ... {*x, *y} = {*y, *x}; It's probably safer to create the temporaries by default and elide them when the elements are provably non-aliasing.On 07/09/2015 04:17 PM, Timon Gehr wrote:Couldn't this could be detected at compile-time and temporary variables created?On 07/09/2015 02:54 PM, rsw0x wrote:E.g. "Note: Cannot swap values by tuple assignment. int x = 1, y = 2; {x, y} = {y, x}; // Lowered to: // x = y, y = x; assert(y == 2); assert(x == 2);" No, please.... someone was willing to produce.Someone is often willing to produce awkward language quirks, so I think being critical of new additions has some value.
Jul 10 2015
On 07/10/2015 12:50 AM, Vlad Levenfeld wrote:On Thursday, 9 July 2015 at 16:08:37 UTC, Timon Gehr wrote:Oh, it certainly is simple to fix, it's just that we don't want this sort of thing to make it into the language specification.On 07/09/2015 04:17 PM, Timon Gehr wrote:Couldn't this could be detected at compile-time and temporary variables created?On 07/09/2015 02:54 PM, rsw0x wrote:E.g. "Note: Cannot swap values by tuple assignment. int x = 1, y = 2; {x, y} = {y, x}; // Lowered to: // x = y, y = x; assert(y == 2); assert(x == 2);" No, please.... someone was willing to produce.Someone is often willing to produce awkward language quirks, so I think being critical of new additions has some value.
Jul 10 2015
On Friday, 10 July 2015 at 21:37:10 UTC, Timon Gehr wrote:On 07/10/2015 12:50 AM, Vlad Levenfeld wrote:Why not? Tuple handling seems like it should be a 1st class language feature... the disconnect between Tuple and TypeTuple always bothered me on a philosophical (and syntactic) level.On Thursday, 9 July 2015 at 16:08:37 UTC, Timon Gehr wrote:Oh, it certainly is simple to fix, it's just that we don't want this sort of thing to make it into the language specification.On 07/09/2015 04:17 PM, Timon Gehr wrote:Couldn't this could be detected at compile-time and temporary variables created?On 07/09/2015 02:54 PM, rsw0x wrote:E.g. "Note: Cannot swap values by tuple assignment. int x = 1, y = 2; {x, y} = {y, x}; // Lowered to: // x = y, y = x; assert(y == 2); assert(x == 2);" No, please.... someone was willing to produce.Someone is often willing to produce awkward language quirks, so I think being critical of new additions has some value.
Jul 10 2015
On 07/11/2015 12:50 AM, Vlad Levenfeld wrote:On Friday, 10 July 2015 at 21:37:10 UTC, Timon Gehr wrote:..? We don't want the /broken/ thing, which I cited, to make it into the language specification.On 07/10/2015 12:50 AM, Vlad Levenfeld wrote:Why not? Tuple handling seems like it should be a 1st class language feature... the disconnect between Tuple and TypeTuple always bothered me on a philosophical (and syntactic) level.On Thursday, 9 July 2015 at 16:08:37 UTC, Timon Gehr wrote:Oh, it certainly is simple to fix, it's just that we don't want this sort of thing to make it into the language specification.On 07/09/2015 04:17 PM, Timon Gehr wrote:Couldn't this could be detected at compile-time and temporary variables created?On 07/09/2015 02:54 PM, rsw0x wrote:E.g. "Note: Cannot swap values by tuple assignment. int x = 1, y = 2; {x, y} = {y, x}; // Lowered to: // x = y, y = x; assert(y == 2); assert(x == 2);" No, please.... someone was willing to produce.Someone is often willing to produce awkward language quirks, so I think being critical of new additions has some value.
Jul 10 2015
On Friday, 10 July 2015 at 22:58:44 UTC, Timon Gehr wrote:We don't want the /broken/ thing, which I cited, to make it into the language specification.Ok, I misunderstood. What's broken, if the temporaries are created (and elided following some compiler analysis)?
Jul 10 2015
On Wed, 08 Jul 2015 07:15:25 +0000, Yuxuan Shui wrote:I think it will be useful to extent switch statement to support any type that implements opEquals and opHash. =20 Is there any technical difficulties to implement this?no, you can do that* with some template programming. so there is no=20 reason to increase compiler complexity. * with some limitations, but they aren't that big.=
Jul 08 2015
On Wednesday, 8 July 2015 at 09:57:16 UTC, ketmar wrote:On Wed, 08 Jul 2015 07:15:25 +0000, Yuxuan Shui wrote:I think it will be useful to extent switch statement to support any type that implements opEquals and opHash. Is there any technical difficulties to implement this?no, you can do that* with some template programming. so there is no reason to increase compiler complexity. * with some limitations, but they aren't that big.
Jul 08 2015
On 07/08/2015 11:57 AM, ketmar wrote:On Wed, 08 Jul 2015 07:15:25 +0000, Yuxuan Shui wrote:The compiler complexity introduced by this change is trivial. This is completely self-contained.I think it will be useful to extent switch statement to support any type that implements opEquals and opHash. Is there any technical difficulties to implement this?no, you can do that* with some template programming. so there is no reason to increase compiler complexity. * with some limitations, but they aren't that big.
Jul 08 2015
On 07/08/2015 07:33 PM, Timon Gehr wrote:The compiler complexity introduced by this change is trivial.Except trivial doesn't mean it's cheap. Would probably take 1-2 days to fully spec/implement/optimize/test/document it. In that time I could finish a thread cache for the GC, or GC-less smart pointers, or finish dub watch, or reduce binary sizes, or finish OSX shared libraries, or join 10 more forum discussions.This is completely self-contained.But is it useful enough to spend the effort and extend the language?
Jul 08 2015
On 07/08/2015 11:32 PM, Martin Nowak wrote:On 07/08/2015 07:33 PM, Timon Gehr wrote:I just noted that increased compiler complexity is absolutely not a reason not to implement this.The compiler complexity introduced by this change is trivial.Except trivial doesn't mean it's cheap. Would probably take 1-2 days to fully spec/implement/optimize/test/document it. In that time I could finish a thread cache for the GC, or GC-less smart pointers, or finish dub watch, or reduce binary sizes, or finish OSX shared libraries, or join 10 more forum discussions.This is completely self-contained.But is it useful enough to spend the effort and extend the language?
Jul 09 2015