Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Separate compilation and compile-time things

0 views
Skip to first unread message

Zohar Kelrich

unread,
Mar 2, 2006, 8:13:07 AM3/2/06
to p6l
We were discussing some confusing macro behaviours, when we came upon
this curious thing. This code is really simple in p5, as it doesn't
really have separate compilation, but in p6, the modules can be pre-
compiled or cached.
8<--
module ImportHeadache;
my $m;

sub import() {
$m++;
}

sub report is export { $m };

sub deport {...}
#-- Meanwhile, elsewhere!
module Elsewhere;
use ImportHeadache; # I'm calling import at Elsewhere's compile time!

#-- Meanwhile, another elsewhere!
module Elsewhere2;
use ImportHeadache; # I'm calling import at Elsewhere2's compile time!

#-- Main program
use v6;
use Elsewhere;
use Elsewhere2;
use ImportHeadache;

say report; # What should I say?

-->8
The result is, of course, (1..3).pick(), depending on whether the
modules were compiled by the same compiler instance at the same time.
Separate compilation may push this number down.

This is deeply weird.

The same thing can happen with macros closing over a value.
(Demonstration is left as an exercise for the weeder :D)

The problem seems to be that we have statefulness that we expect to
survive compilation boundaries.

So, should each compilation unit get a fresh environment? Or should
this simply work like I think it currently does, and just hopefully
not bite people too often? Should doing what this is trying to do be
possible in a different, longer-huffmanized way?

--
Zohar

Yuval Kogman

unread,
Mar 2, 2006, 8:19:25 AM3/2/06
to Zohar Kelrich, p6l
One way to think of your macro example (instead of the ->import one,
which is harder to define, i think):

Every time you use a module it's used by the compiler, and by the
emitted code.

The compiler loads the macros, the emitted code loads the non-macro
stuff.

Since the clsoure is created in the compiler's runtime this is
slightly consistent ;-)


--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /me supports the ASCII Ribbon Campaign: neeyah!!!

Yuval Kogman

unread,
Mar 2, 2006, 8:23:00 AM3/2/06
to Zohar Kelrich, p6l
On Thu, Mar 02, 2006 at 15:13:07 +0200, Zohar Kelrich wrote:
> We were discussing some confusing macro behaviours, when we came upon this curious thing. This code is really simple in p5, as it doesn't really have
> separate compilation, but in p6, the modules can be pre- compiled or cached.
> 8<--
> module ImportHeadache;
> my $m;
>
> sub import() {
> $m++;
> }
>
> sub report is export { $m };
>
> sub deport {...}
> #-- Meanwhile, elsewhere!
> module Elsewhere;
> use ImportHeadache; # I'm calling import at Elsewhere's compile time!
>
> #-- Meanwhile, another elsewhere!
> module Elsewhere2;
> use ImportHeadache; # I'm calling import at Elsewhere2's compile time!
>
> #-- Main program
> use v6;
> use Elsewhere;
> use Elsewhere2;
> use ImportHeadache;
>
> say report; # What should I say?
>
> -->8
> The result is, of course, (1..3).pick(), depending on whether the modules were compiled by the same compiler instance at the same time.

Perl 6 is specced such that it's always separate compilation, so
this should probably always be 0, unless you're tying the value to
disk.

The way it's handled:

$m is reallocated every time a module is used, and thrown away after
it finished compiling.

Then the resulting code will be linked, after $m was garbage
collected. This code can be relinked as many times as we want.

> The problem seems to be that we have statefulness that we expect to survive compilation boundaries.

Well, Perl 5 didn't have such boundries =)

All statefulness in Perl 6 is not saved. Values and code are
dumoped, and will be loaded on every link. This means that this does
not get saved back to disk. This also means that linkage could be
cached.

> So, should each compilation unit get a fresh environment? Or should this simply work like I think it currently does, and just hopefully not bite people
> too often? Should doing what this is trying to do be possible in a different, longer-huffmanized way?

I think separate compilation is more consistent - it allows much

--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &

/\ kung foo master: /me tips over a cow: neeyah!!!!!!!!!!!!!!!!!!!!!!

0 new messages