Leaving :immediatein PIR doesn't actually introduce any problems that we
didn't already have (and can't escape anyway).
There's a PIR file already in svn somewhere in Parrot where a :immediate
function is used to build a large table programmatically at compile time, so
that at runtime it's already completely available. That's neat.
Now think about the alternatives if your goal is to have the table ready to
go at runtime without any computational overhead at all, e.g. a CRC table.
It could be done with a separate program running outside Parrot to generate
source code, the traditional approach for such things. The form of the
output could be your DSL or not, doesn't matter. The point is, that table
has to be generated at compile time, somehow, and that takes running code
that the user wrote. User code that may have side-effects.
Thus, the key inescapable attribute of any build process that includes the
compile-time preparation of application-specific data, whether it's inside
Parrot or a Perl script called from 'make', is this:
** a user-written program is running at compile time **
and you simply cannot escape that. If you kill :immediate {and don't tell
me "deprecate", you want to kill it} the same things happen that you
complain about, they just happen outside the Parrot VM where I think you
think you can ignore them, but they're still there, still part of the whole
compilation process. Any program-generating script has all the
disadvantages you list for :immediate, and it's less convenient to boot.
Ergo, :immediate is not actually creating any problems for you in your
functional-modeling problem. The problems are inherent to user code running
at compile time. If you need to start and stop a new Parrot VM each time,
well, that's no different in principle from a programmer typing "make
distclean" to remove all the intermediate products of autoconf or op2c.pl or
whatever.
--
Chip Salzenberg <[EMAIL PROTECTED]>
