On 13/11/2009 22:05, Bill Baxter wrote:
> On Fri, Nov 13, 2009 at 11:50 AM, Yigal Chripun<yigal100@gmail.com>  wrote:
>>
>> I don't follow your logic regarding CTFE.
>>
>> with 2 phase macros a-la nemerle:
>>
>> macro foo() {
>>   int res = 2 + 3;
>>   return res;
>> }
>>
>> macro bar() {
>>   return q{2 + 3};
>> }
>>
>> foo's addition is done at compile time so the constant folding was
>> implemented in the macro body
>>
>> bar return the AST for the expression "2 + 3". Compiler optimizations like
>> constant folding will apply just as if you wrote that expression yourself
>> instead of generating it by calling a macro.
>
> Right, which is why I'm saying you still want constant folding/CTFE
> even if you have a macro system.  But then if you're going to have
> CTFE sitting around anyway, you might as well use it to implement
> macros instead of going to this funky two-phase thing.   That was one
> point I was making, though not so clearly.
>
>> static if is not supposed to be implemented with macros, rather the
>> equivalent of a static if would be using a regular if *inside* the body of
>> the macro.
>
> But that's how you would implement a static if with macros, no?
> (pardon the incorrect nemerle syntax)
>
> macro static_if(bool cond, a, b) {
>          if (cond) {
>             <|  a  |>
>          } else {
>             <|  b  |>
>          }
> }
>
> --bb

let's start from the end,
yes, you can implement static if that way but I don't see why would you want to do that.

regarding constant folding and 2 phase compilation:
from what I know, DMD currently contains inside two backends, the regular one generates the executable *and* an interpreter which does CTFE. Constant folding is an optimization used by both.

basically we already have two phases of compilation but they are done internally by DMD. This means that DMD has two separate backends instead of just one and that you need separate syntax to target the different phases.

The major problems I see with the current system:
- unnecessary duplication of syntax
- two backends instead of just one which complicates the compiler implementation
- unclear separation of phase in code:
  auto arr = [1.0, 2.0, bar(5.0)]; // when is bar executed?
also, how can I control when it's executed? This is needlessly confusing and doesn't provide enough control to the programmer.

it's analogous to structs vs. classes. I'm sure everyone in the D community agree that this separation of concerns is much better than the bug-prone c++ way.

Yigal Chripun wrote:
> On 13/11/2009 22:05, Bill Baxter wrote:
>> On Fri, Nov 13, 2009 at 11:50 AM, Yigal Chripun<yigal100@gmail.com>  wrote:
>>>
>>> I don't follow your logic regarding CTFE.
>>>
>>> with 2 phase macros a-la nemerle:
>>>
>>> macro foo() {
>>>   int res = 2 + 3;
>>>   return res;
>>> }
>>>
>>> macro bar() {
>>>   return q{2 + 3};
>>> }
>>>
>>> foo's addition is done at compile time so the constant folding was
>>> implemented in the macro body
>>>
>>> bar return the AST for the expression "2 + 3". Compiler optimizations like
>>> constant folding will apply just as if you wrote that expression yourself
>>> instead of generating it by calling a macro.
>>
>> Right, which is why I'm saying you still want constant folding/CTFE
>> even if you have a macro system.  But then if you're going to have
>> CTFE sitting around anyway, you might as well use it to implement
>> macros instead of going to this funky two-phase thing.   That was one
>> point I was making, though not so clearly.
>>
>>> static if is not supposed to be implemented with macros, rather the
>>> equivalent of a static if would be using a regular if *inside* the body of
>>> the macro.
>>
>> But that's how you would implement a static if with macros, no?
>> (pardon the incorrect nemerle syntax)
>>
>> macro static_if(bool cond, a, b) {
>>          if (cond) {
>>             <|  a  |>
>>          } else {
>>             <|  b  |>
>>          }
>> }
>>
>> --bb
> 
> let's start from the end,
> yes, you can implement static if that way but I don't see why would you want to do that.
> 
> regarding constant folding and 2 phase compilation:
> from what I know, DMD currently contains inside two backends, the regular one generates the executable *and* an interpreter which does CTFE

> Constant folding is an optimization used by both.
> 
> basically we already have two phases of compilation but they are done internally by DMD. This means that DMD has two separate backends instead of just one and that you need separate syntax to target the different phases.
> 
> The major problems I see with the current system:
> - unnecessary duplication of syntax
> - two backends instead of just one which complicates the compiler implementation

There's only one backend. The interpreter is basically just constant folding, with a small amount of interpreting of statements. 90% of the CTFE complexity is in the constant folding. The interpreter itself is only about 200 lines of code. But the real backend is huge.

> - unclear separation of phase in code:
>   auto arr = [1.0, 2.0, bar(5.0)]; // when is bar executed?
> also, how can I control when it's executed? This is needlessly confusing and doesn't provide enough control to the programmer.

That particular example is caused by array literals not being immutable, which I am certain is a mistake.

> it's analogous to structs vs. classes. I'm sure everyone in the D community agree that this separation of concerns is much better than the bug-prone c++ way.

On 14/11/2009 13:32, Don wrote:
> Yigal Chripun wrote:
>> On 13/11/2009 22:05, Bill Baxter wrote:
>>> On Fri, Nov 13, 2009 at 11:50 AM, Yigal Chripun<yigal100@gmail.com>
>>> wrote:
>>>>
>>>> I don't follow your logic regarding CTFE.
>>>>
>>>> with 2 phase macros a-la nemerle:
>>>>
>>>> macro foo() {
>>>> int res = 2 + 3;
>>>> return res;
>>>> }
>>>>
>>>> macro bar() {
>>>> return q{2 + 3};
>>>> }
>>>>
>>>> foo's addition is done at compile time so the constant folding was
>>>> implemented in the macro body
>>>>
>>>> bar return the AST for the expression "2 + 3". Compiler
>>>> optimizations like
>>>> constant folding will apply just as if you wrote that expression
>>>> yourself
>>>> instead of generating it by calling a macro.
>>>
>>> Right, which is why I'm saying you still want constant folding/CTFE
>>> even if you have a macro system. But then if you're going to have
>>> CTFE sitting around anyway, you might as well use it to implement
>>> macros instead of going to this funky two-phase thing. That was one
>>> point I was making, though not so clearly.
>>>
>>>> static if is not supposed to be implemented with macros, rather the
>>>> equivalent of a static if would be using a regular if *inside* the
>>>> body of
>>>> the macro.
>>>
>>> But that's how you would implement a static if with macros, no?
>>> (pardon the incorrect nemerle syntax)
>>>
>>> macro static_if(bool cond, a, b) {
>>> if (cond) {
>>> <| a |>
>>> } else {
>>> <| b |>
>>> }
>>> }
>>>
>>> --bb
>>
>> let's start from the end,
>> yes, you can implement static if that way but I don't see why would
>> you want to do that.
>>
>> regarding constant folding and 2 phase compilation:
>> from what I know, DMD currently contains inside two backends, the
>> regular one generates the executable *and* an interpreter which does CTFE
>
>> Constant folding is an optimization used by both.
>>
>> basically we already have two phases of compilation but they are done
>> internally by DMD. This means that DMD has two separate backends
>> instead of just one and that you need separate syntax to target the
>> different phases.
>>
>> The major problems I see with the current system:
>> - unnecessary duplication of syntax
>> - two backends instead of just one which complicates the compiler
>> implementation
>
> There's only one backend. The interpreter is basically just constant
> folding, with a small amount of interpreting of statements. 90% of the
> CTFE complexity is in the constant folding. The interpreter itself is
> only about 200 lines of code. But the real backend is huge.
>
>> - unclear separation of phase in code:
>> auto arr = [1.0, 2.0, bar(5.0)]; // when is bar executed?
>> also, how can I control when it's executed? This is needlessly
>> confusing and doesn't provide enough control to the programmer.
>
> That particular example is caused by array literals not being immutable,
> which I am certain is a mistake.
>
>> it's analogous to structs vs. classes. I'm sure everyone in the D
>> community agree that this separation of concerns is much better than
>> the bug-prone c++ way.

Don,
what's your opinion regarding two phase compilation a-la Nemerle vs. the current D model?

btw, another benefit I forgot to mention regarding this is that in Nemerle compile time code is precompiled which solves a lot of problems with c++ style template code