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 2017
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 2017
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 2017
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 

Import Idiom).
Jun 05 2017
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 

 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 2017
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 

 (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 2017
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 2017
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 

 New Import Idiom).


Seems like this crowd-editing stuff really works!
Jun 07 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017