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

Reply via email to