[31518] in Perl-Users-Digest
Perl-Users Digest, Issue: 2777 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jan 19 00:09:49 2010
Date: Mon, 18 Jan 2010 21:09:15 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 18 Jan 2010 Volume: 11 Number: 2777
Today's topics:
Re: new dbi connection for each request under mod_perl <xhoster@gmail.com>
Re: perl runtime model <jurgenex@hotmail.com>
Re: perl runtime model <sreservoir@gmail.com>
Re: perl runtime model <sreservoir@gmail.com>
Re: perl runtime model <ben@morrow.me.uk>
Re: perl runtime model <sreservoir@gmail.com>
Re: Variable set to 0 <uri@StemSystems.com>
Re: Variable set to 0 <ben@morrow.me.uk>
Re: Variable set to 0 <jurgenex@hotmail.com>
Re: Variable set to 0 <jurgenex@hotmail.com>
Re: Variable set to 0 <sreservoir@gmail.com>
Re: Variable set to 0 <sreservoir@gmail.com>
Re: Variable set to 0 <sreservoir@gmail.com>
Re: Variable set to 0 <uri@StemSystems.com>
Re: Variable set to 0 <sreservoir@gmail.com>
Re: Variable set to 0 <ben@morrow.me.uk>
Re: Variable set to 0 <ben@morrow.me.uk>
Re: Variable set to 0 <ben@morrow.me.uk>
Re: Variable set to 0 <sreservoir@gmail.com>
Re: Variable set to 0 <sreservoir@gmail.com>
Re: Variable set to 0 <tadmc@seesig.invalid>
Re: Variable set to 0 <sreservoir@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 18 Jan 2010 19:30:45 -0800
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: new dbi connection for each request under mod_perl
Message-Id: <4b552abc$0$10322$ed362ca5@nr5-q3a.newsreader.com>
david wrote:
> Hi all,
>
> I have an application that i want to move to mod_perl.
Why do you want to move? Usually you move an application to mod_perl in
order to make it faster. And often an important part of making it
faster is to cache database handles across invocations, rather than
repeatedly creating them anew.
...
> application relies that it won't be the connection. For example, i
> create temporary tables that are deleted automatically after each
> request, because the connection expires, but now not.
> What is the solution for this problem ?
Does the DBMS you are using have an option that temporary tables be
dropped at the end of a transaction, rather than the end of a session?
Xho
------------------------------
Date: Mon, 18 Jan 2010 18:19:59 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: perl runtime model
Message-Id: <635al51ga5n8p0j90dljeujorlpttneap5@4ax.com>
Peng Yu <pengyu.ut@gmail.com> wrote:
>I don't think that you understand what I meant.
To be honest I don't either.
>It is not obvious what makes any interpreted language
>slower than a compiled one. I want to know exactly what make an
>interpreted language slower.
That is a question for a compiler construction class.
In short: all of the analytical work (scanner, parser, context checker)
as well as some sort of code generation (this varies very widely because
of the many different styles of interpreters) that a compiler does
upfront must to be done by the interpreter at runtime and thus adds
significant overhead to interpreted program execution.
>And if perl is slow because it is
>interpreted,
Perl is not slow. For what it does it's pretty darn fast.
>can a perl script be compiled to a machine executable
>code
No, because Perl supports self-modifying programs, see "perldoc -f
eval".
>so that it will be as fast as a C program?
Irrelevant, because the language has a feature that mandates
interpretation.
jue
------------------------------
Date: Mon, 18 Jan 2010 21:49:39 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: perl runtime model
Message-Id: <hj36kj$1vp$1@speranza.aioe.org>
On 1/18/2010 8:47 PM, Jürgen Exner wrote:
> sreservoir<sreservoir@gmail.com> wrote:
>> On 1/18/2010 5:59 PM, Jürgen Exner wrote:
>>> No. The main difference is obviously that Perl is interpreted while C is
>>> compiled.
>>
>> not quite. simplest scheme can be faster than simplest c simply because
>> the scheme interpreter is optimizing its lists and uses tail-calls for
>> recursion.
>
> I don't buy that argument. You may be right with the program conversion,
> you can do just the same in C, too, you just have to do it manually.
in the case of 'most efficient program', I wouldn't buy that, either. I
didn't read that until later, though. it is also not as obvious as it
might seem to you.
> On the other hand launching an interpreter, parsing the source code,
> creating some form of executable code and starting that code adds
> overhead that you simply don't have with code that is already compiled,
> linked, and assembled.
lots of code is dynamically linked, but that's not a significant
difference.
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
------------------------------
Date: Mon, 18 Jan 2010 21:56:57 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: perl runtime model
Message-Id: <hj3729$2s4$1@speranza.aioe.org>
On 1/18/2010 9:19 PM, Jürgen Exner wrote:
> Peng Yu<pengyu.ut@gmail.com> wrote:
>> I don't think that you understand what I meant.
>
> To be honest I don't either.
>
>> It is not obvious what makes any interpreted language
>> slower than a compiled one. I want to know exactly what make an
>> interpreted language slower.
>
> That is a question for a compiler construction class.
> In short: all of the analytical work (scanner, parser, context checker)
> as well as some sort of code generation (this varies very widely because
> of the many different styles of interpreters) that a compiler does
> upfront must to be done by the interpreter at runtime and thus adds
> significant overhead to interpreted program execution.
this is, incidentally, why fastcgi and mod_perl are faster that vanilla
perl/cgi.
>> And if perl is slow because it is
>> interpreted,
>
> Perl is not slow. For what it does it's pretty darn fast.
the key here being _for what it does_. It does do a lot of not-quite-
relevant-but-generally-useful things in small programs.
>> can a perl script be compiled to a machine executable
>> code
>
> No, because Perl supports self-modifying programs, see "perldoc -f
> eval".
less self-modifying as 'decides what to do dynamically'; this is a bit
like conditionals on a much larger scale.
and, incidentally, I've seen people write things like eval $ary[$sel]
with a constant @ary. Lack of a case statement makes people do strange
things.
>> so that it will be as fast as a C program?
>
> Irrelevant, because the language has a feature that mandates
> interpretation.
the alternative is to build in a perl interpreter, and compile the
stuff not in an eval STRING. that has a lot of overhead in and of
itself, though.
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
------------------------------
Date: Tue, 19 Jan 2010 03:10:56 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: perl runtime model
Message-Id: <0fkf27-a5k.ln1@osiris.mauzo.dyndns.org>
Quoth sreservoir <sreservoir@gmail.com>:
>
> and, incidentally, I've seen people write things like eval $ary[$sel]
> with a constant @ary. Lack of a case statement makes people do strange
> things.
Only in Perl 4, I hope. Now Perl has real subrefs, $ary[$sel]->() is
much much better.
> the alternative is to build in a perl interpreter, and compile the
> stuff not in an eval STRING. that has a lot of overhead in and of
> itself, though.
It's effectively impossible in Perl, given the number of modules that
assume BEGIN time comes shortly before runtime (and, in particular, that
BEGIN blocks will be run every time the program is run). INIT was
supposed to fix that, but since perlcc never got anywhere noone uses it.
Ben
------------------------------
Date: Mon, 18 Jan 2010 22:27:18 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: perl runtime model
Message-Id: <hj38r6$6c5$1@speranza.aioe.org>
On 1/18/2010 10:10 PM, Ben Morrow wrote:
>
> Quoth sreservoir<sreservoir@gmail.com>:
>>
>> and, incidentally, I've seen people write things like eval $ary[$sel]
>> with a constant @ary. Lack of a case statement makes people do strange
>> things.
>
> Only in Perl 4, I hope. Now Perl has real subrefs, $ary[$sel]->() is
> much much better.
It was an old piece of code from the 1990's that got 'updated' to 5.
presumably a literal translation.
>> the alternative is to build in a perl interpreter, and compile the
>> stuff not in an eval STRING. that has a lot of overhead in and of
>> itself, though.
>
> It's effectively impossible in Perl, given the number of modules that
> assume BEGIN time comes shortly before runtime (and, in particular, that
> BEGIN blocks will be run every time the program is run). INIT was
> supposed to fix that, but since perlcc never got anywhere noone uses it.
Presumably, 'most efficient' does not call external modules, because
they tend to come with a lot of unnecessary junk which adds overhead.
also, CHECK blocks. if perlcc had gotten somewhere, our responses to
compilation might be much different, though.
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
------------------------------
Date: Mon, 18 Jan 2010 21:13:34 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Variable set to 0
Message-Id: <87pr56j0z5.fsf@quad.sysarch.com>
>>>>> "s" == sreservoir <sreservoir@gmail.com> writes:
s> On 1/18/2010 7:47 PM, Faith Greenwood wrote:
>> I have the following:
>>
>> use strict;
>> use warnings;
>>
>> my $number=0;
>> print "This:$number\n";
>> print "That:$number\n" if $number;
>>
>> __END__
>>
>> Of the two lines that print the variable, why does it print the first
>> line but not the second?
>> If I change the $number to equal 1, then both lines print fine.
>>
>> thank you
s> because 0 is, traditionally, not true, even in perl where false is
s> canonically undef.
undef, '', 0 and '0' are the boolean false values for perl. there is no
canonical one. you can use them how you wish but they will all be false
under perl's boolean tests (which includes if modifier).
for the OP, what did you think 'if' means? that it was defined? for that
use the defined function:
print "That:$number\n" if defined $number;
that will print.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 19 Jan 2010 02:05:24 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Variable set to 0
Message-Id: <4kgf27-9tj.ln1@osiris.mauzo.dyndns.org>
Quoth sreservoir <sreservoir@gmail.com>:
> On 1/18/2010 7:47 PM, Faith Greenwood wrote:
> > I have the following:
> >
> > use strict;
> > use warnings;
> >
> > my $number=0;
> > print "This:$number\n";
> > print "That:$number\n" if $number;
> >
> > __END__
> >
> > Of the two lines that print the variable, why does it print the first
> > line but not the second?
> > If I change the $number to equal 1, then both lines print fine.
> >
> > thank you
>
> because 0 is, traditionally, not true, even in perl where false is
> canonically undef.
No. False in perl is canonically a dualvar that is the empty string in
string context and 0 in numeric context (so there are no warnings on
numeric conversion, unlike a plain "").
~% perl -E'say defined !1'
1
~% perl -wE'say 0 + !1'
0
~% perl -wE'say "[", ("" . !1), "]"'
[]
~% perl -wE'say 0 + ""'
Argument "" isn't numeric in addition (+) at -e line 1.
0
~%
True is canonically the string "1".
Ben
------------------------------
Date: Mon, 18 Jan 2010 18:22:00 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Variable set to 0
Message-Id: <in5al5p4h81ls0pvobvhlf5vap6jgeq3qb@4ax.com>
Faith Greenwood <fgnowfg@gmail.com> wrote:
>I have the following:
>
>use strict;
>use warnings;
>
>my $number=0;
>print "This:$number\n";
>print "That:$number\n" if $number;
>
>__END__
>
>Of the two lines that print the variable, why does it print the first
>line but not the second?
Maybe because you explicitely tell Perl to print the second line only if
$number is true?
>If I change the $number to equal 1, then both lines print fine.
Big surprise, 1 is a true value, 0 is not.
jue
------------------------------
Date: Mon, 18 Jan 2010 18:28:20 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Variable set to 0
Message-Id: <m06al55mt3ju71n4pme2nd87jkea404tah@4ax.com>
sreservoir <sreservoir@gmail.com> wrote:
>because 0 is, traditionally, not true, even in perl where false is
>canonically undef.
That is not correct. While the boolean values of undef is indeed false,
this is by no means canonical. There are several other scalar values,
the numerical 0 just being one of them. Please see 'perldoc perldata'
for details.
jue
------------------------------
Date: Mon, 18 Jan 2010 21:40:22 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: Variable set to 0
Message-Id: <hj3636$uo$1@speranza.aioe.org>
On 1/18/2010 9:05 PM, Ben Morrow wrote:
>
> Quoth sreservoir<sreservoir@gmail.com>:
>> On 1/18/2010 7:47 PM, Faith Greenwood wrote:
>>> I have the following:
>>>
>>> use strict;
>>> use warnings;
>>>
>>> my $number=0;
>>> print "This:$number\n";
>>> print "That:$number\n" if $number;
>>>
>>> __END__
>>>
>>> Of the two lines that print the variable, why does it print the first
>>> line but not the second?
>>> If I change the $number to equal 1, then both lines print fine.
>>>
>>> thank you
>>
>> because 0 is, traditionally, not true, even in perl where false is
>> canonically undef.
>
> No. False in perl is canonically a dualvar that is the empty string in
> string context and 0 in numeric context (so there are no warnings on
> numeric conversion, unlike a plain "").
>
> ~% perl -E'say defined !1'
> 1
> ~% perl -wE'say 0 + !1'
> 0
> ~% perl -wE'say "[", ("" . !1), "]"'
> []
> ~% perl -wE'say 0 + ""'
> Argument "" isn't numeric in addition (+) at -e line 1.
> 0
> ~%
>
> True is canonically the string "1".
~% perl -wle'print !1'
Use of uninitialized value in print at -e line 1.
~%
I suspect this is a historical thing that I never remembered.
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
------------------------------
Date: Mon, 18 Jan 2010 21:42:00 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: Variable set to 0
Message-Id: <hj3667$uo$2@speranza.aioe.org>
On 1/18/2010 9:28 PM, Jürgen Exner wrote:
> sreservoir<sreservoir@gmail.com> wrote:
>> because 0 is, traditionally, not true, even in perl where false is
>> canonically undef.
>
> That is not correct. While the boolean values of undef is indeed false,
> this is by no means canonical. There are several other scalar values,
> the numerical 0 just being one of them. Please see 'perldoc perldata'
> for details.
huh. historically, the comparisons returned undef for false. well, I
guess you learn something new every day.
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
------------------------------
Date: Mon, 18 Jan 2010 21:44:19 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: Variable set to 0
Message-Id: <hj36aj$uo$3@speranza.aioe.org>
On 1/18/2010 9:40 PM, sreservoir wrote:
> On 1/18/2010 9:05 PM, Ben Morrow wrote:
>>
>> Quoth sreservoir<sreservoir@gmail.com>:
>>> On 1/18/2010 7:47 PM, Faith Greenwood wrote:
>>>> I have the following:
>>>>
>>>> use strict;
>>>> use warnings;
>>>>
>>>> my $number=0;
>>>> print "This:$number\n";
>>>> print "That:$number\n" if $number;
>>>>
>>>> __END__
>>>>
>>>> Of the two lines that print the variable, why does it print the first
>>>> line but not the second?
>>>> If I change the $number to equal 1, then both lines print fine.
>>>>
>>>> thank you
>>>
>>> because 0 is, traditionally, not true, even in perl where false is
>>> canonically undef.
>>
>> No. False in perl is canonically a dualvar that is the empty string in
>> string context and 0 in numeric context (so there are no warnings on
>> numeric conversion, unlike a plain "").
>>
>> ~% perl -E'say defined !1'
>> 1
>> ~% perl -wE'say 0 + !1'
>> 0
>> ~% perl -wE'say "[", ("" . !1), "]"'
>> []
>> ~% perl -wE'say 0 + ""'
>> Argument "" isn't numeric in addition (+) at -e line 1.
>> 0
>> ~%
>>
>> True is canonically the string "1".
>
> ~% perl -wle'print !1'
> Use of uninitialized value in print at -e line 1.
>
> ~%
>
> I suspect this is a historical thing that I never remembered.
a newer perl returns the same results as your perl.
false as a string never struck me as useful though.
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
------------------------------
Date: Mon, 18 Jan 2010 21:49:52 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Variable set to 0
Message-Id: <87aawaizan.fsf@quad.sysarch.com>
>>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
BM> Quoth sreservoir <sreservoir@gmail.com>:
>> On 1/18/2010 7:47 PM, Faith Greenwood wrote:
>> > I have the following:
>> >
>> > use strict;
>> > use warnings;
>> >
>> > my $number=0;
>> > print "This:$number\n";
>> > print "That:$number\n" if $number;
>> >
>> > __END__
>> >
>> > Of the two lines that print the variable, why does it print the first
>> > line but not the second?
>> > If I change the $number to equal 1, then both lines print fine.
>> >
>> > thank you
>>
>> because 0 is, traditionally, not true, even in perl where false is
>> canonically undef.
BM> No. False in perl is canonically a dualvar that is the empty string in
BM> string context and 0 in numeric context (so there are no warnings on
BM> numeric conversion, unlike a plain "").
i know that but the OP's issue was not knowing that 0 was false or not
getting that if checked for false and not defined.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Mon, 18 Jan 2010 21:59:23 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: Variable set to 0
Message-Id: <hj376r$2s4$2@speranza.aioe.org>
On 1/18/2010 9:49 PM, Uri Guttman wrote:
>>>>>> "BM" == Ben Morrow<ben@morrow.me.uk> writes:
>
> BM> Quoth sreservoir<sreservoir@gmail.com>:
> >> On 1/18/2010 7:47 PM, Faith Greenwood wrote:
> >> > I have the following:
> >> >
> >> > use strict;
> >> > use warnings;
> >> >
> >> > my $number=0;
> >> > print "This:$number\n";
> >> > print "That:$number\n" if $number;
> >> >
> >> > __END__
> >> >
> >> > Of the two lines that print the variable, why does it print the first
> >> > line but not the second?
> >> > If I change the $number to equal 1, then both lines print fine.
> >> >
> >> > thank you
> >>
> >> because 0 is, traditionally, not true, even in perl where false is
> >> canonically undef.
>
> BM> No. False in perl is canonically a dualvar that is the empty string in
> BM> string context and 0 in numeric context (so there are no warnings on
> BM> numeric conversion, unlike a plain "").
>
> i know that but the OP's issue was not knowing that 0 was false or not
> getting that if checked for false and not defined.
>
the problem with this group is that even when someone agrees with you,
they will disagree with your example.
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
------------------------------
Date: Tue, 19 Jan 2010 02:58:20 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Variable set to 0
Message-Id: <cnjf27-a5k.ln1@osiris.mauzo.dyndns.org>
Quoth sreservoir <sreservoir@gmail.com>:
> On 1/18/2010 9:40 PM, sreservoir wrote:
> > On 1/18/2010 9:05 PM, Ben Morrow wrote:
> >>
> >> No. False in perl is canonically a dualvar that is the empty string in
> >> string context and 0 in numeric context (so there are no warnings on
> >> numeric conversion, unlike a plain "").
> >>
> >> ~% perl -E'say defined !1'
> >> 1
> >> ~% perl -wE'say 0 + !1'
> >> 0
> >> ~% perl -wE'say "[", ("" . !1), "]"'
> >> []
> >> ~% perl -wE'say 0 + ""'
> >> Argument "" isn't numeric in addition (+) at -e line 1.
> >> 0
> >> ~%
> >>
> >> True is canonically the string "1".
> >
> > ~% perl -wle'print !1'
> > Use of uninitialized value in print at -e line 1.
> >
> > ~%
> >
> > I suspect this is a historical thing that I never remembered.
>
> a newer perl returns the same results as your perl.
Which version of perl was your original test? I get !1 defined for all
versions >5.6.0 (the oldest perl I have lying around).
Ben
------------------------------
Date: Tue, 19 Jan 2010 03:06:56 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Variable set to 0
Message-Id: <g7kf27-a5k.ln1@osiris.mauzo.dyndns.org>
Quoth sreservoir <sreservoir@gmail.com>:
> On 1/18/2010 9:28 PM, Jürgen Exner wrote:
> > sreservoir<sreservoir@gmail.com> wrote:
> >> because 0 is, traditionally, not true, even in perl where false is
> >> canonically undef.
> >
> > That is not correct. While the boolean values of undef is indeed false,
> > this is by no means canonical. There are several other scalar values,
> > the numerical 0 just being one of them. Please see 'perldoc perldata'
> > for details.
>
> huh. historically, the comparisons returned undef for false. well, I
> guess you learn something new every day.
I don't know what you mean by 'historically'. sv_no (the canonical false
value) has been as I describe since 5.000; 4.036 had str_no, which
appears to be simply the empty string (I guess Perl 4 didn't have
numeric conversion warnings?).
Ben
------------------------------
Date: Tue, 19 Jan 2010 03:12:38 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Variable set to 0
Message-Id: <6ikf27-a5k.ln1@osiris.mauzo.dyndns.org>
Quoth "Uri Guttman" <uri@StemSystems.com>:
> >>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
>
> BM> Quoth sreservoir <sreservoir@gmail.com>:
> >>
> >> because 0 is, traditionally, not true, even in perl where false is
> >> canonically undef.
>
> BM> No. False in perl is canonically a dualvar that is the empty string in
> BM> string context and 0 in numeric context (so there are no warnings on
> BM> numeric conversion, unlike a plain "").
>
> i know that but the OP's issue was not knowing that 0 was false or not
> getting that if checked for false and not defined.
I know you know that, which is why I wasn't saying it to you. I was
saying it to sreservoir, who apparently didn't.
Ben
------------------------------
Date: Mon, 18 Jan 2010 22:18:28 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: Variable set to 0
Message-Id: <hj38ak$5ci$1@speranza.aioe.org>
On 1/18/2010 9:58 PM, Ben Morrow wrote:
>
> Quoth sreservoir<sreservoir@gmail.com>:
>> On 1/18/2010 9:40 PM, sreservoir wrote:
>>> On 1/18/2010 9:05 PM, Ben Morrow wrote:
>>>>
>>>> No. False in perl is canonically a dualvar that is the empty string in
>>>> string context and 0 in numeric context (so there are no warnings on
>>>> numeric conversion, unlike a plain "").
>>>>
>>>> ~% perl -E'say defined !1'
>>>> 1
>>>> ~% perl -wE'say 0 + !1'
>>>> 0
>>>> ~% perl -wE'say "[", ("" . !1), "]"'
>>>> []
>>>> ~% perl -wE'say 0 + ""'
>>>> Argument "" isn't numeric in addition (+) at -e line 1.
>>>> 0
>>>> ~%
>>>>
>>>> True is canonically the string "1".
>>>
>>> ~% perl -wle'print !1'
>>> Use of uninitialized value in print at -e line 1.
>>>
>>> ~%
>>>
>>> I suspect this is a historical thing that I never remembered.
>>
>> a newer perl returns the same results as your perl.
>
> Which version of perl was your original test? I get !1 defined for all
> versions>5.6.0 (the oldest perl I have lying around).
whatever version it is that ships with fedora core 1. I never did get
that one to connect to the internet.
probably perl 5.6.0 or a 5.004. yes, I probably should update it. sue me
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
------------------------------
Date: Mon, 18 Jan 2010 22:21:09 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: Variable set to 0
Message-Id: <hj38fl$5ci$2@speranza.aioe.org>
On 1/18/2010 10:06 PM, Ben Morrow wrote:
>
> Quoth sreservoir<sreservoir@gmail.com>:
>> On 1/18/2010 9:28 PM, J�rgen Exner wrote:
>>> sreservoir<sreservoir@gmail.com> wrote:
>>>> because 0 is, traditionally, not true, even in perl where false is
>>>> canonically undef.
>>>
>>> That is not correct. While the boolean values of undef is indeed false,
>>> this is by no means canonical. There are several other scalar values,
>>> the numerical 0 just being one of them. Please see 'perldoc perldata'
>>> for details.
>>
>> huh. historically, the comparisons returned undef for false. well, I
>> guess you learn something new every day.
>
> I don't know what you mean by 'historically'. sv_no (the canonical false
> value) has been as I describe since 5.000; 4.036 had str_no, which
> appears to be simply the empty string (I guess Perl 4 didn't have
> numeric conversion warnings?).
I am now slightly confused, too. Must have been confused and/or sleep-
deprived when I thought that. Though I'm not sure how !1 managed to
emit the warning then.
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
------------------------------
Date: Mon, 18 Jan 2010 21:45:47 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Variable set to 0
Message-Id: <slrnhlaah0.k33.tadmc@tadbox.sbcglobal.net>
sreservoir <sreservoir@gmail.com> wrote:
> the problem with this group is
...
This group has no problems.
You must have us confused with some other group.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
------------------------------
Date: Mon, 18 Jan 2010 23:03:13 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: Variable set to 0
Message-Id: <hj3auh$8n5$1@speranza.aioe.org>
On 1/18/2010 10:45 PM, Tad McClellan wrote:
> sreservoir<sreservoir@gmail.com> wrote:
>
>> the problem with this group is
> ...
>
>
> This group has no problems.
>
> You must have us confused with some other group.
>
No, just confusing it with some other definition of problem.
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 2777
***************************************
