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::Pu
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 on
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 d
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
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:
C
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) I
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 eno
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/P
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 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 h
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
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
p
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 mod
>> 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
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
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
> 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 starte
16 matches
Mail list logo
