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: The game of life
I think that's something that perl6 could do better then APL. If anyone would like to channel this APL energy into APL-on-parrot, I'm sure it could some attention since the parrot 1.0 release. =) http://parAPLegic.googlecode.com/ The original implementation was basically a proof of concept to exercise some of the compiler tools and show that unicode on parrot kind of worked. If there's any interest, I can devote a few tuits to it this week. -- Will Coke Coleda
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: Anonymous multidimensional array
On Mon, Jun 1, 2009 at 10:43 PM, John M. Dlugosz And it should be an error if dimensions other than the highest are unspecified. How can it know how to shape it? Use an explicit command to shape up the argument in that case. I don't see why shape(2;*) is not a problem and shape(*;2) is a problem for an lvalue array, either each one (lazily?) demands an even number of elements, or they both fail. In general, multiply the size of the known dimensions, and that's the number of elements you need to fill up one more in the unspecified dimension direction. I do see a problem if there's more than one unspecified dimension. Though I suppose an array of shape(*;*) as an lvalue might be a constraint allowing assignment only of another 2D array?
Re: Anonymous multidimensional array
On Tue, Jun 02, 2009 at 08:21:29AM -0700, yary wrote: : I do see a problem if there's more than one unspecified dimension. : Though I suppose an array of shape(*;*) as an lvalue might be a : constraint allowing assignment only of another 2D array? I don't see why we shouldn't use the capture shape of the value by default all the time, and do linear reshaping only if the value comes in as a flat list. We've gone to some pains to allow ephemeral shaping of values through captures, and it seems like it's good error checking to check the shape of the value against the shape of the container unless explicitly defeated. That is to say, if you erase the capture shape by putting the value into list context, it linearizes it, and then the container knows to reshape. Otherwise the container attempts to use the value slicily. Larry
Re: Anonymous multidimensional array
I haven't gotten deep into the shape/array specs and I need to... nonetheless On Tue, Jun 2, 2009 at 9:55 AM, Larry Wall la...@wall.org wrote: I don't see why we shouldn't use the capture shape of the value by default all the time, and do linear reshaping only if the value comes in as a flat list. This highlights an edge case- in my mind at least, a flat list has a different shape from a one-row array. shape(*) or shape() vs shape(*;0)? Given the above, linear reshaping should not happen when given an explicitly-1D-shaped array on the right hand side, and that's something that should be spelled out and included in the spec tests. Or spell out the contradiction if I guessed wrong! We've gone to some pains to allow ephemeral shaping of values through captures, and it seems like it's good error checking to check the shape of the value against the shape of the container unless explicitly defeated. That is to say, if you erase the capture shape by putting the value into list context, it linearizes it, and then the container knows to reshape. Otherwise the container attempts to use the value slicily. I like this, though my comprehension is currently rather primitive.
r26990 - docs/Perl6/Spec
Author: lwall Date: 2009-06-02 21:28:12 +0200 (Tue, 02 Jun 2009) New Revision: 26990 Modified: docs/Perl6/Spec/S02-bits.pod Log: [S02] require failure when digits exceed radix Modified: docs/Perl6/Spec/S02-bits.pod === --- docs/Perl6/Spec/S02-bits.pod2009-06-02 19:12:39 UTC (rev 26989) +++ docs/Perl6/Spec/S02-bits.pod2009-06-02 19:28:12 UTC (rev 26990) @@ -12,8 +12,8 @@ Maintainer: Larry Wall la...@wall.org Date: 10 Aug 2004 - Last Modified: 23 May 2009 - Version: 169 + Last Modified: 2 Jun 2009 + Version: 170 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -2436,6 +2436,10 @@ :60[12,34,56] # 12 * 3600 + 34 * 60 + 56 :100[3,'.',14,16] # pi +All numbers representing digits must be less than the radix, or an +error will result (at compile time if constant-folding can catch it, +or at run time otherwise). + Any radix may include a fractional part. A dot is never ambiguous because you have to tell it where the number ends:
Re: New CPAN
On Sat, May 30, 2009 at 12:14:14PM -0600, David Green wrote: On 2009-May-30, at 12:06 pm, David Green wrote: ...what Perl6 is today, let alone what it will be tomorrow. Actually, we do kind of know what Perl will look like a decade from now, because P6 is deliberately extensible enough that we may never need a Perl 7. But that simply means that holiday photos are already a possibility: perl -MSteganography::Images pics/2009/ceylon.jpg In fact, you could do that in Perl 5 Storing things in PNGs has already been done, badly, by Acme::Steganography::Image::Png :-) Well, badly as far as the hiding bit goes. The effectiveness of the Floyd- Steinberg dithering actually surprised me. There's real software to do real steganography within JPEGs, that I think stated that it managed to use up to 1 bit in 9 without being obvious. I think that you'd have to understand the JPEG file format to make it work effectively, and I didn't need to do that to prove my point. (Which was that a photo sharing site with no file quota was not a good idea as it could be abused by third parties to completely externalise their file distribution costs) Mmm, I realise that this also means that I've had a JPEG file on CPAN for 4 years now, and no-one has commented :-) Nicholas Clark
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: Anonymous multidimensional array
Larry Wall larry-at-wall.org |Perl 6| wrote: On Tue, Jun 02, 2009 at 08:21:29AM -0700, yary wrote: : I do see a problem if there's more than one unspecified dimension. : Though I suppose an array of shape(*;*) as an lvalue might be a : constraint allowing assignment only of another 2D array? I don't see why we shouldn't use the capture shape of the value by default all the time, and do linear reshaping only if the value comes in as a flat list. We've gone to some pains to allow ephemeral shaping of values through captures, and it seems like it's good error checking to check the shape of the value against the shape of the container unless explicitly defeated. That is to say, if you erase the capture shape by putting the value into list context, it linearizes it, and then the container knows to reshape. Otherwise the container attempts to use the value slicily. Larry Consider: (@a,@b...@c) = SomeCapture; The first container, @a, being fixed-size will grab some of the elements. Now, what's left in SomeCapture is not even starting at a top-level boundary in the original structure. It's in the middle of some list some number of levels down. How does what's left of the capture imply the proper shape? It also means that given a multi-dim array, or a [**] array that can hold any morphology, the right-hand-size can't be a normal return from a map or whatever because you'll get the structure from _that_. The shape of the list is generally determined by the definitions of function return and looping statement semantics, and can't be used to formulate the structure you wanted. As it stands, list assignment is list context for the RHS. That is wise. If the Capture Revolution comes to that, it needs to be carefully thought out. --John
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.
