[32948] in Perl-Users-Digest
Perl-Users Digest, Issue: 4224 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue May 27 11:09:21 2014
Date: Tue, 27 May 2014 08:09:04 -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 Tue, 27 May 2014 Volume: 11 Number: 4224
Today's topics:
copy "sub" hash? catebekensail@yahoo.com
Re: copy "sub" hash? <stevem_@nogood.com>
Re: copy "sub" hash? <gravitalsun@hotmail.foo>
Re: copy "sub" hash? <news@lawshouse.org>
Re: copy "sub" hash? <rweikusat@mobileactivedefense.com>
Re: copy "sub" hash? <hjp-usenet3@hjp.at>
Re: copy "sub" hash? <stevem_@nogood.com>
Re: Help with an operator precedence (?) puzzle <rm-dash-bau-haus@dash.futureapps.de>
Re: Help with an operator precedence (?) puzzle <rweikusat@mobileactivedefense.com>
Re: Help with an operator precedence (?) puzzle <rm-dash-bau-haus@dash.futureapps.de>
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 <rweikusat@mobileactivedefense.com>
Re: Help with an operator precedence (?) puzzle <rweikusat@mobileactivedefense.com>
Re: Help with an operator precedence (?) puzzle <hjp-usenet3@hjp.at>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 26 May 2014 18:32:02 -0700 (PDT)
From: catebekensail@yahoo.com
Subject: copy "sub" hash?
Message-Id: <a728e8e4-3c7f-4457-85d9-250ccee3e4cd@googlegroups.com>
how can you extract "mary" into another hash?
%a = ('mary'=>
{'address'=>11, 'zip'=>12},
'john'=>
{'address'=>21, 'zip'=>22},
);
%b = $a{'mary'}; ???
------------------------------
Date: Mon, 26 May 2014 19:34:10 -0700
From: Steve May <stevem_@nogood.com>
Subject: Re: copy "sub" hash?
Message-Id: <DQSgv.136395$yB7.109246@fx05.iad>
On 05/26/2014 06:32 PM, catebekensail@yahoo.com wrote:
> how can you extract "mary" into another hash?
>
> %a = ('mary'=>
> {'address'=>11, 'zip'=>12},
> 'john'=>
> {'address'=>21, 'zip'=>22},
> );
>
> %b = $a{'mary'}; ???
>
You are copying a reference above.
If you were to (attempt) to print out $b{'address'} you should see
something like:
my %a = ('mary'=>
{'address'=>11, 'zip'=>12},
'john'=>
{'address'=>21, 'zip'=>22},
);
my %b = $a{'mary'};
print qq~$b{'address'}\n~;
Output ->
Reference found where even-sized list expected
Use of uninitialized value $b{"address"} in concatenation (.) or string
Copying the dereferenced value of 'mary' instead:
my %a = ('mary'=>
{'address'=>11, 'zip'=>12},
'john'=>
{'address'=>21, 'zip'=>22},
);
my %b = %{$a{'mary'}};
print qq~$b{'address'}\n~;
Output -> 11
The outer brackets are not mandatory, but I tend to use them in
dereferencing as they are an immediate visual clue as to what the code
is doing.
You could also (simpler in my book) simply take a reference rather than
copy into another hash if that works for your process....
my %a = ('mary'=>
{'address'=>11, 'zip'=>12},
'john'=>
{'address'=>21, 'zip'=>22},
);
my $mary = $a{'mary'};
print $mary->{'address'};
Output -> 11
It might be worth your time to get a handle on references... You WILL
need them sooner or later regardless and OOP is pretty much a mystery
unless you understand them.
hth,
Steve
------------------------------
Date: Tue, 27 May 2014 11:10:10 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: copy "sub" hash?
Message-Id: <lm1h7u$274l$1@news.ntua.gr>
# ???!
$b{mary} = $a{mary};
------------------------------
Date: Tue, 27 May 2014 11:38:03 +0100
From: Henry Law <news@lawshouse.org>
Subject: Re: copy "sub" hash?
Message-Id: <KL2dnTMth7KI9hnOnZ2dnUVZ8tGdnZ2d@giganews.com>
On 27/05/14 02:32, catebekensail@yahoo.com wrote:
> how can you extract "mary" into another hash?
>
> %a = ('mary'=>
> {'address'=>11, 'zip'=>12},
> 'john'=>
> {'address'=>21, 'zip'=>22},
> );
>
> %b = $a{'mary'}; ???
>
Steve May has given you the right answer. I'd just add that
Data::Dumper is endlessly useful in situations like this. I have a
little program called "tryout" which consists of the basic Perl stuff
for a simple program, and I then add in whatever I need below to try
things out. In your case I have this
#!/usr/bin/perl
use strict;
use warnings;
use Data::Dumper;
my %a = ('mary'=>
{'address'=>11, 'zip'=>12},
'john'=>
{'address'=>21, 'zip'=>22},
);
my %b = $a{'mary'};
print Dumper( \%b ); # Dumper likes references
%b = %{$a{mary}};
print Dumper( \%b );
Other points: (1) try not to use $a and $b for lash-up variables. They
have specific meanings in the "sort" function and sooner or later the
two usages will collide, with confusing results. (2) Hash keys which
have only numbers and letters don't need quotes, which saves a lot of
typing. See my example. (3) I'm sure you have "use warnings" and "use
strict" in your real program, don't you?
--
Henry Law Manchester, England
------------------------------
Date: Tue, 27 May 2014 13:29:37 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: copy "sub" hash?
Message-Id: <87k397e766.fsf@sable.mobileactivedefense.com>
Steve May <stevem_@nogood.com> writes:
> On 05/26/2014 06:32 PM, catebekensail@yahoo.com wrote:
>> how can you extract "mary" into another hash?
>>
>> %a = ('mary'=>
>> {'address'=>11, 'zip'=>12},
>> 'john'=>
>> {'address'=>21, 'zip'=>22},
>> );
>>
>> %b = $a{'mary'}; ???
>>
>
> You are copying a reference above.
[...]
> Reference found where even-sized list expected
Not really. Assigning a list to a hash causes the contents of the list
to be turned into key/value pairs as they're encountered, eg this code
[rw@sable]~#perl -e '%h = qw(a 1 b 2); print($h{a}, ", ", $h{b}, "\n")'
1, 2
causes %h to contain a key 'a' which is mapped to 1 and a key 'b' mapped
to 2. $a{mary} returns the value associated with the key 'mary' in the
hash %a. This is a reference to a hash. Since there's no other value,
this is effectively a list of size 1. An attempt to use a reference as
hash key will end up using the stringification of the reference instead,
consequently, what
%b = $a{mary}
does is create a key a la 'HASH(0x8195c70)' in %b whose corresponding
value is undef.
[...]
> Copying the dereferenced value of 'mary' instead:
>
> my %a = ('mary'=>
> {'address'=>11, 'zip'=>12},
> 'john'=>
> {'address'=>21, 'zip'=>22},
> );
>
> my %b = %{$a{'mary'}};
[...]
> The outer brackets are not mandatory, but I tend to use them in
> dereferencing as they are an immediate visual clue as to what the code
> is doing.
They are mandatory in this case:
[rw@sable]~#perl -e '$h{a} = {h => a}; print %$h{a};'
syntax error at -e line 1, near "$h{a"
Execution of -e aborted due to compilation errors.
The exact rules are (quoted from memory) that a simple, scalar variable
holding a reference of the appropriate type can be used anywhere an
identifier could appear as well. Further, a block returning a reference
of an appropriate type can be used instead of the 'simple, scalar
variable'. Since $h{a} is not a scalar variable, %$h{a} is a syntax
error and the second form has to be used instead which is
%{$h{a};}
when written in full. Since the semicolon can be omitted after the last
statement in a block, this can also be written as
%{$h{a}}
It is usually more convenient to use the ->-dereferencing operator
instead of the 'block returning a reference' construct where possible,
eg (showing all three ways to get the value associated with 'a' in the
hash $h refers to):
[rw@sable]~#perl -e '$h = { a => 3 }; print(join(", ", $$h{a}, ${$h}{a}, $h->{a}), "\n")'
3, 3, 3
------------------------------
Date: Tue, 27 May 2014 15:34:26 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: copy "sub" hash?
Message-Id: <slrnlo9532.pp3.hjp-usenet3@hrunkner.hjp.at>
On 2014-05-27 01:32, catebekensail@yahoo.com <catebekensail@yahoo.com> wrote:
> how can you extract "mary" into another hash?
>
> %a = ('mary'=>
> {'address'=>11, 'zip'=>12},
> 'john'=>
> {'address'=>21, 'zip'=>22},
> );
>
> %b = $a{'mary'}; ???
You need the key, too, not just the value:
%b = (mary => $a{'mary'});
(George's solution is equivalent if %b is empty. I leave it to you to
figure out what the difference is if %b is not empty)
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/ | zusammenpat. -- Ralph Babel
------------------------------
Date: Tue, 27 May 2014 08:05:40 -0700
From: Steve May <stevem_@nogood.com>
Subject: Re: copy "sub" hash?
Message-Id: <aR1hv.415447$d32.253004@fx31.iad>
On 05/27/2014 05:29 AM, Rainer Weikusat wrote:
> Steve May <stevem_@nogood.com> writes:
>> On 05/26/2014 06:32 PM, catebekensail@yahoo.com wrote:
>>> how can you extract "mary" into another hash?
>>>
>>> %a = ('mary'=>
>>> {'address'=>11, 'zip'=>12},
>>> 'john'=>
>>> {'address'=>21, 'zip'=>22},
>>> );
>>>
>>> %b = $a{'mary'}; ???
>>>
>>
>> You are copying a reference above.
>
> [...]
>
>> Reference found where even-sized list expected
>
> Not really. Assigning a list to a hash causes the contents of the list
> to be turned into key/value pairs as they're encountered, eg this code
Well, that was directly copied from the error message generated when I
ran the code shown and I would expect the same message to show up for
the OP if they ran the same code. Which is why.... well you catch my drift.
<snip>
>
> [...]
>
>> The outer brackets are not mandatory, but I tend to use them in
>> dereferencing as they are an immediate visual clue as to what the code
>> is doing.
>
> They are mandatory in this case:
Yes, I was thinking about other cases, but in this case they are. I
didn't catch that as I tend to use them all the time in dereferencing
anyway.
\s
------------------------------
Date: Mon, 26 May 2014 15:08:58 +0200
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <53833ce9$0$6612$9b4e6d93@newsspool4.arcor-online.net>
On 24.05.14 15:26, Peter J. Holzer wrote:
>> 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.
Typically, the + operator in programming languages triggers
very much the same assumption (intuitively? training received
at school?), slight changes in meaning is a rare exceptions.
I can't believe that any programmer will be so puzzled by +
that he or she won't recognize "add", or "concatenate".
> “$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.
In which way do you arrive at the conclusion that every reader
("you"...) who has a basic understanding of Perl will see that
there is a conditional statement that consists of a sequence?
Likewise, you argue from Perl's parsing about human parsing:
the difficulty of “do { $frog = 'green' } and return if blort();”
is apparently determined by the number of Perl features enumerated.
Is this counting technicalities enough when assessing the
complexity of a Perl expression as perceived by a human reader?
------------------------------
Date: Mon, 26 May 2014 17:13:21 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <87ppj0r00u.fsf@sable.mobileactivedefense.com>
"G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
> On 24.05.14 15:26, Peter J. Holzer wrote:
[...]
>> $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.
>
> In which way do you arrive at the conclusion that every reader
> ("you"...) who has a basic understanding of Perl will see that
> there is a conditional statement that consists of a sequence?
In which way did you arrive at the impression that 'basic understanding
of Perl' will likely or necessarily exclude 'basic knowledge of the Perl
grammar' as in
Simple Statements
The only kind of simple statement is an expression
evaluated for its side effects. Every simple statement must be
terminated with a semicolon, unless it is the final statement in
a block,
and
Statement Modifiers
Any simple statement may optionally be followed by a
SINGLE modifier, just before the terminating semicolon
(or block ending). The possible modifiers are:
if EXPR
unless EXPR
while EXPR
until EXPR
foreach LIST
(these come from sections [3] and [5] of the relevant manpage)
AFAICT, there's no definition of 'expression' but the pretty obvious
'syntactically valid combination of operators and operands' can be used
for that.
Further, assuming that there are a lot of people on this planet who
believe to have a basic understanding of Perl despite they obviously
haven't, why is this relevant for anything except a 'HR department
performance evaluation' (or 'lack-of-performance' evaluation)?
------------------------------
Date: Mon, 26 May 2014 19:07:32 +0200
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <538374d2$0$6611$9b4e6d93@newsspool4.arcor-online.net>
On 26.05.14 18:13, Rainer Weikusat wrote:
> "G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
>> On 24.05.14 15:26, Peter J. Holzer wrote:
>
> [...]
>
>>> “$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.
>>
>> In which way do you arrive at the conclusion that every reader
>> ("you"...) who has a basic understanding of Perl will see that
>> there is a conditional statement that consists of a sequence?
>
> In which way did you arrive at the impression that 'basic understanding
> of Perl' will likely or necessarily exclude 'basic knowledge of the Perl
> grammar' as in
My impression was (and is), rather, that Perl programmers just
write programs with different levels of attention to Perl's grammar,
for reasons that may or may not be judiciously chosen in view of
both the problem at hand and the audience. Grammar is, I think,
not generally in focus of programmers' attention, because what
is trivial does not need much learning (when switching languages,
say), whereas what is basic will need study and thinking.
Some have studied Perl's grammar, obviously, or copied examples,
and they show us, even when there is no need, technically.
(E.g.: "It's fun!")
As outlined previously. (You have also explained that programmers
learn only for exams, etc., I recall. I won't go that far. But in
any case, they write programs that others will use. And we can look
at the programs, and follow discussions of their qualities.)
> Further, assuming that there are a lot of people on this planet who
> believe to have a basic understanding of Perl despite they obviously
> haven't, why is this relevant for anything except a 'HR department
> performance evaluation' (or 'lack-of-performance' evaluation)?
We create source text that likely reflects our actual
understanding of Perl. Whenever we do that, the resulting text
matters to any programmer and program insofar as both depend on
our text and thus on our understanding. That's why I think it's
relevant.
Transitively.
------------------------------
Date: Mon, 26 May 2014 18:47:20 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <87lhtoqvo7.fsf@sable.mobileactivedefense.com>
"G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
> On 26.05.14 18:13, Rainer Weikusat wrote:
>> "G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
>>> On 24.05.14 15:26, Peter J. Holzer wrote:
>>
>> [...]
>>
>>>> $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.
>>>
>>> In which way do you arrive at the conclusion that every reader
>>> ("you"...) who has a basic understanding of Perl will see that
>>> there is a conditional statement that consists of a sequence?
>>
>> In which way did you arrive at the impression that 'basic understanding
>> of Perl' will likely or necessarily exclude 'basic knowledge of the Perl
>> grammar' as in
>
> My impression was (and is), rather, that Perl programmers just
> write programs with different levels of attention to Perl's grammar,
Can you please substantiate your apparent conviction that people who
aren't even superficially familiar with the Perl documentation write
Perl code and further, could you please provide a reason why this would
be relevant for anything?
[...]
> As outlined previously. (You have also explained that programmers
> learn only for exams, etc.,
Nope. I wrote that the so-called 'educational system' tends to produce
people who have learnt how to get past exams without ever learning anything
else.
------------------------------
Date: Mon, 26 May 2014 23:12:00 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <slrnlo7bh0.5md.hjp-usenet3@hrunkner.hjp.at>
On 2014-05-26 13:08, G.B. <rm-dash-bau-haus@dash.futureapps.de> wrote:
> On 24.05.14 15:26, Peter J. Holzer wrote:
>>> 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.
>
> Typically, the + operator in programming languages triggers
> very much the same assumption (intuitively? training received
> at school?), slight changes in meaning is a rare exceptions.
> I can't believe that any programmer will be so puzzled by +
> that he or she won't recognize "add", or "concatenate".
There, you said it and didn't even realize it. "Add" or "concatenate" is
more than a slight change of meaning. "+" seems deceptively simple. But
it isn't. If you are programming in several languages, you have to watch
out for the differences. Even if you are programming in only one
language, the semantics may not be as simple as you think.
>> “$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.
>
> In which way do you arrive at the conclusion that every reader
> ("you"...) who has a basic understanding of Perl will see that
> there is a conditional statement that consists of a sequence?
It's just syntax. And it's relatively common syntax. And not much
ambiguity even if you aren't familiar with it (yes, you can find an
alternate parsing in everything, but I consider your's to be highly
contrieved. I freely admit that Perl has a lot of dark corners and that
it is not an easy language to learn to read well to survive in the wild.
This particular example seems rather harmless to me, though, especially
considering the proposed one-line alternatives (the 4 line alternative
is of course much more conventional and simpler for someone not so
familiar with Perl, at least when taken out of context).
> Likewise, you argue from Perl's parsing about human parsing:
> the difficulty of “do { $frog = 'green' } and return if blort();”
> is apparently determined by the number of Perl features enumerated.
>
> Is this counting technicalities enough when assessing the
> complexity of a Perl expression as perceived by a human reader?
Only a controlled experiment would show that, but from my experience,
code which triggers the "WTF" reflex is a major distraction.
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: Mon, 26 May 2014 23:01:47 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <87a9a4qjw4.fsf@sable.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> On 2014-05-26 13:08, G.B. <rm-dash-bau-haus@dash.futureapps.de> wrote:
>> On 24.05.14 15:26, Peter J. Holzer wrote:
[...]
>>> $frog = 'green', return if blort(); is relatively simple.
[...]
>> In which way do you arrive at the conclusion that every reader
>> ("you"...) who has a basic understanding of Perl will see that
>> there is a conditional statement that consists of a sequence?
[...]
> the 4 line alternative is of course much more conventional and simpler
> for someone not so familiar with Perl, at least when taken out of
> context).
if (blort()) {
$frog = "magenta";
return;
}
is a syntactical construct which exists in this form in C and in (AFAIK)
all languages whose syntax was directly or indirectly derived from
C. This implies that it can be called 'more common' or 'more widespread'
but I'd be wary of regarding it as 'more conventional': This depends
heavily on the background of the reader, eg, the Bourne shell language
could express this as (untested)
if blort;
then
frog=magenta
return
fi
or
blort && { frog=magenta; return; }
and it could even do
blort && frog=magenta && return
which basically means "it is more conventional because we assume that
people are going to be familiar with what we'd like to refer to as
conventional and unfamiliar with what we want to be regared as
outlandish" in a field most people are completely unfamiliar with.
------------------------------
Date: Mon, 26 May 2014 23:22:40 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <8738fwqixb.fsf@sable.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
[...]
> which basically means "it is more conventional because we assume that
> people are going to be familiar with what we'd like to refer to as
> conventional and unfamiliar with what we want to be regared as
> outlandish" in a field most people are completely unfamiliar with.
Since this is maybe a bit cryptic on its own: Considering that this is a
Perl news group, what's the base for assuming that people won't be
familiar with the first five paragraphs of 'perldoc perlsyn' but will be
familiar with all kinds of "strange, other programming languages"?
------------------------------
Date: Tue, 27 May 2014 16:00:26 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <slrnlo96jq.pp3.hjp-usenet3@hrunkner.hjp.at>
On 2014-05-26 22:01, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> "Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
>> On 2014-05-26 13:08, G.B. <rm-dash-bau-haus@dash.futureapps.de> wrote:
>>> On 24.05.14 15:26, Peter J. Holzer wrote:
>
> [...]
>
>>>> “$frog = 'green', return if blort();” is relatively simple.
>
> [...]
>
>> the 4 line alternative is of course much more conventional and simpler
>> for someone not so familiar with Perl, at least when taken out of
>> context).
>
> if (blort()) {
> $frog = "magenta";
> return;
> }
>
> is a syntactical construct which exists in this form in C and in (AFAIK)
> all languages whose syntax was directly or indirectly derived from
> C. This implies that it can be called 'more common' or 'more widespread'
> but I'd be wary of regarding it as 'more conventional':
I don't have hard figures, and I may be biased by my unix background,
but I think that languages derived from C are now more widespread than
languages derived from Algol[1]. So «if (...) { ... }» should be a very
familiar construct to most programmers. In Algol-derived languages it's
«if ... then begin ... end» which is basically the same, and Python uses
indentation instead of keywords/symbols to delimit the block, but the
basic structure is still the same. Tacking on a condition at the end of
a statement is very rare (I'm sure Perl isn't the only language which
does this, but I can't think of another example off the top of my head).
Using bare conditions for control flow is a bit more common, but still
rare (It is frequently used in shell scripts, rarely in C, any other
languages?). And even those languages which have alternative constructs
(Perl, C, Shell, ...) have the «if condition block» construct and it is
used at least as frequently as the alternatives.
So yes, I think I'm justified in calling this construct "much more
conventional".
| con·ven·tion·al
| adjective \kən-ˈvench-nəl, -ˈven(t)-shə-nəl\
|
| : used and accepted by most people : usual or traditional
|
| : of a kind that has been around for a long time and is considered
| to be usual or typical
|
| : common and ordinary : not unusual
(Merriam Webster)
hp
[1] Yes, I know C is also derived from/influenced by Algol.
--
_ | 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 4224
***************************************
