On Wed, Sep 20, 2000 at 08:03:06AM -0600, Nathan Torkington wrote:
> So we have until October 1 to freeze all the RFCs.
I love you, man!
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Damian Conway wrote:
>
> I don't think the RFC shows that at all.
Well, I think the RFC is a little rough on some things, but that doesn't
necessarily invalidate some of the points.
> Or are you implying that packages and interfaces would dwell in separate
> namespaces? If so: YUCK!
No, c'
On Thu 21 Sep, Hugo wrote:
> perl6-language-regex
>
> Summary report 2920
>
> Mark-Jason Dominus has relinquished the wg chair due to the pressure
> of other commitments; I'll be taking over the chair for the short
> time remaining. Thanks to Mark-Jason for all h
> > * There's also no need to distinguish C and C,
>
> Again, I'm not sure. As the RFC shows, it's quite easy to imagine a
> situation where you have a tangential interface specification that does
> *not* serve as the inheritance point for your class:
I don't think the RFC show
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Eliminate dump() function
=head1 VERSION
Maintainer: Dominus <[EMAIL PROTECTED]>
Date: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 267
Version: 1
Status: Developing
=head1 ABSTRACT
Get
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Any scalar can be a hash key
=head1 VERSION
Maintainer: Steve Fink <[EMAIL PROTECTED]>
Date: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 266
Version: 1
Status: Developing
=head1 ABSTRAC
I don't have time to RFC this now, as I'm leaving soon for several days.
So here's a brain dump.
Camel-3 shows some interesting hints of what's been proposed for my
declarations:
my type $var :attribute = $value;
And we all know that you can use my to declare a group of variables:
my($x,
> * The new C keyword would be unnecessary if *package
> specifications* could take attributes:
>
> interface Fetcher;
>
> would then become:
>
> package Fetcher : interface;
I'm not sure about this - seems like we're squeezing a whol
Ok, at this point I'm trying to clear up misunderstandings. I believe you
know where I stand with relation to your RFC.
On Wed, Sep 20, 2000 at 06:41:52PM -0700, Steve Fink wrote:
> Michael Fowler wrote:
> > Except for the line number reported, which is the important part.
>
> Oh. Certainly yo
On Wed, Sep 20, 2000 at 07:20:44PM -0700, Steve Fink wrote:
> Tom Christiansen wrote:
> > Steve Fink wrote:
> > >% perl -we '$x = 3; $v = "x"; eval "\$$v++"'
> > >Name "main::x" used only once: possible typo at -e line 1.
> >
> > Non sequitur. And no, I don't have time.
>
> It is relevant in that
Have a nice day. And thanks for all the fish.
Tom Christiansen wrote:
>
> >Tom Christiansen wrote:
> >>
> >> >Anything else? Any opinion on whether eval "" should do what it does
> >> >now, and be invisible for the purposes of this analysis; or if it should
> >> >be assumed to instead both use and initialize all visible variables? The
> >> >
Tom Christiansen wrote:
>
> >Tom Christiansen wrote:
> >>
> >> >It happens when I don't bother to declare something. My company has
> >> >several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is
> >> >a pain. As is $My::Package::Name::x.
> >>
> >> Far, far easier to fix behavioral
>But I see code in the XML modules that check defined (@array)
They're buggy and wrong.
--tom
> In all sincerity, your Lingua::Romana::Perligata module is a good
> example. Although not many people may desire to code perl in Latin,
> it is certainly conceivable that modules similar to Perligata may
> allow programming perl in a variety of languages native to the
> progr
>Tom Christiansen wrote:
>>
>> >It happens when I don't bother to declare something. My company has
>> >several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is
>> >a pain. As is $My::Package::Name::x.
>>
>> Far, far easier to fix behavioral problems than to hack Perl.
>>
>> --t
>Tom Christiansen wrote:
>>
>> >Anything else? Any opinion on whether eval "" should do what it does
>> >now, and be invisible for the purposes of this analysis; or if it should
>> >be assumed to instead both use and initialize all visible variables? The
>> >former produces more spurious warnings
Michael Fowler wrote:
>
> On Wed, Sep 20, 2000 at 05:20:54PM -0700, Steve Fink wrote:
> > > $foobal = 3;
> > > if (@ARGV) {
> > > $foobar = @ARGV;
> > > }
> > >
> > > print $foobar;
> > >
> > > Only warn me that $foobar is uninitialized? I always prefer it when the
> > >
>I haven't (and won't) have time to go into this in detail :-(
>
>I feel that this proposal is solving the wrong problem. The issue is
>that the original Forest and Frog (or DBI and DBI::st) classes are not
>*designed* for user-definable Frogs (DBI::st's). If that functionality
>is widely needed,
At 03:37 PM 9/17/00 -0700, I wrote:
> How about an attribute for hashes:
>
> my %foo : fixed;
>
>And now new keys cannot be inserted into the hash just by assigning to
>their values. As to how you could put them there... well the ideas that
>come to mind are [snipped]
>
Spurred on by t
On Wed, Sep 20, 2000 at 05:20:54PM -0700, Steve Fink wrote:
> > $foobal = 3;
> > if (@ARGV) {
> > $foobar = @ARGV;
> > }
> >
> > print $foobar;
> >
> > Only warn me that $foobar is uninitialized? I always prefer it when the
> > actual source of my problem is pointed out,
On Wed, Sep 20, 2000 at 01:52:47PM +0100, Nick Ing-Simmons wrote:
> Tom Hughes <[EMAIL PROTECTED]> writes:
> >
> >What I'd like to see us avoid is the current situation where trying
> >to examine the value of an SV in the debugger is all but impossible
> >for anybody other than a minor god.
>
> W
Tom Christiansen wrote:
>
> >Anything else? Any opinion on whether eval "" should do what it does
> >now, and be invisible for the purposes of this analysis; or if it should
> >be assumed to instead both use and initialize all visible variables? The
> >former produces more spurious warnings, the
Tom Christiansen wrote:
>
> >It happens when I don't bother to declare something. My company has
> >several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is
> >a pain. As is $My::Package::Name::x.
>
> Far, far easier to fix behavioral problems than to hack Perl.
>
> --tom
Not s
All this talk about adding another undef, called null, that is just a
different logical and semantical version of "not defined," or "not
known," or however you want to say it, strikes me as very odd.
I admit I am new enough to Perl that 5 was my first version, but still...
it seems better to make
Michael Fowler wrote:
>
> On Wed, Sep 20, 2000 at 03:25:11PM -0700, Steve Fink wrote:
> > > > complains, but
> > > >
> > > > $x = 3; $x = 3
> > >
> > > As it shouldn't; you've mentioned $x twice, which means you probably didn't
> > > misspell it. That your mentioning twice in this manner is sil
Ok, so you want message catalogues, and not solely on Perl but anything
in the distribution. You should say that.
--tom
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
TC> I'm saying that you can't know what to check for, because you don't
TC> know who generated the exception. Can you use your fancy constants?
Then please tell me how anyone has ever coded
$@ =~ //
They don't know what to
>It happens when I don't bother to declare something. My company has
>several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is
>a pain. As is $My::Package::Name::x.
Far, far easier to fix behavioral problems than to hack Perl.
--tom
> >Which is silly, because you shouldn't have to say '$x = $x = 3' when you
> >mean '$x = 3'. Just because there's a real reason behind it doesn't make it
> >any less silly.
>
> I'd like to see where this can happen. Sounds like someone forgot to
> declare something:
>
> our $x;
> $x =
> "CRT" == Casey R Tweten <[EMAIL PROTECTED]> writes:
CRT> rm them.
Sure, and I can sling around the manpages after they have been installed
in the wrong place. I can also run all of the make files by hand.
If I can go in and simply comment out the INSTALL section of the makefile
(which I h
On Wed, Sep 20, 2000 at 05:10:55PM -0600, Tom Christiansen wrote:
> >Which is silly, because you shouldn't have to say '$x = $x = 3' when you
> >mean '$x = 3'. Just because there's a real reason behind it doesn't make it
> >any less silly.
>
> I'd like to see where this can happen. Sounds like
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace C built-in with C function
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 15 Sep 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 230
Version:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Improved parsing and flexibility of indirect object syntax
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED
perl6-language-regex
Summary report 2920
Mark-Jason Dominus has relinquished the wg chair due to the pressure
of other commitments; I'll be taking over the chair for the short
time remaining. Thanks to Mark-Jason for all his hard work.
I'll be contacting the authors of all outsta
Tom Christiansen wrote:
>
> >Same thing. If $x is lexical, it gives a definite warning. If $x is a
> >global, it says nothing. You're right; I need to point this out in the
> >RFC.
>
> Careful:
>
> sub ouch {
> my $x;
> my $fn = sub { $x++ };
> register($fn);
>
>Anything else? Any opinion on whether eval "" should do what it does
>now, and be invisible for the purposes of this analysis; or if it should
>be assumed to instead both use and initialize all visible variables? The
>former produces more spurious warnings, the latter misses many errors.
You hav
>Which is silly, because you shouldn't have to say '$x = $x = 3' when you
>mean '$x = 3'. Just because there's a real reason behind it doesn't make it
>any less silly.
I'd like to see where this can happen. Sounds like someone forgot to
declare something:
our $x;
$x = 2;
--tom
On Wed, Sep 20, 2000 at 03:25:11PM -0700, Steve Fink wrote:
> > > complains, but
> > >
> > > $x = 3; $x = 3
> >
> > As it shouldn't; you've mentioned $x twice, which means you probably didn't
> > misspell it. That your mentioning twice in this manner is silly is beyond
> > perl's grasp.
>
> Ac
Tom Christiansen wrote:
>
> And what about $$x?
>
> Dang, are we back to this incredible confusion about what it is to be
> defined in Perl.?
>
> undef $a;
>
> That is now UNINITIALIZED. So is this:
>
> $a = undef;
>
> You have initialized it to undef. There is no reasonable differ
Michael Fowler wrote:
>
> On Wed, Sep 20, 2000 at 07:45:16PM -, Perl6 RFC Librarian wrote:
> > "VARIABLE used only once: possible typo" should be replaced with
> > warnings on uses of uninitialized variables (including lexicals).
>
> > $x = 3
>
> I don't understand, who's to say you didn't
> "Bart" == Bart Lateur <[EMAIL PROTECTED]> writes:
Bart> So length is already picky on what it accepts. You need to turn it into
Bart> print length(scalar(@a, 'this is a string'));
Bart> to get perl to accept it.
And then what it's accepting is the scalar-comma operator, giving you
the
>But that doesn't even matter that much here; I'm saying that if the
>compiler can definitely determine that you are using an uninitialized
>variable, it should warn.
...
>$x is a global. The compiler cannot detect all possible assignments to
>or accesses of globals, so it never warns about the
Eric Roode wrote:
>
> Steve Fink wrote:
> >I am merely suggesting that the compiler detect, when it can, that
> >you're trying to use the value of a variable without ever having
> >assigned a value to that variable. And in THAT message, you had better
> >know the name of the variable, since it's
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Implicit counter in for statements, possibly $#.
=head1 VERSION
Maintainer: John McNamara <[EMAIL PROTECTED]>
Date: 16 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 1
>Tom Christiansen wrote:
>> Don't forget /s's other meaning.
>Do you enjoy making people ask what you're talking about?
Of course not. I enjoy giving people enough pointers to help them
learn things for themselves.
>What other
>meaning did you have in mind, overriding $*?
Yes.
--tom
Damien Neil <[EMAIL PROTECTED]> writes:
> If I could be assured that the performance penalty was minimal, I'd
> be delighted to write
> if ($errno == any(EAGAIN EINTR)) { ... }
> over
> if ($errno == EAGAIN || $errno == EINTR) { ... }
> The former is less typing and reads more clearly (to
Tom Christiansen wrote:
> Don't forget /s's other meaning.
Do you enjoy making people ask what you're talking about? What other
meaning did you have in mind, overriding $*?
--
Robert Mathews
Software Engineer
Excite@Home
Perl6 RFCs: Overdue RFCs
Report generated: Wed Sep 20 21:40:38 2000 GMT
265 RFCs submitted.
189 RFCs in development.
126 RFCs not updated within the last 7 days.
perl6-language: 56 RFCs overdue
perl6-internals: 18 RFCs overdue
perl6-language-data: 10 RFCs overdue
perl6-language-flow: 8
At 12:38 PM 9/20/00 -0700, Glenn Linderman wrote:
>OK, scalar variables. But I see code in the XML modules that check
>defined (@array)
Then they should be fixed. That doesn't do anything useful right now.
>Interesting. I learn something every day. Today, you helped. Maybe you
>can help
>
> >$a = null;
> >$b = ($a == 42);
> >print defined($b)? "defined" : "not defined";
>
> >would print "not defined", maybe?
defined() is the wrong operator to be using there. Rather,
$a = null;
$b = ($a == 42);
print is_null($b)? "is null" : "is not null";
In general,
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Allow Varibles in tr///
=head1 VERSION
Maintainer: Richard Proctor <[EMAIL PROTECTED]>
Date: 27 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 166
Version: 3
Stat
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
counting matches
=head1 VERSION
Maintainer: Richard Proctor <[EMAIL PROTECTED]>
Date: 16 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 110
Version: 6
Status: Fro
Bart Lateur wrote:
> On 20 Sep 2000 04:07:27 -, Perl6 RFC Librarian wrote:
>
> >Where an array is declared without ':bounds', @# returns the largest
> >bounds of each dimension that has been accessed:
>
> Wouldn't that be slow?
>
It depends. The array creation RFC proposes that LOLs declared w
Buddha Buck wrote:
> On RFC 204 (LOL refs as indices), I have followed the discussion from
> Ilya that list references will have problems when objects that used
> blessed references to lists as their internal representation are used
> as indices. This does indeed seem to be a problem, but I'm unc
On Fri, 15 Sep 2000 10:29:31 +1100 (EST), Damian Conway wrote:
>Why not just give \I..\E a special "turn-on-interpolation" meaning in
>q{} docs?
This has been uppered already in the pre-discussion to this RFC.
Currently, '\I' is nothing special in q{}, and a lot of people don't
want to chage tha
On Wed, Sep 20, 2000 at 02:47:01PM -0600, Tom Christiansen wrote:
> In Perl, this is the null character: "\0"
...
> It's a shame you don't like it, but this is the way we speak.
Well, it's the way you speak. Myself, I'd call that the NUL
character. :>
- Damien, exercising a pet pe
On Wed, Sep 20, 2000 at 01:21:52PM -0700, Russ Allbery wrote:
> No offense to Damian, but I tried to read and understand his documentation
> and I thought I was back in grad school. I don't think it's the fault of
> the writing either; I think that Quantum::Superpositions is trying to do
> someth
>That was my second thought. I kinda like it, because //s would have two
>effects:
> + let . match a newline too (current)
> + let /$/ NOT accept a trailing newline (new)
Don't forget /s's other meaning.
--tom
In message <[EMAIL PROTECTED]>
Dave Storrs <[EMAIL PROTECTED]> wrote:
> This runs into problems if you currently have an iterator extant and you
> modify the hash to which it points. Immediate suggestions on how to
> handle this would be:
>
> 1) Do what the docs currently do; tel
Glenn Linderman wrote:
> Not a solution.
Frankly, you haven't demonstrated that there's a problem.
--
John Porter
On 20 Sep 2000 04:07:27 -, Perl6 RFC Librarian wrote:
>Where an array is declared without ':bounds', @# returns the largest
>bounds of each dimension that has been accessed:
Wouldn't that be slow?
--
Bart.
On Wed, Sep 20, 2000 at 11:58:08AM -0700, Glenn Linderman wrote:
> > I think that this is better done as a special overloaded object used
> > by database modules which wish to implement SQL-style tri-state logic.
>
> It could be done as an overloaded object. You'd have to be able to overload all
On Wed, 20 Sep 2000 10:03:08 +0100, Hugo wrote:
>In <12839.969393548@chthon>, Tom Christiansen writes:
>: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.
> I have a pretty primitive idea in my head: suppose a Taxi object has
> multiple inheritance, it inherits from both a Car and a Driver... So a
> Taxi is both a Car and a Driver. But shouldn't you also make this that a
> Taxi is a Car that also *contains* a Driver, instead of *being* o
On Wed, Sep 20, 2000 at 07:45:16PM -, Perl6 RFC Librarian wrote:
> "VARIABLE used only once: possible typo" should be replaced with
> warnings on uses of uninitialized variables (including lexicals).
> $x = 3
I don't understand, who's to say you didn't misspell $x? If you're only
using it
* Russ Allbery ([EMAIL PROTECTED]) [21 Sep 2000 07:22]:
> Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> > Yep, this is bad IMHO. Your concern is valid I think, but your
> > "solution" isn't a good one. Why not just use a module like
> > Damian's Quantum::Superpositions?
> No offense to Dam
Tom Christiansen wrote:
>
> By your "reasoning", we can just add infinitely more things that
> take twice a few pages to explain.
>
> Perl is already too hard.
Yes, it is.
And that's why I'm against C.
(Had to get that plug in there) ;-)
-Nate
Thanks for getting this RFC together, Piers.
A few comments:
* I suggest you remove my alternative C<:must(Foo)> suggestion.
It's too ugly to live, inless you just want to use it as a
scare tactic to encourage Larry to chose the C
syntax instead ;-)
>> I'm not happy with your use of "coerce". There's no mutation. It simply
>> *is* those things.
>Fine. So, in particular, it _isn't_ null.
Of course it's null. That's why it has length zero. Stop speaking
SQL at me. I'm speaking Perl.
>> 4) The antiïinitialized value is autovivified to a
>Tom Christiansen wrote:
>> > no strict;
>> > $a = undef;
>> > $b = null;
>>
>> Perl already has a null string: "".
>That's an empty string. In any case, if you really want to call it a
>null string, that's fine, just a little more likely to be
>misinterpreted.
In Perl, this is t
On Mon, 18 Sep 2000 13:26:45 -0700, Glenn Linderman wrote:
>> Read RFC 241 for a brief overview of pseudo-hash problems.
>
>I've already read RFC 241. Re-reading in this context results in the following
>comments/quests for information. The remaining quotes here come from RFC 241...
>
>>
Damian Conway wrote:
>
> I didn't see any mention of my plea that C should pass the
> original variable being tied as one of its arguments. :-(
That's because it's a dumb idea!!
**Kidding!**
I forgot about this, sorry. I'll add it to the next version ;-)
> my $x = 10;
> ti
>> For example, assuming this code:
>>$name = undef;
>>print "Hello world!" if ($name eq undef);
>So don't do that. Use C if you want to ask that question.
That's why I want to change the names of these things. The current
situation invites errors such as seen previously.
Actually,
>That's not much different than the cost of undef, so I fear it proves
>nothing, universally.
YOU OVERQUOTEDsen wrote:
YOU OVERQUOTEDkes a few pages, and a few truth tables to explain NULL.
YOU OVERQUOTEDonly take a few pages and a few examples, to explain the
YOU OVERQUOTED between undef and nu
I didn't see any mention of my plea that C should pass the
original variable being tied as one of its arguments. :-(
E.g.:
sub ReadOnly::TIESCALAR {
my ($class, $original, @otherargs) = @_;
bless {
internals => \@otherargs,
On 20 Sep 2000 13:03:22 -0700, Russ Allbery wrote:
>It's not a hardware problem; the hardware clock just keeps a time. It has
>no concept of time zones.
I thought later on that I wrote this the wrong way. What I ment was: the
guys who did the interface to the hardware.
>It's a software problem
Tom Christiansen <[EMAIL PROTECTED]> writes:
>>$a = null;
>>$b = ($a == 42);
>>print defined($b)? "defined" : "not defined";
>> would print "not defined", maybe?
> In a sane world of real (non-oo-sneaky) perl, the "==" operator returns
> only 1 or "". Both are defined.
But if you
Glenn Linderman <[EMAIL PROTECTED]> writes:
> undef has the following semantics:
> 1) all otherwise uninitialized variables are set to undef
And as the RFC says, quite a few times, for database code you often want
all your variables to start as the null value.
> 2) under "use strict", use of u
Glenn Linderman <[EMAIL PROTECTED]> writes:
> With the multitudinous operator approach, please show me how to make
> each of the following conditional statements print true, without
> cluttering the code with interleaved additional pragmas and scoping
> blocks. Use of pragmas before the code mig
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> Yep, this is bad IMHO. Your concern is valid I think, but your
> "solution" isn't a good one. Why not just use a module like Damian's
> Quantum::Superpositions?
No offense to Damian, but I tried to read and understand his documentation
and I th
Nathan Wiger <[EMAIL PROTECTED]> writes:
> undef has a very well-defined (ha!) Perl meaning: that something is
> undefined. null has a very well-defined RDBMS meaning: that something is
> unknown. Perl allows you to add and concatenate stuff to undef, because
> that value can be coerced into 0 an
From: Chaim Frenkel [mailto:[EMAIL PROTECTED]]
>
> From: Tom Christiansen <[EMAIL PROTECTED]>
> >
> > Same answer: I won't do it because it's evil and
> > wrong. I am vehemently and vociferously opposed to software that
> > is installed *ANYWHERE* without documentation. If there is no
> > docum
Bart Lateur <[EMAIL PROTECTED]> writes:
> This is bad. That system is broken. ;-) I guess that it's the same
> situation on MS-DOS, since there the hardware clock is usually set to
> local time. It could even happen on Win32?!?
> This surely was a bad design decision from the hardware guys. Very
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects: Revamp tie to support extensibility (Massive tie changes)
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 7 Sep 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTEC
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 Sep 2000
Last Updated: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Interface polymorphism considered lovely
=head1 VERSION
Maintainer: Piers Cawley <[EMAIL PROTECTED]>
Date: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 265
Version: 1
Status: Developing
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Built-in functions should be functions
=head1 VERSION
Maintainer: Johan Vromans <[EMAIL PROTECTED]>
Date: 27 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 168
Versi
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Subroutines should be able to return an lvalue
=head1 VERSION
Maintainer: Johan Vromans <[EMAIL PROTECTED]>
Date: 18 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 132
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
linkable output mode
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 121
Version: 2
Status: Fro
> Some of oriental characters in Japanese and Korean are usually
> aligned as if they have 2 columns per character.
>
> Japanese has another formatting rule that punctuation characters
> cannot appear at the beginning of or end of line (depending on
> their meanings).
The pro
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: 4
Status: Froze
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl should have a print operator
=head1 VERSION
Maintainer: Jon Ericson <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Last Modified: 20 Sept 2000
Mailing List: [EMAIL PROTECTED]
Number: 39
Version: 4
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: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 12
Version: 3
Status: Deve
That's not much different than the cost of undef, so I fear it proves
nothing, universally.
Tom Christiansen wrote:
> >It only takes a few pages, and a few truth tables to explain NULL.
> >It should only take a few pages and a few examples, to explain the
> >difference between undef and null.
>
Tom Christiansen wrote:
> Perl has *one* out-of-band value. It doesn't need more. That
> doesn't mean that perhaps some rare sorts of programming might not
> benefit from fancy weirdnesses. That's what modules are for.
> You don't need to complicate the general language to get what
> you want.
I haven't (and won't) have time to go into this in detail :-(
I feel that this proposal is solving the wrong problem. The issue is
that the original Forest and Frog (or DBI and DBI::st) classes are not
*designed* for user-definable Frogs (DBI::st's). If that functionality
is widely needed, the Fo
Tom Christiansen wrote:
> > no strict;
> > $a = undef;
> > $b = null;
>
> Perl already has a null string: "".
That's an empty string. In any case, if you really want to call it a
null string, that's fine, just a little more likely to be
misinterpreted. NULL is neither number nor st
Eric Roode wrote:
> Glenn Linderman wrote:
> >Eric Roode wrote:
> >
> >> 1. You don't say in your RFC, but I'm guessing, that a null value
> >> evaluates to false in a boolean context. Correct?
> >
> >I would expect it to be considered false. Logical expressions involving
> >NULL are defined to
* Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 06:09]:
> iain wrote:
> > * Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 05:49]:
> > > > no strict;
> > > > $a = undef;
> > > > $b = null;
> > > Perl already has a null string: "".
> > Looks more like a string of no length than
1 - 100 of 173 matches
Mail list logo
