Yigal Chripun wrote:
Nick Sabalausky wrote:
I suppose that might make reverse-engineering easier which MS might
not like, but I'm not suggesting this as something that MS should like
or should even do, but rather suggesting it as (business issues
completely aside) something that would possibly gain the benefits of
both styles.
that's the exact opposite of a good solution.
I already mentioned several times before the language Nemerle which
provide the correct solution.
important fact - Nemerle is a .NET language and it does _NOT_ need to
modify the underlining system.
The way it works in Nemerle is pretty simple:
the language has a syntax to compose/decompose AST.
a Macro in nemerle is just a plain old function that uses the same
syntax you'd use at run-time and this "function" can use APIs to access
the compiler's internal data structures (the AST) and manipulate it.
you "connect" it to your regular code by either just calling it like a
regular function or by using attributes.
let's compare to see the benefits:
in D:
tango.io.Stdout("Hello World").newline; // prints at run-time
pragma(msg, "Hello World"); // prints at compile-time
in Nemerle:
macro m () {
Nemerle.IO.printf ("compile-time\n");
<[ Nemerle.IO.printf ("run-time\n") ]>;
}
// and you call it like this:
m();
Nemerle.IO.printf ("run-time\n");
notice how both use the same code, the same printf function?
the only change is that the second line inside the macro is enclosed
inside <[ ]> which means output (return) the AST for this code instead
of actually running the code and returning the result of the call.
Macros in Nemerle need to be compiled since they are regular Nemerle
code and they need to be loaded by the compiler (added to the command
line) in order to compile the code the calls the macros.
essentially these are just plugins for the compiler.
compared to the elegance of this solution, templates are just a crude
copy-paste mechanism implemented inside the compiler.
Nemerle's interesting, but it has its own issues. The largest one is
that it will have to beat history: languages with configurable syntax
have failed in droves in the 1970s.
Before I got into D, I was working on Enki. Enki was my own programming
language and of course made D look like a piece of crap. In Enki, you
had only very few primitives related to macro expansion, and you could
construct all language elements - if, while, for, structures, classes,
exceptions, you name it, from those primitive elements.
There were two elements that convinced me to quit Enki. One was that I'd
got word of a language called IMP72. IMP72 embedded the very same ideas
Enki had, with two exceptions: (1) it was created in 1972, and (2)
nobody gave a damn ever since. IMP72 (and there were others too around
that time) started with essentially one primitive and then generated
itself with a bootstrap routine, notion that completely wowed me and I
erroneously thought would have the world wowed too.
The second reason was that I've had many coffees and some beers with
Walter and he convinced me that configurable syntax is an idea that
people just don't like. Thinking a bit more, I realized that humans
don't operate well with configurable syntax. To use the hackneyed
comparison, no natural language or similar concoction has configurable
syntax. Not even musical notation or whatnot. There's one syntax for
every human language. I speculated that humans can learn one syntax for
a language and then wire their brains to just pattern match semantics
using it. Configurable syntax just messes with that approach, and
besides makes any program hugely context-dependent and consequently any
large program a pile of crap.
That being said, I have no idea whether or not Nemerle will be
successful. I just speculate it has an uphill battle to win.
Andrei
