Sounds like you are on the right track. Separation of concerns,
standardization of some of these solutions without regard to platform or
Perl implementation, and learning from prior art.
Richard Hainsworth richard-at-rusrating.ru |Perl 6| wrote:
Daniel Carrera wrote:
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'.
Mark Overmeer wrote:
Currently in CPAN you have modules like:
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.
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
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
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