New syntax for string mixins

[Nick Sabalausky]

"Don" <nospam at nospam.com> wrote in message 
news:iej7eu$b1l$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> "foobar" <foo at bar.com> wrote in message 
>> news:ieijt6$21mh$1 at digitalmars.com...
>>> 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.
>
> Note that for this to work at all, the compiler needs to be able to 
> generate exectuable code for platform X as well as for Y -- that is, it 
> needs to include two back-ends.
>

But if the compiler doesn't have both backends then the whole question of 
"how does the user's compile-time code get handled if it's being 
cross-compiled?" becomes irrelevent - you'd have to compile it on the target 
plaform anyway, so X == Y. Or am I missing your point?

>>>> 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.
>
> I don't think it's quite the same. In a makefile, every executable is 
> listed, and so you can have some degree of control over it. But in this 
> scenario, the compiler is making calls to arbitrary shared libraries with 
> arbitrary parameters.
> It means the compiler cannot be trusted *at all*.

I suppose that's a reasonable point.