From: Audrey Tang <[EMAIL PROTECTED]>
Date: Tue, 4 Jul 2006 23:54:30 -0400
. . .
Well, I'm curious, as the only dynamic language with this feature --
Perl5 namely -- does not target Parrot, and the current users of this
feature is out of necessity for working around the dynlexpad-
initialization bug, not to implement any language features of their
own . . .
So far I've been holding my tongue, for fear that what I have to say is
somewhat academic, but maybe an additional perspective would help.
As it happens, Common Lisp requires full-blown evaluation during
compilation. Heck, it's had this "feature" since Day 1, since (like
Perl) that's just how it works when you don't produce an object file.
So that arguably makes it older than me (which is saying something!),
and even though it causes all kinds of implementation headaches, nobody
in all that time has been able to dispense with it. In Common Lisp,
loading a source file (i.e. to have it run interpreted) is still defined
to behave identically to loading the binary into which the source was
compiled, even if it was compiled by a separate Lisp instance. Usually,
for most programs, it does.
Even so, I can't see how it would help to use :immediate to compile
Common Lisp. The key is that the evaluation must happen in the
compiling Lisp instance. So, if the compiler sees
(eval-when (:compile-toplevel)
;; magic goes here.
)
it must translate that into PIR *separately*, compile the PIR, and then
execute it, all before it can proceed with the rest of the source [1].
Emitting an :immediate sub (or anything at all) into the same PIR stream
is just plain wrong, as the magic could have side effects that affect
subsequent compilation -- and usually does.
So, extrapolating from this perspective, I have to agree with Audrey
that I can't see a real use case for :immediate.
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Wed, 12 Jul 2006 04:03:40 +0200
On Tue, Jul 11, 2006 at 04:31:36PM -0700, Chip Salzenberg wrote:
> 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.
I think tha main problem are side-effects and compile-time vs. run-time
differences in e.g. math libs. Maybe we can sanitize the evil thing a bit :-)
But by "compile time" you both unambiguously mean "PIR compile time",
not "HLL compile time," since there's no HLL involved. But an HLL
compiler always has the option of building a PIR constant at HLL compile
time [2], so that just leaves the case of human-generated PIR. So it
seems that the real question is this: Does PIR have a need to be an
eval-during-compilation language in its own right?
-- Bob Rogers
http://rgrjr.dyndns.org/
[1] Not that I can actually do this yet.
[2] Admittedly, this ducks representation issues, and ignores any
possible compression benefit.
