On 08/10/2009 17:25, Don wrote:
Jarrett Billingsley wrote:
On Thu, Oct 8, 2009 at 4:00 AM, Don <nos...@nospam.com> 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.
What about Nemerle's macro system design (I'm not talking about their
specific implementation of it) conflicts with D's complete separation of
lex -> parse -> semantic phases?
The phases can still be completely separate *but* extensible by the
macro system.
BTW, regarding this design aspect of DMD and D
The dragon book (second edition) says on page 966:
<quote>
Object-Oriented Versus Phase-Oriented
with an object oriented approach, all the code for a construct is
collected in the class for the construct. Alternatively, with a
phase-oriented approach the code is grouped by phase so a type checking
procedure would have a case for each construct and a code generation
procedure would have a case for each construct, and so on.
the tradeoff is that an object-oriented approach makes it easier to
change or add a construct, such as "for" statements, and a
phase-oriented approach makes it easier to change or add a phase, such
as type checking.
</quote>
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!
