a question about efficiency

[Kiuhnm]

Hi,
I've just started to learn Perl. Here's my first question.

Please look at this code:
--->
my $len1;
foreach (keys %ENV) {
if (length $_ > $len1) { $len1 = length $_ }}
<---
Does Perl execute "length $_" twice or once?
Should I use
if ((my $l = length $_) > $len1) { $len1 = $l }}
instead?

Kiuhnm

[Rainer Weikusat]

Kiuhnm <kiuhnm03.4t.yahoo.it> writes:
> Please look at this code:
> --->
> my $len1;
> foreach (keys %ENV) {
> if (length $_ > $len1) { $len1 = length $_ }}
> <---
> Does Perl execute "length $_" twice or once?

Twice (at least for 5.10.1).

> Should I use
> if ((my $l = length $_) > $len1) { $len1 = $l }}

Certainly not. Even when implemented in a sensible way, the idea to
use an additional variable to keep the length results in somewhat
slower code which is to be expected because it makes Perl perform a
little more work (everything it did for the other case plus an
additional assignment). Creating and destroying a my-variable each
time the if-statement is executed makes that A LOT more work.

NB: This is isn't necessarily true for all other subroutines,
especially, 'user subroutines' implemented in Perl.

-----------
use Benchmark;

timethese(-10, {
a => sub {
my $len1;

length($_) > $len1 and $len1 = length($_) for keys(%ENV);
},

c => sub {
my ($l1, $l0);

($l0 = length($_)) > $l1 and $l1 = $l0 for keys(%ENV);
},

d => sub {
my $l1;

for (keys(%ENV)) {
if ((my $l = length($_)) > $l1) { $l1 = $; }
}
}
});
-------------

[Kiuhnm]

On 2/21/2012 14:47, Rainer Weikusat wrote:
> Kiuhnm<kiuhnm03.4t.yahoo.it> writes:
>> Please look at this code:
>> --->
>> my $len1;
>> foreach (keys %ENV) {
>> if (length $_> $len1) { $len1 = length $_ }}
>> <---
>> Does Perl execute "length $_" twice or once?
>
> Twice (at least for 5.10.1).
>
>> Should I use
>> if ((my $l = length $_)> $len1) { $len1 = $l }}
>
> Certainly not. Even when implemented in a sensible way, the idea to
> use an additional variable to keep the length results in somewhat
> slower code which is to be expected because it makes Perl perform a
> little more work (everything it did for the other case plus an
> additional assignment). Creating and destroying a my-variable each
> time the if-statement is executed makes that A LOT more work.

Ops... I forgot that Perl doesn't use null-terminated strings. strlen()
is an O(n) operation in C, as you well know.

> NB: This is isn't necessarily true for all other subroutines,
> especially, 'user subroutines' implemented in Perl.
>
> -----------
> use Benchmark;
>
> timethese(-10, {
> a => sub {
> my $len1;
>
> length($_)> $len1 and $len1 = length($_) for keys(%ENV);

Interesting. That syntax is new to me, but makes sense. My only doubt is
whether "and" and "&&" are the same thing. It appears so.

> },
>
> c => sub {
> my ($l1, $l0);
>
> ($l0 = length($_))> $l1 and $l1 = $l0 for keys(%ENV);
> },
>
> d => sub {
> my $l1;
>
> for (keys(%ENV)) {
> if ((my $l = length($_))> $l1) { $l1 = $; }
> }
> }
> });
> -------------

If this isn't another Perl feature I don't know about, you forgot an 'l'
in your last assignment. On my PC, the 'l' improves the efficiency. I
guess even undef->0 conversions count.
Anyway, taking that $l out of the loop, makes the last option the fastest.
The "objects" after the "fat commas" are (pointers to?) closures?

Try this code:

-------->
use Benchmark;

timethese(-5, {

a => sub {
my $len1;

length($_) > $len1 and $len1 = length($_) for keys(%ENV);
},

c => sub {
my ($l1, $l0);

($l0 = length($_)) > $l1 and $l1 = $l0 for keys(%ENV);
},

d => sub {
my $l1;

for (keys(%ENV)) {

if ((my $l = length($_)) > $l1) { $l1 = $l; }
}},

e => sub {
my ($l1, $l);

for (keys(%ENV)) {
if (($l = length($_)) > $l1) { $l1 = $l; }
}},

f => sub {
my $l1;

for (keys(%ENV)) {
if (length($_) > $l1) { $l1 = length($_); }
}
}
});
<--------

'e' wins on my PC.

Kiuhnm

[Jürgen Exner]

Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
>Hi,
>I've just started to learn Perl. Here's my first question.
>
>Please look at this code:
>--->
> my $len1;
> foreach (keys %ENV) {
> if (length $_ > $len1) { $len1 = length $_ }}
><---
>Does Perl execute "length $_" twice or once?

In Perl the lenght of a string is O(1). If you read it once or twice
really doesn't make any perceptible difference.
All the other operations in that loop from comparing the values to
executing the jump for the conditional code are significantly more
expensive.

If you have already exhausted all algorithmic optimizations and your
code is still too slow and you really really think you need optimization
on that level, then you should use a different programming language
instead, e.g. assembler or C.

jue

[Rainer Weikusat]

Kiuhnm <kiuhnm03.4t.yahoo.it> writes:
>> d => sub {
>> my $l1;
>>
>> for (keys(%ENV)) {
>> if ((my $l = length($_))> $l1) { $l1 = $; }
>> }
>> }
>> });
>> -------------
>
> If this isn't another Perl feature I don't know about, you forgot an
> l' in your last assignment. On my PC, the 'l' improves the
> efficiency.

Not significantly (if at all).

> I guess even undef->0 conversions count.
> Anyway, taking that $l out of the loop, makes the last option the fastest.
> The "objects" after the "fat commas" are (pointers to?) closures?
>
> Try this code:
>
> -------->
> use Benchmark;
>
> timethese(-5, {

[...]

> });
> <--------
>
> 'e' wins on my PC.

You won't really get anything useful when running this only for 5
seconds and the results aren't really stable even when using a much
larger count:

[rw@sapphire]/tmp $perl c.pl
Benchmark: running a, c, d, e, f for at least 20 CPU seconds...
a: 20 wallclock secs (20.66 usr + 0.12 sys = 20.78 CPU) @ 207958.47/s (n=4321377)
c: 20 wallclock secs (19.97 usr + 0.03 sys = 20.00 CPU) @ 203267.70/s (n=4065354)
d: 21 wallclock secs (20.83 usr + 0.12 sys = 20.95 CPU) @ 169893.65/s (n=3559272)
e: 21 wallclock secs (20.89 usr + 0.06 sys = 20.95 CPU) @ 202873.51/s (n=4250200)
f: 20 wallclock secs (20.87 usr + 0.09 sys = 20.96 CPU) @ 207976.19/s (n=4359181)
[rw@sapphire]/tmp $perl c.pl
Benchmark: running a, c, d, e, f for at least 20 CPU seconds...
a: 22 wallclock secs (21.58 usr + 0.11 sys = 21.69 CPU) @ 200191.47/s (n=4342153)
c: 21 wallclock secs (20.70 usr + 0.05 sys = 20.75 CPU) @ 192327.61/s (n=3990798)
d: 20 wallclock secs (20.72 usr + 0.07 sys = 20.79 CPU) @ 149736.70/s (n=3113026)
e: 22 wallclock secs (21.96 usr + 0.04 sys = 22.00 CPU) @ 187564.00/s (n=4126408)
f: 19 wallclock secs (20.07 usr + 0.10 sys = 20.17 CPU) @ 201994.50/s (n=4074229)

Especially, the relative positions of of (a, f) and (c, e) where the
other way around for most of the runs I did. The result is roughly
that a and f come out first, then, c and e, and then d, which is by
far the worst.

[Ben Morrow]

Quoth Kiuhnm <kiuhnm03.4t.yahoo.it>:

> On 2/21/2012 14:47, Rainer Weikusat wrote:
> >
> > length($_)> $len1 and $len1 = length($_) for keys(%ENV);
>
> Interesting. That syntax is new to me, but makes sense.

You realise the 'and' short-circuits, as in C and shell, right? (It's
not an uncommon idiom in shell, either.)

> My only doubt is whether "and" and "&&" are the same thing. It appears
> so.

They are not quite. '&&' has relatively high precedence (it binds
tightly); 'and' has extremely low precedence. This is an example of when
it matters: if Rainer had used '&&' instead it would have been
equivalent to

((length($_) > $len1) && $len1) = length($_)

which is not at all the same as the

(length($_) > $len1) and ($len1 = length($_))

he actually wrote.

I find the B::Deparse module useful for checking precedence:

perl -MO=Deparse,-p -e'length($_) > $len1 && $len1 = length($_)'
(((length($_) > $len1) && $len1) = length($_));

Adding just '-MO=Deparse' to a perl command-line makes perl print a
compiled-and-decompiled version of your program instead of running it;
adding the ',-p' option to Deparse makes it put in all possible
parentheses.

It is usual to use '&&' when you want a logical operator, and 'and' when
you're using it for control flow.

> > d => sub {
> > my $l1;
> >
> > for (keys(%ENV)) {
> > if ((my $l = length($_))> $l1) { $l1 = $; }
> > }
> > }
> > });
>

> If this isn't another Perl feature I don't know about, you forgot an 'l'
> in your last assignment.

Well, there *is* a $; variable, with an extremely obscure use, but
somehow I doubt that's what Rainer meant... :)

<snip>

> The "objects" after the "fat commas" are (pointers to?) closures?

Yes. In Perl we would normally call them 'references' rather than
'pointers', but it's very much the same thing. (A Perl ref is refcounted
and garbage-collected, and so a good deal safer than a C pointer.)

(Technically they aren't closures in this instance, just anonymous
subroutines, because they don't close over any outer variables. This is
nearly never an important distinction.)

Ben

[Tim McDaniel]

In article <4f438e22$0$1390$4faf...@reader2.news.tin.it>,

Some great answers have been given. I'll just add two small points:

"Micro-optimization leads to micro-results."

For doing max and min, I personally prefer a more parallel-looking
structure like
if ($len1 < length $_) {
$len1 = length $_;
}

--
Tim McDaniel, tm...@panix.com

[Kiuhnm]

On 2/21/2012 16:44, Ben Morrow wrote:
> Quoth Kiuhnm<kiuhnm03.4t.yahoo.it>:
>> On 2/21/2012 14:47, Rainer Weikusat wrote:
>>>
>>> length($_)> $len1 and $len1 = length($_) for keys(%ENV);
>>
>> Interesting. That syntax is new to me, but makes sense.
>
> You realise the 'and' short-circuits, as in C and shell, right? (It's
> not an uncommon idiom in shell, either.)

Of course. What strikes me is that strange "for". That's kind of cool,
though. Finally I can omit those hideous curly braces.

> They are not quite. '&&' has relatively high precedence (it binds
> tightly); 'and' has extremely low precedence. This is an example of when
> it matters: if Rainer had used '&&' instead it would have been
> equivalent to

[...]

> It is usual to use '&&' when you want a logical operator, and 'and' when
> you're using it for control flow.

Thank you. I didn't know that. I'm still at the trial-and-error stage.
"Learning Perl" won't give me too many details until my fragile mind is
ready to assimilate them :)

[...]

> Yes. In Perl we would normally call them 'references' rather than
> 'pointers', but it's very much the same thing. (A Perl ref is refcounted
> and garbage-collected, and so a good deal safer than a C pointer.)

Like in C#. Safety comes at a cost, though. It's not easy to write a
micro-kernel in C# or in Perl ;)

> (Technically they aren't closures in this instance, just anonymous
> subroutines, because they don't close over any outer variables. This is
> nearly never an important distinction.)

Well, theoretically, a closure doesn't need to "capture" outer variables
to be called a closure. But you already know that. I guess it depends on
how a community see things.

Kiuhnm

[Kiuhnm]

On 2/21/2012 16:34, Rainer Weikusat wrote:
> Kiuhnm<kiuhnm03.4t.yahoo.it> writes:
>>> d => sub {
>>> my $l1;
>>>
>>> for (keys(%ENV)) {
>>> if ((my $l = length($_))> $l1) { $l1 = $; }
>>> }
>>> }
>>> });
>>> -------------
>>
>> If this isn't another Perl feature I don't know about, you forgot an
>> l' in your last assignment. On my PC, the 'l' improves the
>> efficiency.
>
> Not significantly (if at all).

It makes a huge difference on my configuration (~30%).

> You won't really get anything useful when running this only for 5
> seconds and the results aren't really stable even when using a much
> larger count:
>
> [rw@sapphire]/tmp $perl c.pl
> Benchmark: running a, c, d, e, f for at least 20 CPU seconds...
> a: 20 wallclock secs (20.66 usr + 0.12 sys = 20.78 CPU) @ 207958.47/s (n=4321377)
> c: 20 wallclock secs (19.97 usr + 0.03 sys = 20.00 CPU) @ 203267.70/s (n=4065354)
> d: 21 wallclock secs (20.83 usr + 0.12 sys = 20.95 CPU) @ 169893.65/s (n=3559272)
> e: 21 wallclock secs (20.89 usr + 0.06 sys = 20.95 CPU) @ 202873.51/s (n=4250200)
> f: 20 wallclock secs (20.87 usr + 0.09 sys = 20.96 CPU) @ 207976.19/s (n=4359181)
> [rw@sapphire]/tmp $perl c.pl
> Benchmark: running a, c, d, e, f for at least 20 CPU seconds...
> a: 22 wallclock secs (21.58 usr + 0.11 sys = 21.69 CPU) @ 200191.47/s (n=4342153)
> c: 21 wallclock secs (20.70 usr + 0.05 sys = 20.75 CPU) @ 192327.61/s (n=3990798)
> d: 20 wallclock secs (20.72 usr + 0.07 sys = 20.79 CPU) @ 149736.70/s (n=3113026)
> e: 22 wallclock secs (21.96 usr + 0.04 sys = 22.00 CPU) @ 187564.00/s (n=4126408)
> f: 19 wallclock secs (20.07 usr + 0.10 sys = 20.17 CPU) @ 201994.50/s (n=4074229)
>
> Especially, the relative positions of of (a, f) and (c, e) where the
> other way around for most of the runs I did. The result is roughly
> that a and f come out first, then, c and e, and then d, which is by
> far the worst.

Well, the results are quite stable on *my* configuation:

Benchmark: running a, c, d, e, f for at least 20 CPU seconds...

a: 22 wallclock secs (20.90 usr + 0.00 sys = 20.90 CPU) @
81467.61/s (n=1702999)
c: 22 wallclock secs (21.09 usr + 0.00 sys = 21.09 CPU) @
79958.99/s (n=1686415)
d: 21 wallclock secs (21.12 usr + 0.00 sys = 21.12 CPU) @
68458.93/s (n=1446058)
e: 20 wallclock secs (21.04 usr + 0.00 sys = 21.04 CPU) @
84107.30/s (n=1769954)
f: 20 wallclock secs (21.43 usr + 0.00 sys = 21.43 CPU) @
81938.84/s (n=1756277)

Benchmark: running a, c, d, e, f for at least 20 CPU seconds...

a: 22 wallclock secs (21.29 usr + 0.00 sys = 21.29 CPU) @
81483.14/s (n=1735102)
c: 21 wallclock secs (21.09 usr + 0.00 sys = 21.09 CPU) @
80093.83/s (n=1689259)
d: 20 wallclock secs (21.03 usr + 0.00 sys = 21.03 CPU) @
68558.51/s (n=1441717)
e: 22 wallclock secs (21.05 usr + 0.00 sys = 21.05 CPU) @
84064.81/s (n=1769144)
f: 22 wallclock secs (21.25 usr + 0.02 sys = 21.26 CPU) @
82042.33/s (n=1744384)

Benchmark: running a, c, d, e, f for at least 20 CPU seconds...

a: 21 wallclock secs (20.90 usr + 0.00 sys = 20.90 CPU) @
81467.61/s (n=1702999)
c: 20 wallclock secs (21.00 usr + 0.00 sys = 21.00 CPU) @
80486.76/s (n=1690061)
d: 22 wallclock secs (21.12 usr + 0.00 sys = 21.12 CPU) @
68882.97/s (n=1454946)
e: 22 wallclock secs (21.22 usr + 0.00 sys = 21.22 CPU) @
84137.82/s (n=1785068)
f: 22 wallclock secs (21.36 usr + 0.00 sys = 21.36 CPU) @
82275.52/s (n=1757076)

And the results won't change if I go from 20 s. to "just" 5 s.:

Benchmark: running a, c, d, e, f for at least 5 CPU seconds...
a: 5 wallclock secs ( 5.27 usr + 0.00 sys = 5.27 CPU) @
81488.15/s (n=429687)
c: 5 wallclock secs ( 5.23 usr + 0.00 sys = 5.23 CPU) @
80314.20/s (n=419722)
d: 4 wallclock secs ( 5.34 usr + 0.00 sys = 5.34 CPU) @
68570.09/s (n=365890)
e: 6 wallclock secs ( 5.26 usr + 0.00 sys = 5.26 CPU) @
84131.25/s (n=442278)
f: 6 wallclock secs ( 5.35 usr + 0.00 sys = 5.35 CPU) @
82214.91/s (n=439932)

Why should they?

Kiuhnm

[Kiuhnm]

On 2/21/2012 17:38, Tim McDaniel wrote:
> Some great answers have been given. I'll just add two small points:
>
> "Micro-optimization leads to micro-results."

I believe that's not entirely true. Sometimes changing a comma will
speed up one's program considerably.

> For doing max and min, I personally prefer a more parallel-looking
> structure like
> if ($len1 < length $_) {
> $len1 = length $_;
> }

I still hate the two braces (6 keys on my keyboard), but that's
undeniably much more readable.

Kiuhnm

[Rainer Weikusat]

[...]

>> You won't really get anything useful when running this only for 5
>> seconds and the results aren't really stable even when using a much
>> larger count:
>>
>> [rw@sapphire]/tmp $perl c.pl
>> Benchmark: running a, c, d, e, f for at least 20 CPU seconds...
>> a: 20 wallclock secs (20.66 usr + 0.12 sys = 20.78 CPU) @ 207958.47/s (n=4321377)
>> c: 20 wallclock secs (19.97 usr + 0.03 sys = 20.00 CPU) @ 203267.70/s (n=4065354)
>> d: 21 wallclock secs (20.83 usr + 0.12 sys = 20.95 CPU) @ 169893.65/s (n=3559272)
>> e: 21 wallclock secs (20.89 usr + 0.06 sys = 20.95 CPU) @ 202873.51/s (n=4250200)
>> f: 20 wallclock secs (20.87 usr + 0.09 sys = 20.96 CPU) @ 207976.19/s (n=4359181)
>> [rw@sapphire]/tmp $perl c.pl
>> Benchmark: running a, c, d, e, f for at least 20 CPU seconds...
>> a: 22 wallclock secs (21.58 usr + 0.11 sys = 21.69 CPU) @ 200191.47/s (n=4342153)
>> c: 21 wallclock secs (20.70 usr + 0.05 sys = 20.75 CPU) @ 192327.61/s (n=3990798)
>> d: 20 wallclock secs (20.72 usr + 0.07 sys = 20.79 CPU) @ 149736.70/s (n=3113026)
>> e: 22 wallclock secs (21.96 usr + 0.04 sys = 22.00 CPU) @ 187564.00/s (n=4126408)
>> f: 19 wallclock secs (20.07 usr + 0.10 sys = 20.17 CPU) @ 201994.50/s (n=4074229)
>>
>> Especially, the relative positions of of (a, f) and (c, e) where the
>> other way around for most of the runs I did. The result is roughly
>> that a and f come out first, then, c and e, and then d, which is by
>> far the worst.
>
> Well, the results are quite stable on *my* configuation:

... which would server as further indication that they are not. Also,
the average difference between two successive value supposedly
measuring the same quantity varies between 17.2 (a) and 245.64
(d). How can this be for a deterministic phenomenon which has been
measured accurately?

> And the results won't change if I go from 20 s. to "just" 5 s.:

> Why should they?

Assuming that each individual measurement is composed of an accurate
part and some random error, it can be expected that the random errors
will tend to cancel out when a 'sufficiently large' number of
individual measurements is averaged. Which implies that longer
sequence ought to yield more accurate results.

But this looks suspiciciously like something people should learn when
they are about 16 or so ...

[Tim McDaniel]

In article <4f43d60b$0$1387$4faf...@reader2.news.tin.it>,

Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
>Of course. What strikes me is that strange "for".

They're called "statement modifiers" in "man perlsyn".

>Finally I can omit those hideous curly braces.

If you think curly braces are "hideous", you might prefer using some
other language instead. Or you might like Lingua::Romana::Perligata,
http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html

--
Tim McDaniel, tm...@panix.com

[Kiuhnm]

On 2/21/2012 19:16, Rainer Weikusat wrote:
> ... which would server as further indication that they are not. Also,
> the average difference between two successive value supposedly
> measuring the same quantity varies between 17.2 (a) and 245.64
> (d). How can this be for a deterministic phenomenon which has been
> measured accurately?
>
>> And the results won't change if I go from 20 s. to "just" 5 s.:
>> Why should they?
>
> Assuming that each individual measurement is composed of an accurate
> part and some random error, it can be expected that the random errors
> will tend to cancel out when a 'sufficiently large' number of
> individual measurements is averaged. Which implies that longer
> sequence ought to yield more accurate results.
>
> But this looks suspiciciously like something people should learn when
> they are about 16 or so ...

No need to be so defensive.

When one does these kinds of benchmarks he or she is not interested in
knowing exactly how many ns his or her piece of code will take to
execute but how much time it will take *on average*.
I don't know how reliable this benchmark is (is it cache-aware?,
etc...), but it clearly shows that code (e) is slightly faster than the
other codes on my configuration *on average*.
This means that if I use code (e) instead of codes (a)-(d) and (f) on a
regular basis, my programs will probably be slightly faster.
It isn't worth it, of course.

Kiuhnm

[Rainer Weikusat]

Kiuhnm <kiuhnm03.4t.yahoo.it> writes:
> On 2/21/2012 19:16, Rainer Weikusat wrote:
>> ... which would server as further indication that they are not. Also,
>> the average difference between two successive value supposedly
>> measuring the same quantity varies between 17.2 (a) and 245.64
>> (d). How can this be for a deterministic phenomenon which has been
>> measured accurately?
>>
>>> And the results won't change if I go from 20 s. to "just" 5 s.:
>>> Why should they?
>>
>> Assuming that each individual measurement is composed of an accurate
>> part and some random error, it can be expected that the random errors
>> will tend to cancel out when a 'sufficiently large' number of
>> individual measurements is averaged. Which implies that longer
>> sequence ought to yield more accurate results.
>>
>> But this looks suspiciciously like something people should learn when
>> they are about 16 or so ...
>
> No need to be so defensive.

That was just my last attempt to assume ignorance instead of malice.
HAND.

[Kiuhnm]

On 2/21/2012 20:36, Tim McDaniel wrote:
> In article<4f43d60b$0$1387$4faf...@reader2.news.tin.it>,
> Kiuhnm<kiuhnm03.4t.yahoo.it> wrote:
>> Of course. What strikes me is that strange "for".
>
> They're called "statement modifiers" in "man perlsyn".
>
>> Finally I can omit those hideous curly braces.
>
> If you think curly braces are "hideous", you might prefer using some
> other language instead.

How drastic!

> Or you might like Lingua::Romana::Perligata,
> http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html

Wow... I hate Latin (I was forced to learn it in high school) but that's
quite original.

Kiuhnm

[Kiuhnm]

I knew it: I shouldn't have told you about the missing "l" :(

Kiuhnm

[Tim McDaniel]

In article <4f44154e$0$1380$4faf...@reader2.news.tin.it>,

Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
>On 2/21/2012 20:36, Tim McDaniel wrote:
>> In article<4f43d60b$0$1387$4faf...@reader2.news.tin.it>,
>> Kiuhnm<kiuhnm03.4t.yahoo.it> wrote:
>>> Of course. What strikes me is that strange "for".
>>
>> They're called "statement modifiers" in "man perlsyn".
>>
>>> Finally I can omit those hideous curly braces.
>>
>> If you think curly braces are "hideous", you might prefer using
>> some other language instead.
>
>How drastic!

I think cashews and pecans and peanuts are great. If you're allergic
to them, why can't I suggest you try other things?

If curly braces are going to make you grit your teeth and detest the
language whenever you deal with them, why not save yourself the pain?

I've heard good things about Ruby. At a quick glance, it has no curly
braces for control flow, but does use them for hashes. I don't know
how much power it has, but the one report I heard of was from a
long-time Perl expert, and he had no complaints about things he could
do in Perl but could not do in Ruby.

--
Tim McDaniel, tm...@panix.com

[Ben Morrow]

Quoth tm...@panix.com:

use List::Util qw/max/;

my $len1 = max map length, keys %ENV;

(I predict this will also be fastest, but I can't be bothered to
benchmark. If you were counting a *really* large hash and you used
while(each) instead of for(keys) you might save a bit of time by
avoiding some memory allocation, but otherwise doing the max in C
instead of Perl is almost certain to be a win.)

If I were feeling this was unclear, or if the expressions were longer, I
might split it up into separate operations, like this:

my $len1 =
max
map length,
keys %ENV;

Ben

[Ben Morrow]

I didn't, actually :). I have no formal training in computer science,
just what I've picked up here and there. At any rate, I do know that
perl internally considers anonymous subs which do in fact close over
outer variables to be different from those which don't; in particular,
a sub {} which doesn't close over anything will return a ref to the same
sub every time, whereas one which doesn't won't. So:

~% perl -E'say for map { sub { 1 } } 1..2'
CODE(0x821928)
CODE(0x821928)
~% perl -E'say for map { my $x; sub { $x } } 1..2'
CODE(0x803aa8)
CODE(0x8196c8)
~%

(and there are a couple more Perl idioms for you :) ).

Ben

[Shmuel Metz]

In <4f43d60b$0$1387$4faf...@reader2.news.tin.it>, on 02/21/2012

at 06:36 PM, Kiuhnm <kiuhnm03.4t.yahoo.it> said:

>Of course. What strikes me is that strange "for".

See statement modifiers in perlsyn.

>"Learning Perl" won't give me too many details until my fragile mind
>is ready to assimilate them :)

I found that it was easier to learn from "Programming Perl" than from
"Learning Perl".

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Rainer Weikusat]

It is (according to a single measurement since I can't be bothered to
spend a serious effort on disproving other peoples phantasies) in the
same league as the other two good versions. Since it again needs to
perform roughly the same operations, this is to be expected (perl
isn't that bad). Sorry but there's really no magic "code distributed
together with Perl" bonus. That's still an indication of the social
state of the author, not of his technical abilities in general, and
certainly not of his ability to work inexplainable magic.

[Shmuel Metz]

In <ji1621$4i3$1...@reader1.panix.com>, on 02/21/2012

at 10:32 PM, tm...@panix.com (Tim McDaniel) said:

>I don't know how much power it has,

Just the core language? One of the things that makes Perl attractive
is CPAN.

[Greg Bacon]

Kiuhnm <kiuhnm03.4t.yahoo.it> wrote

: [...]
: Well, theoretically, a closure doesn't need to "capture" outer

: variables to be called a closure. But you already know that. I guess
: it depends on how a community see things.

I’m curious to see examples of this usage. Without closing over the
lexical environment, what’s left is a function pointer.

Greg
--
There are better ways to earn a living than to prevent other people from
making use of one's contributions to computer science.
-- Donald Knuth

[Tim McDaniel]

In article <4f443df2$4$fuzhry+tra$mr2...@news.patriot.net>,

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
>In <ji1621$4i3$1...@reader1.panix.com>, on 02/21/2012
> at 10:32 PM, tm...@panix.com (Tim McDaniel) said:
>
>>I don't know how much power it has,
>
>Just the core language? One of the things that makes Perl attractive
>is CPAN.

Unfortunately, too often I've been stuck on servers where I am not a
sysadmin or otherwise dare not touch Perl. I can do modules for
myself, but that doesn't help with code for others.

--
Tim McDaniel, tm...@panix.com

[Martijn Lievaart]

On Tue, 21 Feb 2012 19:05:46 +0100, Kiuhnm wrote:

>> For doing max and min, I personally prefer a more parallel-looking
>> structure like
>> if ($len1 < length $_) {
>> $len1 = length $_;
>> }
>
> I still hate the two braces (6 keys on my keyboard), but that's
> undeniably much more readable.

as has been pointed out before:

$len1 < length $_ or $len1 = length $_;

or:

$len1 = length $_ if $len1 < length $_;

or with braces, but reusable and readable in use:

sub max { $_[0] < $_[1] ? $_[1] : $_[0] }

$len1 = max($len1, $length);

TIMTOWTDI

HTH,
M4

[Justin C]

On 2012-02-21, Shmuel Metz <spam...@library.lspace.org.invalid> wrote:
> In <4f43d60b$0$1387$4faf...@reader2.news.tin.it>, on 02/21/2012
> at 06:36 PM, Kiuhnm <kiuhnm03.4t.yahoo.it> said:
>
>>Of course. What strikes me is that strange "for".
>
> See statement modifiers in perlsyn.
>
>>"Learning Perl" won't give me too many details until my fragile mind
>>is ready to assimilate them :)
>
> I found that it was easier to learn from "Programming Perl" than from
> "Learning Perl".

From my non-programming background I found Learning Perl to be
excellent, and *very* accessible. I find PP to be rather dense and,
because of it's size, daunting - I did, though, learn about complex data
structures from that and it blew my mind, I've not picked it up since, I
really should.

Justin.

--
Justin C, by the sea.

[Rainer Weikusat]

gba...@hiwaay.net (Greg Bacon) writes:
> Kiuhnm <kiuhnm03.4t.yahoo.it> wrote
>
> : [...]
> : Well, theoretically, a closure doesn't need to "capture" outer
> : variables to be called a closure. But you already know that. I guess
> : it depends on how a community see things.
>

> I’m curious to see examples of this usage. Without closing over the
> lexical environment, what’s left is a function pointer.

I've had a look at the CLTLv2 (Common Lisp The Language 2nd ed) of
this yesterday and the usage there was 'a closure is a function
defined in a non-null lexical environment' (paraphrase). There was an
added note that an implementation need not create 'a closure' for a
function defined in such an environment if it can be proven that
nothing from this environment is actually needed and that the
distinction would be more or less pointless since no representation of
'closures' was defined and anything that would really matter was that
lexical scoping works properly (and this was written by the guy who
reportedly invented the term). Consequently, what is or isn't a
closure would be something of interest to the implementation and for
users, its just functions/ subroutines who also observe the rules of
lexical scoping if there are such rules to observe.

From a user perspective, if the term is (technically) useful at all,
it would refer to a subroutine defined in a non-null lexical
environment. Since this isn't the case for anonymous subroutines put
as values into a hash at compile-time in the given way, they are not
closures, the original remark quoted above is besides the point and
IMHO, mainly an attempt to make it appear as if the person who started
this thread wasn't wrong after all by intentionally conufsing readers
(some people pursue such goals with great hardiness).

[Rainer Weikusat]

Rainer Weikusat <rwei...@mssgmbh.com> writes:

[...]

> From a user perspective, if the term is (technically) useful at all,
> it would refer to a subroutine defined in a non-null lexical
> environment. Since this isn't the case for anonymous subroutines put
> as values into a hash at compile-time in the given way, they are not
> closures,

This is, of course, completely wrong :-), because there's always 'an
enclosing block' in perl, with 'the current compilation unit' (aka
'file') being the outermost one.

[Shmuel Metz]

In <ji22it$79h$1...@reader1.panix.com>, on 02/22/2012

at 06:39 AM, tm...@panix.com (Tim McDaniel) said:

>Unfortunately, too often I've been stuck on servers where I am not
>a sysadmin or otherwise dare not touch Perl. I can do modules for
>myself, but that doesn't help with code for others.

Aren't you more likely to find Perl already installed than Python or
Ruby? If you're not allowed to download and install a CPAN module than
I doubt that you'd be allowed to install a new language processor.

[Shmuel Metz]

In <-POdnUXcZo6I-tnS...@posted.hiwaay2>, on 02/21/2012
at 09:55 PM, gba...@hiwaay.net (Greg Bacon) said:

>IÔÇÖm

Please check the settings on your news client. Usenet is an ASCII
medium, so anything in other character sets should be MIME encoded. It
looks like you're using UTF-8, in which case I'd recommend an encoding
of QP[1] rather than BASE64.

[1] Bletch!

[Ben Morrow]

Quoth Justin C <justi...@purestblue.com>:

The usual recommendation is that people who can already program (in some
other language) should start with PP, and people who can't should start
with LP. AIUI (I haven't read it: Perl was not my first language, so I
started with PP :) ) LP takes you through a lot of basic programming
concepts that will be invaluable to someone who hasn't met them before
but just get in the way for someone who has.

Ben

[Ben Morrow]

Quoth Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid>:

> In <ji22it$79h$1...@reader1.panix.com>, on 02/22/2012
> at 06:39 AM, tm...@panix.com (Tim McDaniel) said:
>
> >Unfortunately, too often I've been stuck on servers where I am not
> >a sysadmin or otherwise dare not touch Perl. I can do modules for
> >myself, but that doesn't help with code for others.
>
> Aren't you more likely to find Perl already installed than Python or
> Ruby? If you're not allowed to download and install a CPAN module than
> I doubt that you'd be allowed to install a new language processor.

More importantly, *if* you can't touch the system perl but you could
install ruby, you probably can install your own build of perl in its own
directory and use that for your own work. You don't need root to do
this: you can perfectly well build and install perl in a private
directory as an unprivileged user, you just have to make sure you adjust
your #! lines as appropriate.

Of course, you probably did ought to think about questions like 'if my
perl install is owned by the same user that is running my application,
is this a security hole?' (answer: yes). But that applies to the script
files your application is stored in, as well.

Ben

[Tim McDaniel]

In article <ji22it$79h$1...@reader1.panix.com>,

Another reply had:

> Aren't you more likely to find Perl already installed than Python or
> Ruby? If you're not allowed to download and install a CPAN module
> than I doubt that you'd be allowed to install a new language
> processor.

Sorry -- I went off on a tangent. You're right that I'm stuck in the
same way when it comes to choosing Perl versus Python versus Ruby -- I
can't install any of them in a system area if I want to share code.

I was addressing the tangental point "One of the things that makes
Perl attractive is CPAN". As it happens, Perl code I write is
executed by others, so I'd have to convince support to install and
support a useful module. Or I could usually copy its source, and then
I ought to go back every so often to integrate changes.

But we know the drawbacks of the reverse, building things into the
language ...

--
Tim McDaniel, tm...@panix.com

[Shmuel Metz]

In <vgaf19-...@anubis.morrow.me.uk>, on 02/22/2012

at 02:26 PM, Ben Morrow <b...@morrow.me.uk> said:

>The usual recommendation is that people who can already program (in
>some other language) should start with PP, and people who can't
>should start with LP.

That aligns with my experience.

[Kiuhnm]

On 2/21/2012 23:32, Tim McDaniel wrote:
>>> If you think curly braces are "hideous", you might prefer using
>>> some other language instead.
>>
>> How drastic!
>
> I think cashews and pecans and peanuts are great. If you're allergic
> to them, why can't I suggest you try other things?
>
> If curly braces are going to make you grit your teeth and detest the
> language whenever you deal with them, why not save yourself the pain?

I'm just a little surprised that I need braces to enclose single statements.
I'm learning Perl because I'm interested in security (vulnerabilities,
malware, rootkits, etc...) and many scripts are written in Perl. Python
is also on my list.

> I've heard good things about Ruby.

I read its documentation a few years ago. Nothing new, but very well
designed.

Kiuhnm

[Kiuhnm]

On 2/21/2012 22:34, Shmuel (Seymour J.) Metz wrote:
> In<4f43d60b$0$1387$4faf...@reader2.news.tin.it>, on 02/21/2012
> at 06:36 PM, Kiuhnm<kiuhnm03.4t.yahoo.it> said:
>
>> Of course. What strikes me is that strange "for".
>
> See statement modifiers in perlsyn.
>
>> "Learning Perl" won't give me too many details until my fragile mind
>> is ready to assimilate them :)
>
> I found that it was easier to learn from "Programming Perl" than from
> "Learning Perl".

Thanks for the tip. My idea was to read
Learning Perl,
Intermediate Perl and
Mastering Perl,
but I'll have a look at PP. It seems that the latest edition covers Perl
5.14 as well.

Kiuhnm

[Tim McDaniel]

In article <4f454435$0$1382$4faf...@reader1.news.tin.it>,

Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
> I'm just a little surprised that I need braces to enclose single
> statements.

There are reasons. It's easy to forget curly braces and not realize
that the indentation and control flow are not as you expected:

if (-x "$path/$basename")
$name = "$path/$basename";
last;

or the "dangling else" problem:

if (this)
if (that)
stuff;
else
other_stuff;

(Note that in neither case does the indentation match the control
flow, and neither is valid Perl without adding curly braces.)

I think more languages are tending towards viewing Pascal, C, and
C++'s use of optional grouping as a mistake, and tend to require
delimiters.

--
Tim McDaniel, tm...@panix.com

[Greg Bacon]

Rainer Weikusat <rwei...@mssgmbh.com> wrote:

: This is, of course, completely wrong :-), because there's always 'an

: enclosing block' in perl, with 'the current compilation unit' (aka
: 'file') being the outermost one.

Yes, there's always an outer scope, but that's relevant only when
the sub needs to close over outer lexicals. See the implementation
of Perl_cv_clone in pad.c.

Greg
--
...we need an amendment that requires every Congressman and Senator to
certify in writing that he has read a bill in its entirety before he
can vote on it. The same must be required for the President before he
can sign a bill into law. -- Harry Browne

[Kiuhnm]

On 2/22/2012 0:49, Ben Morrow wrote:
> I didn't, actually :). I have no formal training in computer science,
> just what I've picked up here and there. At any rate, I do know that
> perl internally considers anonymous subs which do in fact close over
> outer variables to be different from those which don't; in particular,
> a sub {} which doesn't close over anything will return a ref to the same
> sub every time, whereas one which doesn't won't. So:
>
> ~% perl -E'say for map { sub { 1 } } 1..2'
> CODE(0x821928)
> CODE(0x821928)
> ~% perl -E'say for map { my $x; sub { $x } } 1..2'
> CODE(0x803aa8)
> CODE(0x8196c8)
> ~%
>
> (and there are a couple more Perl idioms for you :) ).

Good example, thanks.
Just a question. When I run the following code I get different values:
my $x; # global variable
say for map { sub { $x } } 1..10000;
It seems that Perl uses closures even when there's no real need for
them. Or am I missing something?

Kiuhnm

[Greg Bacon]

Rainer Weikusat <rwei...@mssgmbh.com> wrote:

: [...] Consequently, what is or isn't a closure would be something

: of interest to the implementation and for users, its just
: functions/ subroutines who also observe the rules of lexical
: scoping if there are such rules to observe.

That is an important distinction for users who want to understand
how a program works, e.g., whether calls through a given ref
are idempotent, whether results depend on @_ parameters only,
whether state lingers in secret hidey-holes, whether closures
communicate via an inaccessible medium, etc.

Yes, it's only a matter of adhering to the rules of lexical scoping,
but those rules add significant expressive power and thus more to
consider while reasoning about programs.

Greg
--
Democracy is the theory that the common people know what they want, and
deserve to get it good and hard.
-- H.L. Mencken

[Kiuhnm]

On 2/22/2012 20:53, Tim McDaniel wrote:
> In article<4f454435$0$1382$4faf...@reader1.news.tin.it>,
> Kiuhnm<kiuhnm03.4t.yahoo.it> wrote:
>> I'm just a little surprised that I need braces to enclose single
>> statements.
>
> There are reasons. It's easy to forget curly braces and not realize
> that the indentation and control flow are not as you expected:
>
> if (-x "$path/$basename")
> $name = "$path/$basename";
> last;
>
> or the "dangling else" problem:
>
> if (this)
> if (that)
> stuff;
> else
> other_stuff;
>
> (Note that in neither case does the indentation match the control
> flow, and neither is valid Perl without adding curly braces.)

I've been programming in C++ for many years and those mistakes are very
uncommon. Moreover, if you use a good editor or, better, a good IDE,
they're virtually impossible.
And even if they were common, isn't Perl the language where
say 1+2+3;
say (1+2)+3
print two different things?
I thought Perl was a language where omitting a few characters was worth
the risk of shooting oneself in the foot.

Kiuhnm

[Tim McDaniel]

In article <4f45709a$0$1380$4faf...@reader2.news.tin.it>,

Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
>I thought Perl was a language where omitting a few characters was
>worth the risk of shooting oneself in the foot.

If that were so, there would be no "use strict" and few variable
declarations. I'd say more that, in general, Perl was designed (if I
can use the word that loosely) to have defaults that Larry Wall (et
al) considered reasonable for the particular case at hand. Functions
without parentheses and behavior in scalar versus list contexts are
illustrative: "In general, they do what you want, unless you want
consistency."

So I assume Larry thought it better to not have a default for compound
statements like if, for, and such. But he didn't see a problem with
omitting curly braces with statement modifiers, or in map or grep.

--
Tim McDaniel, tm...@panix.com

[Ben Morrow]

Quoth Kiuhnm <kiuhnm03.4t.yahoo.it>:

> On 2/22/2012 0:49, Ben Morrow wrote:
> >
> > ~% perl -E'say for map { sub { 1 } } 1..2'
> > CODE(0x821928)
> > CODE(0x821928)
> > ~% perl -E'say for map { my $x; sub { $x } } 1..2'
> > CODE(0x803aa8)
> > CODE(0x8196c8)
> > ~%
>

> Just a question. When I run the following code I get different values:
> my $x; # global variable

This isn't a true global, of course, but a file-scoped lexical. True
package globals (declared with 'our' or 'use vars') are never closed
over, since they are directly accessible from everywhere.

> say for map { sub { $x } } 1..10000;
> It seems that Perl uses closures even when there's no real need for
> them. Or am I missing something?

No, you're not. For efficiency reasons, perl doesn't entirely
distinguish between this case

my $x;
for (1..2) {
sub { $x }
}

and this case

for (1..2) {
my $x;
sub { $x }
}

so it has to create a full closure in both cases. In principle it could
work out that in the first case $x is in a section of code that will
only run once, and treat it as a global, but that information isn't
available at the point where it decides which form of anon sub it needs.

(Incidentally, this issue came up here just the other day in the context
of 'variable will not stay shared' warnings, which are of course very
closely related. In that situation perl treats the second case as though
it were the first, rather than the other way around.)

Ben

[Ben Morrow]

Quoth tm...@panix.com:

> In article <4f45709a$0$1380$4faf...@reader2.news.tin.it>,
> Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
> >I thought Perl was a language where omitting a few characters was
> >worth the risk of shooting oneself in the foot.
>
> If that were so, there would be no "use strict" and few variable
> declarations.

There weren't, in the beginning. That's why 'uninitialised value' and
'variable used only once' warnings were so important: in Perl 4 they
were your only hope of spotting you'd misspelled a variable name. You
will notice, if you look, that there are still a number of modules
distributed with the perl core that don't run under strictures
(Exporter, Carp, and Getopt::Std, for instance).

As time goes on, perl is becoming more strict. This is, in general a
Good Thing.

> I'd say more that, in general, Perl was designed (if I
> can use the word that loosely)

No need to use it loosely. Perl was designed rather carefully, though
not always in a way likely to appeal to language purists. There are a
great many ways of changing Perl which, while they seem sensible on the
surface, actually end up causing huge problems because they go against
the grain of the language (*cough*SvUTF8). For instance, quite a lot of
languages have taken up Perl's regex operators; none of them make them
as easy to use as Perl, despite the initial apparent weirdness of (say)
the =~ operator.

> to have defaults that Larry Wall (et
> al) considered reasonable for the particular case at hand. Functions
> without parentheses and behavior in scalar versus list contexts are
> illustrative: "In general, they do what you want, unless you want
> consistency."

The specific example given ('say (1+2)+3' vs say 1+2+3) was IMHO a
mistake (I have *finally* trained myself to usually add the appropriate
unary + without thinking...), though I'm not entirely sure what the Right
Answer would have been.

One of the problems here is that Perl's grammar is *extremely*
ambiguous. (If you want to give yourself nightmares, go take a look at
the code in toke.c for parsing quoted strings. In particular, the bit
which decides whether a [] is a subscript or a character class...)

> So I assume Larry thought it better to not have a default for compound
> statements like if, for, and such. But he didn't see a problem with
> omitting curly braces with statement modifiers, or in map or grep.

Well, there isn't any need. A braceless 'if' is simply spelled 'and'.
(Before Perl 5 it was spelled '&&', and you had to use more parens.)

(They're even implemented the same: 'if (A) { B }' is compiled, after
optimisation, to exactly the same code as 'A and do { B };', though of
course the lexical scoping is slightly different.)

Ben

[Tim McDaniel]

In article <3vig19-...@anubis.morrow.me.uk>,
Ben Morrow <b...@morrow.me.uk> wrote:
>
>Quoth tm...@panix.com:

>> I'd say more that, in general, Perl was designed (if I
>> can use the word that loosely)
>
>No need to use it loosely. Perl was designed rather carefully,

The prosecutor could introduce package'name as exhibit A and rest.
$[
$]
pseudo-hash
and lots of other things in
http://www.modernperlbooks.com/mt/2009/07/deprecated-pointy-bits.html
that were ill-considered at the time (not just in retrospect).

--
Tim McDaniel, tm...@panix.com

[Ben Morrow]

Quoth tm...@panix.com:

> In article <3vig19-...@anubis.morrow.me.uk>,
> Ben Morrow <b...@morrow.me.uk> wrote:
> >Quoth tm...@panix.com:
> >> I'd say more that, in general, Perl was designed (if I
> >> can use the word that loosely)
> >
> >No need to use it loosely. Perl was designed rather carefully,
>
> The prosecutor could introduce package'name as exhibit A and rest.

package'name was introduced, like so much else in Perl, to be compatible
with an existing language (in this case Ada, which was important at the
time). I don't believe it's actually the least bit ambiguous within the
Perl grammar: it only causes problems for extremely-simple-minded syntax
highlighters, which, again, probably didn't exist at the time.

> $[

This was another get-people-to-switch feature, this time for awk and
Fortran users. Yes, it's an extremely bad fit for Perl 5, but it wasn't
introduced into Perl 5, it was introduced into Perl 1. I don't think
Perl 1 even had 'require' (or 'do FILE'), so problems with global
settings didn't really apply.

> $]

What's wrong with that? (If you wanted to bring up $^V and vstrings and
version.pm I wouldn't disagree, but those are 5.{6,10}-isms rather than
original features.)

> pseudo-hash

Phash was (I believe) a 5005 feature, so, again, relatively recent and
not designed with enough of an eye on the language as a whole.

Ben

[Ted Zlatanov]

On Wed, 22 Feb 2012 20:51:56 +0100 Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:

K> Thanks for the tip. My idea was to read
K> Learning Perl,
K> Intermediate Perl and
K> Mastering Perl,
K> but I'll have a look at PP. It seems that the latest edition covers
K> Perl 5.14 as well.

I'd put the Perl Cookbook either second or third on that list. It's a
very valuable compendium of common problems with good solutions.

Also Unix Power Tools, if you have interest in Unix, is a very good book
to add to this list. Perl grew and exists in a Unix ecosystem (Windows
ports notwithstanding) so learning about the tools and facilities in
that ecosystem is very useful.

Ted

[Kiuhnm]

On 2/23/2012 17:33, Ted Zlatanov wrote:
> On Wed, 22 Feb 2012 20:51:56 +0100 Kiuhnm<kiuhnm03.4t.yahoo.it> wrote:
>
> K> Thanks for the tip. My idea was to read
> K> Learning Perl,
> K> Intermediate Perl and
> K> Mastering Perl,
> K> but I'll have a look at PP. It seems that the latest edition covers
> K> Perl 5.14 as well.
>
> I'd put the Perl Cookbook either second or third on that list. It's a
> very valuable compendium of common problems with good solutions.

Ok!

> Also Unix Power Tools, if you have interest in Unix, is a very good book
> to add to this list. Perl grew and exists in a Unix ecosystem (Windows
> ports notwithstanding) so learning about the tools and facilities in
> that ecosystem is very useful.

Indeed, I've just found out that I can't use wildcards in command-line
arguments because Perl expects the shell to expand them, whereas Windows
expects *the program* to expand them.

Kiuhnm

[Rainer Weikusat]

gba...@hiwaay.net (Greg Bacon) writes:
> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
> : This is, of course, completely wrong :-), because there's always 'an
> : enclosing block' in perl, with 'the current compilation unit' (aka
> : 'file') being the outermost one.
>
> Yes, there's always an outer scope, but that's relevant only when
> the sub needs to close over outer lexicals.

But the fact that there is always a lexical scope implies that
subroutines are never without a lexical environment and that this is
consequently not a distinctive quality in Perl.

[Kiuhnm]

On 2/23/2012 2:08, Ben Morrow wrote:
> Quoth Kiuhnm<kiuhnm03.4t.yahoo.it>:
[...]

>> Just a question. When I run the following code I get different values:
>> my $x; # global variable
>
> This isn't a true global, of course, but a file-scoped lexical. True
> package globals (declared with 'our' or 'use vars') are never closed
> over, since they are directly accessible from everywhere.

Now I understand why we write "my" and not something like "var".

>> say for map { sub { $x } } 1..10000;
>> It seems that Perl uses closures even when there's no real need for
>> them. Or am I missing something?
>
> No, you're not. For efficiency reasons, perl doesn't entirely
> distinguish between this case
>
> my $x;
> for (1..2) {
> sub { $x }
> }
>
> and this case
>
> for (1..2) {
> my $x;
> sub { $x }
> }
>
> so it has to create a full closure in both cases. In principle it could
> work out that in the first case $x is in a section of code that will
> only run once, and treat it as a global, but that information isn't
> available at the point where it decides which form of anon sub it needs.

Then we should probably take "sub { $x }" out of the loop (in real-world
programs, I mean).

> (Incidentally, this issue came up here just the other day in the context
> of 'variable will not stay shared' warnings, which are of course very
> closely related. In that situation perl treats the second case as though
> it were the first, rather than the other way around.)

I'm a little lost here.
Every closure captures the same instance of $x in the first case.
If I write
say &$_ for map { my $x; sub { ++$x } } (1..10)
and
my $x;
say &$_ for map { sub { ++$x } } (1..10)
I expect to get different results.
But I probably miss some context here.

Kiuhnm

[Kiuhnm]

On 2/22/2012 4:55, Greg Bacon wrote:
> Kiuhnm<kiuhnm03.4t.yahoo.it> wrote
>
> : [...]
> : Well, theoretically, a closure doesn't need to "capture" outer
> : variables to be called a closure. But you already know that. I guess
> : it depends on how a community see things.
>

> I'm curious to see examples of this usage. Without closing over the
> lexical environment, what's left is a function pointer.

I wasn't talking about usage. I meant that we might say that every
function is a closure (but the converse is false) the same way as we
might say that every number is a matrix. If you know how to multiply two
matrices you also know how to multiply two numbers.
In Ruby everything is an object. Well, we may design a language where
everything is a closure. The implementation, to be efficient, would see
things differently, of course.

Kiuhnm

[Greg Bacon]

Rainer Weikusat <rwei...@mssgmbh.com> wrote:

: Greg Bacon writes:
:
: > Yes, there's always an outer scope, but that's relevant only when
: > the sub needs to close over outer lexicals. [See the implementation
: > of Perl_cv_clone in pad.c. (Important snip restored! -geb)]
:
: But the fact that there is always a lexical scope implies that

: subroutines are never without a lexical environment and that this is
: consequently not a distinctive quality in Perl.

If a sub has no way of reaching into that lexical environment, then the
distinction is irrelevant. See the implementation of Perl_cv_clone in
pad.c.

Greg
--
It would be an absurdity for jurors to be required to accept the judge's
view of the law, against their own opinion, judgment, and conscience.
-- John Adams

[Ben Morrow]

Quoth Kiuhnm <kiuhnm03.4t.yahoo.it>:

> On 2/23/2012 2:08, Ben Morrow wrote:
>
> > No, you're not. For efficiency reasons, perl doesn't entirely
> > distinguish between this case
> >
> > my $x;
> > for (1..2) {
> > sub { $x }
> > }
> >
> > and this case
> >
> > for (1..2) {
> > my $x;
> > sub { $x }
> > }
> >
> > so it has to create a full closure in both cases. In principle it could
> > work out that in the first case $x is in a section of code that will
> > only run once, and treat it as a global, but that information isn't
> > available at the point where it decides which form of anon sub it needs.
>
> Then we should probably take "sub { $x }" out of the loop (in real-world
> programs, I mean).

Perhaps, if you thought it mattered. It doesn't, usually.

> > (Incidentally, this issue came up here just the other day in the context
> > of 'variable will not stay shared' warnings, which are of course very
> > closely related. In that situation perl treats the second case as though
> > it were the first, rather than the other way around.)
>
> I'm a little lost here.
> Every closure captures the same instance of $x in the first case.
> If I write
> say &$_ for map { my $x; sub { ++$x } } (1..10)
> and
> my $x;
> say &$_ for map { sub { ++$x } } (1..10)
> I expect to get different results.
> But I probably miss some context here.

I was being unclear. 'Variable will not stay shared' is the warning you
get when you close a *named* sub over a variable which will have more
than one instance. Since a named sub only ever has one instance they
obviously all end up referring to the same variable, which ends up not
being shared with the outer scope any more.

However, because perl loses track of the difference between the two
cases above, it has to choose whether to warn for neither or both. Since
this is a warning, rather than an question of correctness, a false
positive is worse than a false negative, so it fails to warn in the
second case.

Ben

[Kiuhnm]

On 2/24/2012 12:17, Ben Morrow wrote:
> I was being unclear. 'Variable will not stay shared' is the warning you
> get when you close a *named* sub over a variable which will have more
> than one instance. Since a named sub only ever has one instance they
> obviously all end up referring to the same variable, which ends up not
> being shared with the outer scope any more.
>
> However, because perl loses track of the difference between the two
> cases above, it has to choose whether to warn for neither or both. Since
> this is a warning, rather than an question of correctness, a false
> positive is worse than a false negative, so it fails to warn in the
> second case.

Ok, now it's clear.

Kiuhnm

[Ben Morrow]

Quoth gba...@hiwaay.net (Greg Bacon):

> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
> : Greg Bacon writes:
> :
> : > Yes, there's always an outer scope, but that's relevant only when
> : > the sub needs to close over outer lexicals. [See the implementation
> : > of Perl_cv_clone in pad.c. (Important snip restored! -geb)]
> :
> : But the fact that there is always a lexical scope implies that
> : subroutines are never without a lexical environment and that this is
> : consequently not a distinctive quality in Perl.
>
> If a sub has no way of reaching into that lexical environment, then the
> distinction is irrelevant. See the implementation of Perl_cv_clone in
> pad.c.

The CvOUTSIDE links are still there, and perl goes to some trouble to
keep them valid. See pad_findlex and the implementation of eval:

perl -E'my ($x, $y, $z) = (1,2,3);
sub foo { say eval $_ for qw/$x $y $z/ }
foo'

Ben

[Rainer Weikusat]

gba...@hiwaay.net (Greg Bacon) writes:
> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
> : Greg Bacon writes:
> : > Yes, there's always an outer scope, but that's relevant only when
> : > the sub needs to close over outer lexicals. [See the implementation
> : > of Perl_cv_clone in pad.c. (Important snip restored! -geb)]
> :
> : But the fact that there is always a lexical scope implies that
> : subroutines are never without a lexical environment and that this is
> : consequently not a distinctive quality in Perl.
>
> If a sub has no way of reaching into that lexical environment, then the
> distinction is irrelevant. See the implementation of Perl_cv_clone in
> pad.c.

Steele defines closure as 'function defined in a non-null lexical
environment'. Originally, I suggested to use the same definition for
Perl. But this definition cannot be used for Perl because it is not
possible to create a Perl subroutine which is outside of any lexical
environment aka 'outer scope'. And 'the implementation of
Perl_cv_clone' doesn't figure here at all: Irregardless of how
closures are implemented in Perl (meaning, even if there wasn't always
an outside link => Ben's posting), there's still always such an
outside environment when the subroutine is created.

[Shmuel Metz]

In <4f46a454$0$1388$4faf...@reader2.news.tin.it>, on 02/23/2012

at 09:40 PM, Kiuhnm <kiuhnm03.4t.yahoo.it> said:

>Indeed, I've just found out that I can't use wildcards in
>command-line arguments because Perl expects the shell to expand
>them, whereas Windows expects *the program* to expand them.

That's an oversimplification. There's nothing in Perl that prevents an
argument from containing wild cards, it's possible to escape wildcards
in the *ix shells and there are other systems besides windoze where
the shell doesn't interpret wildcard characters. See, e.g., glob EXPR
in perlfunc.

[Kiuhnm]

On 2/24/2012 4:15, Shmuel (Seymour J.) Metz wrote:
> In<4f46a454$0$1388$4faf...@reader2.news.tin.it>, on 02/23/2012
> at 09:40 PM, Kiuhnm<kiuhnm03.4t.yahoo.it> said:
>
>> Indeed, I've just found out that I can't use wildcards in
>> command-line arguments because Perl expects the shell to expand
>> them, whereas Windows expects *the program* to expand them.
>
> That's an oversimplification. There's nothing in Perl that prevents an
> argument from containing wild cards, it's possible to escape wildcards
> in the *ix shells and there are other systems besides windoze where
> the shell doesn't interpret wildcard characters. See, e.g., glob EXPR
> in perlfunc.

I'll rephrase it. I can't simply use "while (<>)" like in *ix.

Kiuhnm

[C.DeRykus]

I think it's documented somewhere that
'my' has both compile-time and run-time
effects. In your former case, it's still
a closure but the run-time resets $x because of the scope introduced
by
map; whereas, in the latter, there's no
inner scope to wipe out the incrementing.
Here's an illustration:

perl -E 'my $y; &$_ for map { sub {my $x;++$x;++$y;say "$x|$y" } }
(1..10) '
1|1
1|2
1|3
1|4
1|5
1|6
1|7
1|8
1|9
1|10

Of course, there's probably more to this :)

--
Charles DeRykus

[Kiuhnm]

>> say&$_ for map { my $x; sub { ++$x } } (1..10)
>> and
>> my $x;
>> say&$_ for map { sub { ++$x } } (1..10)

>> I expect to get different results.
>> But I probably miss some context here.
>>
>> Kiuhnm
>
> I think it's documented somewhere that
> 'my' has both compile-time and run-time
> effects. In your former case, it's still
> a closure but the run-time resets $x because of the scope introduced
> by
> map; whereas, in the latter, there's no
> inner scope to wipe out the incrementing.
> Here's an illustration:
>
> perl -E 'my $y;&$_ for map { sub {my $x;++$x;++$y;say "$x|$y" } }
> (1..10) '
> 1|1
> 1|2
> 1|3
> 1|4
> 1|5
> 1|6
> 1|7
> 1|8
> 1|9
> 1|10
>
> Of course, there's probably more to this :)

Yes, I believe there is! Look at the references:

perl -E 'my $y; &$_ for map { sub {my $x;++$x;++$y;say "$x|$y, refs:",
\$x, "|", \$y } } (1..10) '

As you can see, there are many $x. The label is the same, but they're
different variables.

Kiuhnm

[C.DeRykus]

On Feb 24, 12:21 pm, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
> On 2/24/2012 18:55, C.DeRykus wrote:

> ...

> > I think it's documented somewhere that
> > 'my' has both compile-time and run-time
> > effects. In your former case, it's still
> > a closure but the run-time resets $x  because of  the scope introduced
> > by
> > map; whereas, in the latter, there's no
> > inner scope to wipe out the incrementing.
> > Here's an illustration:
>
> > perl -E 'my $y;&$_ for map { sub {my $x;++$x;++$y;say "$x|$y" } }
> > (1..10) '

> > ...

> > Of course, there's probably more to this :)
>
> Yes, I believe there is! Look at the references:
>
> perl -E 'my $y; &$_ for map { sub {my $x;++$x;++$y;say "$x|$y, refs:",
> \$x, "|", \$y } } (1..10) '
>
> As you can see, there are many $x. The label is the same, but they're
> different variables.
>

No, AIUI, memory for is released and
then reallocated for 'my' variables
each time through the loop on a private
stack. You probably shouldn't poke too
deeply into what goes on behind the
peephole :)

--
Charles DeRykus

[Peter J. Holzer]

On 2012-02-21 17:43, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
> On 2/21/2012 16:34, Rainer Weikusat wrote:
>> Kiuhnm<kiuhnm03.4t.yahoo.it> writes:
>>>> d => sub {
>>>> my $l1;
>>>>
>>>> for (keys(%ENV)) {
>>>> if ((my $l = length($_))> $l1) { $l1 = $; }
>>>> }
>>>> }
>>>> });
>>>> -------------
>>>
>>> If this isn't another Perl feature I don't know about, you forgot an
>>> l' in your last assignment. On my PC, the 'l' improves the
>>> efficiency.
>>
>> Not significantly (if at all).
>
> It makes a huge difference on my configuration (~30%).

More importantly, it makes a difference on the correctness. «$;» is not
the same variable as «$l». («use warnings 'numeric'» would have caught
that error, btw).

hp


--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on as...@irtf.org

[Peter J. Holzer]

On 2012-02-21 22:32, Tim McDaniel <tm...@panix.com> wrote:
> In article <4f44154e$0$1380$4faf...@reader2.news.tin.it>,
> Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
>>On 2/21/2012 20:36, Tim McDaniel wrote:
>>> In article<4f43d60b$0$1387$4faf...@reader2.news.tin.it>,
>>> Kiuhnm<kiuhnm03.4t.yahoo.it> wrote:
>>>> Finally I can omit those hideous curly braces.
>>>
>>> If you think curly braces are "hideous", you might prefer using
>>> some other language instead.
[...]
> I've heard good things about Ruby. At a quick glance, it has no curly
> braces for control flow, but does use them for hashes. I don't know
> how much power it has, but the one report I heard of was from a
> long-time Perl expert, and he had no complaints about things he could
> do in Perl but could not do in Ruby.
>

http://www.plat-forms.org/results-2011 may be an interesting read
(unfortunately the "detailed results report" seems to be still missing
after more than a year).

[Peter J. Holzer]

On 2012-02-22 13:43, Shmuel Metz <spam...@library.lspace.org.invalid> wrote:
> In <-POdnUXcZo6I-tnS...@posted.hiwaay2>, on 02/21/2012
> at 09:55 PM, gba...@hiwaay.net (Greg Bacon) said:
>>I郧謒
>
> Please check the settings on your news client. Usenet is an ASCII
> medium, so anything in other character sets should be MIME encoded. It
> looks like you're using UTF-8, in which case I'd recommend an encoding
> of QP[1] rather than BASE64.

The usenet has been 8-bit clean almost since the beginning, so QP and
Base64 are not needed (and should actually be avoided). But any charset
other than US-ASCII has to be declared in a Content-Type header or the
recipient can't know what the bytes mean.

[Kiuhnm]

Isn't you the one who's poking? :)
My assumptions are simpler:
a) Perl has a garbage collector (which supports circular referencing),
b) any "object" is kept alive while referenced,
c) Perl's closures behave like real closures.
You, on the other hand, are focusing on how Perl internally handles
things. That level of detail isn't needed to understand this simple
example, IMHO.
For instance, your explanation is no longer valid if I slightly change
the code, while mine is easier and still correct.
I could be wrong, of course, since the less I know about Perl the more
I'm forced to assume about its design and behavior.

-->
#!/usr/bin/perl -w

use 5.010;

my @xrefs;

my $y;
&$_ for map { sub {

++$y; my $x = $y;
push @xrefs, \$x;

say "$x|$y, refs:", \$x, "|", \$y;

} } (1..10);
say "$_ contains $$_" for (@xrefs);
<--

Kiuhnm

[Ben Morrow]

Quoth Kiuhnm <kiuhnm03.4t.yahoo.it>:

>
> My assumptions are simpler:
> a) Perl has a garbage collector (which supports circular referencing),

Depends on what you mean by 'supports'. Circular chains of refs are
allowed, but they will never be collected until broken (or weakened)
manually.

> b) any "object" is kept alive while referenced,
> c) Perl's closures behave like real closures.

Yup.

Ben

[Kiuhnm]

On 2/25/2012 15:53, Ben Morrow wrote:
>
> Quoth Kiuhnm<kiuhnm03.4t.yahoo.it>:
>>
>> My assumptions are simpler:
>> a) Perl has a garbage collector (which supports circular referencing),
>
> Depends on what you mean by 'supports'. Circular chains of refs are
> allowed, but they will never be collected until broken (or weakened)
> manually.

That's sad.

>> b) any "object" is kept alive while referenced,
>> c) Perl's closures behave like real closures.
>
> Yup.

Glad to hear I got those right.

Kiuhnm

[Shmuel Metz]

In <slrnjkh9sl.8l...@hrunkner.hjp.at>, on 02/25/2012

at 10:19 AM, "Peter J. Holzer" <hjp-u...@hjp.at> said:

>The usenet has been 8-bit clean almost since the beginning,

RFC 977 leaves the question open; I don't know about UUCP. RFC 3977
didn't come out until 2006, although it may well be that all deployed
NNTP software was 8-bit clean by then.

[Greg Bacon]

Rainer Weikusat <rwei...@mssgmbh.com> wrote:

: Steele defines closure as 'function defined in a non-null lexical

: environment'. Originally, I suggested to use the same definition for
: Perl. But this definition cannot be used for Perl because it is not
: possible to create a Perl subroutine which is outside of any lexical
: environment aka 'outer scope'. And 'the implementation of
: Perl_cv_clone' doesn't figure here at all: Irregardless of how
: closures are implemented in Perl (meaning, even if there wasn't always
: an outside link => Ben's posting), there's still always such an
: outside environment when the subroutine is created.

How does C<sub { 3 }> or C<sub { my($x) = @_; $x + 7 }> reach into
the outer lexical scope? Calling either of these representatives a
closure dilutes the term to the point of meaninglessness.

Greg
--
Nevertheless, if we emancipate regexes to serve as co-equal control
structures, and if we can rid ourselves of the regexist attitudes that many
of us secretly harbor, we'll have a much more productive society than we
currently do. -- Larry Wall, Apocalypse 5

[Greg Bacon]

Ben Morrow <b...@morrow.me.uk> wrote:

: The CvOUTSIDE links are still there, and perl goes to some trouble to

: keep them valid. See pad_findlex and the implementation of eval:
:
: perl -E'my ($x, $y, $z) = (1,2,3);
: sub foo { say eval $_ for qw/$x $y $z/ }
: foo'

That example clearly falls outside the category of subs with no
way of reaching into their respective outer lexical environments, so
why bring it up at this point in the discussion?

Greg
--
... the consolidation of the states into one vast republic, sure to be
aggressive abroad and despotic at home, will be the certain precursor of
that ruin which has overwhelmed all those that have preceded it.
-- Robert E. Lee

[Greg Bacon]

Peter J. Holzer <hjp-u...@hjp.at> wrote:

: The usenet has been 8-bit clean almost since the beginning, so QP and

: Base64 are not needed (and should actually be avoided). But any charset
: other than US-ASCII has to be declared in a Content-Type header or the
: recipient can't know what the bytes mean.

Can’t we all just go back to EBCDIC?

Greg
--
Freedom means that when you wake up in the morning, your life, liberty and
property are yours to do with them what you will. Of course, that means that
no one else's life, liberty, or property is yours. That's freedom. It's real
simple. -- James Ostrowski

[Rainer Weikusat]

gba...@hiwaay.net (Greg Bacon) writes:
> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
>
> : Steele defines closure as 'function defined in a non-null lexical
> : environment'. Originally, I suggested to use the same definition for
> : Perl. But this definition cannot be used for Perl because it is not
> : possible to create a Perl subroutine which is outside of any lexical
> : environment aka 'outer scope'. And 'the implementation of
> : Perl_cv_clone' doesn't figure here at all: Irregardless of how
> : closures are implemented in Perl (meaning, even if there wasn't always
> : an outside link => Ben's posting), there's still always such an
> : outside environment when the subroutine is created.
>
> How does C<sub { 3 }> or C<sub { my($x) = @_; $x + 7 }> reach into
> the outer lexical scope? Calling either of these representatives a
> closure dilutes the term to the point of meaninglessness.

I don't quite understand why you're hellbent on misunderstanding my
statement but I don't think that repeating it for a third time makes
any sense.

[Kiuhnm]

On 2/21/2012 22:34, Shmuel (Seymour J.) Metz wrote:
> In<4f43d60b$0$1387$4faf...@reader2.news.tin.it>, on 02/21/2012
> at 06:36 PM, Kiuhnm<kiuhnm03.4t.yahoo.it> said:
>
>> Of course. What strikes me is that strange "for".
>
> See statement modifiers in perlsyn.
>
>> "Learning Perl" won't give me too many details until my fragile mind
>> is ready to assimilate them :)
>
> I found that it was easier to learn from "Programming Perl" than from
> "Learning Perl".

I'm about to finish studying "Learning Perl" and now I understand what
you mean.
The biggest flaw (*) of that book is that it never tells you the entire
story. The result is that I'm never sure of anything when I try to do
something a little more complex. For instance, whenever I try to craft
longer expressions (like in functional programming) I get syntax errors.
Then I start juggling with parentheses, commas, and so on until, by
trial-and-error, I get it right.
I don't know about you, but I'd like to get it right the first time
(well, at least I want to have a chance).

Kiuhnm

(*) Besides having too many footnotes... like this one.

[Shmuel Metz]

In <TJCdnQEN38v8ANTS...@posted.hiwaay2>, on 02/25/2012

at 08:48 PM, gba...@hiwaay.net (Greg Bacon) said:

>Can t we all just go back to EBCDIC?

Sure; which EBCDIC code page do you want? BTDT,GTS.

[Peter J. Holzer]

On 2012-02-25 23:35, Shmuel Metz <spam...@library.lspace.org.invalid> wrote:
> In <slrnjkh9sl.8l...@hrunkner.hjp.at>, on 02/25/2012
> at 10:19 AM, "Peter J. Holzer" <hjp-u...@hjp.at> said:
>>The usenet has been 8-bit clean almost since the beginning,
>
> RFC 977 leaves the question open; I don't know about UUCP. RFC 3977
> didn't come out until 2006, although it may well be that all deployed
> NNTP software was 8-bit clean by then.

C-News was 8-bit clean and it was released in 1987. By about 1990 it
almost completely replaced B-News (one of the last holdouts I remember
whas unido, which was a bit unfortunate since it was at a relatively big
German university, so it had ample opportunity for mangling umlauts).

EBCDIC hosts were more problematic: Not only were they not 8-bit clean,
they weren't even ASCII-clean. It was quite possible to find a usenet
posting in comp.lang.c where all the curly braces had been replaced by
other characters. Minix used a non-standard uuencode format which was
specially designed to survive the damage inflicted by ASCII-EBCDIC
gateways.

[Shmuel Metz]

In <slrnjkksfg.65...@hrunkner.hjp.at>, on 02/26/2012

at 06:54 PM, "Peter J. Holzer" <hjp-u...@hjp.at> said:

>EBCDIC hosts were more problematic: Not only were they not 8-bit
>clean, they weren't even ASCII-clean.

Historically, the ASCII-EBCDIC translation in OS/360 and descendants
has been a dogs breakfast, so I'm not surprised.

[Greg Bacon]

Rainer Weikusat wrote:

: Greg Bacon writes:
:
: > How does C<sub { 3 }> or C<sub { my($x) = @_; $x + 7 }> reach into

: > the outer lexical scope? Calling either of these representatives a
: > closure dilutes the term to the point of meaninglessness.
:
: I don't quite understand why you're hellbent on misunderstanding my
: statement but I don't think that repeating it for a third time makes
: any sense.

I understand your statement just fine. You argued Steele’s
definition of closure is inapplicable to Perl because an outer
lexical environment exists at the point of creation.

This misses the forest for the trees. There is no *semantic*
difference between a function defined in a null lexical environment
and a function defined in a non-null but unreachable lexical
environment.

Greg
--
Men stumble over the truth from time to time, but most pick themselves
up and hurry off as if nothing happened.
-- Winston Churchill

[Rainer Weikusat]

gba...@hiwaay.net (Greg Bacon) writes:
> Rainer Weikusat wrote:
> : Greg Bacon writes:
> :
> : > How does C<sub { 3 }> or C<sub { my($x) = @_; $x + 7 }> reach into
> : > the outer lexical scope? Calling either of these representatives a
> : > closure dilutes the term to the point of meaninglessness.
> :
> : I don't quite understand why you're hellbent on misunderstanding my
> : statement but I don't think that repeating it for a third time makes
> : any sense.
>
> I understand your statement just fine. You argued Steele’s
> definition of closure is inapplicable to Perl because an outer
> lexical environment exists at the point of creation.

This is a fact, there's generally no point in arguing about facts and
I certainly didn't try to.

> This misses the forest for the trees. There is no *semantic*
> difference between a function defined in a null lexical environment
> and a function defined in a non-null but unreachable lexical
> environment.

Further, despite your apparent desire for some kind of opponent,
beyond paraphrasing Steele's definition and coming to the conclusion
that it cannot be applied to Perl, I didn't post anything about *my*
opinion on this topic and actually, I don't even have an opinion about
it, at least not a clear-cut one. So, please feel free to argue (this
time really) about the relative merits of your definition of 'closure'
vs 'the definition someone else used' but please stop targetting me in
lieu of 'the guy with the other opinion' just because I'm coniently
located bystander.

[Tad McClellan]

Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
> On 2/21/2012 22:34, Shmuel (Seymour J.) Metz wrote:

>> I found that it was easier to learn from "Programming Perl" than from
>> "Learning Perl".
>
> I'm about to finish studying "Learning Perl" and now I understand what
> you mean.
> The biggest flaw (*) of that book is that it never tells you the entire
> story.

A reference book (eg. Programming Perl) should tell you then entire story.

A tutorial book (eg. Learning Perl) should tell you the essential parts
of the story without myriad sidetrips into the "exceptions" (which Perl
is famous for).

Each is the Right Tool in different situatuions.


--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.

[Shmuel Metz]

In <slrnjkqda9...@tadbox.sbcglobal.net>, on 02/28/2012

at 02:10 PM, Tad McClellan <ta...@seesig.invalid> said:

>A tutorial book (eg. Learning Perl) should tell you the essential
>parts

I have yet to see a tutorial that covered what I considered the
essential parts. That's why I prefer learning from a reference,
although poor indexing may make it awkward.

[Kiuhnm]

On 2/28/2012 21:10, Tad McClellan wrote:
> Kiuhnm<kiuhnm03.4t.yahoo.it> wrote:
>> On 2/21/2012 22:34, Shmuel (Seymour J.) Metz wrote:
>
>>> I found that it was easier to learn from "Programming Perl" than from
>>> "Learning Perl".
>>
>> I'm about to finish studying "Learning Perl" and now I understand what
>> you mean.
>> The biggest flaw (*) of that book is that it never tells you the entire
>> story.
>
>
> A reference book (eg. Programming Perl) should tell you then entire story.
>
> A tutorial book (eg. Learning Perl) should tell you the essential parts
> of the story without myriad sidetrips into the "exceptions" (which Perl
> is famous for).
>
> Each is the Right Tool in different situatuions.

Let's put it this way: "Learning Perl" is too gentle and forgiving.

Kiuhnm

[Justin C]

On 2012-02-28, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
>
> Let's put it this way: "Learning Perl" is too gentle and forgiving.

I don't think that is the case if you have no programming background at
all.

Justin.

--
Justin C, by the sea.

[Kiuhnm]

On 2/29/2012 13:15, Justin C wrote:
> On 2012-02-28, Kiuhnm<kiuhnm03.4t.yahoo.it> wrote:
>>
>> Let's put it this way: "Learning Perl" is too gentle and forgiving.
>
> I don't think that is the case if you have no programming background at
> all.
>
> Justin.

I would have rather gone for "Programming Perl", but it's quite
outdated. Too bad the 4th edition is still unavailable.

Kiuhnm