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:
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.


Reply via email to