• Stefan Koch (19/19) Sep 05 2019 Hi Guys,
• Simen =?UTF-8?B?S2rDpnLDpXM=?= (5/25) Sep 05 2019 Always happy to see these updates - you're doing great and
• Bastiaan Veelo (3/5) Sep 05 2019 See?!! Just keep on churning :-)
• Dennis (4/7) Sep 05 2019 This reminds me of an article I once found, you might be
• Stefan Koch (5/13) Sep 05 2019 Thank you very much for sharing that link.
• Timon Gehr (3/17) Sep 05 2019 Another thing that works well is to just use the exception handling
• Stefan Koch (10/12) Sep 10 2019 The host language in this case is newCTFE-IR.
• Dominikus Dittes Scherkl (5/7) Sep 05 2019 ?!?
• Stefan Koch (9/18) Sep 05 2019 Well no, if you have CTFE code up the stack which catches the
• Dominikus Dittes Scherkl (4/10) Sep 05 2019 OMG. Do we really want a program to compile that throws and
• FeepingCreature (3/6) Sep 09 2019 Phobos...
• Jonathan M Davis (33/44) Sep 10 2019 And why should code that's run at compile time be any different from cod...
• rjframe (21/33) Sep 12 2019 If `a` calls `b` calls `c` at compile-time, `c` can throw something that...
• FeepingCreature (7/11) Sep 13 2019 I strongly disagree with this.
• Bert (6/43) Sep 13 2019 The problem is that a function that runs in ctfe can also be used
• Jacob Shtokolov (6/7) Sep 07 2019 Just wondering, would it make sense to start a new crowdfunding
• Stefan Koch (5/14) Sep 10 2019 I would certainly not antagonize this :)
• Wyatt (2/4) Sep 15 2019 How much would you need?
• Stefan Koch (4/9) Sep 15 2019 Depends on how much time I take off.
• Oleg B (4/4) Sep 12 2019 Great work!
• Stefan Koch (7/11) Sep 13 2019 It's possible but highly unlikely.

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.

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

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.

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

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.

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.

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.

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

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

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!

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

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

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

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.

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

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?

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.

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?

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.

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

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.