Re: Perl 6 code - a possible compile, link, run cycle
Ingo Blechschmidt wrote:
Hi,
Yuval Kogman wrote:
On Thu, Aug 25, 2005 at 15:42:28 +0200, Ingo Blechschmidt wrote:
This section will contain all information needed:
* User-defined operators
* Other symbols exported by is export
* Exported macros
Okay, this raises a distinction:
Compile time exports
Runtime exports
Well, all exports happen at compile-time, but you're right, some exports
(regular subs) will probably not be used before runtime.
Excuse my stupid question, but what about the equivalent Perl 6 case to
the following.
use Module qw{symbol};
BEGIN {
die Not ready to compile if symbol();
}
Re: Perl 6 code - a possible compile, link, run cycle
On Thu, 25 Aug 2005 16:25:51 +0300, Yuval Kogman [EMAIL PROTECTED] wrote: [...] On Thu, Aug 25, 2005 at 11:16:56 -, David Formosa (aka ? the Platypus) = wrote: [...] use has the potentional to change the way the compiler parses the code. So use needs to be regarded. Hmm... Good point. I don't know how this is dealt with WRT to the every module is compiled with it's own compiler approach perl 6 is supposed to have. When compiling modules the compiler can seperate out stuff that will modify the caller's enviroment (exports ect) and thouse that will not. When use is seen, only this outward facing code needs to be examined. [...] Perhaps the use macro could do this on it's own. Seems sound. -- Please excuse my spelling as I suffer from agraphia. See http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more. Free the Memes.
Re: Perl 6 code - a possible compile, link, run cycle
On Wed, 24 Aug 2005 16:13:03 +0300, Yuval Kogman [EMAIL PROTECTED] wrote: [...] perl6 creates a new instance of the perl compiler (presumably an object). The compiler will only compile the actual file 'foo.pl', and disregard any 'require', 'use', or 'eval' statements. use has the potentional to change the way the compiler parses the code. So use needs to be regarded. -- Please excuse my spelling as I suffer from agraphia. See http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more. Free the Memes.
Re: Perl 6 code - a possible compile, link, run cycle
On Thu, Aug 25, 2005 at 11:16:56 -, David Formosa (aka ? the Platypus) wrote: On Wed, 24 Aug 2005 16:13:03 +0300, Yuval Kogman [EMAIL PROTECTED] wrote: [...] perl6 creates a new instance of the perl compiler (presumably an object). The compiler will only compile the actual file 'foo.pl', and disregard any 'require', 'use', or 'eval' statements. use has the potentional to change the way the compiler parses the code. So use needs to be regarded. Hmm... Good point. I don't know how this is dealt with WRT to the every module is compiled with it's own compiler approach perl 6 is supposed to have. Autrijus - do you have any solution? Either way, this simply implies that compilation is recursive, at least to determine whether the used module affects compilation. Perhaps the use macro could do this on it's own. I still think that regular linkage should be decoupled from compilation though, even if it's partially done during the compilation of a 'use' statement. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me supports the ASCII Ribbon Campaign: neeyah!!! pgptwKRhiHhGC.pgp Description: PGP signature
Re: Perl 6 code - a possible compile, link, run cycle
On Aug 25, 2005, at 7:16 AM, David Formosa (aka ? the Platypus) wrote: On Wed, 24 Aug 2005 16:13:03 +0300, Yuval Kogman [EMAIL PROTECTED] wrote: [...] perl6 creates a new instance of the perl compiler (presumably an object). The compiler will only compile the actual file 'foo.pl', and disregard any 'require', 'use', or 'eval' statements. use has the potentional to change the way the compiler parses the code. So use needs to be regarded. Conceptually, Yuval's mechanism could still work. It's just that, when you go back and compile the 'use' lines, they may invalidate a compilation unit you thought you were finished with. --Dks
Re: Perl 6 code - a possible compile, link, run cycle
Hi,
Yuval Kogman wrote:
On Thu, Aug 25, 2005 at 11:16:56 -, David Formosa (aka ? the
Platypus) wrote:
On Wed, 24 Aug 2005 16:13:03 +0300, Yuval Kogman
[EMAIL PROTECTED] wrote:
perl6 creates a new instance of the perl compiler (presumably an
object). The compiler will only compile the actual file 'foo.pl',
and disregard any 'require', 'use', or 'eval' statements.
use has the potentional to change the way the compiler
parses the code. So use needs to be regarded.
Hmm... Good point.
I don't know how this is dealt with WRT to the every module is
compiled with it's own compiler approach perl 6 is supposed to
have.
The indermediate form of a compiled .pm has to have a section containing
information about the symbols exported by the module, similar to
today's pilGlob section Pugs gives you if you use -CPIL, -CPerl5, or
-CJSON:
$ pugs -CPerl5 -we 'sub foo {...}' | \
perl -MYAML -we 'print Dump(eval )'
--- !perl/PIL::Environment
pilGlob:
[...]
- !perl/PSub
pSubBody: PNil
pSubLValue: 0
pSubName: 'main::foo'
pSubParams: [...]
pSubType: SubRoutine
pilMain: !perl/PStmts
pStmt: PNoop
pStmts: PNil
This section will contain all information needed:
* User-defined operators
* Other symbols exported by is export
* Exported macros
Note that *none* of these things influence the compilation of other .pls
and .pms unless they're exported. I.e.:
# Foo.pm
module Foo {
sub infix:+ ($a, $b) { 42 }
say 1 + 1; # 42
}
# Exported symbols: ::Foo
# test.pl
use Foo;
say 1 + 1; # 2
# Bar.pm
module Foo {
sub infix:+ ($a, $b) is export(:DEFAULT) { 42 }
say 1 + 1; # 42
}
# Exported symbols: ::Foo, infix:+
# test.pl
use Bar;
say 1 + 1; # 42
--Ingo
--
Linux, the choice of a GNU | We are Pentium of Borg. Division is futile.
generation on a dual AMD | You will be approximated.
Athlon!|
Re: Perl 6 code - a possible compile, link, run cycle
On Thu, Aug 25, 2005 at 15:42:28 +0200, Ingo Blechschmidt wrote: This section will contain all information needed: * User-defined operators * Other symbols exported by is export * Exported macros Okay, this raises a distinction: Compile time exports Runtime exports Modules can affect both the compilation of code that links against them by doing compile time exports like macros, infix subs, and so forth, and change the runtime by exporting functions and what not. When code is being compiled all the submodules are compiled, and the compile time exports are read from the linkable unit by the compiler, which determines which of these to use. This is used to affect compilation. The linkable units are cached. Any amount of time passes, and then the compiled code is run, triggerring linkage, which triggers compilation of modules. Since this compilation found the cached files, they are linked, and everyone is happy. There is one problem: If I compile foo.pl, which uses SomeModule, and SomeModule exports stuff at compile time, and foo.pl's object code is saved, what happens when SomeModule is upgraded? We can no longer link against it because potentially foo.pl's compilation depends on a certain state. The solution to this is to give the user some options: try to link the runtime symbols anyway, the user expects it to work try to recompile foo.pl if it's source code is available when compiling foo.pl, prelink SomeModule's runtime symbols into it, to ensure that no other version of SomeModule can affect foo.pl's emitted code. This can be a recursive or non recursive process. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me kicks %s on the nose: neeyah! pgpCvMECA6CmW.pgp Description: PGP signature
Re: Perl 6 code - a possible compile, link, run cycle
Hi, Yuval Kogman wrote: On Thu, Aug 25, 2005 at 15:42:28 +0200, Ingo Blechschmidt wrote: This section will contain all information needed: * User-defined operators * Other symbols exported by is export * Exported macros Okay, this raises a distinction: Compile time exports Runtime exports Well, all exports happen at compile-time, but you're right, some exports (regular subs) will probably not be used before runtime. If I compile foo.pl, which uses SomeModule, and SomeModule exports stuff at compile time, and foo.pl's object code is saved, what happens when SomeModule is upgraded? Right. If you upgrade your glibc to an ABI-incompatible version, things will probably break. But, as you say, we can... try to link the runtime symbols anyway, the user expects it to work try to recompile foo.pl if it's source code is available when compiling foo.pl, prelink SomeModule's runtime symbols into it, to ensure that no other version of SomeModule can affect foo.pl's emitted code. This can be a recursive or non recursive process. --Ingo -- Linux, the choice of a GNU | Mr. Cole's Axiom: The sum of the generation on a dual AMD | intelligence on the planet is a constant; Athlon!| the population is growing.
Re: Perl 6 code - a possible compile, link, run cycle
On 8/25/05, Yuval Kogman [EMAIL PROTECTED] wrote: On Thu, Aug 25, 2005 at 11:16:56 -, David Formosa (aka ? the Platypus) wrote: On Wed, 24 Aug 2005 16:13:03 +0300, Yuval Kogman [EMAIL PROTECTED] wrote: [...] perl6 creates a new instance of the perl compiler (presumably an object). The compiler will only compile the actual file 'foo.pl', and disregard any 'require', 'use', or 'eval' statements. use has the potentional to change the way the compiler parses the code. So use needs to be regarded. Hmm... Good point. I don't know how this is dealt with WRT to the every module is compiled with it's own compiler approach perl 6 is supposed to have. It's pretty simple, really. If module A uses module B, then you go and compile B first. Then, when you get to use B in module A, you just call B::import at compile time. That is, the modules are compiled separately, but you're allowed to run things from an already compiled module while you are compiling another one. Luke
