www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Getting the error from __traits(compiles, ...)

reply Bill Baxter <wbaxter gmail.com> writes:
We can pretty much already use __traits(compiles,{...}) to implement
static interface checking.

template checkInterface(T) {
    enum bool checkInterface =
    __traits(compiles,
    {
       T x;
       // some code exercising various aspects of the interface
    });
}

The main problem with this is that a static "implements interface"
check is done like so:

   static assert(checkInterface!(myType));

And all it tells you is a single yes or no.  It would help in
debugging if you could somehow get the reason for the failure.

So how to do it?  All that comes to mind is something like the evil
Errno from C.  A global that gets set by the last failure.
Let's call it __errmsg, but it could be a pragma, or a __traits thing.
 If you had that then you could write this:

   assertImplements!(checkInterface!(myType));

With:
template assertImplements(bool v)
{
       static if (!v) {
            pragma(msg, __errmsg);
            static assert(false);
       }
}

There are lots of ways you could provide such a concept-checker, but
they all require the basic ability to get the reason for the
__traits(compiles) failure.

Any other thoughts about how to get the failure info?   This is
probably the main complaint against __traits(compiles), that there's
no way to find out what went wrong if the code doesn't compile.  Often
it can just be a typo.  I know I've spent plenty of time looking at
static if(__traits(compiles, ...)) checks that weren't working only to
discover I switched an x for a y somewhere.  Or passed the wrong
number of arguments.

--bb
Nov 12 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:

 Any other thoughts about how to get the failure info?   This is
 probably the main complaint against __traits(compiles), that there's
 no way to find out what went wrong if the code doesn't compile.  Often
 it can just be a typo.  I know I've spent plenty of time looking at
 static if(__traits(compiles, ...)) checks that weren't working only to
 discover I switched an x for a y somewhere.  Or passed the wrong
 number of arguments.


I agree it's a problem. Perhaps we can do:

    __traits(compiles_or_msg, ...)

which would print the error messages, at least making it easier to track 
down.
Nov 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Walter Bright wrote:

 Bill Baxter wrote:

 Any other thoughts about how to get the failure info?   This is
 probably the main complaint against __traits(compiles), that there's
 no way to find out what went wrong if the code doesn't compile.  Often
 it can just be a typo.  I know I've spent plenty of time looking at
 static if(__traits(compiles, ...)) checks that weren't working only to
 discover I switched an x for a y somewhere.  Or passed the wrong
 number of arguments.


 
 I agree it's a problem. Perhaps we can do:
 
    __traits(compiles_or_msg, ...)
 
 which would print the error messages, at least making it easier to track 
 down.


Eh, scratch that dumb idea. Just remove the __traits(compiles, ...) and 
replace it with ..., and you'll get the message!
Nov 12 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 13 Nov 2009 00:00:42 +0300, Walter Bright  
<newshound1 digitalmars.com> wrote:


 Walter Bright wrote:

 Bill Baxter wrote:

 Any other thoughts about how to get the failure info?   This is
 probably the main complaint against __traits(compiles), that there's
 no way to find out what went wrong if the code doesn't compile.  Often
 it can just be a typo.  I know I've spent plenty of time looking at
 static if(__traits(compiles, ...)) checks that weren't working only to
 discover I switched an x for a y somewhere.  Or passed the wrong
 number of arguments.


  I agree it's a problem. Perhaps we can do:
     __traits(compiles_or_msg, ...)
  which would print the error messages, at least making it easier to  
 track down.


 Eh, scratch that dumb idea. Just remove the __traits(compiles, ...) and  
 replace it with ..., and you'll get the message!


He was asking for a string so that it would be possible to parse and/or  
output. More like:

enum s = __traits(compiles_or_msg, ...);
static if (s.length == 0) {
    // no error
} else {
    // do stuff with error message
}
Nov 12 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Denis Koroskin wrote:

 He was asking for a string so that it would be possible to parse and/or 
 output. More like:
 
 enum s = __traits(compiles_or_msg, ...);
 static if (s.length == 0) {
    // no error
 } else {
    // do stuff with error message
 }


Makes sense.
Nov 12 2009
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Thu, Nov 12, 2009 at 1:00 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 Walter Bright wrote:

 Bill Baxter wrote:

 Any other thoughts about how to get the failure info? =A0 This is
 probably the main complaint against __traits(compiles), that there's
 no way to find out what went wrong if the code doesn't compile. =A0Ofte=






n

 it can just be a typo. =A0I know I've spent plenty of time looking at
 static if(__traits(compiles, ...)) checks that weren't working only to
 discover I switched an x for a y somewhere. =A0Or passed the wrong
 number of arguments.


 I agree it's a problem. Perhaps we can do:

 =A0 __traits(compiles_or_msg, ...)

 which would print the error messages, at least making it easier to track
 down.


 Eh, scratch that dumb idea. Just remove the __traits(compiles, ...) and
 replace it with ..., and you'll get the message!


Maybe that is enough combined with a const code snippet

enum code =3D q{
        R r;             // can define a range object
        if (r.empty) {}  // can test for empty
        r.popFront;          // can invoke next
        auto h =3D r.front; // can get the front of the range
}
static if (__traits(compiles, mixin(code))) {
    mixin(code);
}
else {
    pragma(msg, "Unable to instantiate code for type
T=3D`"~T.stringof~"`:\n "~ code);
    pragma(msg, "Compiler reports:" );
    mixin(code);
}

But I was really hoping for a separation of Interface definition and
Interface verification.  With the above you'll have to have two
templates for every interface,  like  isForwardRange!(T) (evals to
bool)  and assertIsForwardRange!(T)  (reports the compiler error or is
silent).   Hmm.... unless

template assertIsInputRange(T, bool noisy=3Dtrue) {
     enum code =3D q{
             R r;             // can define a range object
             if (r.empty) {}  // can test for empty
             r.popFront;          // can invoke next
            auto h =3D r.front; // can get the front of the range
     };
     static if (!__traits(compiles, mixin(code))) {
        static if (noisy) {
             pragma(msg, "Type T=3D`"~T.stringof~"` doesn't support
interface:\n "~ code);
             pragma(msg, "Compiler reports:" );
        }
        mixin(code);
     }
}

template isInputRange(T) {
     enum bool isInputRange =3D __traits(compiles, assertIsInputRange!(T, f=
alse));
}

And then we could wrap the whole shebang in a fancy code-generating
string mixin and define things like the above using:

mixin(DefineInterface(
    "InputRange",
    q{
             R r;             // can define a range object
             if (r.empty) {}  // can test for empty
             r.popFront;          // can invoke next
            auto h =3D r.front; // can get the front of the range
     }));

mixin(DefineInterface!(assertIsInputRange)(
    "ForwardRange",
     q{
        R r1;
        R r2 =3D r1;           // can copy a range object
      })));

Writing DefineInterface is left as an exercise for the reader. :-)
But it looks do-able.
And DefineInterface could take a variadic list of assertIsXXX template
aliases and generate code to check each one.

--bb
Nov 12 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Bill Baxter wrote:

 On Thu, Nov 12, 2009 at 1:00 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Walter Bright wrote:

 Bill Baxter wrote:

 Any other thoughts about how to get the failure info?   This is
 probably the main complaint against __traits(compiles), that there's
 no way to find out what went wrong if the code doesn't compile.  Often
 it can just be a typo.  I know I've spent plenty of time looking at
 static if(__traits(compiles, ...)) checks that weren't working only to
 discover I switched an x for a y somewhere.  Or passed the wrong
 number of arguments.


 I agree it's a problem. Perhaps we can do:

   __traits(compiles_or_msg, ...)

 which would print the error messages, at least making it easier to track
 down.


 Eh, scratch that dumb idea. Just remove the __traits(compiles, ...) and
 replace it with ..., and you'll get the message!


 
 Maybe that is enough combined with a const code snippet
 
 enum code = q{
         R r;             // can define a range object
         if (r.empty) {}  // can test for empty
         r.popFront;          // can invoke next
         auto h = r.front; // can get the front of the range
 }
 static if (__traits(compiles, mixin(code))) {
     mixin(code);
 }
 else {
     pragma(msg, "Unable to instantiate code for type
 T=`"~T.stringof~"`:\n "~ code);
     pragma(msg, "Compiler reports:" );
     mixin(code);
 }
 
 But I was really hoping for a separation of Interface definition and
 Interface verification.  With the above you'll have to have two
 templates for every interface,  like  isForwardRange!(T) (evals to
 bool)  and assertIsForwardRange!(T)  (reports the compiler error or is
 silent).   Hmm.... unless
 
 template assertIsInputRange(T, bool noisy=true) {
      enum code = q{
              R r;             // can define a range object
              if (r.empty) {}  // can test for empty
              r.popFront;          // can invoke next
             auto h = r.front; // can get the front of the range
      };
      static if (!__traits(compiles, mixin(code))) {
         static if (noisy) {
              pragma(msg, "Type T=`"~T.stringof~"` doesn't support
 interface:\n "~ code);
              pragma(msg, "Compiler reports:" );
         }
         mixin(code);
      }
 }
 
 template isInputRange(T) {
      enum bool isInputRange = __traits(compiles, assertIsInputRange!(T,
false));
 }
 
 And then we could wrap the whole shebang in a fancy code-generating
 string mixin and define things like the above using:
 
 mixin(DefineInterface(
     "InputRange",
     q{
              R r;             // can define a range object
              if (r.empty) {}  // can test for empty
              r.popFront;          // can invoke next
             auto h = r.front; // can get the front of the range
      }));
 
 mixin(DefineInterface!(assertIsInputRange)(
     "ForwardRange",
      q{
         R r1;
         R r2 = r1;           // can copy a range object
       })));
 
 Writing DefineInterface is left as an exercise for the reader. :-)
 But it looks do-able.
 And DefineInterface could take a variadic list of assertIsXXX template
 aliases and generate code to check each one.
 
 --bb


I really wish this was folded into the language by allowing structs to 
implement interfaces.

interface Range(T) {
   bool empty();
   void popFront();
   T front();
}

struct MyRange(T) : Range!(T) { ... } // checked by compiler
Nov 12 2009
parent reply grauzone <none example.net> writes:
Yigal Chripun wrote:

 Bill Baxter wrote:

 On Thu, Nov 12, 2009 at 1:00 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Walter Bright wrote:

 Bill Baxter wrote:

 Any other thoughts about how to get the failure info?   This is
 probably the main complaint against __traits(compiles), that there's
 no way to find out what went wrong if the code doesn't compile.  Often
 it can just be a typo.  I know I've spent plenty of time looking at
 static if(__traits(compiles, ...)) checks that weren't working only to
 discover I switched an x for a y somewhere.  Or passed the wrong
 number of arguments.


 I agree it's a problem. Perhaps we can do:

   __traits(compiles_or_msg, ...)

 which would print the error messages, at least making it easier to 
 track
 down.


 Eh, scratch that dumb idea. Just remove the __traits(compiles, ...) and
 replace it with ..., and you'll get the message!


 Maybe that is enough combined with a const code snippet

 enum code = q{
         R r;             // can define a range object
         if (r.empty) {}  // can test for empty
         r.popFront;          // can invoke next
         auto h = r.front; // can get the front of the range
 }
 static if (__traits(compiles, mixin(code))) {
     mixin(code);
 }
 else {
     pragma(msg, "Unable to instantiate code for type
 T=`"~T.stringof~"`:\n "~ code);
     pragma(msg, "Compiler reports:" );
     mixin(code);
 }

 But I was really hoping for a separation of Interface definition and
 Interface verification.  With the above you'll have to have two
 templates for every interface,  like  isForwardRange!(T) (evals to
 bool)  and assertIsForwardRange!(T)  (reports the compiler error or is
 silent).   Hmm.... unless

 template assertIsInputRange(T, bool noisy=true) {
      enum code = q{
              R r;             // can define a range object
              if (r.empty) {}  // can test for empty
              r.popFront;          // can invoke next
             auto h = r.front; // can get the front of the range
      };
      static if (!__traits(compiles, mixin(code))) {
         static if (noisy) {
              pragma(msg, "Type T=`"~T.stringof~"` doesn't support
 interface:\n "~ code);
              pragma(msg, "Compiler reports:" );
         }
         mixin(code);
      }
 }

 template isInputRange(T) {
      enum bool isInputRange = __traits(compiles, 
 assertIsInputRange!(T, false));
 }

 And then we could wrap the whole shebang in a fancy code-generating
 string mixin and define things like the above using:

 mixin(DefineInterface(
     "InputRange",
     q{
              R r;             // can define a range object
              if (r.empty) {}  // can test for empty
              r.popFront;          // can invoke next
             auto h = r.front; // can get the front of the range
      }));

 mixin(DefineInterface!(assertIsInputRange)(
     "ForwardRange",
      q{
         R r1;
         R r2 = r1;           // can copy a range object
       })));

 Writing DefineInterface is left as an exercise for the reader. :-)
 But it looks do-able.
 And DefineInterface could take a variadic list of assertIsXXX template
 aliases and generate code to check each one.

 --bb


 
 I really wish this was folded into the language by allowing structs to 
 implement interfaces.
 
 interface Range(T) {
   bool empty();
   void popFront();
   T front();
 }
 
 struct MyRange(T) : Range!(T) { ... } // checked by compiler
 


One problem with this was that arrays wouldn't automagically be ranges 
anymore. Right now, "int[] a; a.popFront();" works, because std.array 
has a global function popFront. Some old language hack turns a.popFront 
into popFront(a).
Nov 13 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
grauzone wrote:

 Yigal Chripun wrote:

 I really wish this was folded into the language by allowing structs to 
 implement interfaces.

 interface Range(T) {
   bool empty();
   void popFront();
   T front();
 }

 struct MyRange(T) : Range!(T) { ... } // checked by compiler


 
 One problem with this was that arrays wouldn't automagically be ranges 
 anymore. Right now, "int[] a; a.popFront();" works, because std.array 
 has a global function popFront. Some old language hack turns a.popFront 
 into popFront(a).


you're talking about this construct:
int[] arr;
void foo(int[], params) {}  => arr.foo(params);

This should not be considered a hack but rather should be a feature 


I also think that arrays (containers) must be distinct from 
slices/ranges (views).
Nov 13 2009
parent grauzone <none example.net> writes:
Yigal Chripun wrote:

 grauzone wrote:

 Yigal Chripun wrote:

 I really wish this was folded into the language by allowing structs 
 to implement interfaces.

 interface Range(T) {
   bool empty();
   void popFront();
   T front();
 }

 struct MyRange(T) : Range!(T) { ... } // checked by compiler


 One problem with this was that arrays wouldn't automagically be ranges 
 anymore. Right now, "int[] a; a.popFront();" works, because std.array 
 has a global function popFront. Some old language hack turns 
 a.popFront into popFront(a).


 
 you're talking about this construct:
 int[] arr;
 void foo(int[], params) {}  => arr.foo(params);
 
 This should not be considered a hack but rather should be a feature 



I'd rather have some sort of open types, which are the clean version of 
this hack.


 I also think that arrays (containers) must be distinct from 
 slices/ranges (views).
Nov 13 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Bill Baxter wrote:

 We can pretty much already use __traits(compiles,{...}) to implement
 static interface checking.
 
 template checkInterface(T) {
     enum bool checkInterface =
     __traits(compiles,
     {
        T x;
        // some code exercising various aspects of the interface
     });
 }
 
 The main problem with this is that a static "implements interface"
 check is done like so:
 
    static assert(checkInterface!(myType));
 
 And all it tells you is a single yes or no.  It would help in
 debugging if you could somehow get the reason for the failure.
 
 So how to do it?  All that comes to mind is something like the evil
 Errno from C.  A global that gets set by the last failure.
 Let's call it __errmsg, but it could be a pragma, or a __traits thing.
  If you had that then you could write this:
 
    assertImplements!(checkInterface!(myType));
 
 With:
 template assertImplements(bool v)
 {
        static if (!v) {
             pragma(msg, __errmsg);
             static assert(false);
        }
 }
 
 There are lots of ways you could provide such a concept-checker, but
 they all require the basic ability to get the reason for the
 __traits(compiles) failure.
 
 Any other thoughts about how to get the failure info?   This is
 probably the main complaint against __traits(compiles), that there's
 no way to find out what went wrong if the code doesn't compile.  Often
 it can just be a typo.  I know I've spent plenty of time looking at
 static if(__traits(compiles, ...)) checks that weren't working only to
 discover I switched an x for a y somewhere.  Or passed the wrong
 number of arguments.
 
 --bb


I think you might be asking for:

static try {
    xxx;
}
catch( CompilerError[] errors){
    pragma(msg, "Failure in Frobozz!");
    pragma(msg, errors[0].msg);
}
Nov 13 2009
next sibling parent Justin Johansson <free beer.com> writes:
 There are lots of ways you could provide such a concept-checker, but
 they all require the basic ability to get the reason for the
 __traits(compiles) failure.
 
 Any other thoughts about how to get the failure info?   This is
 probably the main complaint against __traits(compiles), that there's
 no way to find out what went wrong if the code doesn't compile.  Often
 it can just be a typo.  I know I've spent plenty of time looking at
 static if(__traits(compiles, ...)) checks that weren't working only to
 discover I switched an x for a y somewhere.  Or passed the wrong
 number of arguments.
 
 --bb


 
 I think you might be asking for:
 
 static try {
     xxx;
 }
 catch( CompilerError[] errors){
     pragma(msg, "Failure in Frobozz!");
     pragma(msg, errors[0].msg);
 }


This is very interesting.
Given previous/recent discussion about scopes, should there be,
or are there, analogous static scope statements so that one could make
use of scope(exit), scope(failure), et. al. in a static context?

beers,
Justin
Nov 13 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Don:


 I think you might be asking for:
 
 static try {
     xxx;
 }
 catch( CompilerError[] errors){
     pragma(msg, "Failure in Frobozz!");
     pragma(msg, errors[0].msg);
 }


Good. I'd like to have a handy&clean way to verify that some static asserts
throw inside my unit tests.

Bye,
bearophile
Nov 13 2009
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Fri, Nov 13, 2009 at 12:09 AM, Don <nospam nospam.com> wrote:

 Bill Baxter wrote:

 We can pretty much already use __traits(compiles,{...}) to implement
 static interface checking.

 template checkInterface(T) {
 =A0 =A0enum bool checkInterface =3D
 =A0 =A0__traits(compiles,
 =A0 =A0{
 =A0 =A0 =A0 T x;
 =A0 =A0 =A0 // some code exercising various aspects of the interface
 =A0 =A0});
 }

 The main problem with this is that a static "implements interface"
 check is done like so:

 =A0 static assert(checkInterface!(myType));

 And all it tells you is a single yes or no. =A0It would help in
 debugging if you could somehow get the reason for the failure.

 So how to do it? =A0All that comes to mind is something like the evil
 Errno from C. =A0A global that gets set by the last failure.
 Let's call it __errmsg, but it could be a pragma, or a __traits thing.
 =A0If you had that then you could write this:

 =A0 assertImplements!(checkInterface!(myType));

 With:
 template assertImplements(bool v)
 {
 =A0 =A0 =A0 static if (!v) {
 =A0 =A0 =A0 =A0 =A0 =A0pragma(msg, __errmsg);
 =A0 =A0 =A0 =A0 =A0 =A0static assert(false);
 =A0 =A0 =A0 }
 }

 There are lots of ways you could provide such a concept-checker, but
 they all require the basic ability to get the reason for the
 __traits(compiles) failure.

 Any other thoughts about how to get the failure info? =A0 This is
 probably the main complaint against __traits(compiles), that there's
 no way to find out what went wrong if the code doesn't compile. =A0Often
 it can just be a typo. =A0I know I've spent plenty of time looking at
 static if(__traits(compiles, ...)) checks that weren't working only to
 discover I switched an x for a y somewhere. =A0Or passed the wrong
 number of arguments.

 --bb


 I think you might be asking for:

 static try {
 =A0 xxx;
 }
 catch( CompilerError[] errors){
 =A0 pragma(msg, "Failure in Frobozz!");
 =A0 pragma(msg, errors[0].msg);
 }


Heh heh.  Well I proposed something along those lines before, and it
didn't catch on, so I decided to avoid mentioning it this time.  :-)
http://digitalmars.com/d/archives/digitalmars/D/static_try_catch_construct_=
would_be_helpful_66794.html

But yeh, actually now that you mention it that handles both problems I
brought up recently.

1) how to run code only if it compiles and avoid repeating yourself.
(the original reason I proposed it)

2) how to get and report errors related to failure to compile some
code. (this one I hadn't thought of back then)

But yeh, it looks like that could solve both problems.

--bb
Nov 13 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
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.
Design is often like that, with phases of expansion of functionality followed
by phases of synthesis and generalization.

Bye,
bearophile
Nov 13 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Fri, Nov 13, 2009 at 8:40 AM, bearophile <bearophileHUGS lycos.com> wrot=
e:

 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 s=


tatic version. At that point people will start seeing this little duplicati=
on in the language and someone may invent a way to throw away all the stati=
c 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 =3D=3D xxx)) {}
else static if (is(type=3D=3Dyyy)) {} 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
Nov 13 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Fri, Nov 13, 2009 at 8:40 AM, bearophile <bearophileHUGS 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)



"static if" is different from "if" in the way it handles scopes. Also, 
the former is a declaration, the latter is a statement.

Andrei
Nov 13 2009
parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Nov 13, 2009 at 9:38 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Fri, Nov 13, 2009 at 8:40 AM, bearophile <bearophileHUGS 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. =A0 static if (is(type =3D=3D xxx)) {=




}

 else static if (is(type=3D=3Dyyy)) {} 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. =A0The code you execute at compile
 time is written in exactly the same language as what you execute at
 runtime. =A0And no CTFE engine is required to make it work. =A0Only one
 new construct required, the macro facility itself.

 But I don't think that leads to elimination static if, etc. =A0It 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. =A0And if you can fold the constant 2+3, why not the
 constant add(2,3)? =A0So 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. =A0 Ultimately it's
 not really necessary to specify static if vs regular if. =A0 It's yet
 another extension of constant folding -- if the condition is a compile
 time constant, then it can act as a static if. =A0 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. =A0I think you're right. =A0"static if" =A0should go away. =




=A0But

 "2-stage" compilation isn't really necessary, just more extensions to
 the constant folding engine. =A0(Or perhaps you could say constant
 folding is already a separate stage of a 2-stage process)



 "static if" is different from "if" in the way it handles scopes.


Good point.  It's not really an essential distinction, though.  If the
language had no-scope blocks in addition to scope blocks then you
could have no-scope dynamic if() also.

I've always found it unpleasing anyway that one word (somewhat
separated from the {}) changes whether {} creates a scope or not.


 Also, the
 former is a declaration, the latter is a statement.


That mostly just means you can use "static if" at the top level, right?
If the language eliminated "static if" then clearly all if's at the
top level would be required to have static conditions and use no-scope
blocks.

But ok.  These things probably make it too big a change for D to swallow.

--bb
Nov 13 2009
prev sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 13/11/2009 19:30, Bill Baxter wrote:

 On Fri, Nov 13, 2009 at 8:40 AM, bearophile<bearophileHUGS 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.

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.
Nov 13 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Fri, Nov 13, 2009 at 11:50 AM, Yigal Chripun <yigal100 gmail.com> wrote:

 On 13/11/2009 19:30, Bill Baxter wrote:

 On Fri, Nov 13, 2009 at 8:40 AM, bearophile<bearophileHUGS 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. =A0 static if (is(type =3D=3D xxx)) {=




}

 else static if (is(type=3D=3Dyyy)) {} 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. =A0The code you execute at
 compile time is written in exactly the same language as what you
 execute at runtime. =A0And 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. =A0It 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. =A0And if you can fold the constant 2+3, why not the
 constant add(2,3)? =A0So 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. =A0 Ultimately
 it's not really necessary to specify static if vs regular if. =A0 It's
 yet another extension of constant folding -- if the condition is a
 compile time constant, then it can act as a static if. =A0 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. =A0I think you're right. =A0"static if" =A0should go away.
 But "2-stage" compilation isn't really necessary, just more
 extensions to the constant folding engine. =A0(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() {
 =A0int res =3D 2 + 3;
 =A0return res;
 }

 macro bar() {
 =A0return 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 lik=


e

 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 o=


f

 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
Nov 13 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
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.
Nov 14 2009
parent reply Don <nospam nospam.com> writes:
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.
Nov 14 2009
parent Yigal Chripun <yigal100 gmail.com> writes:
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
Nov 14 2009