On 03/27/2013 06:20 PM, H. S. Teoh wrote:
> On Wed, Mar 27, 2013 at 05:55:54PM +0100, Timon Gehr wrote:
> [...]
>> If CTFE does not terminate, compilation is not allowed to succeed.
>
> Heh, I think this one is unimplementable, as it amounts to solving the
> halting problem. :)
> ...

Actually it does not. Non-success denotes either failure or non-termination.

On Wed, Mar 27, 2013 at 06:29:59PM +0100, Timon Gehr wrote:
> On 03/27/2013 06:20 PM, H. S. Teoh wrote:
> >On Wed, Mar 27, 2013 at 05:55:54PM +0100, Timon Gehr wrote: [...]
> >>If CTFE does not terminate, compilation is not allowed to succeed.
> >
> >Heh, I think this one is unimplementable, as it amounts to solving
> >the halting problem. :)
> >...
> 
> Actually it does not. Non-success denotes either failure or non-termination.

But how do you check for non-termination?


T

-- 
If creativity is stifled by rigid discipline, then it is not true creativity.

On Wednesday, 27 March 2013 at 17:19:40 UTC, H. S. Teoh wrote:
> On Wed, Mar 27, 2013 at 10:48:31AM -0400, Andrei Alexandrescu wrote:
>> Found this: http://stackoverflow.com/questions/15652718/object-error-access-violation-when-printing-result-of-std-algorithm-cartesianpr
>
> IMO, this is a compiler bug. If the compiler can't correctly generate
> code for something, it shouldn't just keep quiet and generate wrong
> code.
>

That work fairly well for closures and context pointer. It is a proven strategy.

On 3/27/13 1:17 PM, H. S. Teoh wrote:
> On Wed, Mar 27, 2013 at 10:48:31AM -0400, Andrei Alexandrescu wrote:
>> Found this: http://stackoverflow.com/questions/15652718/object-error-access-violation-when-printing-result-of-std-algorithm-cartesianpr
>
> IMO, this is a compiler bug. If the compiler can't correctly generate
> code for something, it shouldn't just keep quiet and generate wrong
> code.

Then bugzillize!

Andrei

On Wednesday, 27 March 2013 at 14:48:32 UTC, Andrei Alexandrescu wrote:
> Found this: http://stackoverflow.com/questions/15652718/object-error-access-violation-when-printing-result-of-std-algorithm-cartesianpr
>
> Soon we'll need to clearly define the limits of CTFE, and what happens when it fails.

Aren't the limits just Safe D? (i.e. if it's in Safe D, it compiles, anything more is implementation defined?)

27-Mar-2013 23:14, Peter Alexander пишет:
> On Wednesday, 27 March 2013 at 14:48:32 UTC, Andrei Alexandrescu wrote:
>> Found this:
>> http://stackoverflow.com/questions/15652718/object-error-access-violation-when-printing-result-of-std-algorithm-cartesianpr
>>
>>
>> Soon we'll need to clearly define the limits of CTFE, and what happens
>> when it fails.
>
> Aren't the limits just Safe D? (i.e. if it's in Safe D, it compiles,
> anything more is implementation defined?)

No - one can call writeln (if one day it's marked @trusted). CTFE can never do such a thing. Plus no access to globals etc. in general sense no side effects.

-- 
Dmitry Olshansky

On Wed, 27 Mar 2013 23:43:07 +0400
Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

> 27-Mar-2013 23:14, Peter Alexander пишет:
> > On Wednesday, 27 March 2013 at 14:48:32 UTC, Andrei Alexandrescu wrote:
> >> Found this: http://stackoverflow.com/questions/15652718/object-error-access-violation-when-printing-result-of-std-algorithm-cartesianpr
> >>
> >>
> >> Soon we'll need to clearly define the limits of CTFE, and what happens when it fails.
> >
> > Aren't the limits just Safe D? (i.e. if it's in Safe D, it compiles, anything more is implementation defined?)
> 
> No - one can call writeln (if one day it's marked @trusted). CTFE can never do such a thing.

There's (thankfully) already a ctfeWriteln (or something like that). So
about all that needs to happen for writeln to work in CTFE is for it to
start with:

if(__ctfe) {
    ctfeWriteln(...);
    return;
}

Or something like that.

> Plus no access to globals etc. in general
> sense no side effects.
> 

27-Mar-2013 23:50, Nick Sabalausky пишет:
> On Wed, 27 Mar 2013 23:43:07 +0400
> Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
>
>> 27-Mar-2013 23:14, Peter Alexander пишет:
>>> On Wednesday, 27 March 2013 at 14:48:32 UTC, Andrei Alexandrescu
>>> wrote:
>>>> Found this:
>>>> http://stackoverflow.com/questions/15652718/object-error-access-violation-when-printing-result-of-std-algorithm-cartesianpr
>>>>
>>>>
>>>> Soon we'll need to clearly define the limits of CTFE, and what
>>>> happens when it fails.
>>>
>>> Aren't the limits just Safe D? (i.e. if it's in Safe D, it compiles,
>>> anything more is implementation defined?)
>>
>> No - one can call writeln (if one day it's marked @trusted). CTFE can
>> never do such a thing.
>
> There's (thankfully) already a ctfeWriteln (or something like that). So
> about all that needs to happen for writeln to work in CTFE is for it to
> start with:
>
> if(__ctfe) {
>      ctfeWriteln(...);
>      return;
> }
>
> Or something like that.

That's far cry from full I/O ;)

In fact I believe we might need more general set of "built-in" functions for CTFE. The goal is to define as small set as possible covering as many good use-cases as possible.

And you still can't read/write to TLS global from CTFE for obvious reasons.

>> Plus no access to globals etc. in general
>> sense no side effects.
>>


-- 
Dmitry Olshansky

On 03/27/2013 06:50 PM, H. S. Teoh wrote:
> On Wed, Mar 27, 2013 at 06:29:59PM +0100, Timon Gehr wrote:
>> On 03/27/2013 06:20 PM, H. S. Teoh wrote:
>>> On Wed, Mar 27, 2013 at 05:55:54PM +0100, Timon Gehr wrote:
>>> [...]
>>>> If CTFE does not terminate, compilation is not allowed to succeed.
>>>
>>> Heh, I think this one is unimplementable, as it amounts to solving
>>> the halting problem. :)
>>> ...
>>
>> Actually it does not. Non-success denotes either failure or
>> non-termination.
>
> But how do you check for non-termination?
>
>
> T
>

Why would you need to?

27-Mar-2013 21:50, H. S. Teoh пишет:
> On Wed, Mar 27, 2013 at 06:29:59PM +0100, Timon Gehr wrote:
>> On 03/27/2013 06:20 PM, H. S. Teoh wrote:
>>> On Wed, Mar 27, 2013 at 05:55:54PM +0100, Timon Gehr wrote:
>>> [...]
>>>> If CTFE does not terminate, compilation is not allowed to succeed.
>>>
>>> Heh, I think this one is unimplementable, as it amounts to solving
>>> the halting problem. :)
>>> ...
>>
>> Actually it does not. Non-success denotes either failure or
>> non-termination.
>
> But how do you check for non-termination?
>

Watchdog if you need it.
Going by no reasonable program written in D can compile longer <insert your time to get some coffee>.

>
> T
>


-- 
Dmitry Olshansky