On Wed, 2009-02-11 at 18:14 -0500, Diego Novillo wrote: > On Wed, Feb 11, 2009 at 11:46, Pjotr Kourzanov > <peter.kourza...@xs4all.nl> wrote: > > > Should we not have a way to specify a plugin in the source itself? > > This could be achieved by tagging a function with a __plugin__ > > attribute (or a #pragma), exporting the PluginAPI as a bunch of > > built-in functions and having the compiler itself (1) ensure that such > > functions only call portable built-ins, and (2) compiling/executing or > > interpreting them as compilation passes. Then, the code can just > > #include a source-level plugin to have it available just for that > > translation unit. > > But then, what would be the difference between this and just adding > your pass to the compiler? Well I guess you don't have to rebuild the compiler, once it supports such JIT plugins. Otherwise you might end up with building lots of compilers with only minor differences and getting a Makefile headache.
Also portability can be improved, since JIT plugins can be made as portable as any scripting language. > I'm not sure I understand what this would > buy you in terms of simplicity. Perhaps I'm missing something. I can imagine a situation when you'll want a set of plugins to apply only to some specific parts of your code. Or specific plugin options for some parts, but not others. For such cases, you'd better just #include an appropriate plugin or supply a parameter via a #pragma to it, rather than solve these issues in the Makefiles. As a bonus, these will have to be distributed in source form, so no illegal proprietary gambles are possible. You might get additional benefits from executing JIT plugins in a restricted or "managed" mode (only allow usage of some restricted builtins by plugin sourcecode), rather than just allowing random access to whole compiler workspace. Pjotr.
