Re: Module naming conventions
John M. Dlugosz wrote: Yes. did you read mine? Yes, I read your email. Sounds like you are thinking of Parrot vs pure perl, and missed my point about being utterly different implementations, not choices within one. Chances are, the most popular implementations of Perl 6 will allow C bindings, just like Perl 5. Some, like Rakudo, will have both C and Parrot bindings. In this day, users do have a choice. A Rakudo user could install a module that uses C bindings, or he could install a module that is all Perl, or he could install a module that uses Parrot. There are perfectly valid reasons why he might choose one option or another. A SMOP user might install a module that uses C bindings, or one that is all Perl. There are valid reasons why he might want one or the other. Daniel.
Re: Module naming conventions
On Jun 2, 2009, at 5:11 PM, Daniel Carrera wrote: John M. Dlugosz wrote: So CPAN6 is basically only going to be for Parrot? What are you talking about? Did you even read my email? I said that a module might be implemented in multiple languages (see Digest::SHA VS Digest::SHA::PurePerl) and someone might have both versions installed. Daniel. Speaking as an almost complete outsider (I'm a bioperl core dev writing up a perl6 port), I find the tone of several of these more recent posts (re: CPAN6 and module conventions) counterproductive. TimToady recently posted about snippiness and 'tensegrity', so I'm not the only one sensing it. chris
Re: Module naming conventions
On Tue, Jun 02, 2009 at 02:56:46AM +0200, Daniel Carrera wrote: Jon Lang wrote: On Mon, Jun 1, 2009 at 5:44 PM, Daniel Carrera daniel.carr...@theingots.org wrote: I think we might need to come up with some sort of standard naming convention to distinguish dependencies. Something that the *user* can recognize quickly when he browses CPAN. Why do we need the dependencies to be part of the name? Perl 6 provides a rugged versioning system for its modules; we should use it. I read S11 and AFAICT Perl 6 only includes metadata for *versions* and *authority*: class Dog:ver1.2.1:authcpan:JRANDOM; class Dog:ver1.2.1:authhttp://www.some.com/~jrandom; class Dog:ver1.2.1:authmailto:jran...@some.com; Just because these are the only adverbs mentioned doesn't necessarily mean they're the only ones that will be allowed. Indeed, S11 goes on to later say: The required parts for library insertion are the short name of the class/module, its version number, and a URI identifying the author (or authorizing authority, so we call it auth to be intentionally ambiguous). The fact that S11 says required parts leads me to believe that there can be other parts that aren't required. Pm
Re: Module naming conventions
On Tue, Jun 02, 2009 at 10:58:21AM +0200, Daniel Carrera wrote: John M. Dlugosz wrote: The front-end should figure out which binary is proper for your platform. I don't like that idea in the slightest. (1) It is not Perl's job to know if you have a C compiler, C libraries and tool chain. (2) If my computer can handle Perl, C and Parrot, I want the choice of what to install. (3) That includes the possibility of installing more than one module. It is perfectly legitimate to install three implementations of SHA (one in C, one in Parrot and one in pure Perl). This last one means that there has to be a way to tell Perl which of the Digest::SHA modules I want to use for this particular program. Suppose I want to install three versions of SHA. One in C, one in Perl, one in Parrot. I need a way to specify in the use statement which one I want. For the Parrot case at least, I suspect one would/could do: use SHA:fromParrot; (See the :from adverb in S11.) Indeed, for someone who is running an implementation of Perl 6 on Parrot (and where a Parrot-specific implementation of SHA is available), I would expect a plain usa SHA; to load SHA.pm which then in turn does the :fromParrot version of use. Or any other number of implementation-specific tricks that can hide the details for a generic use SHA but still make it possible for more specific requirements to be made. Pm
Re: Module naming conventions
Hi Patrick, To reduce list traffic, I'm replying to both of your emails together. Just because these are the only adverbs mentioned doesn't necessarily mean they're the only ones that will be allowed. Ok. My interpretation was that adding adverbs would require updating the spec. More importantly, I thought that it would be more difficult to get agreement on a new adverb. I figure that at this late stage in the process, you probably don't want to make a lot of language changes. In your other email, you say: For the Parrot case at least, I suspect one would/could do: use SHA:fromParrot; (See the :from adverb in S11.) That looks great. I didn't think of that. Perhaps it can be used for C as well. We might have to abuse the :from a little to include the name of the C bindings (if there is more than one option). Daniel.
Re: Module naming conventions
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. Either in the name or with the name, we need some kind of separation when you want to leave everything in one archive. With the idea of target, I think that the intention was to have them added to distributions. But above seems to me applied to pm files. Or is that not your intention? Currently, these problems are resolved in the Makefile.PL: some modules try to autodetect whether to install a binary or a pure perl implementation based on the availability of a C compile. That isn't simple. The main problem with this kind of solutions, is that you do not know beforehand which tags you need to distinguish. For instance, you may also want to release a different version for VMS (so need an OS component), for small systems, and so forth. Multiple classes of tags/targets/keywords? There are at least 2 different perspectives: . the author must be able to provide such special selection criterium in the name to avoid name-space collissions. . the user needs to know which selections there are: which possible values s/he can expect and in which combinations. An alternative solution is: . do not standardize on name extensions: simply have the author choose one. For instance a version number with his PauseID added. . have the install tools decide the best option: it should be able to search in the meta-data of the distribution for the optimal match with the platform it is on. The install tools need to be a bit smarter in this respect that what we currently use. For instance, a dependency could be: requires: Some-Module version 2.*-DANIEL (very explicit) requires: Some-Module version * (easy for user, best fit) There are (in any solution) various complications: . how do we know which versions are compatible? Other people can release incompatible modules in the same product name. . new releases by the same autor sometimes break the interface as well, with a major version number increment. . if the user does not specify an explicit version, which one to take? Who decides the preference? . will Perl6 version on PM files, like perl5, or on distributions (like all other projects do)? . how does the client get the info to do the best match? The 02packages.details file is already far too large. Server-side? A few of these problems need to be tackled in the versioning scheme, some are automatable, and some may require user intervention at install time. Some new balance between them, Perl5 is very simple compared to the need requirements. -- MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Re: Module naming conventions
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. Daniel.
Re: Module naming conventions
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.
Re: Module naming conventions
Daniel Carrera daniel.carrera-at-theingots.org |Perl 6| wrote: John M. Dlugosz wrote: The front-end should figure out which binary is proper for your platform. I don't like that idea in the slightest. (1) It is not Perl's job to know if you have a C compiler, C libraries and tool chain. (2) If my computer can handle Perl, C and Parrot, I want the choice of what to install. (3) That includes the possibility of installing more than one module. It is perfectly legitimate to install three implementations of SHA (one in C, one in Parrot and one in pure Perl). This last one means that there has to be a way to tell Perl which of the Digest::SHA modules I want to use for this particular program. Suppose I want to install three versions of SHA. One in C, one in Perl, one in Parrot. I need a way to specify in the use statement which one I want. Daniel. So CPAN6 is basically only going to be for Parrot? I think the front end too, running under the same Perl system, will know what kind it is itself! Remember, Parrot != Perl. Perl 6 is a specification, and I hope to see several solid implementations take root over the next two decades. We also want to allow Perl 6 to be suitable for applications, not only for power users, administrators, and program writers. So download an application, and it knows how to grab dependent or updated components without the clueless user even caring it's written in Perl.
Re: Module naming conventions
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.
Re: Module naming conventions
John M. Dlugosz wrote: So CPAN6 is basically only going to be for Parrot? What are you talking about? Did you even read my email? I said that a module might be implemented in multiple languages (see Digest::SHA VS Digest::SHA::PurePerl) and someone might have both versions installed. Daniel.
Re: Module naming conventions
Chris Fields wrote: Speaking as an almost complete outsider (I'm a bioperl core dev writing up a perl6 port), I find the tone of several of these more recent posts (re: CPAN6 and module conventions) counterproductive. TimToady recently posted about snippiness and 'tensegrity', so I'm not the only one sensing it. Ok, I'll watch my tone. Sorry. I did try to temper my response. I admit I was a bit frustrated when I wrote, but not very. I did not think I was being too aggressive in my response. But clearly you disagree, so I will try to change. I don't seem to run into tenserity problems on IRC, and I seem to be much more productive there. I don't know why there is a difference (different people? different topics? different medium?). But whatever the reason, I think that I'll stay mostly on IRC, at least for now. Daniel.
Re: Module naming conventions
Daniel Carrera daniel.carrera-at-theingots.org |Perl 6| wrote: John M. Dlugosz wrote: So CPAN6 is basically only going to be for Parrot? What are you talking about? Did you even read my email? I said that a module might be implemented in multiple languages (see Digest::SHA VS Digest::SHA::PurePerl) and someone might have both versions installed. Daniel. Yes. did you read mine? Sounds like you are thinking of Parrot vs pure perl, and missed my point about being utterly different implementations, not choices within one.
Re: Module naming conventions
On Mon, Jun 1, 2009 at 5:44 PM, Daniel Carrera daniel.carr...@theingots.org wrote: I think we might need to come up with some sort of standard naming convention to distinguish dependencies. Something that the *user* can recognize quickly when he browses CPAN. Why do we need the dependencies to be part of the name? Perl 6 provides a rugged versioning system for its modules; we should use it. -- Jonathan Dataweaver Lang
Re: Module naming conventions
Jon Lang wrote: On Mon, Jun 1, 2009 at 5:44 PM, Daniel Carrera daniel.carr...@theingots.org wrote: I think we might need to come up with some sort of standard naming convention to distinguish dependencies. Something that the *user* can recognize quickly when he browses CPAN. Why do we need the dependencies to be part of the name? Perl 6 provides a rugged versioning system for its modules; we should use it. I read S11 and AFAICT Perl 6 only includes metadata for *versions* and *authority*: class Dog:ver1.2.1:authcpan:JRANDOM; class Dog:ver1.2.1:authhttp://www.some.com/~jrandom; class Dog:ver1.2.1:authmailto:jran...@some.com; This has nothing to do with dependencies. There is no reason why the same author cannot write two variations of the same module, with different dependencies. In fact, I suspect that will happen often. Digest::SHA and Digest::SHA::PurePerl are written by the same author. He recommends the C version to most people, but he also wrote a Perl only version for people who don't have access to a C compiler. module Using the version or authority fields to denote dependencies is a much greater abuse than using the base name. Daniel.
Re: Module naming conventions
On Mon, Jun 1, 2009 at 7:50 PM, Jon Lang datawea...@gmail.com wrote: On Mon, Jun 1, 2009 at 5:44 PM, Daniel Carrera daniel.carr...@theingots.org wrote: I think we might need to come up with some sort of standard naming convention to distinguish dependencies. Something that the *user* can recognize quickly when he browses CPAN. Why do we need the dependencies to be part of the name? Perl 6 provides a rugged versioning system for its modules; we should use it. I agree entirely with Jon. This sounds like a fruitless idea and outside the scope of the language. The only idea that I would give any consideration to would be to extend the versioning metadata to allow for the user to define new metadata. That sounds too similar to the goals of XML, but it would at least allow the community to define what metadata is important. Some things are best left unsaid. -Jason s1n Switzer
Re: Module naming conventions
Daniel Carrera daniel.carrera-at-theingots.org |Perl 6| wrote: Naming issues are likely to become worse in Perl 6 when we also have modules that use Parrot. You might have three implementations of Digest::SHA, one in Perl 6, one that uses Parrot, and one that uses C. Worse, you might even find a module that depends on both Parrot *and* C. Much much worse. There will be many implementations of Perl 6, and each will have totally different non-native interfaces. The front-end should figure out which binary is proper for your platform. Non-binary source code can simply contain everything supported, and let the build process sort it out.
