New syntax for string mixins

Don nospam at nospam.com
Sat Dec 18 13:00:13 PST 2010


Nick Sabalausky wrote:
> "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.

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.

>>> 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*.


More information about the Digitalmars-d mailing list