www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Complex Meta Programming

reply Manfred Nowak <svv1999 hotmail.com> writes:
In http://www.digitalmars.com/webnews/newsgroups.php?
art_group=digitalmars.D.learn&article_id=12478
BCS describes an example for which more complex features in the 
metalanguage seem to be a requirement, if one wants to have short 
compile times.

Is the current approach good enough?

-manfred 
May 18 2008
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Manfred,

 In http://www.digitalmars.com/webnews/newsgroups.php?
 art_group=digitalmars.D.learn&article_id=12478
 BCS describes an example for which more complex features in the
 metalanguage seem to be a requirement, if one wants to have short
 compile times.

 Is the current approach good enough?

My fist thought is no, it would be nice to have something better. In the case cited, I'd love to have a way to have the return type computed based on what I try to return (like in a delegate literal). However on second though it crops up that in this case, my case it would not be enough, take this code for example auto Foo(A,B)(A a, B b) { if(a<b) return Foo(++a, --b); else if(a == b) return b; else return a; } The type of Foo is dependent on the type of Foo. DMD would need to detect this and resolve it (by noticing that Foo's return need only be the Closet common base of A and B). Another solution would be to provide a mechanism to detect cyclical definitions (a static CyclicTemplae predicate or something) that would allow the program to handle this themselves. I guess the up shot of this is that I don't think ad-hoc additions will be a good idea. If we are going to look into more construct, we need to do some "real design" on them.
May 18 2008
parent bearophile <bearophileHUGS lycos.com> writes:
BCS:
 auto Foo(A,B)(A a, B b)
 {
   if(a<b)
     return Foo(++a, --b);
   else if(a == b)
     return b;
   else
     return a;
 }

Maybe for such things you need a type inferencer plugged into a "modern" type system, like the ones you can find in ML or Haskell. Bye, bearophile
May 18 2008
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
Manfred Nowak wrote:
 In http://www.digitalmars.com/webnews/newsgroups.php?
 art_group=digitalmars.D.learn&article_id=12478
 BCS describes an example for which more complex features in the 
 metalanguage seem to be a requirement, if one wants to have short 
 compile times.
 
 Is the current approach good enough?
 
 -manfred 

If you could do everything at runtime, you could store the results as you chose. Then you would get significantly better runtime in many cases, as well as enabling some things that aren't currently possible. Of course, if you could simply store results at compiletime instead, you'd get the same benefits.
May 18 2008
parent BCS <ao pathlink.com> writes:
Reply to Chris,

 Manfred Nowak wrote:
 
 In http://www.digitalmars.com/webnews/newsgroups.php?
 art_group=digitalmars.D.learn&article_id=12478
 BCS describes an example for which more complex features in the
 metalanguage seem to be a requirement, if one wants to have short
 compile times.
 Is the current approach good enough?
 
 -manfred
 

you chose. Then you would get significantly better runtime in many cases, as well as enabling some things that aren't currently possible. Of course, if you could simply store results at compiletime instead, you'd get the same benefits.

IMNSHO within reason, compile times are not an issue. The longest compile time I've seen with DMD (dparse processing the full D grammar so I don't expect to see it go much higher) was 14min. That's about par for finding bugs. I'm willing to run with longer compile times if it generates faster or more bug free code. The only reason I'll back a change in meta land would be to make more robust, readable or capable code.
May 18 2008