Jarrett Billingsley wrote:
On Thu, Oct 8, 2009 at 4:00 AM, Don <[email protected]> wrote:
So it looks to me like the mechanics of it are basically identical.
Just Nemerle's syntax is nicer.
Only with trivial examples. With more complicated examples they look less
identical. I'm basing my views on pages like this:
http://nemerle.org/Macros_-_extended_course._Part_2
Unless I'm totally misunderstanding this, it looks to me as though Nemerle
macros are implemented as compiler plugins.
All the advanced facilities are obtained by exposing the compiler's API!
Well they're not.. "plugins" per se as much as "compiled modules."
Okay yes that's basically a plugin :P But it's not that different from
D, where you use compile-time executed functions to do the same sorts
of things. It's just that you precompile those functions instead of
having the compiler "compile" them on every compilation.
No. CTFE is simply taking constant-folding to its logical conclusion.
But really, I don't see how this is significantly different from
hooking into the D compiler's internals with __traits, .stringof,
.mangleof and the like. So it uses an object-oriented API to access
those things instead of ad-hoc hacks. And?
The thing I think is elegant about D's approach, ugly as the syntax
currently is, is the complete separation of the lex - parse - semantic -
codegen phases. And I think CTFE is fantastic (and I plan to fix it so
it works properly). Think about how easy it is to explain.
I'm not a fan of is(typeof()) .stringof and __traits in their current
form. They are hackish indeed, and weren't originally intended for macro
development. (Actually .stringof isn't hackish, just buggy and
unspecified). BUT they demonstrate the benefit of the seperate
compilation phases. The fundamentals are strong.
> I don't know how you can trash Nemerle's approach while leaving D's
unmentioned.
What do you mean, 'unmentioned'? Hey, you started this by trashing D's
approach!
