Michael G Schwern <[EMAIL PROTECTED]> writes:
> On Mon, Jan 14, 2002 at 11:43:24PM +0000, Piers Cawley wrote:
>> > What's left?
>>
>> What about begin blocks with side effects. How do you propose
>> detecting the side effects. How do you deal with things that may
>> dispatch to different subroutines depending on when they are
>> evaluated? How do you deal with arrays getting initialised (and
>> possible extended) twice? How, in short do you solve the halting
>> problem?
>
> A scene from Perl: The Gathering.
>
> Piers has played the Halting Problem card your thread!
>
> Schwern counters by taping Hitler and playing two Befuddled
> Innocence cards!
>
> ;)
Tee hee.
> I don't understand. Why do we have to deal with them? Just translate
> the Perl code in the BEGIN block to C <hand wave>, dump it and make
> sure it gets run first. Right?
>
> I think I'm missing something very vital here.
Let's see if I can come up with a simple counterexample that will show
up the problem.
#!perl
my($compile_time, $start_time);
BEGIN {$compile_time .= localtime(time)}
# Later:
print "Compiled at $compile_time\n";
print "Started at $start_time\n";
...
BEGIN {$start_time .= localtime(time)}
__END__
How do you intend to distinguish between those two BEGIN blocks, one
of which must be run at script compile time, the other of which must
be run at (for want of a better description) INIT time? And neither of
which can be run twice (hence the .=).
The only thing that can make that distinction is a human being. The
compiler can probably guess that the two blocks should only be run
once (the .= is something of a giveaway there), but the information
about which side of 'writing the interpreter state out to an
executable file' the code should be run on is not available to any but
the most sophisticated of computing machines known to us.
>> The point is that even B::Deparse, which tries very hard to get BEGIN
>> blocks right, can't do this and, according to the above extract, is
>> highly unlikely to do so in the forseeable future.
>
> Like I said, I don't expect perlcc to run perfectly Right Now, but I
> do expect this to be considered a bug, not a feature. The upshot of
> this is: don't prop up the perlcc tests to shield against this.
On further reflection, the stuff that B::Deparse gets wrong doesn't
really affect B::CC. Deparse can shove BEGIN blocks in the wrong
place, but that's irrelevant in the case of B::CC, we're just
concerned with executing them in the right order. Unless the problems
of getting the scope (and hence the closures) wrong crops up in B::CC
too.
> That was the original point of this thread. Somebody will come along
> and fix it someday. That day might be tommorrow, dunno. Three weeks
> ago perlcc was declared indefinitely dead in the water, now its alive
> and kicking again. We do impossible things all the time.
No, we do *hard* things all the time. I'm merely pointing out that
what you want is actually impossible and not merely hard.
Best chance of having a compiler that can get it right is for it to
ask a human about every begin block that isn't obviously a use
statement in disguise. But if we're going to bring in human judgement
we could have just written INIT statements in the first place.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
