www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Compile-Time Sort in D

reply Mike Parker <aldacron gmail.com> writes:
The crowd-edited (?) blog post exploring some of D's compile-time 
features is now live. Thanks again to everyone who helped out 
with it.

The blog:
https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/

Reddit:
https://www.reddit.com/r/programming/comments/6fefdg/compiletime_sort_in_d/
Jun 05
next sibling parent reply Jon Degenhardt <jond noreply.com> writes:
On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote:
 The crowd-edited (?) blog post exploring some of D's 
 compile-time features is now live. Thanks again to everyone who 
 helped out with it.

 The blog:
 https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/

 Reddit:
 https://www.reddit.com/r/programming/comments/6fefdg/compiletime_sort_in_d/
Very nice post!
Jun 05
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/5/2017 10:54 AM, Jon Degenhardt wrote:
 On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote:
 The crowd-edited (?) blog post exploring some of D's compile-time features is 
 now live. Thanks again to everyone who helped out with it.

 The blog:
 https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/

 Reddit:
 https://www.reddit.com/r/programming/comments/6fefdg/compiletime_sort_in_d/
Very nice post!
It's also on Hacker News under "Compile-Time Sort in D".
Jun 05
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 5 June 2017 at 17:54:05 UTC, Jon Degenhardt wrote:

 Very nice post!
Thanks! If it gets half as many page views as yours did, I'll be happy. Yours is the most-viewed post on the blog -- over 1000 views more than #2 (my GC post), and 5,000 more than #3 (A New Import Idiom).
Jun 05
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Tuesday, 6 June 2017 at 01:08:45 UTC, Mike Parker wrote:
 On Monday, 5 June 2017 at 17:54:05 UTC, Jon Degenhardt wrote:

 Very nice post!
Thanks! If it gets half as many page views as yours did, I'll be happy. Yours is the most-viewed post on the blog -- over 1000 views more than #2 (my GC post), and 5,000 more than #3 (A New Import Idiom).
I was surprised it's so popular, as the proggit thread didn't do that great, but it did well on HN and I now see it inspired more posts for Rust (written by bearophile, I think) and Go, in addition to the Nim post linked here before: https://users.rust-lang.org/t/faster-command-line-tools-in-d-rust/10992 https://aadrake.com/posts/2017-05-29-faster-command-line-tools-with-go.html
Jun 07
parent reply Jon Degenhardt <jond noreply.com> writes:
On Wednesday, 7 June 2017 at 20:59:50 UTC, Joakim wrote:
 On Tuesday, 6 June 2017 at 01:08:45 UTC, Mike Parker wrote:
 On Monday, 5 June 2017 at 17:54:05 UTC, Jon Degenhardt wrote:

 Very nice post!
Thanks! If it gets half as many page views as yours did, I'll be happy. Yours is the most-viewed post on the blog -- over 1000 views more than #2 (my GC post), and 5,000 more than #3 (A New Import Idiom).
I was surprised it's so popular, as the proggit thread didn't do that great, but it did well on HN and I now see it inspired more posts for Rust (written by bearophile, I think) and Go, in addition to the Nim post linked here before: https://users.rust-lang.org/t/faster-command-line-tools-in-d-rust/10992 https://aadrake.com/posts/2017-05-29-faster-command-line-tools-with-go.html
I was surprised as well, pleasantly of course. Using a simple example may have helped. Personally, I'm not bothered by the specific instances of negative feedback on Reddit. It's hard to write a post that manages to avoid that sort of thing entirely. It was also nice to see related follow-up in the D forums ("how to count lines fast" and "std.csv Performance Review"). It's less if the case for how well suited D's facilities are for the type of problem came across. It's much more clear in the Compile-Time Sort post. --Jon
Jun 07
parent Jonathan M Davis via Digitalmars-d-announce writes:
On Thursday, June 08, 2017 01:08:42 Jon Degenhardt via Digitalmars-d-
announce wrote:
 I was surprised as well, pleasantly of course. Using a simple
 example may have helped. Personally, I'm not bothered by the
 specific instances of negative feedback on Reddit. It's hard to
 write a post that manages to avoid that sort of thing entirely.
 It was also nice to see related follow-up in the D forums ("how
 to count lines fast" and "std.csv Performance Review"). It's less
 if the case for how well suited D's facilities are for the type
 of problem came across. It's much more clear in the Compile-Time
 Sort post.
And even the reddit discussion on the compile-time sort post devolved a bit into arguments over stuff like enums as manifest constants. Using reddit to get information out there is useful, but from what I've seen, the comments usually devolve into a fairly negative discussion. I don't spend much time on reddit though. - Jonathan M Davis
Jun 07
prev sibling parent MysticZach <reachzach ggmail.com> writes:
On Tuesday, 6 June 2017 at 01:08:45 UTC, Mike Parker wrote:
 On Monday, 5 June 2017 at 17:54:05 UTC, Jon Degenhardt wrote:

 Very nice post!
Thanks! If it gets half as many page views as yours did, I'll be happy. Yours is the most-viewed post on the blog -- over 1000 views more than #2 (my GC post), and 5,000 more than #3 (A New Import Idiom).
Seems like this crowd-editing stuff really works!
Jun 07
prev sibling next sibling parent reply Seb <seb wilzba.ch> writes:
On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote:
 The crowd-edited (?) blog post exploring some of D's 
 compile-time features is now live. Thanks again to everyone who 
 helped out with it.

 The blog:
 https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/

 Reddit:
 https://www.reddit.com/r/programming/comments/6fefdg/compiletime_sort_in_d/
This is a great article, Mike! At the end I expected a reference to D's great template constraints [1], maybe it's still worth adding sth. like this to show how amazingly useful CTFE is? auto myRandomEngine(ulong m, ulong a, ulong c)(ulong seed) if (properLinearCongruentialParameters!(m, a, c)) { return seed; } void main() { static assert(!__traits(compiles, myRandomEngine!(1, 2, 3)(42))); myRandomEngine!(1UL << 32, 1664525, 1013904223)(42); } Or alternatively if you don't want to rewrite properLinearCongruentialParameters e.g. auto myRandomEngine(ulong m, ulong a, ulong c)(ulong seed) if (pLCP!(m, a, c)) { return seed; } template pLCP(ulong m, ulong a, ulong c) { enum pLCP = properLinearCongruentialParameters(m, a, c); } [1] https://dlang.org/spec/template.html#template_constraints
Jun 05
parent Mike Parker <aldacron gmail.com> writes:
On Monday, 5 June 2017 at 21:35:54 UTC, Seb wrote:
 This is a great article, Mike!
Thanks!
 At the end I expected a reference to D's great template 
 constraints [1], maybe it's still worth adding sth. like this 
 to show how amazingly useful CTFE is?
It's a good idea! I don't think I'll and change it at this point, though. When I was rewriting the last section, I considered showing two versions of a templated function -- one that uses the validator in a constraint and one that uses it at runtime -- but I worried that would add more noise. The msg pragma and the writeln kept the focus more narrow (which is something that kept coming up in feedback). And at that point, I was ready to be done with it. I worked on that post for a significant chunk of two days.
Jun 05
prev sibling next sibling parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote:
 The crowd-edited (?) blog post exploring some of D's 
 compile-time features is now live. Thanks again to everyone who 
 helped out with it.

 The blog:
 https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/

 Reddit:
 https://www.reddit.com/r/programming/comments/6fefdg/compiletime_sort_in_d/
Ah Reddit... The article about the elegance of CTFE. Let's discuss the meaning of "enum" then...
Jun 05
prev sibling next sibling parent Joakim <dlang joakim.fea.st> writes:
On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote:
 The crowd-edited (?) blog post exploring some of D's 
 compile-time features is now live. Thanks again to everyone who 
 helped out with it.

 The blog:
 https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/

 Reddit:
 https://www.reddit.com/r/programming/comments/6fefdg/compiletime_sort_in_d/
Nice work, the reddit likes keep going up. Nothing new for D users, but by encapsulating CTFE in a bite-sized blog post, you've gotten some outsiders to pay attention. Just read perhaps the most ringing endorsement I've ever seen for D in the comments: "How do you explain that in D complex metaprogramming artifacts such as bitfields, regex engines, compile-time parser generators, checked integers, generic allocators, are readily available from a smaller community, when in C++ you need an article explaining what tricks to use to sort a list of integers at compile time?" https://www.reddit.com/r/programming/comments/6fefdg/comment/dijct48
Jun 06
prev sibling parent reply John Carter <john.carter taitradio.com> writes:
On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote:
 https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/
Seems like you have inspired people... http://blog.zdsmith.com/posts/compiletime-sort-in-nim.html
Jun 07
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 7 June 2017 at 21:47:58 UTC, John Carter wrote:
 On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote:
 https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/
Seems like you have inspired people... http://blog.zdsmith.com/posts/compiletime-sort-in-nim.html
We should make another post showing the string import feature.
Jun 07
prev sibling next sibling parent reply cym13 <cpicard openmailbox.org> writes:
On Wednesday, 7 June 2017 at 21:47:58 UTC, John Carter wrote:
 On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote:
 https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/
Seems like you have inspired people... http://blog.zdsmith.com/posts/compiletime-sort-in-nim.html
Seeing that the one and only D example in the nim article is a broken one (using static instead of enum or static immutable for 'b') we should have started with a correct example before showing the broken one... Good to know for next time.
Jun 08
next sibling parent ag0aep6g <anonymous example.com> writes:
On 06/08/2017 09:07 PM, cym13 wrote:
 Seeing that the one and only D example in the nim article is a broken 
 one (using static instead of enum or static immutable for 'b') we should 
 have started with a correct example before showing the broken one... 
 Good to know for next time.
Broken? It works just fine.
Jun 08
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 8 June 2017 at 19:07:50 UTC, cym13 wrote:

 Seeing that the one and only D example in the nim article is a 
 broken one (using static instead of enum or static immutable 
 for 'b') we should have started with a correct example before 
 showing the broken one... Good to know for next time.
static variables are initialized with compile-time values. They don't need be immutable for that.
Jun 08
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 9 June 2017 at 01:34:14 UTC, Mike Parker wrote:
 On Thursday, 8 June 2017 at 19:07:50 UTC, cym13 wrote:

 Seeing that the one and only D example in the nim article is a 
 broken one (using static instead of enum or static immutable 
 for 'b') we should have started with a correct example before 
 showing the broken one... Good to know for next time.
static variables are initialized with compile-time values. They don't need be immutable for that.
they need immutable if you want to use them again at compile-time. Therefore it is a good habit to get into.
Jun 08
prev sibling parent Cym13 <cpicard openmailbox.org> writes:
On Friday, 9 June 2017 at 01:34:14 UTC, Mike Parker wrote:
 On Thursday, 8 June 2017 at 19:07:50 UTC, cym13 wrote:

 Seeing that the one and only D example in the nim article is a 
 broken one (using static instead of enum or static immutable 
 for 'b') we should have started with a correct example before 
 showing the broken one... Good to know for next time.
static variables are initialized with compile-time values. They don't need be immutable for that.
My bad, I miscopied the code.
Jun 09
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/7/17 5:47 PM, John Carter wrote:
 On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote:
 https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/
Seems like you have inspired people... http://blog.zdsmith.com/posts/compiletime-sort-in-nim.html
That is kind of neat. While I can say that D can perform technically the same feat via pragma(msg, ...) and importing a file directly (would leave a comment on the blog, but there isn't a spot for it), the fact that you can execute arbitrary code in a block at compile time that can use the *actual* i/o routines you would use at runtime is pretty impressive. Stefan would have a field day with this power :) -Steve
Jun 09
next sibling parent Adrian Matoga <dlang.spam matoga.info> writes:
On Friday, 9 June 2017 at 12:15:50 UTC, Steven Schveighoffer 
wrote:
 On 6/7/17 5:47 PM, John Carter wrote:
 On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote:
 https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/
Seems like you have inspired people... http://blog.zdsmith.com/posts/compiletime-sort-in-nim.html
That is kind of neat. While I can say that D can perform technically the same feat via pragma(msg, ...) and importing a file directly (would leave a comment on the blog, but there isn't a spot for it), the fact that you can execute arbitrary code in a block at compile time that can use the *actual* i/o routines you would use at runtime is pretty impressive. Stefan would have a field day with this power :)
Yeah, it feels C++'y when you need to leave CTFE if you want to print some value computed in CTFE or use it as a name of file to load. :/
Jun 09
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 9 June 2017 at 12:15:50 UTC, Steven Schveighoffer 
wrote:
 Stefan would have a field day with this power :)
I think he would certainly appreciate an improved ability to debug CTFE code.
Jun 09
prev sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 9 June 2017 at 12:15:50 UTC, Steven Schveighoffer 
wrote:
  [it] can use the *actual* i/o routines [at compile-time] you 
 would use at runtime is pretty impressive.

 Stefan would have a field day with this power :)

 -Steve
Infact I think this would scale pretty badly. I do not want to debug some ctfe which loads dlls and does god what to the environment. Even the restricted form of ctfe D supports is pretty hard to get right. If I'd had to worry about an interface to runtime code I'd be a little unhappy.
Jun 09
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/9/17 10:49 AM, Stefan Koch wrote:
 On Friday, 9 June 2017 at 12:15:50 UTC, Steven Schveighoffer wrote:
  [it] can use the *actual* i/o routines [at compile-time] you would
 use at runtime is pretty impressive.

 Stefan would have a field day with this power :)
Infact I think this would scale pretty badly. I do not want to debug some ctfe which loads dlls and does god what to the environment. Even the restricted form of ctfe D supports is pretty hard to get right. If I'd had to worry about an interface to runtime code I'd be a little unhappy.
I kind of remember you saying at dconf2016 "If only CTFE could write to the filesystem, I could fully support sqlite at compile time!" or something like that. At least in terms of i/o printing to the console or whatnot, it would be cool to be able to do so at compile-time just directly with writeln. As of now, a CTFE function can't call writeln, and it also can't pragma(msg, ...) because it has to be written as a runtime function. -Steve
Jun 09
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Steven Schveighoffer wrote:

 At least in terms of i/o printing to the console or whatnot, it would be 
 cool to be able to do so at compile-time just directly with writeln. As 
 of now, a CTFE function can't call writeln, and it also can't pragma(msg, 
 ...) because it has to be written as a runtime function.
yeah, `ctfeWriteln()`, even in very rudimentary form, will be priceless for debugging CTFE code. sure, CTFE code can be called in runtime and debugged, but sometimes it require alot of bouncing back and forth, like "let's replace all `enum` values with `auto` down the code, and then back", 'cause result of one CTFE call may be used in another CTFE call, and so on...
Jun 09
parent reply "H. S. Teoh via Digitalmars-d-announce" writes:
On Fri, Jun 09, 2017 at 06:30:54PM +0300, ketmar via Digitalmars-d-announce
wrote:
 Steven Schveighoffer wrote:
 
 At least in terms of i/o printing to the console or whatnot, it
 would be cool to be able to do so at compile-time just directly with
 writeln. As of now, a CTFE function can't call writeln, and it also
 can't pragma(msg, ...) because it has to be written as a runtime
 function.
yeah, `ctfeWriteln()`, even in very rudimentary form, will be priceless for debugging CTFE code. sure, CTFE code can be called in runtime and debugged, but sometimes it require alot of bouncing back and forth, like "let's replace all `enum` values with `auto` down the code, and then back", 'cause result of one CTFE call may be used in another CTFE call, and so on...
Yes, please add ctfeWriteln(). While D's CTFE capabilities are quite impressive even with today's CTFE engine, and I'm sure it will be even more awesome with Stefan's new CTFE engine, when things go wrong it's very hard to debug. Ironically enough, sometimes I find myself having to call the CTFE function at runtime and debug that instead, before turning it back to a compile-time call. Having ctfeWriteln() would be a big help in making CTFE code easier to debug. (Of course, there's also the CTFE debugger that Stefan alluded to recently... while that would be even more awesome, I think ctfeWriteln is easier to implement, so it's more likely to materialize in the near future. :-P) T -- That's not a bug; that's a feature!
Jun 09
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 9 June 2017 at 16:50:15 UTC, H. S. Teoh wrote:
 Yes, please add ctfeWriteln().
ctfeWriteln has it's own set of problems. I resurrected a PR for it a while back. And somewhere along the lines it broke again. newCTFE's debugging facilities which will come later this year, will provide a much better alternative. (though the debugging facilities will only be available using the slow bytecode backend)
Jun 09
prev sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 9 June 2017 at 15:16:56 UTC, Steven Schveighoffer 
wrote:
 On 6/9/17 10:49 AM, Stefan Koch wrote:
 If I'd had to worry about an interface to runtime code I'd be 
 a little
 unhappy.
I kind of remember you saying at dconf2016 "If only CTFE could write to the filesystem, I could fully support sqlite at compile time!" or something like that.
It's amazing how modest your feature requests become once you have to implement them yourself ;))
Jun 09