New syntax for string mixins

[Nick Sabalausky]

"foobar" <foo at bar.com> wrote in message 
news:ieijt6$21mh$1 at digitalmars.com...
> Don Wrote:
>
>> VladD2 wrote:
>> > Don Wrote:
>> >> Suppose the pre-compiled code, when run, asks what CPU it's on. What's
>> >> the answer? Is it X or Y?
>> >
>> > Current: X
>> > Target: Y
>> >
>> > Macro - a plugin to the compiler. It works on the same platform as the 
>> > compiler, but generates code through the API which abstracts the macro 
>> > from the target platform. If you need generate platform specific code, 
>> > you should worry about it in macro logic.
>> > In any case macro is a meta-programm wich generate or/and transform 
>> > code.
>>
>> Yes. But in D there's no distinction between code which is destined for
>> a macro, versus any other function. You can call a function once at
>> compile time, and the same function at compile time.

I think you mean "You can call a function once at compile time, and the same 
function at **runtime**."


>> My understanding of
>> Nemerle (which is quite likely to be wrong!) is that at least some
>> functions are callable only at compile-time.
>>

I'd be surprised. I would think that all you would have to do to use the 
same Nemerle function at both runtime and compile-time would be to include 
its module in both the "compile the compiler-plugin step" and in the "load 
compiler-plugins and compile the app" step.


>
> I don't see how there needs to be different code to accomplish the above 
> use case. You have a function that tests the hardware it's being run on. 
> When this function is called in the compiler context it would return X, 
> when it's called from the target executable it returns Y.
>

The problem with that is, what if you're generating target-platform-specific 
code at compile-time? You'd be generating code for the wrong platform. I 
think VladD2 is right: You need to keep track of both "current" system and 
"target" system. Unfortunately, there is some information about the "target" 
system the compile-time code wouldn't be able discern without giving it the 
ability to run code (RPC? Virtualization? Really, really good emulator?) on 
the target system, but then again, that's a limitation with any 
cross-compiling scenario.


>> I'm also scared of the implications of allowing arbitrary code execution
>> during compilation. Make a typo in your program, and then compilation
>> may wipe files from your hard disk, or corrupt an external database,
>> etc... On some platforms you may be able to sandbox it, but since it's
>> running as part of the compilation process, rather than with the
>> permissions it will eventually have, it just seems like a security
>> nightmare.
>>

That's an interesting point. OTOH, it's common for software to come with its 
own build script or makefile, and those can certainly do literally anything 
like you describe above - but I haven't seen that as being a real problem.


>
> This is a void argument since templates are Turing complete.
> It's *already* possible to do all of the above in D at compile time, it's 
> just a matter of how much code is required to accomplish this.
>

Not true. This is a frequent misconception about Turning-completeness. Just 
because something is Turing complete does *not* mean it can do anything that 
any other Turing complete system can do (contrary to how many college profs 
explain it). It *does* mean that it can *calculate* anything that any other 
Turing complete system can calculate. But it doesn't necessarily have 
*access* to everything that any other Turing complete system has access to. 
And D's compile-time system, whether CTFE or templates, does not currently 
provide any way to access any I/O, launch any processes, or do any direct 
memory access.