Don Wrote: > VladD2 wrote: > > Hi, > > > > I'm one of Nemerle developers. > > Cool! > > >> From an implementation point of view, the differences between Nemerle > >> macros and string mixins are mostly syntactic. > > > > You are deeply mistaken! > > I'd advise to study the Nemerle macro-system. > > > > You missed: pattern matching, > > Yes, you've got me there. I've assumed that pattern matching, while a > major feature, is not fundamental to the Nemerle macro-system, but I may > be mistaken. > > One obvious difference which *is* fundamental is that Nemerle macros > allow new syntax. > > Am I correct in thinking that Nemerle always requires complete ASTs? > That is, given a name "x", can you access variables "x1", "x2", "x3" ? > > > quasi-quotation, > > No, that's present in D. It's the primary reason I say that the > differences are mostly syntactic, since I see this as THE fundamental > feature. You need to be able to reenter the macro system after you have > left it. Once you can do that, you can do pretty much anything. > > BTW if you argued that D's current syntax is quite horrible, I couldn't > disagree with you. > > > running of fully functional Nemerle > > code in compile time, > > Yes, but that's a different issue. In D, running code at compile time is > regarded as an aspect of constant-folding, and is not restricted to > macros. > > > access to compiler API in macros > > In practice, has to be a library, right? Otherwise the compiler > internals would be exposed? (This is an issue we're struggling with). > > Another one of the big differences is that D doesn't allow compile-time > code to call external functions. Although it could certainly be done, it > raises some big issues. Eg, we cannot assume that the target CPU is the > same as the one we're running on. With a JIT compiler, you don't have > that problem.
Don, can you please elaborate on this point? Here's my understanding: The D compiler is run once to both 'execute' compile time code which you refer above as constant folding AND to generate the binary to execute at run-time. Nemerle separates this into two distinct steps: 1. you compile regular code inside macro definitions into a compiler plugin. 2. when compiling the intended run-time code you need to load the compiled macros from step 1 above on the command line of the compiler. Since you're talking above about cross-compilation and let's say we run the compiler on X and compile for Y, I see no problem to load precompiled macros for X in order to compile the code for Y. The only limit as far as I can see is that it won't be possible to load macros compiled by the such a cross compiler on X unless as you say JIT is employed. Perhaps it makes sense to disable macro definition in a cross-compilation scenario and only allow usage. Is there something else that I'm missing here? > > > and IntelliSense support. > > I did mention that... > > >> The one thing about them that I find really impressive is the IDE > >> integration, especially that they got syntax highlighting to work. > >> I don't know they've done that. > > > > "syntax highlighting" ? :) > > We have full IntelliSense support: syntax highlighting, code completion, > > macro > > expansion (in tooltips). > > I meant Intellisense, not just syntax highlighting. Though note that you > can't do syntax highlighting *perfectly* unless the IDE understands the > code. > > > We simply use the Nemerle compiler to achive that. > > Doesn't leave me any less impressed. <g>
