Automatic dependencies

[Paul Wolneykien]

21.09.2010 03:11, NotFound writes:
>> * The problem *
>>
>>    Extracting a representative set of dependencies using the described
>> method is only possible when a high-level language compiler that
>> produces a code of the module translates the set of static module
>> requirements (i.e. the "import" section entries or "use Module::Name"
>> expressions) into the corresponding load instructions and places the in
>> the module initialization section (:init :load), not the "main" module code.
>>
>> * The proposition. Questions *
>>
>>   From my point of view, that policy seems logical and natural. Is it
>> the same for you?
>
> No. Just an example: a module should be able to choose what to load
> during its initialization, depending on environment variables,
> arguments passed to a initialization sub...

   That is a striking example of a dynamic dependence: if the desired 
module is not found, the error is probably in the program command line 
or the setup of environment variables. In this case, an installation of 
the program itself can still be correct.

>
>>   Anyway I don't like policies. Instead of that I propose to make some
>> modifications to the PCT in such a way that any properly defined
>> compiler would produce a code with all static module loading procedures
>
> PCT is just a set of tools. Is not the only way of writing compilers
> targeting parrot.

   Yes. When a programmer writes such a compiler with no help of special 
tools he/she is responsible for all of the conventions and/or policies 
to be applied.

>
> Another point of view: this is just a matter of using an appropriate
> definition. If a module is loaded via PIR directives or during :load /
> :init phase, is "static" and is a dependency. If not, is dynamically
> loaded ans should not be considered a dependency.
>

   Yes again. But that is a little reverse of the problem: if the 
:load/:init phase contains some "dynamic load" code (as you stated 
above) then the resulting set of dependencies is not stable nor static. 
But I try to find a way to encode true static dependencies into the 
bytecode.

   Information about static dependencies is a very important if you want 
to get a stable software distribution. If one program can not be run 
without another program you should install both of them. In the form of 
a high-level language source code the static dependencies a explicitly 
stated: if we read "use File::Temp;" at the beginning and the program is 
compiled successfully, then there is a good reason to treat the module 
File/Temp.pm as a static dependency.


   When such a program is translated into a bytecode module the 
information that was explicitly stated is lost: without some policy or 
convention there is no way to distinguish "File/Temp.pm" from a dynamic 
dependency.


   There is still a way to extract the reliable information about static 
dependencies from the original high-level language files, i.e. Perl or 
Python module sources. That approach is in an active use in Sisyphus 
now. Many languages, same problem, different solutions. Why not to unify 
and simplify all of them? One of the Parrot goals is unification, isn't it?

-- 
Paul Wolneykien,
   ALT Linux, Ltd.