New syntax for string mixins

[foobar]

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>