"foobar" <f...@bar.com> wrote in message news:ieijt6$21m...@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.