Do everything in Java…

[H. S. Teoh via Digitalmars-d]

On Thu, Dec 11, 2014 at 10:17:29AM +1100, Daniel Murphy via Digitalmars-d wrote:
> "H. S. Teoh via Digitalmars-d"  wrote in message
> news:mailman.3042.1418240846.9932.digitalmars-d at puremagic.com...
> 
> >Also, storing a full AST is probably overkill -- lexing and parsing
> >the source generally doesn't take up too much of the compiler's time,
> >so we might as well just use the source code instead.
> 
> Exactly
> 
> >What makes it more worthwhile is if the AST has already been somewhat
> >processed, e.g., constants have been folded, etc.. Probably after
> >semantic1 and semantic2 have been run (though I'm not sure how far
> >one can get if the template hasn't been instantiated yet).
> 
> Not very far at all.
> 
> >This way, work that has already been done doesn't need to be repeated
> >again.
> 
> When it's templates that haven't been instantiated, you haven't done
> any of the work yet.

Well, I was thinking more of how far we *could* go, rather than how far
dmd *actually* goes currently (which is nowhere at all, since all it
does right now is to parse the template, until you instantiate it).

But I suspect you can't go too far -- at least, not if the code actually
depends on the template arguments in any meaningful way. As an extreme
case, Dicebot's example is one where you can't go anywhere at all:

	auto myFunc(string code)() {
		return mixin(code);
	}

On the other extreme, you have templates that really shouldn't be
templates because they don't actually depend on their template
arguments:

	auto myFunc(A...)() {
		return 1+2*3/4-5;
	}

You could basically already compile the entire function without caring
for the template arguments.

Real-life use cases, of course, generally fall somewhere in between
these two extremes. So I'd expect they would have some parts that cannot
be processed any further than parsing, and other parts that can
ostensibly go quite far, depending on how independent they are of the
template arguments.

Hmm, on second thoughts, this seems to be an interesting direction to
explore, because template code that you *can* get quite far on, also
represents code that is quite independent of template arguments, which
means a large part of them should be identical across different template
arguments. That makes them candidates for being merged, which would help
reduce template bloat. By attempting analysis of template bodies, the
compiler might be able to automatically identify these
"mostly-independent" pieces of code, and perhaps apply some strategies
for automatic code merging.


T

-- 
Windows 95 was a joke, and Windows 98 was the punchline.