www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - newCTFE Status September 2019

reply Stefan Koch <uplink.coder googlemail.com> writes:
Hi Guys,

The issues with closures seem to be resolved.
It turns out it was not an issue with the closure handling but it 
failed for non-explicitly initialized structs.

While running my tests I discovered that I forgot to implement 
exception-handling :-/.
That's why I am currently working on implementing it.

Since personally I do _try_ to avoid Exceptions.
I do not have a good mental model of them.
Therefore Implementing them might take a while until it's correct.

Currently I am trying to model a thrown Exception with a 
specially flagged return value, which will go up into the 
catch-clause-stack instead, of being returned to the caller.

The implementation is work in progress, so there are no 
experimental results yet.
If anyone sees a flaw in this model, please alert me to it.

Cheers,

Stefan

P.S. your support is always appreciated.
Sep 05
next sibling parent Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Thursday, 5 September 2019 at 07:33:21 UTC, Stefan Koch wrote:
 Hi Guys,

 The issues with closures seem to be resolved.
 It turns out it was not an issue with the closure handling but 
 it failed for non-explicitly initialized structs.

 While running my tests I discovered that I forgot to implement 
 exception-handling :-/.
 That's why I am currently working on implementing it.

 Since personally I do _try_ to avoid Exceptions.
 I do not have a good mental model of them.
 Therefore Implementing them might take a while until it's 
 correct.

 Currently I am trying to model a thrown Exception with a 
 specially flagged return value, which will go up into the 
 catch-clause-stack instead, of being returned to the caller.

 The implementation is work in progress, so there are no 
 experimental results yet.
 If anyone sees a flaw in this model, please alert me to it.

 Cheers,

 Stefan

 P.S. your support is always appreciated.
Always happy to see these updates - you're doing great and important work! :) -- Simen
Sep 05
prev sibling next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Thursday, 5 September 2019 at 07:33:21 UTC, Stefan Koch wrote:
 Hi Guys,

 The issues with closures seem to be resolved.
See?!! Just keep on churning :-) Bastiaan.
Sep 05
prev sibling next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Thursday, 5 September 2019 at 07:33:21 UTC, Stefan Koch wrote:
 Currently I am trying to model a thrown Exception with a 
 specially flagged return value, which will go up into the 
 catch-clause-stack instead, of being returned to the caller.
This reminds me of an article I once found, you might be interested in it: https://nim-lang.org/araq/quirky_exceptions.html
Sep 05
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 5 September 2019 at 09:32:38 UTC, Dennis wrote:
 On Thursday, 5 September 2019 at 07:33:21 UTC, Stefan Koch 
 wrote:
 Currently I am trying to model a thrown Exception with a 
 specially flagged return value, which will go up into the 
 catch-clause-stack instead, of being returned to the caller.
This reminds me of an article I once found, you might be interested in it: https://nim-lang.org/araq/quirky_exceptions.html
Thank you very much for sharing that link. Their approach is better than what I had originally since, that way catch-blocks can be created after the Call. and there is no need to build closures.
Sep 05
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05.09.19 12:15, Stefan Koch wrote:
 On Thursday, 5 September 2019 at 09:32:38 UTC, Dennis wrote:
 On Thursday, 5 September 2019 at 07:33:21 UTC, Stefan Koch wrote:
 Currently I am trying to model a thrown Exception with a specially 
 flagged return value, which will go up into the catch-clause-stack 
 instead, of being returned to the caller.
This reminds me of an article I once found, you might be interested in it: https://nim-lang.org/araq/quirky_exceptions.html
Thank you very much for sharing that link. Their approach is better than what I had originally since, that way catch-blocks can be created after the Call. and there is no need to build closures.
Another thing that works well is to just use the exception handling mechanism of the host language.
Sep 05
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 5 September 2019 at 21:19:07 UTC, Timon Gehr wrote:
 Another thing that works well is to just use the exception 
 handling mechanism of the host language.
The host language in this case is newCTFE-IR. And that is intentionally quite close to what a simple RISC processor would provide. As it is supposed to be just-in-time compile-able with minimal overhead. Therefore it does not provide exception handling support, and likely never will. Since that would mean every backend would have to provide a way to stack catch-clauses and such.
Sep 10
prev sibling next sibling parent reply Dominikus Dittes Scherkl <dominikus.scherkl continental-corporation.com> writes:
On Thursday, 5 September 2019 at 07:33:21 UTC, Stefan Koch wrote:
 While running my tests I discovered that I forgot to implement 
 exception-handling :-/.
?!? Shouldn't an exception thrown during CTFE simply put out it's message as compilation error and stop there? - Otherwise the result can only be some bogous binary that's completely useless...
Sep 05
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 5 September 2019 at 10:17:53 UTC, Dominikus Dittes 
Scherkl wrote:
 On Thursday, 5 September 2019 at 07:33:21 UTC, Stefan Koch 
 wrote:
 While running my tests I discovered that I forgot to implement 
 exception-handling :-/.
?!? Shouldn't an exception thrown during CTFE simply put out it's message as compilation error and stop there? - Otherwise the result can only be some bogous binary that's completely useless...
Well no, if you have CTFE code up the stack which catches the Exception then it's fine. It's only a problem if the Exception would escape out of the ctfe-entry-point. Therefore I do have to provide the means for Exceptions to be thrown and caught within ctfe. Life is though sometimes :)
Sep 05
parent reply Dominikus Dittes Scherkl <dominikus.scherkl continental-corporation.com> writes:
On Thursday, 5 September 2019 at 10:23:18 UTC, Stefan Koch wrote:
 Well no, if you have CTFE code up the stack which catches the 
 Exception then it's fine.
 It's only a problem if the Exception would escape out of the 
 ctfe-entry-point.

 Therefore I do have to provide the means for Exceptions to be 
 thrown and caught within ctfe.
OMG. Do we really want a program to compile that throws and catches exceptions _during compilation_? Who programs such crappy shit should suffer worse than a simple compile error!
Sep 05
next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
On Thursday, 5 September 2019 at 10:55:30 UTC, Dominikus Dittes 
Scherkl wrote:
 OMG. Do we really want a program to compile that throws and 
 catches exceptions _during compilation_? Who programs such 
 crappy shit should suffer worse than a simple compile error!
Phobos...
Sep 09
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, September 5, 2019 4:55:30 AM MDT Dominikus Dittes Scherkl via 
Digitalmars-d wrote:
 On Thursday, 5 September 2019 at 10:23:18 UTC, Stefan Koch wrote:
 Well no, if you have CTFE code up the stack which catches the
 Exception then it's fine.
 It's only a problem if the Exception would escape out of the
 ctfe-entry-point.

 Therefore I do have to provide the means for Exceptions to be
 thrown and caught within ctfe.
OMG. Do we really want a program to compile that throws and catches exceptions _during compilation_? Who programs such crappy shit should suffer worse than a simple compile error!
And why should code that's run at compile time be any different from code that's run at runtime with regards to the ability to handle exceptions - especially when CTFE supports a large portion of the language and allows for arbitrarily complex code? The only major differences are that some things can't be done during CTFE that can be done during runtime, and most CTFE is operating on known input. Yes, ideally, you wouldn't be getting any exceptions with known input, but if the code is sufficiently complex, it wouldn't necessarily be easy to know that exceptions were involved if the code handled them, and it could be extremely annoying for such code to fail at compile time when it would succeed at runtime - especially if you're calling code that you have no control over. Also, it _is_ possible to have input at compile time which is not known ahead of time and which can vary between compilation runs. By using string imports, it's possible to have your program operating on arbitrary input at compile time just like you'd get at runtime, and not being able to have exceptions function normally under such circumstances could be crippling. I definitely agree that the vast majority of CTFE code should not involve exceptions at all, because the vast majority of it operates on known inputs, and most of it is simple enough that you can easily avoid having exceptions be involved, but just because most CTFE code shouldn't be doing anything with exceptions doesn't mean that _no_ CTFE code should be doing anything with exceptions. Ideally, it would be possible to do everything at compile time that you can do at runtime. That's not currently possible, and it will likely never be possible, but disallowing a feature that we can make work is just needlessly restricting what we can do. Also, it's currently possible with CTFE today to throw and catch exceptions. So, if newCTFE can't handle it, then it won't be able to do as much as CTFE can currently do, which means that without falling back to the current CTFE in such a case, newCTFE would not be a viable replacement for the current CTFE engine. - Jonathan M Davis
Sep 10
prev sibling parent reply rjframe <dlang ryanjframe.com> writes:
On Thu, 05 Sep 2019 10:55:30 +0000, Dominikus Dittes Scherkl wrote:

 On Thursday, 5 September 2019 at 10:23:18 UTC, Stefan Koch wrote:
 Well no, if you have CTFE code up the stack which catches the Exception
 then it's fine.
 It's only a problem if the Exception would escape out of the
 ctfe-entry-point.

 Therefore I do have to provide the means for Exceptions to be thrown
 and caught within ctfe.
OMG. Do we really want a program to compile that throws and catches exceptions _during compilation_? Who programs such crappy shit should suffer worse than a simple compile error!
If `a` calls `b` calls `c` at compile-time, `c` can throw something that `a` can catch, interpret, and rethrow with a more meaningful message/ context. I'd argue that it is bad practice to have a thrown Exception at CT that doesn't result in a failed compilation; compile-time exceptions should be treated by the programmer like failed assertions - something has gone wrong that needs to be fixed before deployment. It is possible though: --- int fail() { throw new Exception("error"); } int func() { try { return fail(); } catch (Exception) {} return 0; } enum a = func(); void main() {} --- --Ryan
Sep 12
next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
On Thursday, 12 September 2019 at 11:57:35 UTC, rjframe wrote:
 I'd argue that it is bad practice to have a thrown Exception at 
 CT that doesn't result in a failed compilation; compile-time 
 exceptions should be treated by the programmer like failed 
 assertions
I strongly disagree with this. CTFE is explicitly not supposed to be a separate universe with its own standards of behavior; it's supposed to just be "functions, executed at compiletime". Crucially, the *same* functions as at runtime, hence opening up the use of Phobos. Phobos, which silently throws and catches exceptions internally.
Sep 13
prev sibling parent Bert <Bert gmail.com> writes:
On Thursday, 12 September 2019 at 11:57:35 UTC, rjframe wrote:
 On Thu, 05 Sep 2019 10:55:30 +0000, Dominikus Dittes Scherkl 
 wrote:

 On Thursday, 5 September 2019 at 10:23:18 UTC, Stefan Koch 
 wrote:
 Well no, if you have CTFE code up the stack which catches the 
 Exception
 then it's fine.
 It's only a problem if the Exception would escape out of the
 ctfe-entry-point.

 Therefore I do have to provide the means for Exceptions to be 
 thrown and caught within ctfe.
OMG. Do we really want a program to compile that throws and catches exceptions _during compilation_? Who programs such crappy shit should suffer worse than a simple compile error!
If `a` calls `b` calls `c` at compile-time, `c` can throw something that `a` can catch, interpret, and rethrow with a more meaningful message/ context. I'd argue that it is bad practice to have a thrown Exception at CT that doesn't result in a failed compilation; compile-time exceptions should be treated by the programmer like failed assertions - something has gone wrong that needs to be fixed before deployment. It is possible though: --- int fail() { throw new Exception("error"); } int func() { try { return fail(); } catch (Exception) {} return 0; } enum a = func(); void main() {} --- --Ryan
The problem is that a function that runs in ctfe can also be used to run at run time... the code at runtime might be designed to use exceptions and then your arbitrary limitation for simplicity will break ctfe code and then ctfe won't be just like rt any more. This will then require hacks to get things to work out...
Sep 13
prev sibling next sibling parent reply Jacob Shtokolov <jacob.100205 gmail.com> writes:
On Thursday, 5 September 2019 at 07:33:21 UTC, Stefan Koch wrote:
 P.S. your support is always appreciated.
Just wondering, would it make sense to start a new crowdfunding campaign dedicated to newCTFE? I think this is quite an important feature for the compiler. I would donate. Previously we had campaigns for Code-D VSCode extension and D Lang forums server. Why don't make it again for this amazing work?
Sep 07
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 7 September 2019 at 10:17:41 UTC, Jacob Shtokolov 
wrote:
 On Thursday, 5 September 2019 at 07:33:21 UTC, Stefan Koch 
 wrote:
 P.S. your support is always appreciated.
Just wondering, would it make sense to start a new crowdfunding campaign dedicated to newCTFE? I think this is quite an important feature for the compiler. I would donate. Previously we had campaigns for Code-D VSCode extension and D Lang forums server. Why don't make it again for this amazing work?
I would certainly not antagonize this :) With a bit of funding I'd be able to take time off work, And give newCTFE the last push and polish it needs.
Sep 10
parent reply Wyatt <wyatt.epp gmail.com> writes:
On Tuesday, 10 September 2019 at 11:53:28 UTC, Stefan Koch wrote:
 With a bit of funding I'd be able to take time off work,
 And give newCTFE the last push and polish it needs.
How much would you need?
Sep 15
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Sunday, 15 September 2019 at 12:00:27 UTC, Wyatt wrote:
 On Tuesday, 10 September 2019 at 11:53:28 UTC, Stefan Koch 
 wrote:
 With a bit of funding I'd be able to take time off work,
 And give newCTFE the last push and polish it needs.
How much would you need?
Depends on how much time I take off. If I life cheaply for a while 1200 eur would buy me a month, to dedicate to newCTFE.
Sep 15
prev sibling parent reply Oleg B <code.viator gmail.com> writes:
Great work!

Will newCTFE able to work in -betterC mode? By now CTFE engine 
have some limitations at this point: 
https://forum.dlang.org/thread/djmdhhcuwaroznpkfjis forum.dlang.org?page=1
Sep 12
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 12 September 2019 at 20:25:12 UTC, Oleg B wrote:
 Great work!

 Will newCTFE able to work in -betterC mode? By now CTFE engine 
 have some limitations at this point: 
 https://forum.dlang.org/thread/djmdhhcuwaroznpkfjis forum.dlang.org?page=1
It's possible but highly unlikely. BetterC throws the error when the function goes through SemA (semantic analysis) before ctfe can get to evaluating the functions. Changing that would require a special pre-codegen pass And would be a really invasive change.
Sep 13