[32831] in Perl-Users-Digest
Perl-Users Digest, Issue: 4096 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Dec 20 06:09:34 2013
Date: Fri, 20 Dec 2013 03:09:05 -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 Fri, 20 Dec 2013 Volume: 11 Number: 4096
Today's topics:
Can't locate object method "new" via package smilesonisamal@gmail.com
Re: Can't locate object method "new" via package <gravitalsun@foo.com>
Re: Can't locate object method "new" via package <jurgenex@hotmail.com>
Extra commas ignored? (Tim McDaniel)
Re: Extra commas ignored? <bill@todbe.com>
Re: Extra commas ignored? (Tim McDaniel)
Re: Extra commas ignored? (Tim McDaniel)
Re: Extra commas ignored? <bill@todbe.com>
Re: Extra commas ignored? <bill@todbe.com>
Re: Extra commas ignored? <janek_schleicher@yahoo.de>
Re: Extra commas ignored? <rweikusat@mobileactivedefense.com>
Re: Extra commas ignored? (Tim McDaniel)
Re: Extra commas ignored? <jurgenex@hotmail.com>
Re: Extra commas ignored? <rweikusat@mobileactivedefense.com>
Re: Extra commas ignored? <ben@morrow.me.uk>
Re: Extra commas ignored? <ben@morrow.me.uk>
Re: How to replace UniCode representation with actual c <Usenet@Grolea.us>
Re: How to replace UniCode representation with actual c <ben@morrow.me.uk>
Syntax understanding problem <justin.1303@purestblue.com>
Re: Syntax understanding problem <gravitalsun@foo.com>
Re: Syntax understanding problem <jurgenex@hotmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 20 Dec 2013 02:33:44 -0800 (PST)
From: smilesonisamal@gmail.com
Subject: Can't locate object method "new" via package
Message-Id: <6b35d31c-9eff-40b1-9a8a-d1de2376c595@googlegroups.com>
Hi all,
I am finding an issue in perl v5.10.1. I am getting the following issue.
I have added the path in @INC in my script.
Error : Can't locate object method "new" via package
Can anybody help me in this regard?
Regards
Pradeep
------------------------------
Date: Fri, 20 Dec 2013 12:52:20 +0200
From: George Mpouras <gravitalsun@foo.com>
Subject: Re: Can't locate object method "new" via package
Message-Id: <l917ft$2b47$1@news.ntua.gr>
# try
use strict;
use warnings;
use FindBin;
use lib $FindBin::Bin;
use MyModule;
...
------------------------------
Date: Fri, 20 Dec 2013 03:00:58 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Can't locate object method "new" via package
Message-Id: <mo88b95nk26bacms7h0r7qrkhmlppm6tuj@4ax.com>
smilesonisamal@gmail.com wrote:
>Hi all,
> I am finding an issue in perl v5.10.1. I am getting the following issue.
>I have added the path in @INC in my script.
>
>Error : Can't locate object method "new" via package
>
>Can anybody help me in this regard?
As has been customary for decades please post a small, self-contained
program that exhibits the problem and that other people can run and
test.
jue
------------------------------
Date: Wed, 18 Dec 2013 21:53:52 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Extra commas ignored?
Message-Id: <l8t5hf$fub$1@reader1.panix.com>
So I figured that allowing one trailing comma was merely special-cased
to allow for neat diffing, like in a revision-control system diffing
old
%a = (
FIELD1 => 23,
FIELD2 => 45,
);
versus new
%a = (
FIELD1 => 23,
FIELD2 => 45,
FIELD3 => 67,
);
But then I accidentally did
FIELD67 => , # FIXME
and learned that the extra comma is ignored. In fact, it seems to
ignore extra commas wherever:
$ perl -e 'use strict; use warnings; use Data::Dumper; my @a = (15,,,,,,16,,,,); print Dumper(\@a), "\n"'
$VAR1 = [
15,
16
];
The exception is that it doesn't allow a leading comma just after the
"(".
Why in the dickens are extra commas permitted in most places?
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 18 Dec 2013 16:21:14 -0800
From: "$Bill" <bill@todbe.com>
Subject: Re: Extra commas ignored?
Message-Id: <l8te5m$87t$1@dont-email.me>
On 12/18/2013 13:53, Tim McDaniel wrote:
>
> $ perl -e 'use strict; use warnings; use Data::Dumper; my @a = (15,,,,,,16,,,,); print Dumper(\@a), "\n"'
> $VAR1 = [
> 15,
> 16
> ];
>
> The exception is that it doesn't allow a leading comma just after the
> "(".
>
> Why in the dickens are extra commas permitted in most places?
perlop
...
Comma Operator
...
In list context, it's just the list argument separator, and inserts both its
arguments into the list. These arguments are also evaluated from left to
right.
Basically you just have null arguments to the comma operator after the
15 and 16.
------------------------------
Date: Thu, 19 Dec 2013 03:24:02 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Extra commas ignored?
Message-Id: <l8tosi$eq4$1@reader1.panix.com>
In article <l8te5m$87t$1@dont-email.me>, $Bill <bill@todbe.com> wrote:
>On 12/18/2013 13:53, Tim McDaniel wrote:
>>
>> $ perl -e 'use strict; use warnings; use Data::Dumper; my @a = (15,,,,,,16,,,,); print Dumper(\@a), "\n"'
>> $VAR1 = [
>> 15,
>> 16
>> ];
>>
>> The exception is that it doesn't allow a leading comma just after the
>> "(".
>>
>> Why in the dickens are extra commas permitted in most places?
>
>perlop
>...
> Comma Operator
>...
> In list context, it's just the list argument separator, and inserts both its
> arguments into the list.
I saw that, but most of these commas are missing an argument on one
side or both.
>Basically you just have null arguments to the comma operator after
>the 15 and 16.
I don't know of anywhere in Perl where there's a concept of "null
argument", or even where "null" might occur at all (except for null
string and NUL character). They certainly aren't undef arguments
(which I might have expected) or the output would have shown them.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 19 Dec 2013 03:31:10 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Extra commas ignored?
Message-Id: <l8tp9u$1mt$1@reader1.panix.com>
In article <l8tosi$eq4$1@reader1.panix.com>,
Tim McDaniel <tmcd@panix.com> wrote:
>I don't know of anywhere in Perl where there's a concept of "null
>argument", or even where "null" might occur at all (except for null
>string and NUL character).
And null statement.
I shouldn't have gone down that path. Anyway, I don't know of any
"null arguments" anywhere.
$a = $b + ;
is a syntax error (hell, I'd better check that ... yup) as is
$c = >> $d;
And things that might look like something with an implied operand are
actually a different operator, like
$e = * $f; # Can't use an undefined value as a symbol reference at -e line 1.
$g = - h; # Results in "-h"
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 18 Dec 2013 22:20:02 -0800
From: "$Bill" <bill@todbe.com>
Subject: Re: Extra commas ignored?
Message-Id: <l8u36d$3lu$1@dont-email.me>
On 12/18/2013 19:24, Tim McDaniel wrote:
> In article <l8te5m$87t$1@dont-email.me>, $Bill <bill@todbe.com> wrote:
>> On 12/18/2013 13:53, Tim McDaniel wrote:
>>>
>>> $ perl -e 'use strict; use warnings; use Data::Dumper; my @a = (15,,,,,,16,,,,); print Dumper(\@a), "\n"'
>>> $VAR1 = [
>>> 15,
>>> 16
>>> ];
>>>
>>> The exception is that it doesn't allow a leading comma just after the
>>> "(".
>>>
>>> Why in the dickens are extra commas permitted in most places?
>>
>> perlop
>> ...
>> Comma Operator
>> ...
>> In list context, it's just the list argument separator, and inserts both its
>> arguments into the list.
>
> I saw that, but most of these commas are missing an argument on one
> side or both.
>
>> Basically you just have null arguments to the comma operator after
>> the 15 and 16.
>
> I don't know of anywhere in Perl where there's a concept of "null
> argument",
Would missing argument give you a warmer fuzzier feeling ? :)
It's a list with null/missing arguments in the list and therefore there
is nothing to insert into the list for the null/missing arguments.
or even where "null" might occur at all (except for null
> string and NUL character).
Null \Null\, a. [L. nullus not any, none; ne not + ullus any, a
dim. of unus one; cf. F. nul. See {No}, and {One}, and cf.
{None}.]
3. (Math.) Empty; having no members; as, the null set.
They certainly aren't undef arguments
> (which I might have expected) or the output would have shown them.
------------------------------
Date: Wed, 18 Dec 2013 22:24:07 -0800
From: "$Bill" <bill@todbe.com>
Subject: Re: Extra commas ignored?
Message-Id: <l8u3e2$4jj$1@dont-email.me>
On 12/18/2013 19:31, Tim McDaniel wrote:
> In article <l8tosi$eq4$1@reader1.panix.com>,
> Tim McDaniel <tmcd@panix.com> wrote:
>> I don't know of anywhere in Perl where there's a concept of "null
>> argument", or even where "null" might occur at all (except for null
>> string and NUL character).
>
> And null statement.
>
> I shouldn't have gone down that path. Anyway, I don't know of any
> "null arguments" anywhere.
>
> $a = $b + ;
>
> is a syntax error (hell, I'd better check that ... yup) as is
>
> $c = >> $d;
It obviously depends on the operator and the context. The only operator
we're talking about is the comma operator and only in a list context
(totally different results in a scalar context).
> And things that might look like something with an implied operand are
> actually a different operator, like
>
> $e = * $f; # Can't use an undefined value as a symbol reference at -e line 1.
>
> $g = - h; # Results in "-h"
>
------------------------------
Date: Thu, 19 Dec 2013 09:06:59 +0100
From: Janek Schleicher <janek_schleicher@yahoo.de>
Subject: Re: Extra commas ignored?
Message-Id: <bhfnp1F3mfrU1@mid.individual.net>
Am 18.12.2013 22:53, schrieb Tim McDaniel:
> So I figured that allowing one trailing comma was merely special-cased
> to allow for neat diffing, like in a revision-control system diffing
> old
> %a = (
> FIELD1 => 23,
> FIELD2 => 45,
> );
...
>
> Why in the dickens are extra commas permitted in most places?
Beside the syntactic parsing reasons,
it has the benefit of easy maintanance.
Imagine you'd have something in addition like
%b = (
FIELD3 => 81,
FIELD4 => 99,
);
and for w/e reason you want to combine then in source code to
%ab = (
...
...
);
with the extra unnecessairy comma at the end,
you just can copy and paste the data lines,
without them, you'd have to insert a , at some place.
Especially when working with configuration, that gets disturbing and
when dynamic evaluation comes into play, also can lead to strange failures.
Greetings,
Janek
------------------------------
Date: Thu, 19 Dec 2013 14:07:34 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Extra commas ignored?
Message-Id: <874n65lys9.fsf@sable.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> In article <l8te5m$87t$1@dont-email.me>, $Bill <bill@todbe.com> wrote:
>>On 12/18/2013 13:53, Tim McDaniel wrote:
>>>
>>> $ perl -e 'use strict; use warnings; use Data::Dumper; my @a = (15,,,,,,16,,,,); print Dumper(\@a), "\n"'
>>> $VAR1 = [
>>> 15,
>>> 16
>>> ];
>>>
>>> The exception is that it doesn't allow a leading comma just after the
>>> "(".
>>>
>>> Why in the dickens are extra commas permitted in most places?
>>
>>perlop
>>...
>> Comma Operator
>>...
>> In list context, it's just the list argument separator, and inserts both its
>> arguments into the list.
>
> I saw that, but most of these commas are missing an argument on one
> side or both.
The key is the "it's just the list argument separator" here which
implies that a comma in list context is not 'the comma operator' (which
takes two arguments, evaluates both left-to-right and returns the
result of the right one[*]) but a separator. This means it is used while
creating a token sequence during syntactical analysis: Once the lexer
encounters a , the current token is finished and it starts accumulating
a new one. Enter another comma --- no token yet, continue looking. And
so on[**].
[*] Technically, the scalar-context comma operator is also not an operator
in the sense that + is, it's rather a compiler directive.
[**] This description might seem inaccurate, eg it is possible to
define a sub
sub digits
{
return 0,,1,2,3,4,5,6,7,8,9;
}
which, when executed in list context, returns a list of digits but
ends up returning only the last element of this list in scalar context.
However, what happens here is just that all list elements are pushed on
the stack from left to right. In scalar context, the element at the top
of the stack kept while all others are removed.
------------------------------
Date: Thu, 19 Dec 2013 17:48:40 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Extra commas ignored?
Message-Id: <l8vbhn$319$1@reader1.panix.com>
In article <bhfnp1F3mfrU1@mid.individual.net>,
Janek Schleicher <janek_schleicher@yahoo.de> wrote:
>with the extra unnecessairy comma at the end,
>you just can copy and paste the data lines,
>without them, you'd have to insert a , at some place.
Yes, I understand that. As I wrote:
> So I figured that allowing one trailing comma was merely special-cased
> to allow for neat diffing, like in a revision-control system diffing
As you wrote, it also helps maintenance.
In a similar way, Perl allows dropping the semicolon before "}", but I
always put one there anyway (with limited exceptions: one-line or
few-line code blocks for sort, grep, and map).
I understand the concept of "null statement" and that it's
occasionally useful, so I have a mental model of why
perl -e '{print "a\n";;;;;;;;;;;;;;; print "b\n"}'
works fine.
What I'm asking is why Perl allows and ignores multiple internal
commas in a list. What benefit could this possibly give? Does that
benefit outweigh being silent on the occasional of leaving off an
operand?
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 19 Dec 2013 10:15:18 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Extra commas ignored?
Message-Id: <tid6b9lo2o9ukp69fa66o6aov9pre031jd@4ax.com>
tmcd@panix.com (Tim McDaniel) wrote:
>In a similar way, Perl allows dropping the semicolon before "}",
Actually, that's not quite correct.
In Perl the semicolon is a statement seperator instead of a statement
terminator as in some other programming languages.
Therefore Perl allows you to create an emtpy statement, e.g. in front of
a "}", by adding an additional semicolon if it pleases you.
That's the same age-old question as if
"foo\nbar\n\buz"
is a text with 3 lines or a text with 2 lines plus some garbage after
the second line.
jue
------------------------------
Date: Thu, 19 Dec 2013 22:58:23 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Extra commas ignored?
Message-Id: <87bo0ccusw.fsf@sable.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> tmcd@panix.com (Tim McDaniel) writes:
>> In article <l8te5m$87t$1@dont-email.me>, $Bill <bill@todbe.com> wrote:
>>>On 12/18/2013 13:53, Tim McDaniel wrote:
>>>>
>>>> $ perl -e 'use strict; use warnings; use Data::Dumper; my @a = (15,,,,,,16,,,,); print Dumper(\@a), "\n"'
>>>> $VAR1 = [
>>>> 15,
>>>> 16
>>>> ];
>>>>
>>>> The exception is that it doesn't allow a leading comma just after the
>>>> "(".
>>>>
>>>> Why in the dickens are extra commas permitted in most places?
>>>
>>>perlop
>>>...
>>> Comma Operator
>>>...
>>> In list context, it's just the list argument separator, and inserts both its
>>> arguments into the list.
>>
>> I saw that, but most of these commas are missing an argument on one
>> side or both.
>
> The key is the "it's just the list argument separator" here which
> implies that a comma in list context is not 'the comma operator' (which
> takes two arguments, evaluates both left-to-right and returns the
> result of the right one[*]) but a separator.
This idea is unfortunately unsuitable for describing the behaviour of
perl because commatose expression apparently generally work, cf
perl -e 'print 5 if 0,,,,5'
------------------------------
Date: Thu, 19 Dec 2013 23:42:22 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Extra commas ignored?
Message-Id: <urccoa-i4c2.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
>
> In a similar way, Perl allows dropping the semicolon before "}", but I
> always put one there anyway (with limited exceptions: one-line or
> few-line code blocks for sort, grep, and map).
Actually, it's the other way round: allowing the trailing ; is the
special case.
> I understand the concept of "null statement" and that it's
> occasionally useful, so I have a mental model of why
> perl -e '{print "a\n";;;;;;;;;;;;;;; print "b\n"}'
> works fine.
>
> What I'm asking is why Perl allows and ignores multiple internal
> commas in a list. What benefit could this possibly give? Does that
> benefit outweigh being silent on the occasional of leaving off an
> operand?
As I explained xthread, this is just what happens when you write a yacc
grammar that allows an optional trailing separator. Comma and semicolon
are handled identically here; in particular, while you may find the
concept of a 'null statement' useful, Perl does not, in that (say)
'print "a";;;; print "b";;;' still compiles to exactly two statements.
Ben
------------------------------
Date: Thu, 19 Dec 2013 23:36:17 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Extra commas ignored?
Message-Id: <hgccoa-i4c2.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>
> The key is the "it's just the list argument separator" here which
> implies that a comma in list context is not 'the comma operator' (which
> takes two arguments, evaluates both left-to-right and returns the
> result of the right one[*]) but a separator.
There is only one comma operator. It always parses the same, and it
always compiles down to the same opcode (it has to, because context
isn't always known at compile time). Like many Perl operators, it has
different behaviour in different contexts; in list context, it evaluates
both arguments, in order, in list context and returns the concatenation
of the two lists; in scalar context it evaluates the LHS in void context
then the RHS in scalar context and returns the result of the RHS; in
void context it evaluates both arguments, in order, in void context, and
returns nothing.
In fact perl optimises a little here: a sequence of comma operators are
not compiled into a sequence of nested binary operators, but instead are
compiled into a single multiple-argument OP_LIST operator. The effect,
however, is exactly as I described above.
(I would express this as 'a list in scalar context evaluates to its last
element', but some people take exception to the phrase 'a list in scalar
context'.)
> This means it is used while
> creating a token sequence during syntactical analysis: Once the lexer
> encounters a , the current token is finished and it starts accumulating
> a new one. Enter another comma --- no token yet, continue looking. And
> so on[**].
This is not how it works. The lexer returns the comma to the parser as
an operator (if you grep through toke.c you will find OPERATOR(',') in
the relevant places). The grammar then says
listexpr: listexpr ','
| listexpr ',' term
| term
;
which allows any number of commas after an element. I suspect the
intention was only to allow a trailing comma, and allowing multiple
commas was a side-effect of the way yacc works. (And yes, this
production handles both list- and scalar-context commas; as I said
before, they have to compile the same way.)
> [*] Technically, the scalar-context comma operator is also not an operator
> in the sense that + is, it's rather a compiler directive.
Nonsense. The lexer, parser and optree handle it exactly the same way as
they handle +, except for the fact that OP_LIST takes multiple arguments.
Ben
------------------------------
Date: Wed, 18 Dec 2013 21:49:33 -0500
From: Wes Groleau <Usenet@Grolea.us>
Subject: Re: How to replace UniCode representation with actual character?
Message-Id: <l8tmrs$egl$1@dont-email.me>
On 12-18-2013, 07:11, Rainer Weikusat wrote:
> Saving you text to a file (utf-8 encoded) and processing that with
>
> perl -pe 'BEGIN { binmode($_, 'utf8') for (*STDIN, *STDOUT) } s/U\+([A-F0-9]{4})/chr(hex($1))/eg'
>
> yields
Thanks. That did replace the code with the character. But
I apparently didn't express clearly. I want to keep the code
and ADD the character. I tried several ways to pre-pend $1\t
and kept getting syntax errors. FINALLY succeeded with
perl -CSD -p -i -e \
's/U\+([A-F0-9]{4})/"U+$1\t".chr(hex($1))/eg;' \
/tmp/Chars_Info.txt
> NB: The binmode(STDOUT, 'utf8') isn't strictly needed, its rather a kow tow
> in front of the idea that the character encoding used by perl should be
> "weird and different from anything else" because that's An
> Abstraction[tm].
As far as I can tell, -CSD makes _everything_ UTF-8.
Why is -CSD the same as -C -S -D
and -pe the same as -p -e
but -pie and -CSDpie are errors
when -CSD -p -i -e work fine ?
Anyway, it works. Thanks very much guys
--
Wes Groleau
You always have time for what you do first.
------------------------------
Date: Thu, 19 Dec 2013 12:34:30 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: How to replace UniCode representation with actual character?
Message-Id: <mn5boa-6s52.ln1@anubis.morrow.me.uk>
Quoth none.of@your.biz:
>
> As far as I can tell, -CSD makes _everything_ UTF-8.
Yes.
> Why is -CSD the same as -C -S -D
It's not.
> and -pe the same as -p -e
Because -p doesn't take an argument, so -e is interpreted as a new
switch.
> but -pie and -CSDpie are errors
Because -i and -C do take arguments, so the 'e' and the 'SDpie' are
interpreted as arguments to -i and -C respectively. (-i is actually
quite happy with 'e' as an argument, but the missing -e probably makes a
mess of the rest of the command line.)
Ben
------------------------------
Date: Fri, 20 Dec 2013 09:32:32 +0000
From: Justin C <justin.1303@purestblue.com>
Subject: Syntax understanding problem
Message-Id: <gefdoa-a5o.ln1@zem.masonsmusic.co.uk>
I've just found something in code I wrote, but I don't
understand it and don't know where I found it. I wrote it a long
time ago. I have this line:
($discard = 0, next) if /^Relayed messages/;
I was tweaking the program for a issue I had (that turns out to
have been elsewhere), and changed the above to:
$discard = 0 if /^Relayed messages/;
At a later stage I had to revert to the original behaviour and
put this:
($discard = 0 && next) if /^Relayed messages/;
Which didn't do what I wanted!
Where can I read about this behaviour of the comma? And what is
that && doing in the last version, am I really saying ($discard
= 0) and ($discard = next)?
Justin.
--
Justin C, by the sea.
------------------------------
Date: Fri, 20 Dec 2013 12:22:27 +0200
From: George Mpouras <gravitalsun@foo.com>
Subject: Re: Syntax understanding problem
Message-Id: <l915ns$2706$1@news.ntua.gr>
you are using a list but instead of data, its items is executed code.
More examples
my
@array;
@array = ( print 12 , 1==1 ? 'foo' : 'boo' ) if 2==2;
@array = qw/a b/ if 2==0;
use Data::Dumper; print Dumper \@array
------------------------------
Date: Fri, 20 Dec 2013 02:58:51 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Syntax understanding problem
Message-Id: <ic78b9po8li3nr4kn21j9mnslpbbk8n1pu@4ax.com>
Justin C <justin.1303@purestblue.com> wrote:
>I've just found something in code I wrote, but I don't
>understand it
That's not surpising. You are (mis?)-using data structures as control
flow elements. That is at the very least a rather questionable habit.
>and don't know where I found it. I wrote it a long
>time ago. I have this line:
>
>($discard = 0, next) if /^Relayed messages/;
If the condition is true, then you are creating a temporary list that is
never used. This list has 2 elements, first the value 0, and second the
return value of next. As a side effect while calculating the first value
it also sets $discard to 0. And of course 'next' never returns, so it
does not really have a valid return value.
>I was tweaking the program for a issue I had (that turns out to
>have been elsewhere), and changed the above to:
>
>$discard = 0 if /^Relayed messages/;
Well, this version obviously never jumps to the next incarnation of
whatever enclosing loop you got.
>At a later stage I had to revert to the original behaviour and
>put this:
>
>($discard = 0 && next) if /^Relayed messages/;
>
>Which didn't do what I wanted!
Not surprising that's something completely different. Here you got a
list with only one element. And this element is calculated as the result
of the assignment of the expression (0 && next) to $discard because &&
has a higher precedence than the assignment.
0 is logical 'false', therefore the && short-circuits and never
evaluates the right side 'next' but instead returns 'false' immediately
and that's what gets assigned to $discard. And then the code continues
with the next statement.
>Where can I read about this behaviour of the comma? And what is
>that && doing in the last version, am I really saying ($discard
>= 0) and ($discard = next)?
No, why would you think so? You are saying
($discard = (0 && next)) if /^Relayed messages/;
just as if you were writing
($foo = 4 + 9) if /^Relayed messages/;
jue
------------------------------
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 4096
***************************************
