>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-docume
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 s
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
/*==
ww
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
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
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
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 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 s
Adam Turoff <[EMAIL PROTECTED]> writes:
> 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
In order to trim the large number of RFCs that have not been updated in
many weeks, yet are still "in development", I've prepared a report
of which RFCs are most overdue.
http://dev.perl.org/rfc/overdue.html
Here is the current status, broken down by group:
Report generated: Tue Sep 19 07:06
A not uncommon question arises, "I want to write a Perl program and
distribute it to my customers/users/co-workers, but what if they don't
have Perl?" This may be someone wanting to ship out their code to
Windows and Mac machines, or maybe they're in some company gripped in
the clutches of Java a
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' RF
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 C > > [\%{"$class\::FIELDS"}], $class>, but the current pseudohash
> > > implementation do
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 defa
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 t
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 prog
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
aut
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 C function to return all the necessary
> >information in a list co
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
> 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 seem
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 co
[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,
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. Mos
> "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes:
MGS> As I understand it, there is currently no agreed upon common event
MGS> loop architecture in Perl. This means that if two event-based modules
MGS> are used together (say, Net::IRC and POE) the one who's main loop
MGS> star
Michael G Schwern wrote:
> All these techniques have their strengths and weaknesses which I'm
> sure we're all aware of (and this is the wrong place to debate them).
> What I'm concerned is that Perl 6 has a clean, reliable, free and
> straightforward way(s) to use Perl without perl. How clean,
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, taki
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
> 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 @hash{qw(_name _rank _snum)} : public;
sub dostuff : private { }
I'd be in
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
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 ta
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 every
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 qu
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
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
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 enha
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 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
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
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 a
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
==
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
[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
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
- 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 m
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 documen
>> "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
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 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
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
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.
>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 ABST
> 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
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
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
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
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
>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
>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" }
>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
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
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
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
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
> 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
>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
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
> "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
> 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.
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]
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
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
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
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
> > 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,
>
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
> > >
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
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
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
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 bi
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 C with a generic C function
>
>
> These RFCs propose alternative solutions to this problem:
>
> RFC 37:
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 arg
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 g
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Subroutines: Replace C with a generic C function
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 6 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 21
On Tue, Sep 19, 2000 at 07:47:58AM -, Perl6 RFC Librarian wrote:
> Subroutines: Replace C with a generic C 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'.
--
Michael G Sch
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
1 - 100 of 154 matches
Mail list logo
