> > Should I point out that RFC 225 (Superpositions) actually covers
> > most of this?
> >
> > C is equivalent in semantics to C or C.
>
> I'd love to read your not yet available paper to which the RFC
> refers. However, until it is available, and I have time to read it,
>
Glenn Linderman <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:
>> I agree with Tom; I think it's pretty self-evident that they're the
>> same thing. undef means exactly the same thing as null; that's not the
>> problem. The problem is that Perl doesn't implement the tri-state
>> logic semant
On Tue, 19 Sep 2000, Glenn Linderman wrote:
> > I agree that undef and NULL have different semantics. However, this is
> > clearly SQL's fault and not Perl's. We shouldn't repeat their mistake
> > just because we occasionally have to interface with their system.
>
> They are different. Neithe
Damian Conway wrote:
> Should I point out that RFC 225 (Superpositions) actually covers most of this?
>
> C is equivalent in semantics to C or C.
I'd love to read your not yet available paper to which the RFC refers. However,
until it is available, and I have time to read it, I'll spend my time
Russ Allbery wrote:
> I agree with Tom; I think it's pretty self-evident that they're the same
> thing. undef means exactly the same thing as null; that's not the
> problem. The problem is that Perl doesn't implement the tri-state logic
> semantics that most users of null are used to, which is
Sam Tregar wrote:
> Does it really make it more difficult? I would argue that having NULLs
> mapped to undefs is actually better than having real NULLs in Perl. An
> undef is a rather concrete and easily dealt with value - simply test with
> defined(). Plus, if you're careless enough to try to
Glenn Linderman <[EMAIL PROTECTED]> writes:
> Tom Christiansen wrote:
>>> Currently, Perl has the concept of C, which means that a value
>>> is not defined. One thing it lacks, however, is the concept of
>>> C, which means that a value is known to be unknown or not
>>> applicable. These are two s
Tom Christiansen wrote:
> >Currently, Perl has the concept of C, which means that a value is
> >not defined. One thing it lacks, however, is the concept of C,
> >which means that a value is known to be unknown or not applicable. These
> >are two separate concepts.
>
> No, they aren't.
>
> --tom
At 10:11 PM 9/19/00 -0700, Nathan Wiger wrote:
>Tom Christiansen wrote:
> >
> > >Currently, Perl has the concept of C, which means that a value is
> > >not defined. One thing it lacks, however, is the concept of C,
> > >which means that a value is known to be unknown or not applicable. These
> > >
On 20 Sep 2000, Perl6 RFC Librarian wrote:
> The absence of a C concept and keyword in Perl makes it more
> difficult to interface with relational databases and other medium which
> utilize C. Modules such as C must map C to C,
> which is an imperfect match.
Does it really make it more difficult
Tom Christiansen wrote:
>
> >Currently, Perl has the concept of C, which means that a value is
> >not defined. One thing it lacks, however, is the concept of C,
> >which means that a value is known to be unknown or not applicable. These
> >are two separate concepts.
>
> No, they aren't.
Uhhh, y
Tom Christiansen wrote:
>
> >Mostly harmless. Right before raising the famous "Can't locate method
> >..." error, Perl should check to see if C is in effect. If so,
> >it should read the C config file and ...
>
> ***LINEARLY READ A FLAT FILE!!?!?!***
I didn't get into the guts too much intentio
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtin: reduce
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 10 August 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 76
Version: 3
Status: Froze
>Mostly harmless. Right before raising the famous "Can't locate method
>..." error, Perl should check to see if C is in effect. If so,
>it should read the C config file and ...
***LINEARLY READ A FLAT FILE!!?!?!***
--tom
>Currently, Perl has the concept of C, which means that a value is
>not defined. One thing it lacks, however, is the concept of C,
>which means that a value is known to be unknown or not applicable. These
>are two separate concepts.
No, they aren't.
--tom
>Currently many programs handle error returns by examining the text of
>the error returned in $@. This makes changes in the text of the error
>message, an issue for the backwards compatibility police.
eval { fn() };
if ($@ == EYOURWHATHURTS) { }
sub fn { die "blindlesnot" }
Should I point out that RFC 225 (Superpositions) actually covers most of this?
C is equivalent in semantics to C or C.
Except, of course, the superpositional versions work...In Constant Time!
;-)
Damian
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Arrays: @#arr for getting the dimensions of an array
=head1 VERSION
Maintainer: Buddha Buck <[EMAIL PROTECTED]>
Date: 8 Sep 2000
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
New pragma 'autoload' to load functions and modules on-demand
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 24 Aug 2000
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Provide a standard module to simplify the creation of source filters
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 20 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 264
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add null() keyword and fundamental data type
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 263
Version: 1
Status: De
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Index Attribute
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 262
Version: 1
Status: Developing
=head1 ABSTRACT
An attr
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Pattern matching on perl values
=head1 VERSION
Maintainer: Steve Fink <[EMAIL PROTECTED]>
Date: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 261
Version: 1
Status: Developing
=head1 ABST
>The warning for the use of an unassigned variable should be "use of
>uninitialized variable C<$x>".
The problem with that idea, now as before, is that this check happens
where Perl is looking at a value, not a variable. Even were it possible
to arduously modify Perl to handle explicitly named
On Tue, Sep 19, 2000 at 08:14:24PM -0600, Tom Christiansen wrote:
> >Following Glenn's lead, I'm in the process of RFC'ing a new null()
> >keyword and value
>
> As though one were not already drowning in a surfeit of subtly
> dissimilar false values.
Hear, hear.
Three-valued logic is enough.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Arrays: Use list reference for multidimensional array access
=head1 VERSION
Maintainer: Buddha Buck <[EMAIL PROTECTED]>
Date: 8 Sep 2000
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
All perl generated errors should have a unique identifier
=head1 VERSION
Maintainer: Chaim Frenkel <[EMAIL PROTECTED]>
Date: 9 Aug 2000
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
N
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
variable usage warnings
=head1 VERSION
Maintainer: Steve Fink <[EMAIL PROTECTED]>
Date: 2 Aug 2000
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 12
Version: 2
Status: Deve
> Let me ask you:
>
>foo('a','b', 'c')
>
> Is 'b' the 1st parameter or the 2nd?
This is the classical mistake of confusing indices and ordinals.
The 1st argument is bound to the parameter whose index is [0],
The 2nd argument is bound to the parameter whose index is [1], etc.
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> But I'm *never* going to take out ^0. Having ^1 mean $_[0] is Just
DC> Plain Wrong.
Though I see your point. I'm not sure how many would make the connection
between ^1 and $_[0].
I see ^1 as the _first_ argument not as the zero-th offs
>> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>TC> I would be opposed to any mechanism that could allow people
>TC> to have their code without its attendant documentation.
>Why?
>What if I have one or two development boxes, and two handfuls of
>production machines. I don't need d
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
TC> I would be opposed to any mechanism that could allow people
TC> to have their code without its attendant documentation.
Why?
What if I have one or two development boxes, and two handfuls of
production machines. I don't need documen
> Ummm...Maybe I'm missing something, but how does reduce() know the
> difference between
>
> $sum = reduce ^_+^_, 0, @values;
>
> unshift @values, 0;
> $sum = reduce ^_+^_, @values;
There *isn't* any difference. Both versions guarantee that the list
Ilya Zakharevich wrote:
>
> $_ is not ALLCAPS. @EXPORT_OK should die (see RFC 233). @ISA is on
> its way to its grave already, see C.
Yeah, but you're still just sidestepping my point. Your position seems
poised on the hope that no more special variables get introduced, or
that some of the exi
>Ummm...Maybe I'm missing something, but how does reduce() know the
>difference between
>$sum = reduce ^_+^_, 0, @values;
>unshift @values, 0;
>$sum = reduce ^_+^_, @values;
You know, I really find it much more legible to consistently write
these sorts of thing with brac
> In any case, the preferred option should be to provide a default value:
>
> $sum = reduce ^_+^_, 0, @values;
>
> which is always cleaner *and* shorter. :-)
Ummm...Maybe I'm missing something, but how does reduce() know the
difference between
$sum = reduce ^_+^_, 0, @values;
On Tue, Sep 19, 2000 at 07:17:20PM -0700, Nathan Wiger wrote:
> > ==
> > Either way I'm not sure it solves the problem; if each module asserts
> > that *they* are the smarter one then you either wind up with the same
> > situation you
>> (SE), AFAIK, and therefore the man pages should be an option that could be
>> deleted to save space.
>This is already an option, and has been for years. I don't imagine that
>would change in perl6.
I should much prefer to see random modules deleted instead.
--tom
> > $sum = @numbers ? reduce ^_+^_, @numbers : 0;
>
> Although we're back to the pain of what happens when @numbers is
> really fn(). This is unsatisfactorily nonidempotent (aliapotent? :-)
>
> $sum = fn() ? reduce ^_+^_, fn() : 0;
It would seem likely that most would tr
> ==
> Either way I'm not sure it solves the problem; if each module asserts
> that *they* are the smarter one then you either wind up with the same
> situation you have now or even worse contention.
>
>> $IO::STDERR->print @stuff;
>> print $IO::STDERR @stuff;
You know, I already resent having to use STDERR instead of stderr.
Adding five noisy characters, or seven, is way, way over the top.
As for system globals, when one suggested to Larry that these be
something on the order of SYS::ARGV
Damian Conway wrote:
>
> The problem with specifying them as attributes is that I do not believe
> there is any way (or even any proposed way) of applying attributes to
> a hash entrie or a hash slice, nor is there any way of *retrospectively*
> applying an attribute to a hash that has already be
==
> This RFC proposes a minimal efficient well-scaling mechanism for
exporting.
> Only export of subroutines and tags are supported by this
mechanism.
>
Though I'm not completely sure how the implementation works in other
compiled
>Tom suggested:
> > Why not just check @numbers?
>Hear, hear:
> $sum = @numbers ? reduce ^_+^_, @numbers : 0;
Although we're back to the pain of what happens when @numbers is
really fn(). This is unsatisfactorily nonidempotent (aliapotent? :-)
$sum = fn() ? reduce ^_+^_, fn() : 0
>Following Glenn's lead, I'm in the process of RFC'ing a new null()
>keyword and value
As though one were not already drowning in a surfeit of subtly
dissimilar false values.
--tom
On Tue, Sep 19, 2000 at 06:39:49PM -0700, Nathan Wiger wrote:
> > The presence of a method STORE is visible outside of the module, and
> > may be &required* if the module follows some published (non-Perl) API.
> > Variables are of different ilk.
>
> I think you're overlooking they can both be equ
Ilya Zakharevich wrote:
>
> The presence of a method STORE is visible outside of the module, and
> may be &required* if the module follows some published (non-Perl) API.
> Variables are of different ilk.
I think you're overlooking they can both be equally visible:
$Foo::DEBUG = 1;
Foo::S
Adam Turoff wrote:
>
>On Tue, Sep 19, 2000 at 07:26:17PM -0400, Bradley M. Kuhn wrote:
> > I am curious if this applies to any Working Groups besides
>perl6-language.
>
>I don't see why not. We're nearing the 300 RFC mark, and most of
>the RFCs have yet to make it to v2. I don't think encouagin
On Tue, Sep 19, 2000 at 07:26:17PM -0400, Bradley M. Kuhn wrote:
> I am curious if this applies to any Working Groups besides perl6-language.
I don't see why not. We're nearing the 300 RFC mark, and most of
the RFCs have yet to make it to v2. I don't think encouaging
hit-and-run RFC submission
Thanks to everyone for their valuable feedback on this RFC.
Clearly the proposed solution is not adequate, perhaps because
it does not address the central issue that iterators really ought
to be stateful objects, rather than statefree functions.
I don't have time to rework the proposal from scra
On Tue, 19 Sep 2000, Curtis Jewell wrote:
> (SE), AFAIK, and therefore the man pages should be an option that could be
> deleted to save space.
This is already an option, and has been for years. I don't imagine that
would change in perl6.
--
Andy Dougherty [EMAIL PROTECTED]
At 04:57 PM 9/19/00 -0700, Nathan Wiger wrote:
>Following Glenn's lead, I'm in the process of RFC'ing a new null()
>keyword and value that will do this:
>
> $a = 1;
> $b = null;
> $c = $a + $b;
>
>$c is null, not 1.
>
>Since undef() has established semantics, I don't think these should
>chan
On Tue, Sep 19, 2000 at 06:49:20PM -0500, Curtis Jewell wrote:
> From: "Adam Turoff" <[EMAIL PROTECTED]>
> > Are you proposing something like this:
> >
> > Standard distribution:
> > 1: Everything (core, docs, standard modules)
> >
> > Alternative Distribution:
> > 2a: core language (+ pragmatic m
At 11:21 -0400 2000.09.18, Chaim Frenkel wrote:
>CN> I don't think you understand ... if you use $ENV{TZ}, at least it can be
>CN> changed for each user, for when you change time zones, DST, etc. For
>CN> Config.pm, you have to edit a global value. Ick.
>
>But the OS's idea of the epoch is globa
- Original Message -
From: "Adam Turoff" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 19, 2000 15:08
Subject: Re: RFC 260 (v1) More modules
> Sorry this is so long. No time to condense it.
>
> On Tue, Sep 19, 2000 at 07:41:20PM -, Perl6 RFC Librarian wrote:
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 04:57 PM 9/18/00 +0100, Tom Hughes wrote:
>
> >Doesn't this run a significant danger of leading us straight back
> >into the perl5 problem of making debugging of the source code more
> >or less impossible?
>
> N
I have just learned of the RFC "freeze or die" deadline of 25 September 2000
(ok, I am behind on my email. :)
I am curious if this applies to any Working Groups besides perl6-language.
As chair of the Licensing Working Group, I am a bit concerned that we
haven't developed enough possible licensin
[Please forgive me for chiming in late on this thread; I just got a chance
to catch up on mailing list traffic.]
> > On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote:
> > > That's fine for the VM and the support libraries, but I'd *really* like
> > > to see the parser/front-end in Perl. T
==
What if both modules have this :override bit set at the same time?
Does the second one still win? Or does the first one win again?
==
It is wise to live the behaviour
One of the major outstanding issues is still exactly what clock Perl
intends to keep and return from the time command. There has been some
discussion of the difficulties in obtaining the Unix epoch on platforms
where the native system clock is not using the Unix epoch; Nathan, could
you update yo
> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes:
DLN> This too is something that would be very easy to do in
DLN> everything-is-an-exception world. All events throw "EVENT-whatever"
DLN> exceptions, and there you are.
and how do you dispatch on those events? an event loop should a
> These raise an exception whenever they're feeling curmudgeonly:
>
> glob require substr sysread syswrite write
>
> I presume this would fall in the lattermost category.
Very nicely expressed :-)
Damian
* Damian Conway ([EMAIL PROTECTED]) [20 Sep 2000 08:35]:
[...]
> Even at the risk of Destroying the Entire Universe???
> What do others think?
Return a specified value (such as 'undef'). It would allow for more
elegant code, I think. The universe is old enough to cope by itself.
cheers,
--
ia
The problem with specifying them as attributes is that I do not believe
there is any way (or even any proposed way) of applying attributes to
a hash entrie or a hash slice, nor is there any way of *retrospectively*
applying an attribute to a hash that has already been declared elsewhere.
Damian
On Wed, Sep 20, 2000 at 08:35:20AM +1100, Damian Conway wrote:
>> No other builtin dies like that at
>> runtime. Perhaps a return of undef would be more like other operators.
>
> That was my original proposal, but it was howled down by the
> mathematical elite, who vigorously insisted tha
Jonathan Scott Duff wrote:
>
> With the exact same semantics? I.e.,
>
> my $hash{$key} : private = $val;
>
> makes %hash non-autovivifying, thus forcing the programmer to
> "declare" all of the hash keys he intends to use?
If you wanted to declare you lexical scope separate from your
> > This RFC proposes a builtin C function, modelled after
> > Graham Barr's C subroutine from builtin.pm
>
> Please refer to List::Util rather than builtin.pm
Noted. Thanks.
> the module name was changed as many did not like the name builting,
> as it was not.
Bah. I liked
On Wed, Sep 20, 2000 at 08:22:38AM +1100, iain truskett wrote:
> I'd believe so. I think I mentally assumed that Damian was grabbing a
> syntax trick from another RFC.
Heh, I think the exact same thing is what confused me :-)
> I must say that the ^0, ^1 style notation really makes some expres
On Tue, Sep 19, 2000 at 03:23:30PM -0600, Tom Christiansen wrote:
> >> If the original list has no elements, C immediately throws an
> >> exception.
>
> >What do you mean by exception, die ? No other builtin dies like that at
> >runtime.
>
> Well, more can trigger run-time exceptions than peopl
[...]
Original:
$sorted = reduce { push @{$_[0][$_[1]%2]}, $_[1]; $_[0] } [[],[]], @numbers;
Transformed, and made erroneous:
$sorted = reduce { push @{ ^0[ ^1 % 2 ] }, ^1; ^0 }, [[],[]], @numbers;
Transformed correctly:
$sorted = reduce { push @{ ^0->[ ^1 % 2 ] }, ^1; ^0 }, [[],[]], @number
> From [EMAIL PROTECTED] Wed
Sep 20 07:43:36 2000
> Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25])
>by indy05.csse.monash.edu.au (8.8.8/8.8.8) with ESMTP id HAA27221
>for <[EMAIL PROTECTED]>; Wed, 20 Sep 2000 07:43:36 +1100 (EST)
> Received
>> If the original list has no elements, C immediately throws an
>> exception.
>What do you mean by exception, die ? No other builtin dies like that at
>runtime.
Well, more can trigger run-time exceptions than people usually notice,
but I don't know of one that does so on an empty list.
These
* Jonathan Scott Duff ([EMAIL PROTECTED]) [20 Sep 2000 07:43]:
> On Wed, Sep 20, 2000 at 07:31:35AM +1100, iain truskett wrote:
[...]
> > $sorted = reduce { push @{ ^0 [ ^1 % 2 ] }, ^1; ^0 }, [[],[]], @numbers;
> I guess I'm confused with the syntax. Shouldn't there be an -> in
> there?
> $sort
> > Collection:
> >
> > @triples = @{ reduce sub($;$$$){ [@{shift},[@_] }, [], @singles };
>
> You've a typo there
Noted. Thanks.
Damian
> > $primary_context = want 'LIST', 2, 'LVALUE';
>
> So these arguments can be passed in any order, and want checks them? I
> like it. But I worry if you say something like:
>
>my 42 @stuff = get_data;
>
> And get_data looks like:
>
>sub get_data {
I would be opposed to any mechanism that could allow people
to have their code without its attendant documentation.
--tom
>Tim Conrow wrote:
>>
>> Tom Christiansen wrote:
>> > Perhaps what you're truly looking for is a generalized tainting mechanism.
>>
>> Sounds cool, but I have only the vaguest idea what you (may) mean. Pointers?
>> RFCs? Examples? Hints?
>Sorry for the clutter, but I didn't want to come off too
>Just to note: in version 2 of the RFC, it's associated with the pad of
>the block in which the C appears.
> > then what are you going to do?
>The short answer is that there is no "manual" reset of iterators.
I am concerned about that.
sub fn(\%) {
my $href = shift;
whi
On Tue, Sep 19, 2000 at 08:41:34AM +1200, Christian Soeller wrote:
> > Finally as an overload expert what do you think about the proposals
> > to make arrays overloadable objects so one can say things like:
> >
> > @x = 3 * @y;
>
> Is this where RFC 231's suggestion for OO slicing comes in (see
Tim Conrow wrote:
>
> Tom Christiansen wrote:
> > Perhaps what you're truly looking for is a generalized tainting mechanism.
>
> Sounds cool, but I have only the vaguest idea what you (may) mean. Pointers?
> RFCs? Examples? Hints?
Sorry for the clutter, but I didn't want to come off too clueles
Nathan Torkington <[EMAIL PROTECTED]> writes:
> Randal L. Schwartz writes:
> > This proposal makes length() an un-prototypable (and therefore
> > unoverridable). Do you have a proposal for how to handle that?
>
> Do we really want everything in Perl to be overridable?
RFC 168.
-- Johan
On Wed, Sep 20, 2000 at 07:31:35AM +1100, iain truskett wrote:
> * Jonathan Scott Duff ([EMAIL PROTECTED]) [20 Sep 2000 07:15]:
> > On Tue, Sep 19, 2000 at 07:29:56PM -, Perl6 RFC Librarian wrote:
> > > =head1 TITLE
> > >
> > > Builtin: reduce
> [...]
> > > Separation:
> > >
> > > $s
On Tue, Sep 19, 2000 at 12:35:31PM -0700, Nathan Wiger wrote:
> > This RFC proposes two new keywords -- C and C -- that limit
> > the accessibility of keys in a hash, and of methods.
>
> I still think these should be attributes across the board:
>
>my $hash{$key} : private = $val;
>my @h
Tom Christiansen wrote:
> Perhaps what you're truly looking for is a generalized tainting mechanism.
Sounds cool, but I have only the vaguest idea what you (may) mean. Pointers?
RFCs? Examples? Hints?
--
-- Tim Conrow [EMAIL PROTECTED] |
* Jonathan Scott Duff ([EMAIL PROTECTED]) [20 Sep 2000 07:15]:
> On Tue, Sep 19, 2000 at 07:29:56PM -, Perl6 RFC Librarian wrote:
> > =head1 TITLE
> >
> > Builtin: reduce
[...]
> > Separation:
> >
> > $sorted = reduce { push @{$_[0][$_[1]%2]}, $_[1]; $_[0] }
> >
On Wed, Sep 20, 2000 at 07:06:21AM +1100, Damian Conway wrote:
>> >This RFC proposes that the internal cursor iterated by the C
>> >function be stored in the pad of the block containing the C,
>> >rather than being stored within the hash being iterated.
>>
>> Then how do you s
On Mon, Sep 18, 2000 at 08:56:28AM -0400, Karl Glazebrook wrote:
> Firstly does your proposal allow for a slice like 10..20:2 (i.e. with
> a stride of 2) ?
As shipped: no. But if this is made a primitive (which I would not
like), then the only change which is needed is to make the
tie::multi::r
On Tue, Sep 19, 2000 at 07:29:56PM -, Perl6 RFC Librarian wrote:
> This RFC proposes a builtin C function, modelled after Graham Barr's
> C subroutine from builtin.pm
Please refer to List::Util rather than builtin.pm
the module name was changed as many did not like the name builting, as it
On Tue, Sep 19, 2000 at 07:29:56PM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Builtin: reduce
...
> Collection:
>
> @triples = @{ reduce sub($;$$$){ [@{shift},[@_] }, [], @singles };
You've a typo there, it should be:
@triples = @{ reduce sub($;$$$){ [@{shift},[@_]]
I would suggest looking at the SDK that is being developed for perl5.
In fact I would suggest that is probbaly the way to go, a small-ish core
and various SDK's targeted towards different areas.
As many of these modules are maintained by separate authors, haveing
a separate SDK will allow a diff
Sorry this is so long. No time to condense it.
On Tue, Sep 19, 2000 at 07:41:20PM -, Perl6 RFC Librarian wrote:
>
> =head2 Core bloat?
>
> The most obvious objection is core bloat. 5.6.0 is already over 5
> megs and only going to get fatter. Throwing lots of modules into the
> core will
On Mon, Sep 18, 2000 at 02:31:10PM -0400, Chaim Frenkel wrote:
> How about a Base64 to match with uuencode?
> PRL> This RFC proposes simple enhancements to templates of pack/unpack builtins.
> PRL> These enhancements do not change the spirit of how pack/unpack is used.
> PRL> The semantic is enha
This too is something that would be very easy to do in
everything-is-an-exception world. All events throw "EVENT-whatever"
exceptions, and there you are.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
> >This RFC proposes that the internal cursor iterated by the C
> >function be stored in the pad of the block containing the C,
> >rather than being stored within the hash being iterated.
>
> Then how do you specify which iterator is to be reset when you wish
> to do that? Curr
On 19 Sep 2000, Perl6 RFC Librarian wrote:
> =head2 Which modules?
Just to throw out some possibilities for discussion:
Date::Manip or some other date manipulation module. Date::Manip is cool
but awfully huge, I know.
Can't think of others right at this moment.
-dave
/*==
ww
What can be done to make $ work "better", so we don't have to
make people use /foo\z/ to mean /foo$/? They'll keep writing
the $ for things that probably oughtn't abide optional newlines.
Remember that /$/ really means /(?=\n?\z)/. And likewise with \Z.
--tom
Andy Dougherty wrote:
>
> > Perl should be able to distinguish between printable strings and
> > packed binary data stored as strings (presumed to not be printable
> > text)
>
> All strings are "printable" in perl, since print just calls fwrite(). I
> can and do use perl to "print" binary data.
Perhaps what you're truly looking for is a generalized tainting mechanism.
--tom
Sam Tregar wrote:
>
> On 19 Sep 2000, Perl6 RFC Librarian wrote:
>
> > Distinguish packed binary data from printable strings
>
> What defines a "printable" string? What if I'm working in an environment
> that can "print" bytes that yours can't?
Usage DWIMishly defines a printable string. As I
>This RFC proposes that the internal cursor iterated by the C function
>be stored in the pad of the block containing the C, rather than
>being stored within the hash being iterated.
Then how do you specify which iterator is to be reset when you wish
to do that? Currently, you do this by specif
1 - 100 of 154 matches
Mail list logo
