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.
Not if you have compilers from different vendors. And that's one of the
key problems with making such an API part of language -- the potential
for vendor lock-in.
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.
I stand by that.
Look, I was Forth guy back in the day. Forth and Lisp both have
hack-free macros. Particularly in the case of Forth, the language is
largely defined in the library; you can even make the case that the
compiler is part of the library. So there's no problem with the library
extending the language.
But in the case of Nemerle, it's a conventional compiler with hooks for
library code.
I just feel that Nermele's approach is diametrically opposed to Forth/Lisp.
It's personal opinion. To me, that looks like a hack.
To make one thing clear:
D's compile-time reflection is a hack. And that makes most current 'D
macros' hackish. I just feel that most of the problems lie on the
reflection side.
