[32840] in Perl-Users-Digest
Perl-Users Digest, Issue: 4106 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jan 1 03:09:34 2014
Date: Wed, 1 Jan 2014 00:09:04 -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 Wed, 1 Jan 2014 Volume: 11 Number: 4106
Today's topics:
Re: Extra commas ignored? <rweikusat@mobileactivedefense.com>
Re: Extra commas ignored? <ben@morrow.me.uk>
Re: PDL Questions - Dec. 21, 2013 <news@lawshouse.org>
Re: PDL Questions - Dec. 21, 2013 <invalid@invalid.nl>
Re: PDL Questions - Dec. 21, 2013 <whynot@pozharski.name>
Re: PDL Questions - Dec. 21, 2013 <rweikusat@mobileactivedefense.com>
Re: PDL Questions - Dec. 21, 2013 <jblack@nospam.com>
Re: Question about language setting <kst-u@mib.org>
Re: Question about language setting <dave@invalid.invalid>
Re: Syntax understanding problem <derykus@gmail.com>
Re: Syntax understanding problem <ben@morrow.me.uk>
Re: Syntax understanding problem <derykus@gmail.com>
Re: Syntax understanding problem <source@netcom.com>
Re: Syntax understanding problem <ben@morrow.me.uk>
Re: Syntax understanding problem <derykus@gmail.com>
Re: Syntax understanding problem <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 30 Dec 2013 21:50:59 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Extra commas ignored?
Message-Id: <87fvpat3cs.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> > Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> >>
>> >> ie, there is something like a list operator and the , is used as purely
>> >> syntactical element for separating terms in a list.
>> >
>> > OK, you can call it that if you like; it's not really any different from
>> > the ?: operator, which uses '?' and ':' to separate its three
>> > arguments.
>>
>> If it really wasn't different, you'd refer to 'the question mark
>> operator' and 'the colon operator' in this case and this would be as
>> inadequate because they're also just syntactical elements of something
>> else.
>
> As I said, you can call it what you like. 'The comma operator' is easier
> to say than 'the list-of-terms-separated-by-(possibly-multiple)-commas
> operator', but if you'd rather call it OP_LIST or 'the list operator'
> that's fine by me. (You might get some argument from people who claim
> there's no such thing as a list in scalar context, an attitude that is
> unfortunately supported by the documentation.)
I think refering to the complete syntactical construct as 'list' or
'list expression' makes more sense than talking about a 'comma operator'
here, especially considering that ; isn't called 'the semicolon
operator' despite the striking similarities between the two: A list is a
comma-separated list of expression which are evaluated from left to
right and ultimatively end up as arguments of a list operator. If an
explicit list operator doesn't exist, an implicit "return the list in
list context, the last element otherwise" list operator is being used
(which implies that a list expression in scalar context _works_ like the
C 'comma operator', except that the syntax is less restrictive).
------------------------------
Date: Mon, 30 Dec 2013 22:15:33 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Extra commas ignored?
Message-Id: <5t79pa-c3i1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> >
> > As I said, you can call it what you like. 'The comma operator' is easier
> > to say than 'the list-of-terms-separated-by-(possibly-multiple)-commas
> > operator', but if you'd rather call it OP_LIST or 'the list operator'
> > that's fine by me. (You might get some argument from people who claim
> > there's no such thing as a list in scalar context, an attitude that is
> > unfortunately supported by the documentation.)
>
> I think refering to the complete syntactical construct as 'list' or
> 'list expression' makes more sense than talking about a 'comma operator'
> here, especially considering that ; isn't called 'the semicolon
> operator' despite the striking similarities between the two: A list is a
> comma-separated list of expression which are evaluated from left to
> right and ultimatively end up as arguments of a list operator. If an
> explicit list operator doesn't exist, an implicit "return the list in
> list context, the last element otherwise" list operator is being used
> (which implies that a list expression in scalar context _works_ like the
> C 'comma operator', except that the syntax is less restrictive).
I agree entirely. However, when talking to other Perl people, 'the comma
operator' is a term they are familiar with, and 'a list (expression) in
scalar context' is often something they have been taught doesn't exist.
The similarities between comma and semicolon, which I hadn't explicitly
noticed before I started poking through perly.y, are most telling here.
Ben
------------------------------
Date: Mon, 30 Dec 2013 23:39:10 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <i-idndQz9d6CmV_PnZ2dnUVZ8tidnZ2d@giganews.com>
On 30/12/13 05:08, E.D.G. wrote:
> It has been my personal experience that instead of help, requests for
> assistance here have usually been met with criticism and arguments.
I am an amateur Perl programmer, largely self-taught, and have followed
this group since I first started writing my own systems in Perl about
fifteen years ago. So: not a professional, not an expert, always a
student. I have started threads numerous times and have never had
anything other than expert, focussed help.
Brusque it may have seemed (e.g. the one line of code that I'd got wrong
re-written correctly, with neither preamble nor farewell), but never
discourteous. People may have suggested that I approach something a
different way (or avoid doing it altogether), but it was never critical,
in the modern jeering, finger-pointing, fault-finding sense.
I put this down to a basic philosopy of asking questions, which I'd sum
up thus: "Do everything you can to the limit of your own skill, explain
what you're trying to do and what you have done, post some code that
behaves in the way that troubles you, and ask for advice". Works every
time.
You EDG, on the other hand, post portentous pronouncements here,
alluding to your world-saving activities, and always talking
generalities about whether or not Perl is "suitable" for use by some
mythical scientific community of which you believe you are a part. You
never explain what you're doing; you don't show what you've done, and
the only thing you ever ask for is "Please will someone join my project
and do what *I* want done, for nothing and without asking any questions".
It's hardly surprising that contumely was mainly what you received. To
modify the old saying, "Ask garbage questions, get garbage answers".
--
Henry Law Manchester, England
------------------------------
Date: Tue, 31 Dec 2013 08:57:15 +0100
From: jjb <invalid@invalid.nl>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <52c278db$0$2840$e4fe514c@news2.news.xs4all.nl>
On 30-12-2013 08:34, E.D.G. wrote:
> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
> news:Neadnf8OsfUzYl3PnZ2dnUVZ_o2dnZ2d@earthlink.com...
>
> ... I don't know exactly how the Newsgroup management structure
> works.
Right.
By the way: if you want to drive in a nail, don't use Perl. If you want
to quickly make a working program, don't use a hammer. If you want to
travel a long distance, use neither Perl nor a hammer.
Each mentioned tool is very good, but only for some purposes. It is
IMHO an intelligence criterium wether someone uses the correct tool for
his/her/its purpose.
Scientists are (mostly) intelligent.
Conclusions left to the reader.
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
------------------------------
Date: Tue, 31 Dec 2013 06:49:33 +0200
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <slrnlc4j6t.9h8.whynot@orphan.zombinet>
with <87ha9r3stf.fsf@new.chromatico.net> Charlton Wilbur wrote:
*SKIP*
> Some years back, a masterful bookseller of my acquaintance said, "You
> know, the best thing you can do for your business is to find the 5% of
> your customers that take 80% of your time and effort, and convince
> them to patronize your competitors instead."
What kind of tribe do you belong to? That seems all of you are talking
in sigs. That must be diet or something then.
*CUT*
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Tue, 31 Dec 2013 14:00:25 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <87ppodnmrq.fsf@sable.mobileactivedefense.com>
Charlton Wilbur <cwilbur@chromatico.net> writes:
[...]
> Some years back, a masterful bookseller of my acquaintance said, "You
> know, the best thing you can do for your business is to find the 5% of
> your customers that take 80% of your time and effort, and convince them
> to patronize your competitors instead."
This lends itself to the following, neat algorithm
while ($customers = count_whoever_still_buys_stuff_here()) {
get_rid_of_n(int($customers * 5 / 100 + 0.5));
reduce_staff_accordingly();
pocket_the_balance();
}
goto &chapter_11;
which is the very essence of "professionally manageing someone else's
company" (in the USA, predominantly). It is not reliable, unfortunately,
because sometimes, the owner may be able to stop this runaway process
with a SIGKILL while there's still something of his company left.
------------------------------
Date: Tue, 31 Dec 2013 15:25:28 -0600
From: John Black <jblack@nospam.com>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <MPG.2d2cf245a5473bac9897a6@news.eternal-september.org>
In article <i-idndQz9d6CmV_PnZ2dnUVZ8tidnZ2d@giganews.com>, news@lawshouse.org says...
>
> On 30/12/13 05:08, E.D.G. wrote:
> > It has been my personal experience that instead of help, requests for
> > assistance here have usually been met with criticism and arguments.
>
> I am an amateur Perl programmer, largely self-taught, and have followed
> this group since I first started writing my own systems in Perl about
> fifteen years ago. So: not a professional, not an expert, always a
> student. I have started threads numerous times and have never had
> anything other than expert, focussed help.
>
> Brusque it may have seemed (e.g. the one line of code that I'd got wrong
> re-written correctly, with neither preamble nor farewell), but never
> discourteous. People may have suggested that I approach something a
> different way (or avoid doing it altogether), but it was never critical,
> in the modern jeering, finger-pointing, fault-finding sense.
>
> I put this down to a basic philosopy of asking questions, which I'd sum
> up thus: "Do everything you can to the limit of your own skill, explain
> what you're trying to do and what you have done, post some code that
> behaves in the way that troubles you, and ask for advice". Works every
> time.
This has been my experience as well. I am also self taught. Programming in Perl is not my
job. I use Perl to do parts of my job better. I've asked several questions here and have
gotten very helpful answers to all of them.
John Black
------------------------------
Date: Mon, 30 Dec 2013 16:31:23 -0800
From: Keith Thompson <kst-u@mib.org>
Subject: Re: Question about language setting
Message-Id: <ln8uv197z8.fsf@nuthaus.mib.org>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
[...]
> Results as to whether or not setlocale works on OS/2 are somewhat
> unclear. Assuming your system starts with 'English' language settings,
> you could use a modified test program,
>
> -----------
> #include <locale.h>
> #include <stdio.h>
>
> int main(void) {
> printf("%f\n",2.5);
> setlocale(LC_NUMERIC, "de_DE");
> printf("%f\n",2.5);
> setlocale(LC_NUMERIC, "C");
> printf("%f\n",2.5);
>
> return 0;
> }
> -----------
>
> this should print (possibly with variations in the number of trailing
> zeroes)
>
> 2.500000
> 2,500000
> 2.500000
>
> If it doesn't, in particular, if there's a dot instead of a comma in the
> second line, setlocale doesn't work as it is supposed to and if you
> can't switch from English to German in this way, chances are very high
> that switching from German to English also won't work.
setlocale() returns a char* that's either a pointer to a string (if it
succeeded), or a null pointer (if it failed). It's probably worth
adding code to check for this rather than just depending on the output
of printf to change. (On my system, the first setlocale() call fails
because I don't have any German locales installed.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Tue, 31 Dec 2013 11:01:40 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Question about language setting
Message-Id: <fV45K0OBJxbE-pn2-LTDFjX18w9MD@paddington.bear.den>
On Mon, 30 Dec 2013 16:16:06 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
Hi Ben
> I've checked the code and perl already DTRT: it explicitly sets
> LC_NUMERIC to "C" before parsing or formatting numbers. If that doesn't
> do what it's supposed to do you're going to get weird number formatting
> bugs somewhere. (I'm slightly surprised perl is the only thing affected
> by this, but maybe you aren't using anything else that calls setlocale
> at all.)
>
Well it was actually setting LC_MONETARY due to the locale.h mistake.
I am not that surprised. An app would need to be a) complied with the
faulty libc, b) run in a locale where the separator was not a period
and c) actually try and change LC_NUMERIC/LC_MONETARY - Very low
probability I would say. With respect, I would say that treating a
version number as anything other than a string was not a very good
idea. A quick split on not a digit?
--
Regards
Dave Saville
------------------------------
Date: Tue, 31 Dec 2013 15:12:41 -0800
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Syntax understanding problem
Message-Id: <l9vj28$17o$1@speranza.aioe.org>
On 12/30/2013 9:20 AM, Tim McDaniel wrote:
> In article <l9s9cc$nte$1@reader1.panix.com>,
> Tim McDaniel <tmcd@panix.com> wrote:
>> In article <3264pa-g15.ln1@anubis.morrow.me.uk>,
>> Ben Morrow <ben@morrow.me.uk> wrote:
>>>
>>> Quoth tmcd@panix.com:
>>>>> /^Relayed message/ and $discard = 0, next;
>>>>
>>>> the assignment gets done and $discard is set to 0. It's just that the
>>>> 0 return value coming out of the assignment is discarded.
>>>
>> ...
> Of course, as written, that would obviously simplify into two cases.
> But I don't understand what's going on.
>
> print (scalar (($a = 23)), "\n");
> print (scalar (($a = 23) = 45), "\n");
>
> prints
>
> 23
> 1
>
> ... unless the parentheses around the second assignment, which I added
> merely for precedence, make it considered a list assignment. But that
> would be so insanely stupid -- there would be no way to get a scalar
> assignment as in case 1, except maybe with an intervening sub call or
> somewhting.
>
The only quick ways to finesse the list context that occur to me:
perl -E 'say scalar( (($a=23)=45)[-1] )'
perl -E 'say scalar( do{($a=23)=45;$a} )'
(can't think of any reason to do so however).
--
Charles DeRykus
------------------------------
Date: Tue, 31 Dec 2013 23:42:54 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Syntax understanding problem
Message-Id: <uc1cpa-0on.ln1@anubis.morrow.me.uk>
Quoth Charles DeRykus <derykus@gmail.com>:
> On 12/30/2013 9:20 AM, Tim McDaniel wrote:
> >
> > print (scalar (($a = 23) = 45), "\n");
[...]
> > ... unless the parentheses around the second assignment, which I added
> > merely for precedence, make it considered a list assignment. But that
> > would be so insanely stupid -- there would be no way to get a scalar
> > assignment as in case 1, except maybe with an intervening sub call or
> > somewhting.
>
> The only quick ways to finesse the list context that occur to me:
>
> perl -E 'say scalar( (($a=23)=45)[-1] )'
> perl -E 'say scalar( do{($a=23)=45;$a} )'
I'm not sure what these are meant to do... in both cases the '= 45' is a
list assignment. If you want to perform a scalar context assignment to
the result of a scalar context assignment, I believe the simplest way is
like this:
${\($a = 23)} = 45;
(Neither scalar() nor a do{} block can be assigned to, so although they
would be conceptually simpler they don't work.)
Ben
------------------------------
Date: Tue, 31 Dec 2013 17:18:45 -0800
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Syntax understanding problem
Message-Id: <l9vqej$fk2$1@speranza.aioe.org>
On 12/31/2013 3:42 PM, Ben Morrow wrote:
>
> Quoth Charles DeRykus <derykus@gmail.com>:
>> On 12/30/2013 9:20 AM, Tim McDaniel wrote:
>>>
>>> print (scalar (($a = 23) = 45), "\n");
> [...]
>>> ... unless the parentheses around the second assignment, which I added
>>> merely for precedence, make it considered a list assignment. But that
>>> would be so insanely stupid -- there would be no way to get a scalar
>>> assignment as in case 1, except maybe with an intervening sub call or
>>> somewhting.
>>
>> The only quick ways to finesse the list context that occur to me:
>>
>> perl -E 'say scalar( (($a=23)=45)[-1] )'
>> perl -E 'say scalar( do{($a=23)=45;$a} )'
>
> I'm not sure what these are meant to do... in both cases the '= 45' is a
> list assignment. If you want to perform a scalar context assignment to
> the result of a scalar context assignment, I believe the simplest way is
> like this:
>
> ${\($a = 23)} = 45;
>
> (Neither scalar() nor a do{} block can be assigned to, so although they
> would be conceptually simpler they don't work.)
>
Did I skew off-tangent...? this was just a workaround to
finesse the list context within case #2 and get the same results as
case #1, ie, the complaint/challenge: "no way to get a scalar assignment
as in case 1, except maybe with an intervening sub call or something"
> print (scalar (($a = 23)), "\n"); # case 1
> print (scalar (($a = 23) = 45), "\n"); # case 2
> prints
> 23
> 1
--
Charles DeRykus
------------------------------
Date: Tue, 31 Dec 2013 20:49:52 -0800
From: David Harmon <source@netcom.com>
Subject: Re: Syntax understanding problem
Message-Id: <6IGdnav5wJ0nA17PnZ2dnUVZ_rWdnZ2d@earthlink.com>
On Mon, 30 Dec 2013 17:44:47 +0000 in comp.lang.perl.misc, Rainer
Weikusat <rweikusat@mobileactivedefense.com> wrote,
>tmcd@panix.com (Tim McDaniel) writes:
>
>[...]
>
>
>> print (scalar (($a = 23) = 45), "\n");
>>
>> prints
>>
>> 1
>>
>> ... unless the parentheses around the second assignment, which I added
>> merely for precedence, make it considered a list assignment.
>
>Ehh ... well ... ($a = 23) is obviously a list with a single elementy so
>
>($a = 23) = 45
>
>is obviously a list assignment.
How should I write it if I just want to clarify the precedence
without creating a list context?
------------------------------
Date: Wed, 1 Jan 2014 04:53:56 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Syntax understanding problem
Message-Id: <4kjcpa-gfk2.ln1@anubis.morrow.me.uk>
Quoth Charles DeRykus <derykus@gmail.com>:
> On 12/31/2013 3:42 PM, Ben Morrow wrote:
> > Quoth Charles DeRykus <derykus@gmail.com>:
> >> On 12/30/2013 9:20 AM, Tim McDaniel wrote:
> >>>
> >>> print (scalar (($a = 23) = 45), "\n");
> > [...]
> >>> ... unless the parentheses around the second assignment, which I added
> >>> merely for precedence, make it considered a list assignment. But that
> >>> would be so insanely stupid -- there would be no way to get a scalar
> >>> assignment as in case 1, except maybe with an intervening sub call or
> >>> somewhting.
> >>
> >> The only quick ways to finesse the list context that occur to me:
> >>
> >> perl -E 'say scalar( (($a=23)=45)[-1] )'
> >> perl -E 'say scalar( do{($a=23)=45;$a} )'
> >
> > I'm not sure what these are meant to do... in both cases the '= 45' is a
> > list assignment. If you want to perform a scalar context assignment to
> > the result of a scalar context assignment, I believe the simplest way is
> > like this:
> >
> > ${\($a = 23)} = 45;
>
> Did I skew off-tangent...? this was just a workaround to
> finesse the list context within case #2 and get the same results as
> case #1, ie, the complaint/challenge: "no way to get a scalar assignment
> as in case 1, except maybe with an intervening sub call or something"
>
> > print (scalar (($a = 23)), "\n"); # case 1
> > print (scalar (($a = 23) = 45), "\n"); # case 2
> > prints
> > 23
> > 1
Someone is certainly confused here, but I'm not sure who it is...
In all the code snippets in this post, the expression '$a = 23' is a
scalar assignment. In all but mine, the expression '(...) = 45' is a
list assignment. I thought (but I could be wrong) that this was what Tim
was complaining about: that the brackets, which he included only for
precedence, also ended up changing which assignment operator was
invoked.
I'm still not sure what you mean by 'finessing the list context'. Your
first example evaluates the '() = 45' list assignment in list context
(returning a list of one element containing $a as an lvalue), then
slices out the last element of that list, evaluating the slice in scalar
context (returning $a as an rvalue). The second achieves the same thing
by a different route, evaluating the list assignment in void context and
then returning $a as an rvalue directly from the do block. Neither case
returns a value that can be assigned to directly.
Ben
------------------------------
Date: Tue, 31 Dec 2013 22:46:34 -0800
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Syntax understanding problem
Message-Id: <la0dl7$mqc$1@speranza.aioe.org>
On 12/31/2013 8:53 PM, Ben Morrow wrote:
>
> Quoth Charles DeRykus <derykus@gmail.com>:
>> On 12/31/2013 3:42 PM, Ben Morrow wrote:
>>> Quoth Charles DeRykus <derykus@gmail.com>:
>>>> On 12/30/2013 9:20 AM, Tim McDaniel wrote:
>>>>>
>>>>> print (scalar (($a = 23) = 45), "\n");
>>> [...]
>>>>> ... unless the parentheses around the second assignment, which I added
>>>>> merely for precedence, make it considered a list assignment. But that
>>>>> would be so insanely stupid -- there would be no way to get a scalar
>>>>> assignment as in case 1, except maybe with an intervening sub call or
>>>>> somewhting.
>>>>
>>>> The only quick ways to finesse the list context that occur to me:
>>>>
>>>> perl -E 'say scalar( (($a=23)=45)[-1] )'
>>>> perl -E 'say scalar( do{($a=23)=45;$a} )'
>>>
>>> I'm not sure what these are meant to do... in both cases the '= 45' is a
>>> list assignment. If you want to perform a scalar context assignment to
>>> the result of a scalar context assignment, I believe the simplest way is
>>> like this:
>>>
>>> ${\($a = 23)} = 45;
>>
>> Did I skew off-tangent...? this was just a workaround to
>> finesse the list context within case #2 and get the same results as
>> case #1, ie, the complaint/challenge: "no way to get a scalar assignment
>> as in case 1, except maybe with an intervening sub call or something"
>>
>> > print (scalar (($a = 23)), "\n"); # case 1
>> > print (scalar (($a = 23) = 45), "\n"); # case 2
>> > prints
>> > 23
>> > 1
>
> Someone is certainly confused here, but I'm not sure who it is...
>
> ...
> I'm still not sure what you mean by 'finessing the list context'. Your
> first example evaluates the '() = 45' list assignment in list context
> (returning a list of one element containing $a as an lvalue), then
> slices out the last element of that list, evaluating the slice in scalar
> context (returning $a as an rvalue). The second achieves the same thing
> by a different route, evaluating the list assignment in void context and
> then returning $a as an rvalue directly from the do block. Neither case
> returns a value that can be assigned to directly.
>
>
Hm, I assumed there was already consensus that case #2 created a list
context and case #1 didn't. The "finesses" were simple workarounds to
force identical print output as I mentioned earlier. I suspect a more
penetrating analysis was sought :)
--
Charles DeRykus
------------------------------
Date: Wed, 1 Jan 2014 06:37:01 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Syntax understanding problem
Message-Id: <dlpcpa-5ol2.ln1@anubis.morrow.me.uk>
Quoth "Newsgroup only please, address is no longer replyable." <bad@example.invalid>:
> On Mon, 30 Dec 2013 17:44:47 +0000 in comp.lang.perl.misc, Rainer
> Weikusat <rweikusat@mobileactivedefense.com> wrote,
> >
> >Ehh ... well ... ($a = 23) is obviously a list with a single elementy so
This is incorrect. In an expression such as
($a = 23) + 1
the parenthesised part is not a list, it is a scalar.
> >
> >($a = 23) = 45
> >
> >is obviously a list assignment.
>
> How should I write it if I just want to clarify the precedence
> without creating a list context?
If the LHS of an assignment is parenthesised it is always a list
assignment. There is no way to avoid this, nor, I believe, is there any
good reason to need to do so. (If you can come up with one I'd be
interested to see it.)
Ben
------------------------------
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 4106
***************************************
