[32361] in Perl-Users-Digest
Perl-Users Digest, Issue: 3628 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Mar 2 03:09:25 2012
Date: Fri, 2 Mar 2012 00:09:07 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 2 Mar 2012 Volume: 11 Number: 3628
Today's topics:
Re: access to variable names inside subprocedure <cartercc@gmail.com>
Re: access to variable names inside subprocedure <ben@morrow.me.uk>
Re: given...when <willem@toad.stack.nl>
Re: given...when <kiuhnm03.4t.yahoo.it>
Re: given...when <willem@toad.stack.nl>
Hash key types and equality of hash keys (Tim McDaniel)
Re: Hash key types and equality of hash keys <rweikusat@mssgmbh.com>
Re: Hash key types and equality of hash keys (Tim McDaniel)
Re: Hash key types and equality of hash keys <ben@morrow.me.uk>
Re: lang comparison: in-place algorithm for reversing a <rweikusat@mssgmbh.com>
Re: lang comparison: in-place algorithm for reversing a <w_a_x_man@yahoo.com>
Re: lang comparison: in-place algorithm for reversing a <xahlee@gmail.com>
Re: New Science Discovery: Perl Detracters Remain Idiot (Seymour J.)
Re: New Science Discovery: Perl Idiots Remain Idiots Af (Seymour J.)
Re: New Science Discovery: Perl Idiots Remain Idiots Af <chiron613@gmail.com>
references (4567890) <kiuhnm03.4t.yahoo.it>
Re: references (4567890) <ben@morrow.me.uk>
Re: rm .cpan? <rurban@cpanel.net>
Re: rm .cpan? <rurban@cpanel.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 1 Mar 2012 09:47:13 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: access to variable names inside subprocedure
Message-Id: <ccafea3c-fab7-43e6-b7ec-edeb348e832f@r1g2000yqk.googlegroups.com>
On Feb 29, 6:23=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> =A0 =A0 my %Data;
>
> =A0 =A0 for (qw/fileone filetwo/) {
> =A0 =A0 =A0 =A0 read_file $_;
> =A0 =A0 =A0 =A0 write_file $_;
> =A0 =A0 }
>
> =A0 =A0 sub read_file {
> =A0 =A0 =A0 =A0 my ($file) =3D @_;
> =A0 =A0 =A0 =A0 open my $F, "<", $file or die ...;
> =A0 =A0 =A0 =A0 $Data{$file} =3D [ <$F> ];
> =A0 =A0 }
>
> =A0 =A0 sub write_file {
> =A0 =A0 =A0 =A0 my ($file) =3D @_;
> =A0 =A0 =A0 =A0 open my $F, ">", $file or die ...;
> =A0 =A0 =A0 =A0 for (@{ $Data{$file} }) {
> =A0 =A0 =A0 =A0 =A0 =A0 print $F $_;
> =A0 =A0 =A0 =A0 }
> =A0 =A0 }
Okay, some thoughts about programming paradigms.
When I learned C, I learned to write a main function, which called
other functions and then exited.
When I learned Java, I learned to decompose my problem domain into
classes. Unfortunately, I had a couple of OO development classes
before I actually learned Java, and it didn't make much since to me,
but when I started writing Java for real, I wrote it bottom up, tests
first, and liked it very much.
In the past couple of years, I've begun writing Lisp, and have
acquired a taste for the functional style. Whenever I have the energy,
I try to write my Perl scripts in a more-or-less functional style, but
it takes a lot of energy and I often get lazy.
My Perl scripts tend to start off as pseudo code, and I implement the
script incrementally, converting the pseudo code to real code piece by
piece. This has more in common with C than with the others, but I
don't think in terms of one MAIN function, but a number of MAIN
functions that I call sequentially, much like a batch file.
I see where you are going -- wrapping the program in one gigantic
foreach loop. Conceptually, the idea is new to me, and I'm not sure
how to deal with it, or if I can deal with it in the light of my
previous experience. It strikes me as being more closely related to
the functional style than the others, and if I were writing in Lisp, I
can visualize how the program would appear visually (and I don't mean
like fingernail clippings mixed with oatmeal).
Thoughts?
CC.
------------------------------
Date: Thu, 1 Mar 2012 20:38:53 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: access to variable names inside subprocedure
Message-Id: <tb3529-0gl.ln1@anubis.morrow.me.uk>
Quoth ccc31807 <cartercc@gmail.com>:
>
> In the past couple of years, I've begun writing Lisp, and have
> acquired a taste for the functional style. Whenever I have the energy,
> I try to write my Perl scripts in a more-or-less functional style, but
> it takes a lot of energy and I often get lazy.
Personally I think that's good style, except when it gets in the way.
> My Perl scripts tend to start off as pseudo code, and I implement the
> script incrementally, converting the pseudo code to real code piece by
> piece. This has more in common with C than with the others, but I
> don't think in terms of one MAIN function, but a number of MAIN
> functions that I call sequentially, much like a batch file.
They aren't different, except that in Perl your main function doesn't
have a name so you can't call it again.
> I see where you are going -- wrapping the program in one gigantic
> foreach loop. Conceptually, the idea is new to me, and I'm not sure
> how to deal with it, or if I can deal with it in the light of my
> previous experience.
No.... that was just an example, because I didn't have your original
code quoted. If I were to rewrite that with minimal changes I might
write
use Storable;
my %Data;
$Data{"hashref1.dat"} = retrieve('hashref1.dat');
$Data{"hashref2.dat"} = retrieve('hashref2.dat');
$Data{"hashref3.dat"} = retrieve('hashref3.dat');
# extensive processing on %Data
# ... then
save_hashes("hashref1.dat", "hashref2.dat", "hashref3.dat");
exit(0);
but I can't see something like those first three lines without wanting
to turn it into a loop.
Ben
------------------------------
Date: Thu, 1 Mar 2012 16:27:39 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: given...when
Message-Id: <slrnjkv8rr.nt3.willem@toad.stack.nl>
Kiuhnm wrote:
) On 2/28/2012 20:38, Shmuel (Seymour J.) Metz wrote:
)> Another poster gave what, IMHO, was a sound reason for the practice;
)> if you add a line you need a separating semicolon, but you don't want,
)> e.g., diff, to treat the original line as changed. Of course, you
)> could add a semicolon on a separate line, but that would generally be
)> poor style.
)
) I understand, but why not using a smarter tool?
Can you name such a tool?
More specifically, one that is suitable for source control?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Thu, 01 Mar 2012 17:58:14 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: given...when
Message-Id: <4f4faaa5$0$1386$4fafbaef@reader2.news.tin.it>
On 3/1/2012 17:27, Willem wrote:
> Kiuhnm wrote:
> ) On 2/28/2012 20:38, Shmuel (Seymour J.) Metz wrote:
> )> Another poster gave what, IMHO, was a sound reason for the practice;
> )> if you add a line you need a separating semicolon, but you don't want,
> )> e.g., diff, to treat the original line as changed. Of course, you
> )> could add a semicolon on a separate line, but that would generally be
> )> poor style.
> )
> ) I understand, but why not using a smarter tool?
>
> Can you name such a tool?
> More specifically, one that is suitable for source control?
No, because I don't use any.
Kiuhnm
------------------------------
Date: Thu, 1 Mar 2012 21:31:40 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: given...when
Message-Id: <slrnjkvqls.1uqc.willem@toad.stack.nl>
Kiuhnm wrote:
) On 3/1/2012 17:27, Willem wrote:
)> Kiuhnm wrote:
)> ) On 2/28/2012 20:38, Shmuel (Seymour J.) Metz wrote:
)> )> Another poster gave what, IMHO, was a sound reason for the practice;
)> )> if you add a line you need a separating semicolon, but you don't want,
)> )> e.g., diff, to treat the original line as changed. Of course, you
)> )> could add a semicolon on a separate line, but that would generally be
)> )> poor style.
)> )
)> ) I understand, but why not using a smarter tool?
)>
)> Can you name such a tool?
)> More specifically, one that is suitable for source control?
)
) No, because I don't use any.
Then I must assume such a 'smarter tool' does not exist,
which answers your question.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Thu, 1 Mar 2012 17:46:09 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Hash key types and equality of hash keys
Message-Id: <jiocl1$aj5$1@reader1.panix.com>
I tried "man perldata", but I didn't notice anything applicable.
I've always used only strings as hash keys -- I've just assumed
without any evidence that they're the only things that work.
But it occurred to me to wonder what else could be used as keys.
(Any scalar value can be used as hash *data*, I think.)
I was expecting errors from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#! /usr/bin/perl
use warnings;
use strict;
use Data::Dumper;
my %hash = ();
my $i = 23;
$hash{\$i} = 'narf';
$hash{sub { print 'blort' }} = 'hurple';
my $f = sub { print 'bazinga' };
$hash{$f} = 'poit';
$hash{qr/acc/} = 'zing';
$hash{undef} = 'WTF?';
print $hash{\$i}, "\n";
print $hash{sub { print 'blort' }}, "\n";
print $hash{$f}, "\n";
print $hash{qr/acc/}, "\n";
print $hash{undef}, "\n";
print Data::Dumper->Dump([\%hash], [qw[hash]]), "\n";
exit 0;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
but I was astonished that most of it worked:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ perl ~/local/test/027.pl ; perl -v
narf
Use of uninitialized value in print at
/home/tmcdaniel/local/test/027.pl line 14.
poit
zing
WTF?
$hash = {
'SCALAR(0x116ede20)' => 'narf',
'undef' => 'WTF?',
'CODE(0x116f4200)' => 'poit',
'CODE(0x116ede80)' => 'hurple',
'(?-xism:acc)' => 'zing'
};
This is perl, v5.8.8 built for x86_64-linux-thread-multi
...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So I'm thinking that, in Perl, hash keys can also be any scalar.
Is that documented anywhere?
That then leads to the question: what counts as "equal" in the context
of looking up a hash value?
- sub { print 'blort' } is considered a different key from a later
lexical use of sub { print 'blort' }.
- But qr/acc/ matches a later lexical use of qr/acc/.
- The same reference to the same item is equal to itself, which is not
surprising. That is, evaluate the reference in one place, store it
in a variable, and use that variable's value. (E.g., $f = sub {...}
and use $f.)
- A reference to the same scalar (\$i) is consistent, even though I
didn't assign \$i to a variable. This too is unsurprising. This
probably works with a reference to any variable.
- "undef" is identical, and without a warning.
I'm sure I'm overlooking some other scalar value types. And I cannot
try every value even of the types I know about -- qr/acc/ is simple
enough that Perl knows it's identical to another instance, but for all
I know, if there's a certain more complicated expression or some
certain modifier, Perl doesn't understand equality (much like sub{}).
So is there documentation for what keys are considered equal?
I don't think there's an operator to check for that equality
(other than "sub hashequal { my ($a, $b) = @_; my %t = ($a, 1); return exists $t{$b}; }")
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 01 Mar 2012 18:12:03 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Hash key types and equality of hash keys
Message-Id: <87r4xc6vik.fsf@sapphire.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> I tried "man perldata", but I didn't notice anything applicable.
>
> I've always used only strings as hash keys -- I've just assumed
> without any evidence that they're the only things that work.
> But it occurred to me to wonder what else could be used as keys.
[...]
> $hash = {
> 'SCALAR(0x116ede20)' => 'narf',
> 'undef' => 'WTF?',
> 'CODE(0x116f4200)' => 'poit',
> 'CODE(0x116ede80)' => 'hurple',
> '(?-xism:acc)' => 'zing'
> };
[...]
> So I'm thinking that, in Perl, hash keys can also be any scalar.
> Is that documented anywhere?
It is documented:
Hashes are unordered collections of scalar values indexed by
their associated string key.
[perldata(1)]
This means that if you use something which is not a string as hash
key, that something is stringified and the resulting string becomes
the actual key.
------------------------------
Date: Thu, 1 Mar 2012 18:32:24 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Hash key types and equality of hash keys
Message-Id: <jiofbo$4de$1@reader1.panix.com>
In article <87r4xc6vik.fsf@sapphire.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>tmcd@panix.com (Tim McDaniel) writes:
>> I tried "man perldata", but I didn't notice anything applicable.
>>
>> I've always used only strings as hash keys -- I've just assumed
>> without any evidence that they're the only things that work.
>> But it occurred to me to wonder what else could be used as keys.
>
>[...]
>
>> $hash = {
>> 'SCALAR(0x116ede20)' => 'narf',
>> 'undef' => 'WTF?',
>> 'CODE(0x116f4200)' => 'poit',
>> 'CODE(0x116ede80)' => 'hurple',
>> '(?-xism:acc)' => 'zing'
>> };
>
>[...]
>
>> So I'm thinking that, in Perl, hash keys can also be any scalar.
>> Is that documented anywhere?
>
>It is documented:
>
> Hashes are unordered collections of scalar values indexed by
> their associated string key.
> [perldata(1)]
>
>This means that if you use something which is not a string as hash
>key, that something is stringified and the resulting string becomes
>the actual key.
*light dawns over Marblehead* Why, lookie at all those *QUOTATION MARKS*
in the key positions in the Data::Dumper->Dump output, as opposed to
what it outputs when given a real reference!
Thank you. I blush.
I just realized that
$hash{undef} = 'WTF?';
was wrong: "undef" is interpreted as a string, of course.
$hash{undef()} = 'WTF?';
gives a warning "Use of uninitialized value in hash element" and
the key is a null string.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 1 Mar 2012 20:29:41 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Hash key types and equality of hash keys
Message-Id: <lq2529-0gl.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> I tried "man perldata", but I didn't notice anything applicable.
>
> I've always used only strings as hash keys -- I've just assumed
> without any evidence that they're the only things that work.
> But it occurred to me to wonder what else could be used as keys.
> (Any scalar value can be used as hash *data*, I think.)
perldoc -q "reference as a hash key"
:)
Ben
------------------------------
Date: Thu, 01 Mar 2012 22:14:35 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: lang comparison: in-place algorithm for reversing a list in Perl,Python, Lisp
Message-Id: <87zkc0oto4.fsf@sapphire.mobileactivedefense.com>
Xah Lee <xahlee@gmail.com> writes:
[...]
> similarly, in perl, either one
> require POSIX; floor(x/y);
> the require POSIX instead of Math is a quirk. But even, floor should
> really be builtin.
> or
> using a perl hack
> int(x/y)
>
> all of the above are quirks. They rely on computer engineering by-
> products (such as int),
Integral numbers are not 'a computer engineering byproduct'.
> or rely on the lang's idiosyncrasy. One easy way to measure it is
> whether a programer can read and understand a program without having
> to delve into its idiosyncrasies. Problem with these lang idioms is
> that it's harder to understand, and whatever advantage/optimization
> they provide is microscopic and temporary.
It's hard to understand for someone who knows only mathematical
idiosyncrasies and who is also convinced that this should really be
more than enough for a lifetime. But that's not some kind of 'natural
knowledge' people just happen to have but systematically drilled into
pupils from a very early age, despite most of them won't ever have any
use for any of it insofar it goes beyond + - * /.
[...]
> idiomatic programing, is a bad thing.
If you have to use something (like a particular programming language)
but you resent learning how to use it and rather make lofty excuses,
chances are that you are rather a lazy f*cker than a great philosopher
...
------------------------------
Date: 2 Mar 2012 07:17:34 GMT
From: "WJ" <w_a_x_man@yahoo.com>
Subject: Re: lang comparison: in-place algorithm for reversing a list in Perl,Python, Lisp
Message-Id: <jips6e0f14@enews2.newsguy.com>
Xah Lee wrote:
> fun example.
>
> in-place algorithm for reversing a list in Perl, Python, Lisp
> http://xahlee.org/comp/in-place_algorithm.html
>
> plain text follows
> ----------------------------------------
>
> What's “In-place Algorithm”?
>
> Xah Lee, 2012-02-29
>
> This page tells you what's “In-place algorithm”, using {python, perl,
> emacs lisp} code to illustrate.
>
> Here's Wikipedia In-place algorithm excerpt:
>
> In computer science, an in-place algorithm (or in Latin in situ) is an
> algorithm which transforms input using a data structure with a small,
> constant amount of extra storage space. The input is usually
> overwritten by the output as the algorithm executes. An algorithm
> which is not in-place is sometimes called not-in-place or out-of-
> place.
>
> Python
>
> Here's a python code for reversing a list. Done by creating a new
> list, NOT using in-place:
>
> # python
> # reverse a list
>
> list_a = ["a", "b", "c", "d", "e", "f", "g"]
>
> list_length = len(list_a)
> list_b = [0] * list_length
>
> for i in range(list_length):
> list_b[i] = list_a[list_length -1 - i]
>
> print list_b
> Here's in-place algorithm for reversing a list:
>
> # python
> # in-place algorithm for reversing a list
>
> list_a = ["a", "b", "c", "d", "e", "f", "g"]
>
> list_length = len(list_a)
>
> for i in range(list_length/2):
> x = list_a[i]
> list_a[i] = list_a[ list_length -1 - i]
> list_a[ list_length -1 - i] = x
>
> print list_a
> Perl
>
> Here's a perl code for reversing a list. Done by creating a new list,
> NOT using in-place:
>
> # perl
>
> use strict;
> use Data::Dumper;
>
> my @listA = qw(a b c d e f g);
>
> my $listLength = scalar @listA;
> my @listB = ();
>
> for ( my $i = 0; $i < $listLength; $i++ ) {
> $listB[$i] = $listA[ $listLength - 1 - $i];
> }
>
> print Dumper(\@listB);
>
> # perl
> # in-place algorithm for reversing a list.
>
> use strict;
> use Data::Dumper;
> use POSIX; # for “floor”
>
> my @listA = qw(a b c d e f g);
>
> my $listLength = scalar @listA;
>
> for ( my $i = 0; $i < floor($listLength/2); $i++ ) {
> my $x = $listA[$i];
> $listA[$i] = $listA[ $listLength - 1 - $i];
> $listA[ $listLength - 1 - $i] = $x;
> }
>
> print Dumper(\@listA);
> __END__
>
> emacs lisp
>
> ;; emacs lisp
> ;; reverse a array
>
> (setq arrayA ["a" "b" "c" "d" "e" "f" "g"])
>
> (setq arrayLength (length arrayA))
>
> (setq arrayB (make-vector arrayLength 0))
>
> (dotimes (i arrayLength )
> (aset arrayB i (aref arrayA (- (1- arrayLength) i)) )
> )
>
> (print (format "%S" arrayB))
> ;; emacs lisp
> ;; in-place algorithm for reversing a array
>
> (setq arrayA ["a" "b" "c" "d" "e" "f" "g"])
>
> (setq arrayLength (length arrayA))
>
> (dotimes (i (floor (/ arrayLength 2)))
> (let (x)
> (setq x (aref arrayA i))
> (aset arrayA i (aref arrayA (- (1- arrayLength) i)))
> (aset arrayA (- (1- arrayLength) i) x) ) )
>
> (print (format "%S" arrayA))
>
> Xah
NewLisp:
> (setq lst '(2 3 5 8))
(2 3 5 8)
> (reverse lst)
(8 5 3 2)
> lst
(8 5 3 2)
------------------------------
Date: Thu, 1 Mar 2012 14:04:10 -0800 (PST)
From: Xah Lee <xahlee@gmail.com>
Subject: Re: lang comparison: in-place algorithm for reversing a list in Perl,Python, Lisp
Message-Id: <8e769add-e63c-4a74-bb7e-ddd36c04a415@vs5g2000pbc.googlegroups.com>
On Mar 1, 7:04=A0am, Kaz Kylheku <k...@kylheku.com> wrote:
lisp:
(floor (/ x y)) --[rewrite]--> (floor x y)
Thanks for this interesting point.
I don't think it's a good lang design, more of a lang quirk.
similarly, in Python 2.x,
x/y
will work when both x and y are integers. Also,
x//y
works too, but that // is just perlish unreadable syntax quirk.
similarly, in perl, either one
require POSIX; floor(x/y);
the require POSIX instead of Math is a quirk. But even, floor should
really be builtin.
or
using a perl hack
int(x/y)
all of the above are quirks. They rely on computer engineering by-
products (such as int), or rely on the lang's idiosyncrasy. One easy
way to measure it is whether a programer can read and understand a
program without having to delve into its idiosyncrasies. Problem with
these lang idioms is that it's harder to understand, and whatever
advantage/optimization they provide is microscopic and temporary.
best is really floor(x/y).
idiomatic programing, is a bad thing. It was spread by perl, of
course, in the 1990s. Idiomatic lang, i.e. lang with huge number of
bizarre idioms, such as perl, is the worst.
Xah
------------------------------
Date: Thu, 01 Mar 2012 10:07:15 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: New Science Discovery: Perl Detracters Remain Idiots After A Decade!
Message-Id: <4f4f90a3$38$fuzhry+tra$mr2ice@news.patriot.net>
In <fgD3r.7862$_63.3414@newsfe19.iad>, on 03/01/2012
at 04:52 AM, Chiron <chiron613@gmail.com> said:
>Yes. That (the mathematically defined way) is a particular way, is
>it not?
No. There is no "the mathematically defined way".
>However, I wasn't specifically referring to infix/postfix/prefix or
>anything of that nature. I wasn't limiting my comment to lisp
>notation in particular, since what I said applies to any language.
No, it doesn't.
>I was referring to the placement of parentheses (or other
>groupings) to indicate to *humans* what the intended sequence
>of events was.
Operator precedence has the same purpose, and was around long before
computers. Quite often expressions exploiting operator precedence are
easier *for humans* to read than expressions involving deeply nested
parentheses.
>Mathematically,
Your exposure to Mathematics is too limited.
>and in any language with which I am familiar,
Your exposure to computer languages is too limited.
>the sequence: 2 + 6 / 3 will yield 4.
Try it in APL.
>Whenever there is *any* possibility of ambiguity, I see no reason
>not to clarify.
Even if doing so makes it harder to read? Since you keep referring to
Mathematics, I will point out that it is rare in Mathematics for
anybody to publish a complete proof. Minor steps are almost always
omitted to make for easier reading, and ambiguous shortcuts are used
in the expectation that the reader will understand what is meant.
>Back in the days when the way you wrote your code affected how it
>was compiled,
That would be the present.
>it made sense to rely heavily on language-specific
>features, thus saving a few bytes.
Those optimizations involved adding extraneous parentheses, not
omitting redundant parentheses.
>A few extra variables, if they help clarity, aren't going to hurt
>anything.
And if they harm clarity?
>Let the machine do the grunt work.
That's exactly what languages with operator precedence do.
>Pamper your readers (which in a few weeks or months might be you)
>and show exactly what you had in mind.
The two goals conflict.
>That's all I'm saying.
No; you're saying to use redundant parentheses, which conflicts with
other things you're saying.
--
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 spamtrap@library.lspace.org
------------------------------
Date: Thu, 01 Mar 2012 10:13:11 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: New Science Discovery: Perl Idiots Remain Idiots After A Decade!New Science Discovery: Perl Idiots Remain Idiots Af
Message-Id: <4f4f9207$39$fuzhry+tra$mr2ice@news.patriot.net>
In <DuD3r.21706$cL.12835@newsfe17.iad>, on 03/01/2012
at 05:07 AM, Chiron <chiron613@gmail.com> said:
>Hmm... maybe, instead of just ridiculing him,
I'm treating him as he treats others.
>BTW, I happen to agree with you insofar as this poster not
>understanding the nature of mathematics. His comment reminds me of
>the article, "Transgressing the Boundaries: Towards a
>Transformative Hermeneutics of Quantum Gravity"
A brilliant piece of work. I greatly enjoyed it and the reaction to
its disclosure.
--
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 spamtrap@library.lspace.org
------------------------------
Date: Fri, 02 Mar 2012 07:27:58 GMT
From: Chiron <chiron613@gmail.com>
Subject: Re: New Science Discovery: Perl Idiots Remain Idiots After A Decade!New Science Discovery: Perl Idiots Remain Idiots After A Decade!
Message-Id: <2E_3r.4452$HX7.1864@newsfe11.iad>
On Wed, 29 Feb 2012 00:09:16 -0800, Xah Lee wrote:
Xah, you won't grow even an inch taller by cutting others down.
--
I joined scientology at a garage sale!!
------------------------------
Date: Thu, 01 Mar 2012 20:27:56 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: references (4567890)
Message-Id: <4f4fcdba$0$1386$4fafbaef@reader2.news.tin.it>
Is there any good reason (why) we can't write
ref->[0][1] instead of $ref->[0][1]
and, above all,
@ref->[0][1] instead of @{$ref->[0][1]}
?
------------------------------
Date: Thu, 1 Mar 2012 20:48:23 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: references (4567890)
Message-Id: <nt3529-0gl.ln1@anubis.morrow.me.uk>
Quoth Kiuhnm <kiuhnm03.4t.yahoo.it>:
> Is there any good reason (why) we can't write
> ref->[0][1] instead of $ref->[0][1]
That parses as
ref($_)->[0][1]
and if you don't use a reserved word it parses as one of
"foo"->[0][1]
or foo()->[0][1]
depending on whether there is a 'sub foo' in scope. The former is a
symref (it's equivalent to ${"foo"}[0][1]) and will cause an error under
strict "refs".
> and, above all,
> @ref->[0][1] instead of @{$ref->[0][1]}
> ?
I did up a patch for perl at one point that made
$ref->[0][1][]
(with an empty set of brackets on the end) equivalent to
@{$ref->[0][1]}
and the equivalent for %{}, but it was rejected on the grounds that it
wasn't useful enough to be worth introducing new syntax for. (Personally
I'd rather an explicit syntax like that than 5.14's auto-deref for
specific ops like push, but there we go.)
Ben
------------------------------
Date: Thu, 01 Mar 2012 10:44:20 -0600
From: Reini Urban <rurban@cpanel.net>
Subject: Re: rm .cpan?
Message-Id: <4F4FA764.1000900@cpanel.net>
On 02/18/2012 01:28 PM, Bill M wrote:
> My production machine has only a small (2G) flash drive and I want to
> free up as much space as is possible. What are the implications of
> completely removing the complete .cpan dir? If I keep part of it intact,
> will it make upgrading any easier?
Keep .cpan but rm -rf .cpan/build and ./cpan/sources if you are low on
disc space.
Using cpanm is preferred as it is faster using online metadata and does
not keep slack.
--
Reini
------------------------------
Date: Thu, 01 Mar 2012 10:44:32 -0600
From: Reini Urban <rurban@cpanel.net>
Subject: Re: rm .cpan?
Message-Id: <jio91c$4gr$2@speranza.aioe.org>
On 02/18/2012 01:28 PM, Bill M wrote:
> My production machine has only a small (2G) flash drive and I want to
> free up as much space as is possible. What are the implications of
> completely removing the complete .cpan dir? If I keep part of it intact,
> will it make upgrading any easier?
Keep .cpan but rm -rf .cpan/build and ./cpan/sources if you are low on
disc space.
Using cpanm is preferred as it is faster using online metadata and does
not keep slack.
--
Reini
------------------------------
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 3628
***************************************
