Michael G Schwern <[EMAIL PROTECTED]> writes:
> On Mon, Jan 14, 2002 at 10:38:36PM +0000, Piers Cawley wrote:
>> >> Deferring BEGIN blocks 'til runtime will break rather more realworld
>> >> program than it fixes I think.
>> >
>> > Where is deferring involved?
>>
>> Err... it goes like this:
>>
>> <compile phase, includes BEGIN blocks and any modules that get 'use'd
>> by the main program>
>> <CHECK phase>
>> <INIT phase>
>> <Runtime>
>> <END>
>>
>> The compiled file gets dumped out at CHECK time as I think we said
>> before. What you propose is to defer BEGIN processing to after the
>> CHECK phase. So, how do you decide whether
>>
>> BEGIN {
>> push @INC, 'bibble';
>> }
>>
>> gets evaluated at compile time (which it should because it has far
>> reaching effects about where stuff gets included from during
>> compilation), or if it gets evaluated at runtime. Admittedly, this one
>> is rather straightforward.
>
> Oh, I think you misunderstand. Everything gets evaluated like normal.
> BEGIN blocks run, checks, whatever. Then its all compiled and dumped.
> The only difference I'm proposing is that any code in the BEGIN blocks
> (mod use statements and whatnot) is also dumped. So the resulting
> C code mirrors what the original was doing.
>
> You can get at the BEGIN code via B::save_BEGINs. You can figure out
> what's code and what's just a use statement. You can squelch any
> output with O.pm's -qq.
>
> 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?
>
>
>> Meanwhile we *do* have INIT blocks will do what you want without doing
>> the impossible. (Well, admittedly, educating programmers might well be
>> nearly impossible too, but dammit the behaviour of BEGIN blocks has
>> been *documented* since before there was a Perl compiler. And the
>> behaviour of INIT and CHECK blocks have also been clearly documented
>> since they were interested.
>>
>> This really is a case of 'READ THE FSCKING MANUAL'.
>
> Its also a case of "I'd rather not break backwards compatibility [1]
> just to feed perlcc's neurosises".
>
> There's also the factor that for all intents and purposes, Joe Average
> Programmer really shouldn't have to care about the difference between
> BEGIN, INIT and CHECK. In fact, they should be able to get along just
> fine without ever knowing INIT and CHECK even exist. Sort of like
> *foo{HASH} and the finer points of the -D switch.
And they don't. UNTIL THEY COME TO RUN perlcc on the thing. Now, maybe
there's a case for at least warning if we come across a BEGIN block
that doesn't look like a 'use' during compilation so that the
programmer can fix things.
> Its perlcc's job to reproduce the actions of the original code to the
> best of its abilities. It might turn out that its not possible. This
> is, after all, an experiment.
>From the documentation for B::Deparse:
BUGS
· The only pragmas to be completely supported are: "use
warnings", "use strict 'refs'", "use bytes", and "use
integer". ($[, which behaves like a pragma, is also
supported.)
Excepting those listed above, we're currently unable
to guarantee that B::Deparse will produce a pragma at
the correct point in the program. Since the effects
of pragmas are often lexically scoped, this can mean
that the pragma holds sway over a different portion of
the program than in the input file.
· In fact, the above is a specific instance of a more
general problem: we can't guarantee to produce BEGIN
blocks or "use" declarations in exactly the right
place. So if you use a module which affects compila
tion (such as by over-riding keywords, overloading
constants or whatever) then the output code might not
work as intended.
This is the most serious outstanding problem, and will
be very hard to fix.
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. And what you're
looking for is somewhat harder. Meanwhile, for any version of Perl
that can run perlcc, we have INIT blocks that do the Right Thing. So
by passing a small amount of work off to the programmer doing the
compilation we should get a compiled program that works.
--
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?
