This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add memoize into the standard library
=head1 VERSION
Maintainer: Adam Turoff [EMAIL PROTECTED]
Date: 14 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 228
Version:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Extend the window to turn on taint mode
=head1 VERSION
Maintainer: Adam Turoff [EMAIL PROTECTED]
Date: 14 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 227
It's hard to remember the sequence of values that the following
builtins return:
stat/lstat
caller
localtime/gmtime
get*
and though it's easy to look them up, it's a pain to look them up
Every Single Time.
Moreover, code like this is far from self-documenting:
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 Aug 2000
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 76
Version: 2
Status: Frozen
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
More modules
=head1 VERSION
Maintainer: Michael G Schwern [EMAIL PROTECTED]
Date: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 260
Version: 1
Status: Developing
=head1 ABSTRACT
Perl
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Fix iteration of nested hashes
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 18 Sep 2000
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 255
Version: 2
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
/*==
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
Damian Conway wrote:
That's it! I'm gonna take that whole section out and burn it!
;-)
$1 is the *only* place in Perl where an index starts at 1. *It's* the one
that's inconsistent. Fix *it*.
I'd love to. But we're stuck, unless we make a $CMD which holds what $0
currently holds, which I
On Tue, Sep 19, 2000 at 08:47:11AM +0100, Piers Cawley wrote:
That *shouldn't* be hard. If you're getting hung up on details like
=over 4, =item, L and C, then leave them out.
No, I'm getting hung up on the fact that it'll take a bunch of time to
flesh out the RFCs beyond a simple
All RFCs must fall into one of three status categories:
Developing (RFC is incomplete; commments requested)
Frozen (Comments received; nothing more to say)
Retracted (Comments received; author is removing idea from
consideration.)
(NB: 'Retracted'
Adam Turoff [EMAIL PROTECTED] writes:
On Mon, Sep 18, 2000 at 10:18:41AM -0600, Nathan Torkington wrote:
Piers Cawley writes:
The idea here is to allow people to get ideas on the lists in a rough
form where they can get some initial comments (which may blow the
'real' RFC out of the
Michael G Schwern [EMAIL PROTECTED] writes:
On Mon, Sep 18, 2000 at 09:48:27AM +0100, Piers Cawley wrote:
Michael G Schwern [EMAIL PROTECTED] writes:
Nope. fields::new() basically just does Cbless
[\%{"$class\::FIELDS"}], $class, but the current pseudohash
implementation doesn't
Chaim Frenkel [EMAIL PROTECTED] writes:
"NC" == Nicholas Clark [EMAIL PROTECTED] writes:
NC $htdoc = open uri "http://www.yahoo.com" or die; with uri in the
NC standard library and also make it easy to stack the module that
NC does uri at the top of 'file' so that the default is to call
As I understand it, there is currently no agreed upon common event
loop architecture in Perl. This means that if two event-based modules
are used together (say, Net::IRC and POE) the one who's main loop
starts up first will win.
So the question I put to you all is, would it make sense for Perl
On Tue, 19 Sep 2000, Nathan Wiger wrote:
And then there's the lexical variable issue too:
The default variable scope rules for Ruby (default: local) are
much better suited for medium-to-large scale programming tasks;
no "my, my, my" proliferation is needed for safe Ruby
I don't like OOP, you folks obviously do. Maybe docs/specs/... are interesting
for you ...
Have fun.
From: [EMAIL PROTECTED]
Newsgroups: fm.announce
Subject: Ruby 1.6.0 - An object-oriented language for quick and easy programming
Date: 19 Sep 2000 09:58:15 GMT
application: Ruby 1.6.0
On Mon, Sep 18, 2000 at 08:54:30AM -0600, Tom Christiansen wrote:
This RFC proposes that rather than three separate mechanisms (in three
separate namespaces) to determine object typing information, Perl 6
simply extend the Cref function to return all the necessary
information in a list
On Mon, 18 Sep 2000, Glenn Linderman wrote:
This is an interesting comment to be made about an interesting side effect of
this proposal.
[snip]
(1) array elements can be accessed by name
(2) member data can be looked up quicker (by array index, rather than by
hashed name)
[snip]
new RFC:
What sets Ruby apart is a clean and consistent
language design where everything is an object.
I like this part. Assuming I ever finish my last RFC I'd like Perl to
have embedded objects as well. The difference being Perl's wouldn't get
in the way, unlike Python's.
Of particular interest seems
On Tue, Sep 19, 2000 at 06:57:07AM -, Perl6 RFC Librarian wrote:
=head1 OUTSTANDING ISSUES
A few people mentioned that using memoize() as a function has some
action-at-a-distance qualities, although it is useful for caching
builtin functions such as cos() and sin().
But those could
[in Ruby documentation:]
The default variable scope rules for Ruby (default: local) are much
better suited for medium-to-large scale programming tasks; no "my,
my, my" proliferation is needed for safe Ruby programming
* Dave Storrs ([EMAIL PROTECTED]) [20 Sep 2000 02:08]:
Actually, this
Dave Storrs wrote:
The default variable scope rules for Ruby (default: local) are
much better suited for medium-to-large scale programming tasks;
no "my, my, my" proliferation is needed for safe Ruby programming
Actually, this is the bit that interests me. Most times,
At 06:58 PM 9/15/00 +0100, Simon Cozens wrote:
On Fri, Sep 15, 2000 at 12:53:29PM -0400, Dan Sugalski wrote:
The only reason I can see nice winning over fast is if nice brings in
whole
new concepts to the language. (Like, say, matrix ops or Damian's
currying stuff)
Well, taking the
At 04:57 PM 9/18/00 +0100, Tom Hughes wrote:
In message [EMAIL PROTECTED]
Dan Sugalski [EMAIL PROTECTED] wrote:
As for the language we implement perl in (and thus ultimately need to
translate to the compiler-target language), I'm thinking of something like
Chip's PIL. (Or PIL
This RFC proposes two new keywords -- Cprivate and Cpublic -- 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 @hash{qw(_name _rank _snum)} : public;
sub dostuff : private {
On Tue, Sep 19, 2000 at 12:35:31PM -0700, Nathan Wiger wrote:
This RFC proposes two new keywords -- Cprivate and Cpublic -- 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;
On Tue, Sep 19, 2000 at 08:07:33AM -0700, Dave Storrs wrote:
On Tue, 19 Sep 2000, Nathan Wiger wrote:
And then there's the lexical variable issue too:
The default variable scope rules for Ruby (default: local) are
much better suited for medium-to-large scale programming tasks;
On Tue, 19 Sep 2000, Adam Turoff wrote:
On Tue, Sep 19, 2000 at 08:07:33AM -0700, Dave Storrs wrote:
I think I would be
guardedly in favor of changing the default scope from global to local
(although I have the feeling there is something I'm not considering). What
does everyone else
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Private keys and methods
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 1 Sep 2000
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 188
Version: 2
At 03:40 AM 9/19/00 -0400, Michael G Schwern wrote:
As I understand it, there is currently no agreed upon common event
loop architecture in Perl. This means that if two event-based modules
are used together (say, Net::IRC and POE) the one who's main loop
starts up first will win.
So the
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]
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
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 only
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
I would be opposed to any mechanism that could allow people
to have their code without its attendant documentation.
--tom
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 enhanced
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
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 quote)?
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
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 data
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
"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 allow for
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 global!
No,
==
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
[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. There
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?
Not
- 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:
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 modules)
2b:
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]
==
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
(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
"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 documentation
"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 documentation
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 been
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]
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. Make
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
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
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;
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:
Should I point out that RFC 225 (Superpositions) actually covers most of this?
Cnull is equivalent in semantics to Cany() or Call().
Except, of course, the superpositional versions work...In Constant Time!
;-)
Damian
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 braces
Currently, Perl has the concept of Cundef, which means that a value is
not defined. One thing it lacks, however, is the concept of Cnull,
which means that a value is known to be unknown or not applicable. These
are two separate concepts.
No, they aren't.
--tom
Ilya Zakharevich wrote:
$_ is not ALLCAPS. @EXPORT_OK should die (see RFC 233). @ISA is on
its way to its grave already, see Cuse base.
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
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: Frozen
Tom Christiansen wrote:
Currently, Perl has the concept of Cundef, which means that a value is
not defined. One thing it lacks, however, is the concept of Cnull,
which means that a value is known to be unknown or not applicable. These
are two separate concepts.
No, they aren't.
Uhhh,
On 20 Sep 2000, Perl6 RFC Librarian wrote:
The absence of a Cnull concept and keyword in Perl makes it more
difficult to interface with relational databases and other medium which
utilize Cnull. Modules such as CDBI must map Cnull to Cundef,
which is an imperfect match.
Does it really make
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 to be
Tom Christiansen wrote:
Mostly harmless. Right before raising the famous "Can't locate method
..." error, Perl should check to see if Cautoload is in effect. If so,
it should read the Cautoload.conf config file and ...
***LINEARLY READ A FLAT FILE!!?!?!***
I didn't get into the guts too
"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 offset. To
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.
So,
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]
At 10:11 PM 9/19/00 -0700, Nathan Wiger wrote:
Tom Christiansen wrote:
Currently, Perl has the concept of Cundef, which means that a value is
not defined. One thing it lacks, however, is the concept of Cnull,
which means that a value is known to be unknown or not applicable. These
are
I'm planning to withdraw RFC184 ("Perl should support an interactive
mode"), due to lack of interest. There was little discussion of it,
and the consensus seemed to be that Cperl -de0 is "good enough" for
most purposes, and Cpsh for all others. While I do not agree, it
does mean there is no
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Distinguish packed binary data from printable strings
=head1 VERSION
Maintainer: Tim Conrow [EMAIL PROTECTED]
Date: 18 Sept 2000
Mailing List: [EMAIL PROTECTED]
Number: 258
Version: 1
Status:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtins : Make use of hashref context for garrulous builtins
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 19 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 259
On Tue, Sep 19, 2000 at 07:00:35AM -, Perl6 RFC Librarian wrote:
=head1 IMPLEMENTATION
I know almost nothing about internals, so this is probably wrong, but
see if I convey my meaning anyway.
Well, I have nothing to say about the utility of this module, but I
can say that for your
On Tue, Sep 19, 2000 at 07:47:58AM -, Perl6 RFC Librarian wrote:
Subroutines: Replace Cwantarray with a generic Cwant function
Just as long as I can still say:
return want 'LIST' ? @some_array
: $some_scalar;
I'll be happy. And, of course, want 'LVALUE'.
--
Unless I hear otherwise, I plan on freezing RFC 204 and RFC 206 this
evening (17:30 New York time), and issue a revised version of 207. The
frozen versions will be substantially identical to the versions ow
released.
On RFC 204 (LOL refs as indices), I have followed the discussion from
Ilya
On Mon, 18 Sep 2000, Bart Lateur wrote:
On 13 Sep 2000 07:07:42 -, Perl6 RFC Librarian wrote:
Many newbies think of the number of
elements in an array as its "length"
Doesn't this reflect C's idea of "a string is an array of characters"?
Which isn't the idea behind strings in Perl.
Great changes, Damian! I'm just going to check on some clarification:
When Cwant is called with arguments in a scalar context:
$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
On 19 Sep 2000 09:23:00 +0300, Ariel Scolnicov [EMAIL PROTECTED] wrote:
I'm planning to withdraw RFC184 ("Perl should support an interactive
mode"), due to lack of interest. There was little discussion of it,
and the consensus seemed to be that Cperl -de0 is "good enough" for
most
Michael G Schwern wrote:
Would anyone find it useful to have a UNIVERSAL method which reports
on what sybols a given module exports?
I don't see any reason why this should be anything other than a module.
A module in the core, if it's that important.
--
John Porter
We're building
Nathan Wiger wrote:
One thing that Nat will soon be releasing is an RFC on strict typing.
I'll also have one (hopefully) on an embedded tie-like solution that
will allow you to create your own variable types. With these you would
conceivably be able to say:
use strict 'types';
my packed
On Tue, Sep 19, 2000 at 09:23:00AM +0300, Ariel Scolnicov wrote:
I'm planning to withdraw RFC184 ("Perl should support an interactive
mode"), due to lack of interest.
I'd say leave it in. What could it hurt?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
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. print $a is perfectly fine
even if $a
On Tue, 19 Sep 2000, H.Merijn Brand wrote:
On 19 Sep 2000 09:23:00 +0300, Ariel Scolnicov [EMAIL PROTECTED] wrote:
I'm planning to withdraw RFC184 ("Perl should support an interactive
mode"), due to lack of interest. There was little discussion of it,
I seem to have missed
Tom Christiansen wrote:
Perl should fly far and fast from starting down the bumpy road where
that data is strongly typed in the mythical and deceptive text-vs-binary
sense ... Heed the wisdom of the Unix ...
Tom's exactly right. Data should be data, at least by default.
One of the
* 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] }
[[],[]],
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] |
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:
$sorted = reduce { push
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 clueless. I
Just to note: in version 2 of the RFC, it's associated with the pad of
the block in which the Ceach 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;
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 clueless. I
Collection:
@triples = @{ reduce sub($;$$$){ [@{shift},[@_] }, [], @singles };
You've a typo there
Noted. Thanks.
Damian
* 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?
$sorted =
If the original list has no elements, Creduce 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
This RFC proposes that the internal cursor iterated by the Ceach function
be stored in the pad of the block containing the Ceach, 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
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: from
1 - 100 of 132 matches
Mail list logo
