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
 


 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.
 


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