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
==
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.
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]
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
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
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, 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 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 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 {
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
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
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
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
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,
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
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]
On Tue, Sep 19, 2000 at 07:00:36AM -, Perl6 RFC Librarian wrote:
=head1 REFERENCES
This RFC explains the mechanism by which HASHREF context would be detected:
RFC 21: Replace Cwantarray with a generic Cwant function
These RFCs propose alternative solutions to this problem:
RFC
Would anyone find it useful to have a UNIVERSAL method which reports
on what sybols a given module exports? For example:
package Foo;
@EXPORT = qw(this @that);
@EXPORT_OK = qw($up down);
# this, @that, $up, down
print join ", ", Foo-exports;
With an
Some of oriental characters in Japanese and Korean are usually
aligned as if they have 2 columns per character. Jperl has been
patched on format built-in so that Japanese characters get
special treatments:
- 2-byte characters occupy 2 columns
* this assumption is not strictly correct, but
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:
On Mon, 18 Sep 2000, Michael G Schwern wrote:
I'm sure there are many times when pack should have been used but it
got hacked together with something else. The prime example is [...]
I must admit I'm with Michael on this one. I've been writing Perl
on and off for two or three
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? Specifically I'm wondering how
this proposal handles Unicode.
Perl should fly
On Tue, 19 Sep 2000, Dave Storrs wrote:
"Unpack takes binary data in some particular format and
disassembles it, assigning various pieces of it to variables according to
formatting that you supply. Pack does the opposite, using your supplied
formatting to crunch Perl scalar variables
At 07:29 AM 9/19/00 -0700, Dave Storrs wrote:
I guess, if I had to write an explanation of pack/unpack based on
my limited understanding, it would be something like:
"Unpack takes binary data in some particular format and
disassembles it, assigning various pieces of it to
Michael G Schwern wrote:
Would anyone find it useful to have a UNIVERSAL method which reports
on what sybols a given module exports? For example:
With an argument, it would be analgous to can():
print "Yes" if Foo-exports('this');
If exports() could take arbitrary symbols, just
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
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
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
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
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
Nathan Wiger wrote:
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 ...
I shouldn't have used the term "binary" in the proposal
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
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 noted
Perhaps what you're truly looking for is a generalized tainting mechanism.
--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. print $a
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?
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},[@_]] },
On Tue, Sep 19, 2000 at 07:29:56PM -, Perl6 RFC Librarian wrote:
This RFC proposes a builtin Creduce function, modelled after Graham Barr's
Creduce 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
On Wed, Sep 20, 2000 at 07:06:21AM +1100, Damian Conway wrote:
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
* 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
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
This RFC proposes a builtin Creduce function, modelled after
Graham Barr's Creduce 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
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 that it
Even at the risk of Destroying the Entire Universe???
What do others think?
I dunno, seems awfully extreme. Returning undef and testing with "||
die" seems sufficient to me...
$sum = reduce {$_[0]+$_[1]} 0, @numbers || die "Chaos!!";
Note with the || that way, it'll die immediately if
$sum = reduce {$_[0]+$_[1]} 0, @numbers || die "Chaos!!";
Note with the || that way, it'll die immediately if @numbers is empty,
even before destroying the universe.
Yes, but why are you passing the size of the array in there?
--tom
Tom Christiansen wrote:
$sum = reduce {$_[0]+$_[1]} 0, @numbers || die "Chaos!!";
Note with the || that way, it'll die immediately if @numbers is empty,
even before destroying the universe.
Yes, but why are you passing the size of the array in there?
'Cause I'm an idiot,
"DC" == Damian Conway [EMAIL PROTECTED] writes:
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
$sum = reduce {$_[0]+$_[1]} 0, @numbers || die "Chaos!!";
Note with the || that way, it'll die immediately if @numbers is empty,
even before destroying the universe.
Yes, but why are you passing the size of the array in there?
:-)
And even if you wrote:
$sum
Why not just check @numbers?
--tom
After an initial spark of interest, discussion related to RFC199 has
dropped off considerably. I'd like to gather any last comments anyone would
like to contribute and then freeze the RFC at the end of the week.
I'm particularly interested in commentary for and against:
- the proposal as a
On Tue, Sep 19, 2000 at 08:06:58AM -0700, Nathan Wiger wrote:
If exports() could take arbitrary symbols, just like @EXPORT
Yes, that's the idea.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee
==
No special UPPERCASE_NAME subroutines
Whoa! What about ALLCAPS variables? Should we axe all of them as well?
They're the exact same idea.
==
What ALLCAPS
==
Please show me how to write:
print STDERR @stuff;
without it, while keeping it a method of the STDERR filehandle, and
without requiring -.
==
Why not use -?
Just as a data point, I have now removed this short-circuiting bits
from the Creduce RFC. You may take that as a deferral to -- and
endorsement of -- the more general mechanism mooted in RFC 199.
Damian
Ilya Zakharevich wrote:
==
No special UPPERCASE_NAME subroutines
Whoa! What about ALLCAPS variables? Should we axe all of them as well?
They're the exact same idea.
Tom suggested:
Why not just check @numbers?
Hear, hear:
$sum = @numbers ? reduce ^_+^_, @numbers : 0;
Moreover, I suspect that the usual idiom will be:
$result = reduce $reducer, $default, @list;
That is:
$sum = reduce ^_+^_, 0, @numbers;
in which case the
Ilya Zakharevich wrote:
Why not use -?
$IO::STDERR-print @stuff;
print $IO::STDERR @stuff;
Ok, something here is extreme confused. Is not the second form an
instance of indirect object syntax?
==
This would cause about
On Tue, Sep 19, 2000 at 04:22:31PM -0700, Nathan Wiger wrote:
What ALLCAPS variables?
Well, @ARGV comes to mind.
I see, and @INC, %INC, %ENV, %SIG.
Maybe we should provide a special namespace for these as well,
besides main::?
This is a nice possible solution. There may be many others
"Perl6" == Perl6 RFC Librarian [EMAIL PROTECTED] writes:
Perl6 If the reduction subroutine has a prototype, that prototype
Perl6 determines how many items are reduced at a time. If the reduction subroutine
Perl6 is a block or has no prototype, two items are reduced each time.
... is
On Tue, Sep 19, 2000 at 04:26:47PM -0700, Nathan Wiger wrote:
$IO::STDERR-print @stuff;
print $IO::STDERR @stuff;
Ok, something here is extreme confused. Is not the second form an
instance of indirect object syntax?
It is not with a bareword at the second place, so is not causing the
In message [EMAIL PROTECTED]
Perl6 RFC Librarian [EMAIL PROTECTED] wrote:
=head1 MIGRATION ISSUES
Minimal. No-one nests iterators now because it doesn't work.
Indeed. It is just concievable though that somebody might write
each more than once as part of a single iteration -
On Tue, Sep 19, 2000 at 04:06:00PM -0600, Tom Christiansen wrote:
Why not just check @numbers?
Well if the 'use trisate' pragma ever arises (did anyone RFC that ?)
$a = 1;
$b = undef;
$c = $a + $b;
$c is undef, not 1.
Graham.
Ilya Zakharevich wrote:
On the other hand, there are only 5 names, not hundreds of them, and
they do not "get in the way", as ADD would do (prohibiting a method
named ADD). So letting them be may be also a solution...
Uhhh, I think you should check the Camel. These variables certainly do
Ilya Zakharevich wrote:
On Tue, Sep 19, 2000 at 04:26:47PM -0700, Nathan Wiger wrote:
$IO::STDERR-print @stuff;
print $IO::STDERR @stuff;
Ok, something here is extreme confused. Is not the second form an
instance of indirect object syntax?
It is not with a bareword at the
Graham Barr wrote:
On Tue, Sep 19, 2000 at 04:06:00PM -0600, Tom Christiansen wrote:
Why not just check @numbers?
Well if the 'use trisate' pragma ever arises (did anyone RFC that ?)
Following Glenn's lead, I'm in the process of RFC'ing a new null()
keyword and value that will do this:
On Tue, Sep 19, 2000 at 04:50:04PM -0700, Nathan Wiger wrote:
Ilya Zakharevich wrote:
On the other hand, there are only 5 names, not hundreds of them, and
they do not "get in the way", as ADD would do (prohibiting a method
named ADD). So letting them be may be also a solution...
On Tue, Sep 19, 2000 at 04:52:12PM -0700, Nathan Wiger wrote:
Ok, you should clarify this. You're not suggesting that indirect object
syntax be removed. You're suggesting that it should not accept
barewords. These are two separate things.
Agreed. I realized the ambiguity only after I posted
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
change. I
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
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;
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 equally
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
$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 trade
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;
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
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
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
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
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" }
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
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
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]
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
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
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:
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
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
1 - 100 of 106 matches
Mail list logo
