March 27, 2013 Re: CTFE is getting too powerful :o) | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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.
|
March 27, 2013 Re: CTFE is getting too powerful :o) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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. |
March 27, 2013 Re: CTFE is getting too powerful :o) | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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.
|
March 27, 2013 Re: CTFE is getting too powerful :o) | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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
|
March 27, 2013 Re: CTFE is getting too powerful :o) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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?)
|
March 27, 2013 Re: CTFE is getting too powerful :o) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander | 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 |
March 27, 2013 Re: CTFE is getting too powerful :o) | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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. > |
March 27, 2013 Re: CTFE is getting too powerful :o) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | 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 |
March 27, 2013 Re: CTFE is getting too powerful :o) | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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?
|
March 27, 2013 Re: CTFE is getting too powerful :o) | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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 |
Copyright © 1999-2021 by the D Language Foundation