Getting the error from __traits(compiles, ...)

[Bill Baxter]

On Fri, Nov 13, 2009 at 11:50 AM, Yigal Chripun <yigal100 at gmail.com> wrote:
> On 13/11/2009 19:30, Bill Baxter wrote:
>>
>> On Fri, Nov 13, 2009 at 8:40 AM, bearophile<bearophileHUGS at lycos.com>
>> wrote:
>>>
>>> Bill Baxter:
>>>>
>>>> 2) how to get and report errors related to failure to compile
>>>> some code. (this one I hadn't thought of back then)
>>>
>>> I'd like a "static foreach" too. Eventually most statements will
>>> have a static version. At that point people will start seeing this
>>> little duplication in the language and someone may invent a way to
>>> throw away all the static versions and allow normal D code to be
>>> used at compile time, maybe with a 2-stage compilation or
>>> something.
>>
>> A static switch would be nice too.   static if (is(type == xxx)) {}
>> else static if (is(type==yyy)) {} else static if ... gets kinda
>> tedious.
>>
>>
>> The kind of unification you're talking about is one thing I like
>> about Nemerle's 2-phase macros-as-plugins.  The code you execute at
>> compile time is written in exactly the same language as what you
>> execute at runtime.  And no CTFE engine is required to make it work.
>> Only one new construct required, the macro facility itself.
>>
>> But I don't think that leads to elimination static if, etc.  It just
>> means that such things become implementable as macros, rather than
>> language constructs.
>>
>> On the other hand, having macros doesn't mean that you don't want
>> constant folding.  And if you can fold the constant 2+3, why not the
>> constant add(2,3)?  So desire to fold as many constants as possible
>> naturally leads to a desire to do CTFE and be able to execute your
>> entire language at compile time.
>>
>> And once you're there -- yeh, I guess you're right.   Ultimately
>> it's not really necessary to specify static if vs regular if.   It's
>> yet another extension of constant folding -- if the condition is a
>> compile time constant, then it can act as a static if.   Same goes
>> for loops. But like regular loop unrolling optimizations, the
>> compiler should decide if it's prudent to unroll that 10,000 static
>> foreach loop or not.
>>
>> So in short.  I think you're right.  "static if"  should go away.
>> But "2-stage" compilation isn't really necessary, just more
>> extensions to the constant folding engine.  (Or perhaps you could say
>> constant folding is already a separate stage of a 2-stage process)
>>
>> --bb
>
> 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