I should mention something less obvious as well: a declaration both
manipulates symbols known to the compiler, and usually causes allocation of
storage at runtime; and for classes, composition has runtime components.
Among other things that must be split between compile-time and runtime. So
it's not just explicit initialization that relies on this.
On Thu, Jul 19, 2018 at 5:48 PM Brandon Allbery <allber...@gmail.com> wrote:
> Consider that "declarations" are actually executable code. They have
> compile-time meaning, but many also have runtime meaning. This is most
> obvious when it's a variable with an initializer: the initialization is at
> runtime, not compile time. Which means MAIN has to run after all such, or
> variables won't be initialized properly.
>
> Most commonly you would not combine a MAIN sub with non-declaring code.
>
> On Thu, Jul 19, 2018 at 5:32 PM Laurent Rosenfeld via perl6-users <
> perl6-us...@perl.org> wrote:
>
>> Hi folks,
>>
>> The documentation for the MAIN sub says that "the sub with the special
>> name MAIN is executed after all relevant phasers."
>>
>> My understanding is that MAIN automatically executes before any code
>> other than phasers happening at compile time or at the end or right after
>> the end of compilation. It seems that this is not the case. It seems that
>> my perception is wrong and that code not belonging to any sub is executed
>> before MAIN.
>>
>> For example, take this code:
>>
>> sub execute_after_main(Str $string) {
>> say "this $string after MAIN?";
>> }
>> execute_after_main("1");
>>
>> sub MAIN() {
>> say "This is MAIN so this should print first";
>> }
>> execute_after_main("2");
>>
>> This prints the following:
>>
>> this 1 after MAIN?
>> this 2 after MAIN?
>> This is MAIN so this should print first
>>
>> I was expecting the MAIN message to be printed first.
>>
>> Did I miss something? Is my understanding wrong? I'd never seen that, but
>> I guess all my scripts using MAIN had all the code in subs called from
>> MAIN. So maybe I've never hit that case.
>>
>> Cheers,
>> Laurent.
>>
>
>
> --
> brandon s allbery kf8nh sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
