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.
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
