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. :/

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.

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.

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

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

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!

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 ;))

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)