Build and Installation of modules should be implementation specific (Was: Re: 6PAN Spec question)
Em Seg, 2008-12-22 às 15:06 +1100, Timothy S. Nelson escreveu: On Sat, 20 Dec 2008, Mark Overmeer wrote: For ???B. In the current set-up, you use CPAN.pm to download, and then install. The 'cpan' script is a wrapper around CPAN.pm. CPAN.pm starts the install tool. A more convient structure would be to have an user application (maybe the same 'cpan' script), which calls some download backend to retreive the distribution and then calls the right install tool per distribution. I would say: ???B is cpan-NG That would be one way of labelling it. I prefer to leave that labelling up to the people who will actually be writing the software. For all I know, they might prefer to begin with a direct port of CPANPLUS, and work from there. While I agree that ???B plays the role that CPAN.pm does today, I do think we should leave that to be implementation specific, being the implementation responsability to provide a minimal set of features in its package manager so you can install standard Perl modules. This is important because Parrot compiles its code to bytecode, SMOP might even always run from source code (since separating compile-time from run-time may be tricky). Mix together the different Operating Systems where the module should be installed and you get something that is not really spec-able. This also makes it really cool for distribution maintainers, since they know that they can make a custom package manager to create distro-specific packages for every Perl 6 implementation. daniel
r24558 - docs/Perl6/Spec
Author: moritz Date: 2008-12-22 17:23:57 +0100 (Mon, 22 Dec 2008) New Revision: 24558 Modified: docs/Perl6/Spec/S12-objects.pod Log: [S12] fixed small typo Modified: docs/Perl6/Spec/S12-objects.pod === --- docs/Perl6/Spec/S12-objects.pod 2008-12-22 16:14:10 UTC (rev 24557) +++ docs/Perl6/Spec/S12-objects.pod 2008-12-22 16:23:57 UTC (rev 24558) @@ -188,7 +188,7 @@ Note that the Cself function is not context sensitive and thus always returns the current object as a single item even in list context. Hence if your current object happens to be an array but you did not -declare it with an explicit array variable. you need to explicitly +declare it with an explicit array variable, you need to explicitly access the elements of the array somehow: any(self) # WRONG
Question regarding Ranges
I've got a question regarding Ranges and in particular, infinite Ranges. How should a range such as: (0..Inf) or (-Inf..0) be represented when it is converted to a string? I believe that Pugs currently attempts to create a range of infinite length and provides no stringified value. I'm unable to find a definitive answer in the Apocalypses and would appreciate any clarification! Best regards, Cory
Re: Question regarding Ranges
On Mon, Dec 22, 2008 at 02:32:00PM -0800, cory.spen...@gmail.com wrote: : : I've got a question regarding Ranges and in particular, infinite : Ranges. How should a range such as: : : (0..Inf) : : or : : (-Inf..0) : : be represented when it is converted to a string? I believe that Pugs : currently attempts to create a range of infinite length and provides : no stringified value. I'm unable to find a definitive answer in the : Apocalypses and would appreciate any clarification! There's no formal requirement for unambiguous consistency in stringified values, only the need for clarity to a human viewer, so I think in such cases it's reasonable to return whatever .perl would return. Arguably we could also put some kind of meta marker on it to indicate that the value is indirectly represented, so maybe VAL(0..Inf) or some such. It's not like you'd see such values so often that the extra indication of unusualness would be unwelcome. Larry
