[32946] in Perl-Users-Digest
Perl-Users Digest, Issue: 4222 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun May 25 03:09:17 2014
Date: Sun, 25 May 2014 00:09:03 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 25 May 2014 Volume: 11 Number: 4222
Today's topics:
Re: Help with an operator precedence (?) puzzle <rweikusat@mobileactivedefense.com>
Re: Help with an operator precedence (?) puzzle <rweikusat@mobileactivedefense.com>
Re: Help with an operator precedence (?) puzzle <hjp-usenet3@hjp.at>
Re: Help with an operator precedence (?) puzzle <hjp-usenet3@hjp.at>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 23 May 2014 20:52:01 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <87fvk0cly6.fsf@sable.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
[...]
[original code]
>>> $frog = 'green' and return if blort();
>>> do { $frog = 'green' } and return if blort();
[...]
> Simplicity trumps complexity and most would agree "if...else" or
> a comma op would be preferable to some hack to avoid a compiler
> warning. However, what if someone argues a basic, unambiguous
> and very English-looking variant:
> "blort() and $frog="green" and return;
>
> is more expressive and avoids a debilitating case of "whitespace
> blindness".
I have no idea what 'whitespace blindness' is supposed to mean in this
context but I don't really see a difference between
$frog = "green" and return if blort();
and
blort() and $frog="green" and return;
both use
$frog = 'green' and return
to express
$frog = 'green', return
relying on the fact that the result of the assignment happens to
count as true because of the value being assigned. Technically, that's
an abuse of the and operator because it's not used because of its
primary property
Binary "and" returns the logical conjunction of the
two surrounding expressions
not even in the sense it is usually being employed for making
flow-control descisions,
[...] performs a short-circuit logical AND operation. That is,
if the left operand is false, the right operand is not even
evaluated.
but solely because it is a binary operator with a suitable precedence,
hence, enabling one to put two sub-expression joined by it in place of
an expression, whose 'actual meaning' 'happens to be irrelevant in the
given context'.
------------------------------
Date: Fri, 23 May 2014 21:17:20 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <87bnuockrz.fsf@sable.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
[...]
>> "blort() and $frog="green" and return;
[...]
> that's an abuse of the and operator because it's not used because of its
> primary property
[...]
> but solely because it is a binary operator with a suitable precedence,
> hence, enabling one to put two sub-expression joined by it in place of
> an expression, whose 'actual meaning' 'happens to be irrelevant in the
> given context'.
To be fair: This is not really true. The perl and-operator is also
derived from the english conjunction 'and' which can server as 'comma
operator' in English sentences, eg
He came home and went to bed.
------------------------------
Date: Sat, 24 May 2014 15:00:49 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <slrnlo1601.78o.hjp-usenet3@hrunkner.hjp.at>
On 2014-05-21 15:40, G.B. <rm-dash-bau-haus@dash.futureapps.de> wrote:
> On 20.05.14 23:01, Rainer Weikusat wrote:
>>
> If there is confusion about the comma operator---and this thread
> undeniably demonstrates there is---
I've just reread the thread and as far as I can see the only person who
expressed any confusion about the comma operator was you -- and unless I
misunderstood you you aren't confused about it yourself but were just
speculating that some perl programmers were confused.
So, no, this thread doesn't demonstrate that there is confusion about
the comma operator.
>> (it took me more than five years of writing a lot of C before I
>> encountered an "Oh! I really need a postincrement here!" situation
>> for the first time).
You never *really* need a postincrement operator. You can always get the
same effect by saving the previous value in an auxiliary variable[1]. It
does make code more concise, though. The canonical example is of course
strcpy, which can be implemented as “while (*s++ = *t++);”.
>> Random 'first example' of a statement similar to
>> the one under discussion I found
>>
>> $rc = rmdir($_[0]);
>> $rc or $sysc = "rmdir $_[0]", last;
>>
>> That's part of a multi-step algorithm for deleting a directory
>> including its contents. It contains a few more 'error handling'
>> statements of the general form
>>
>> <success> or sysc = <description of failure>, last
>>
>> and turning these into
>>
>> if ($rc) {
>> $sysc = "rmdir $_[0]";
>> last;
>> }
>> wouldn't exactly make the code easier to read as the
>> not-really-important parts would take up a lot more space.
>
> Not to mention make it incorrect, am I right? (! $rc)
Yes.
> It does remove the "natural" ambiguity of forming groups by comma
> discussed previously, though, which needs looking up what this
> thread's Subject line is indicating does need looking up.
There is no "natural ambiguity of forming groups" specific to the comma
operator. All operators have arbitrary precedence.
The precedence is sometimes based on existing practice (“*” has a higher
precedence than in most programming languages “+” because you already
learned that in primary school, Perl inherited the precedence from C),
sometimes on the assumptions of the authors about usage (in C “==” has a
higher precedence than “&” because Ritchie assumed that ((a == b) & c)
would be more frequent than (a == (b & c)) so you should be able to omit
the parentheses in the first case -- an assumption which turned out to
be wrong after && was introduced).
As a programmer you learn those which are most common, and you can
usually ignore the rest, because you can always use parentheses to make
it clear (and look it up if you find a (for you) ambiguous combination)
in somebody else's code.
Perl does have a few surprising precedence rules, e.g.:
$y = sin $x + 1;
is parsed as
$y = sin($x + 1);
not as
$y = sin($x) + 1;
as one used to mathematical notation might expect. If you think about
it, that's logical (“print $x + 1” is also parsed as “print($x + 1)“),
but it is still easy to misread.
> By what criteria do you arrive at "easier to read"?
> Subjectively, objectively, statistically, ..., or based
> on your later mention of it: inherently?
Subjectely, probably. But there is an objective component here: It is
harder to read 4 lines instead of 1, so
$rc or $sysc = "rmdir $_[0]", last;
may indeed be objectively (i.e., measurable in an experiment) easier to
read than
if (!$rc) {
$sysc = "rmdir $_[0]";
last;
}
(I don't know the code in question, so maybe there is a reason to split
the call to rmdir from the error handling but I would probably write
this as:
$rc = rmdir($_[0]) or $sysc = "rmdir $_[0]", last;
“function_call() or error_handling” is a very common idiom in Perl and
you should have a good reason for deviating from it.)
hp
[1] Unless you are writing a function-like macro. But in almost all
cases you could write a function instead, so you don't *really* need it
in this case either.
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sat, 24 May 2014 15:26:14 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <slrnlo17fm.78o.hjp-usenet3@hrunkner.hjp.at>
On 2014-05-20 11:24, G.B. <rm-dash-bau-haus@dash.futureapps.de> wrote:
> On 19.05.14 23:33, Peter J. Holzer wrote:
>>>> $frog = 'green', return if blort();
>>>>
>>>> seems like a pretty natural choice.
>>>
>>> The choice seems to match the nature, and possibly the interest,
>>> of a competent Perl consultant, since interpreting it correctly
>>> requires substantial knowledge of Perl,
[...]
>> In addition, the comma operator is present
>> in C and many languages derived from it (not in Java, though).
>
> The presence of some comma operator in similar or related languages
> makes discerning the comma even more tricky, in particular if you
> frequently need to switch languages (Perl, C, sh, Python). A slight
> change of meaning only adds pitfalls.
So I guess we should avoid the ”+” operator like the plague, since it is
present in most programming languages.
>> Also, how do the alternatives
>>
>> $frog = 'green' and return if blort();
>> do { $frog = 'green' } and return if blort();
>>
>> require less "substantial knowledge of Perl"? How are they "more
>> natural" to a non-Perl programmer?
>
> These, too, require substantial knowledge of Perl.
> They, too, mix several aspects of: conditionality, precedence
> (associativity), absence of presence of punctuation, ... all on 1 line.
You were butting in in an already lengthy discussion between Rainer and
Charles were these were the alternatives. If you accuse Rainer of trying
to create work for highly paid consultants by replacing these with the
comma operator, the only possible conclusion is that you consider these
less simpler or more readable. I strongly disagree.
“$frog = 'green', return if blort();” is relatively simple. Sure, you
need basic Perl knowledge to read it, but you don't have to think about
it. There's a conditional statement and it consists of a sequence.
That's it.
“do { $frog = 'green' } and return if blort();” OTOH needs much more
thought and background knowledge. Firstly, the return comes after and,
and and is short-circuiting, so it won't be executed if the left side is
false. You have to look at left side to determine that it is always true
and think a bit about whether that's intentional or not. And then
there's the strange do{} block which doesn't serve any apparent purpose.
Why is it here? You have to think about that, too, and unless you
already know the answer, you are unlikely to find it in a few seconds
(unless you've been a programming instructor: "Strange extra code which
doesn't change the meaning" reeks of "student encountered a compiler
warning he didn't understand and made random changes to make it shut
up.)
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
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 4222
***************************************
