Jarrett Billingsley wrote:
On Thu, Oct 8, 2009 at 11:25 AM, Don <nos...@nospam.com> 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.
All the Nemerle *implementation* is doing differently here is having
you precompile the functions that are to be executed at compile-time.
That's it. The resultant semantics are utterly the same. You are
running code at compile-time, it doesn't matter if that code is
running on the hardware or in a VM in the compiler.
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.
And Nemerle's macros are *hard* to explain? They're a function that
executes at compile time. Oh, wait! That's exactly the same as CTFE.
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!
I'm not talking about me. I'm talking about you. I don't know how you
can trash a language with macros that were designed *from the bottom
up* to be used as such and which are treated as first-class citizens,
while not admitting the hilariously ad-hoc nature of a language where
macros fall out as a consequence of a number of other, ill-defined
poorly-implemented unorthogonal features.
Sigh, I'm done.
I agree with Jarrett here. And also seeing how some things are
implemented in D using CTFE and .stringof and it's parsing is very
complex to understand. I mean, I read the code and it's very hard for me
to understand what's going on. Specially because it's mostly all of the
time parsing strings and extracting information which I don't know in
what format it comes in the first place, it's just guess and work around it.
