Separate compilation and compile-time things

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

• Separate compilation and compile-time things by Zohar Kelrich
• Re: Separate compilation and compile-time things by Yuval Kogman
• Re: Separate compilation and compile-time things by Yuval Kogman