www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Sorting in D Blog Post Review Request

reply Mike Parker <aldacron gmail.com> writes:
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
next sibling parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
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/c674888dea1e0ead0c6a8fd28b0333d3
Added a couple of comments.
Jun 04
prev sibling next sibling parent Joakim <dlang joakim.fea.st> writes:
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/c674888dea1e0ead0c6a8fd28b0333d3
I 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
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
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
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
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:
 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!
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
parent Joakim <dlang joakim.fea.st> writes:
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:
 [...]
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.
Oh, I'd actually show the source for our quicksort too, to emphasize how different it is from theirs.
Jun 04
prev sibling next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 06/04/2017 06:07 PM, Mike Parker wrote:
 https://gist.github.com/mdparker/51599471b5f19fe05ff01ca95b34d453
From 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
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sunday, June 04, 2017 19:16:09 ag0aep6g via Digitalmars-d wrote:
 On 06/04/2017 06:07 PM, Mike Parker wrote:
 https://gist.github.com/mdparker/51599471b5f19fe05ff01ca95b34d453
From 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.
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 Davis
Jun 04
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
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
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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
parent Mike Parker <aldacron gmail.com> writes:
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:
 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.
That's a stale copy now, but thanks anyway :-)
Jun 05
prev sibling parent WhatMeWorry <kheaser gmail.com> writes:
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/c674888dea1e0ead0c6a8fd28b0333d3
Just 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