Daniel Carrera wrote:
Mark Overmeer wrote:
Currently in CPAN you have modules like:
Digest::MD5
Digest::SHA
Digest::MD5::Perl
Digest::SHA::PurePerl
The difference is that the first two are implemented in C and the
later two in Perl.
This is comparible to adding a "target" to each of the modules, a
suggestion when you started this long thread.
I'm thinking of a different problem. Regardless of how CPAN works,
once stuff is installed in my system, I need a way to tell Perl which
of the three different (installed) SHA modules I want to use.
If there is no good solution, people will just use the module names in
ad-hoc ways as exemplified above. Do we really want each person adding
their own thing to the module name (::Perl vs ::PurePerl)?
I figure that the ways to avoid that is to change the language
semantics or add a naming convention. I assumed that changing the
language semantics was a non-starter.
We have here an implied relationship between what is in a program (which
the perl6 specifications handle) and what is outside the program - the
implementation of functionality (eg., in C, parrot, Python, tcl-tk).
Lets call this 'external functionality'.
My view is that the program should be provided with a link to the
external functionality by the implementation. We have a "normal" set of
rules, viz., the name used by the program has a simple relationship to
the files containing the software implementing the functionality. BUT we
also should have the ability to change via a configuration process the
external name.
Hence, 'use MyModule::submodule;' by default would be located in <lib
path>/MyModule/submodule.pm' but if we set the perl6 program manager's
configuration file appropriately, it could be located in
/home/test/submodule.test
Without touching the program, different modules with the same
functionality and interfaces could be tested.
For me the crucial thing is not the design of a CPAN replacement, but
the design of the perl6 module manager. I would like something that
functions in a similar way to the alternatives system that Ubuntu (all
linux?) uses.
Such a system (a simple reference inside a program aliasing to a more
complex path by the perl6 manager) would make it much easier to enhance
the portability of perl6 programs both cross platform and cross
language. Suppose inside a perl6 program there is a unicode named module
and it needs to be run on a platform that does not fully support
unicode. The perl6 management system would provide a means for the
unicode name to be 'mangled' into a platform-dependent physical path.
The system would also provide a means for specifying more complex
locations, such as in a database or somewhere else on the internet.
Finally, we would be able to implement layering without touching the
perl6 software. Thus the perl6 program would be in one layer, the perl6
module manager in another layer. It would then be possible to have
different implementations of the module manager, such that some provide
only minimal aliasing, whilst others offer database or zip file sources.
