Metacode mechanics

[Georg Wrede]

--- this post of mine is more or less academic ---

Don Clugston wrote (in D.announce:2783):


....

> That would be OK. The issue is that the compiler is a tool for 
> converting text to machine code. It has no mechanism for executing the 
> machine code.

....

> The compiler does have a mechanism for executing the "template language" 
> at compile time, which is what my code is using. But, the template 
> language (which I'll call Double D (DD) :-) ) is fundamentally different 
> to the ordinary D language (eg, it has no variables). Conceivably, a 
> compiler could convert a D function into a DD metafunction, provided 
> that it doesn't write to any variables except at initialisation, and 
> doesn't use any control structures other than "if-else" and "return",
> and all of its parameters are compile-time constants. But that would be 
> so restricted as to be almost useless.
> 
> Of course the compiler itself could have the DD code built into it, but 
> DD is a horribly inefficient language, and it would be hideous to 
> program from inside the compiler.

This brings us squarely back to a year ago, when I was discussing 
metaprogramming at length. (In several D newsgroups here.)

My original idea was that we should have 3 levels of language in "D".

  - asm
  - "normal D"
  - the metalanguage

AND that all of the meta stuff would be in a language with its own 
syntax and semantics, distinct from "normal D".

The idea was, that on all of these 3 levels of programming, the required 
  (as well as the most common) idioms are very different. Thus meta 
level concepts will be hard and murky to express in "normal D", or "an 
outgrowth of normal D".

I got the impression (perhaps mistakenly?) that Walter was strongly 
opposed to having a meta-level-specific "language" on top of D, while I 
was against the "D-outgrowth" metalanguage. Well, seems we've got right 
there now.

(--------------

> What could perhaps be done is to allow functions with all-constant 
> parameters to be converted into overloads.

This is definitely a worthy idea.

-------------)

Back to the issue at hand:

What I'm still saying, is that (even though Walter and Don have made 
completely kick-ass progress here), there's a glass ceiling waiting for 
us at this rate. By the time we have evolved the D meta business into 
something that has cleared all major obstacles, it will be a hard to 
use, cumbersome, and unobvious metalanguage. (( but still a hell of a 
lot nicer and of course much more powerful than C++ templates ever ))

Thus, it would behoove us to start examining the features and properties 
of a from-ground-up designed meta level language for D. (Definitely not 
ever even intended to anything earlier than D2.0!)

A year ago this was a pipe dream. But now, with the experience we gain 
from the existing meta language, and (foremost) since I'm not alone 
anymore in thinking that such an undertaking is actually within reach, 
we really could start outlining it now!

---

So I suggest that we:

  - continue developing the current D metalanguage
  - continue to have both Don's and Phobos' regexps
  - in this NG start the development of requirements for KBDM

KBDM being Kick-Butt D Metalanguage. :-)