Polishing D - suggestions and comments

[Dan]

Robert Fraser Wrote:

> You mentioned IDEs a couple times, specifically in that they should be 
> able to access DMD via some sort of API. While this would be great, 
> Descent (in trunk, sadly the kinks are still being worked out...) takes 
> a different approach. We have a full Java port of the DMD semantic 
> front-end, which we are using to do things like display errors inline as 
> the user types. From working with Descent, I can say that having 
> programatic access to the AST would be nice, but since most advanced 
> IDEs would want to extend it anyway, it's a lot of work for a small gain.

Yeah, D exposing the AST would be a *huge* benefit to modifying the compiler, and allowing things like third party profilers and optimizers.

For profiling, I've always argued that I want this:

~~~

I can't rightly find out all the things that modify my variable 'x' without an AST; so how am I supposed to notice when I write

if(x < 0) 
   x = Math_bla(x);

before the only three places calling a function, and then inside the function deep in another file it's already got

int Math_bla(x) {
  if(x > 0)
    do something
  if(x == 0)
    do something else
  if(x == double.nan)
...
}

~~~

This really should be noticed by a profiler/optimizer, so that the programmer can detect impossible branch cases.  There's more.  We really ought to have a "potential range filter" for numbers; so when we do this:

x ^= 1;

And later we go:

switch(x) {
   case 1:
   case 2:
   case 3:
   case 4:
}

When we look at x in that switch, we see that it's inherently even.

The problem is intractable without an AST; and even then, the optimizer/profiler will be a grand project.