digitalmars.D - Sorting in D Blog Post Review Request
- Mike Parker (13/13) Jun 04 2017 As a result of the ongoing thread, 'C++17 cannot beat D surely'
- Stanislav Blinov (2/6) Jun 04 2017 Added a couple of comments.
- Joakim (10/23) Jun 04 2017 I don't think this is a good response to the original post,
- Mike Parker (10/11) Jun 04 2017 So I took the feedback I've gotten so far, stepped away and
- Joakim (6/19) Jun 04 2017 Much better, a standard overview of CTFE, but that's better for a
- Joakim (3/10) Jun 04 2017 Oh, I'd actually show the source for our quicksort too, to
- ag0aep6g (9/10) Jun 04 2017 From there: "What it boils down to is this: if a function *can* be
- Jonathan M Davis via Digitalmars-d (7/17) Jun 04 2017 Yeah, the compiler doesn't care at all about whether a function can be
- Mike Parker (4/13) Jun 05 2017 Thanks to everyone who provided feedback here and elsewhere. I've
- Vladimir Panteleev (3/6) Jun 05 2017 Sorry for the late feedback (only saw this recently), but I left
- Mike Parker (2/8) Jun 05 2017 That's a stale copy now, but thanks anyway :-)
- WhatMeWorry (5/18) Jun 04 2017 Just a minor typo: writeln(b); should be // [1, 2, 3]
As a result of the ongoing thread, 'C++17 cannot beat D surely' [1], I've slapped together a blog post about it all. A post about CTFE sort in D by itself would be rather short. So I also wrote about two points of the confusion (one of which was my own) that arose in the thread. I'd like to publish it tomorrow (Monday), so I've put the draft in a gist [2] and I'm looking to get anyone who's willing to read it and let me know here if I've made any errors. Thanks in advance. [1] http://forum.dlang.org/post/bhdehyzrlfklfkxicpea forum.dlang.org [2] https://gist.github.com/mdparker/c674888dea1e0ead0c6a8fd28b0333d3
Jun 04 2017
On Sunday, 4 June 2017 at 08:34:23 UTC, Mike Parker wrote:I'd like to publish it tomorrow (Monday), so I've put the draft in a gist [2] and I'm looking to get anyone who's willing to read it and let me know here if I've made any errors.https://gist.github.com/mdparker/c674888dea1e0ead0c6a8fd28b0333d3Added a couple of comments.
Jun 04 2017
On Sunday, 4 June 2017 at 08:34:23 UTC, Mike Parker wrote:As a result of the ongoing thread, 'C++17 cannot beat D surely' [1], I've slapped together a blog post about it all. A post about CTFE sort in D by itself would be rather short. So I also wrote about two points of the confusion (one of which was my own) that arose in the thread. I'd like to publish it tomorrow (Monday), so I've put the draft in a gist [2] and I'm looking to get anyone who's willing to read it and let me know here if I've made any errors. Thanks in advance. [1] http://forum.dlang.org/post/bhdehyzrlfklfkxicpea forum.dlang.org [2] https://gist.github.com/mdparker/c674888dea1e0ead0c6a8fd28b0333d3I don't think this is a good response to the original post, diving into a bunch of arcana about initialization and allocation rather than showing how simple D's compile-time sort is. It'd be better to just have a nuts and bolts post showing how the _same_ code can be done much easier in D, including actually showing D's quicksort and maybe mentioning __ctfe, then show how easy it is to do something much more advanced in D, like Teoh said. This post goes off on a couple tangents, maybe it could be a follow-up blog post after one addressing the original C++ post.
Jun 04 2017
On Sunday, 4 June 2017 at 08:34:23 UTC, Mike Parker wrote:I've slapped together a blog post about it all.So I took the feedback I've gotten so far, stepped away and thought about it for a bit, and agreed that I was taking the wrong approach. So I've given it a rewrite. The original gist is still there, but the new one is here: https://gist.github.com/mdparker/51599471b5f19fe05ff01ca95b34d453 I'm open to any changes or additions anyone would like to make. That includes rewriting large portions of it (or all of it, if anyone is up for it). Destroy!
Jun 04 2017
On Sunday, 4 June 2017 at 16:07:35 UTC, Mike Parker wrote:On Sunday, 4 June 2017 at 08:34:23 UTC, Mike Parker wrote:Much better, a standard overview of CTFE, but that's better for a general audience. I'd leave out the bit about allocation altogether, a technical detail that depends on the compiler and could just be fixed someday. Stick that in your GC blog post later on, and refer back to this post then.I've slapped together a blog post about it all.So I took the feedback I've gotten so far, stepped away and thought about it for a bit, and agreed that I was taking the wrong approach. So I've given it a rewrite. The original gist is still there, but the new one is here: https://gist.github.com/mdparker/51599471b5f19fe05ff01ca95b34d453 I'm open to any changes or additions anyone would like to make. That includes rewriting large portions of it (or all of it, if anyone is up for it). Destroy!
Jun 04 2017
On Sunday, 4 June 2017 at 16:48:11 UTC, Joakim wrote:On Sunday, 4 June 2017 at 16:07:35 UTC, Mike Parker wrote:Oh, I'd actually show the source for our quicksort too, to emphasize how different it is from theirs.[...]Much better, a standard overview of CTFE, but that's better for a general audience. I'd leave out the bit about allocation altogether, a technical detail that depends on the compiler and could just be fixed someday. Stick that in your GC blog post later on, and refer back to this post then.
Jun 04 2017
On 06/04/2017 06:07 PM, Mike Parker wrote:https://gist.github.com/mdparker/51599471b5f19fe05ff01ca95b34d453From there: "What it boils down to is this: if a function *can* be executed at compile time, it *will* be." I think that gives the wrong impression. We regularly have newcomers in D.learn who expect CTFE to happen where it doesn't. They have a function call with all compile-time constants, and they expect it to be handled by CTFE. They think that the call *can* be evaluated at compile time, so it *will* be. But that's not how it works. CTFE only kicks in when the destination *requires* a compile-time constant.
Jun 04 2017
On Sunday, June 04, 2017 19:16:09 ag0aep6g via Digitalmars-d wrote:On 06/04/2017 06:07 PM, Mike Parker wrote:Yeah, the compiler doesn't care at all about whether a function can be called during CTFE until it actually attempts it, and it's only going to attempt it in a context where the result _must_ be known at compile-time, whereas that line implies that the compiler calls functions at compile-time whenever it can, which would have a _very_ different effect. - Jonathan M Davishttps://gist.github.com/mdparker/51599471b5f19fe05ff01ca95b34d453From there: "What it boils down to is this: if a function *can* be executed at compile time, it *will* be." I think that gives the wrong impression. We regularly have newcomers in D.learn who expect CTFE to happen where it doesn't. They have a function call with all compile-time constants, and they expect it to be handled by CTFE. They think that the call *can* be evaluated at compile time, so it *will* be. But that's not how it works. CTFE only kicks in when the destination *requires* a compile-time constant.
Jun 04 2017
On Sunday, 4 June 2017 at 16:07:35 UTC, Mike Parker wrote:So I took the feedback I've gotten so far, stepped away and thought about it for a bit, and agreed that I was taking the wrong approach. So I've given it a rewrite. The original gist is still there, but the new one is here: https://gist.github.com/mdparker/51599471b5f19fe05ff01ca95b34d453 I'm open to any changes or additions anyone would like to make. That includes rewriting large portions of it (or all of it, if anyone is up for it). Destroy!Thanks to everyone who provided feedback here and elsewhere. I've incorporated much of it and that has resulted in a much better post. I'll be publishing it in a ~ 3 hours or so.
Jun 05 2017
On Monday, 5 June 2017 at 11:01:49 UTC, Mike Parker wrote:Thanks to everyone who provided feedback here and elsewhere. I've incorporated much of it and that has resulted in a much better post. I'll be publishing it in a ~ 3 hours or so.Sorry for the late feedback (only saw this recently), but I left some comments on the gist.
Jun 05 2017
On Monday, 5 June 2017 at 14:19:38 UTC, Vladimir Panteleev wrote:On Monday, 5 June 2017 at 11:01:49 UTC, Mike Parker wrote:That's a stale copy now, but thanks anyway :-)Thanks to everyone who provided feedback here and elsewhere. I've incorporated much of it and that has resulted in a much better post. I'll be publishing it in a ~ 3 hours or so.Sorry for the late feedback (only saw this recently), but I left some comments on the gist.
Jun 05 2017
On Sunday, 4 June 2017 at 08:34:23 UTC, Mike Parker wrote:As a result of the ongoing thread, 'C++17 cannot beat D surely' [1], I've slapped together a blog post about it all. A post about CTFE sort in D by itself would be rather short. So I also wrote about two points of the confusion (one of which was my own) that arose in the thread. I'd like to publish it tomorrow (Monday), so I've put the draft in a gist [2] and I'm looking to get anyone who's willing to read it and let me know here if I've made any errors. Thanks in advance. [1] http://forum.dlang.org/post/bhdehyzrlfklfkxicpea forum.dlang.org [2] https://gist.github.com/mdparker/c674888dea1e0ead0c6a8fd28b0333d3Just a minor typo: writeln(b); should be // [1, 2, 3] enum int[] a = [ 3, 1, 2 ]; static b = sort(a); writeln(b); // [0, 1, 2, 3, 4]
Jun 04 2017