Yigal Chripun wrote:
On 10/10/2009 00:36, Christopher Wright wrote:
Yigal Chripun wrote:
On 09/10/2009 00:38, Christopher Wright wrote:
It makes macros highly compiler-specific, or requires the compiler's
AST
to be part of the language.
Nemerle took the nuclear option, and its macros are all-powerful.
That's
a reasonable way of doing things. I'd be happy with a more restricted
system that's easier to standardize, especially if it got rid of all
the
hacky string manipulation in current D metaprogramming. (Seriously,
even
__traits returns string arrays for a lot of stuff. It's ridiculous.)
It doesn't have to be compiler specific. all is needed is a
standardized API to the compiler.
Right. It adds something huge that's normally compiler-specific to the
language. This makes me uncomfortable. It greatly increases the
difficulty of implementation.
I disagree - a properly designed compiler will have such an API anyway.
Look at how Clang is designed - it's a modular compiler where each part
has its own library. you can combine its libs in different ways to
provide different options: a full command-line compiler, semantic
analysis for IDE, incremental builder for an IDE, etc..
that design obviously requires APIs for the different components.
What's so hackish about that?
Reread. Current D metaprogramming is hackish. Nemerle's isn't.
I was referring to what Don said that providing a hook into the compiler
is hackish.
many large modular systems do exactly that: eclipse, firefox, even the
OS itself. Unix provides syscalls which *are* an API to the OS.
a properly designed API doesn't have to expose internal implementation
details.
btw, in Nemerle they have syntax to compose/decompose AST specifically
so they don't need to expose the internal structure of the AST.
So they have a separate object model for the syntax tree that macros can
affect. This is what I would recommend for D.
What do you mean by object model?
they have a synax to manipulate AST:
<[ some code ]> would be parsed by the compiler as the AST of "some
code" and would be represented internally by the compiler specific AST
representation.
I looked up nemerle macros after this. There are a couple parts.
1. AST Mixins
It's a lot like string mixins with builtin string formatting and
automatic conversion of arguments to their string form. Syntactic sugar
on top of this. That's all that macros are. Yes, you can manipulate the
AST, but at this stage, it's entirely opaque.
2. Compiler plugins
You can define a compiler module that does arbitrary things to the AST.
Many modules will make use of macros. The Nemerle compiler might attempt
to conflate plugins with macros, but if there were an alternate
implementation of Nemerle, the difference would become very apparent
very quickly.
AST mixins are sexy. Compiler plugins are also sexy[1], but targeted
toward a much different audience. D could benefit from both, but the
latter is far lower on the list than a decent compile-time reflection
system. And of this, only compiler plugins have the issues that I
mentioned earlier.
[1] Unless you're Richard Stallman. Onoz, someone could use a
proprietary plugin with GCC!
