[32651] in Perl-Users-Digest
Perl-Users Digest, Issue: 3927 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Apr 17 14:09:32 2013
Date: Wed, 17 Apr 2013 11:09:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 17 Apr 2013 Volume: 11 Number: 3927
Today's topics:
clever fork <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: clever fork <rweikusat@mssgmbh.com>
Re: Find::File OS/2 <dave@invalid.invalid>
Re: More idiomatic <rvtol+usenet@xs4all.nl>
Re: More idiomatic <peter@makholm.net>
Re: More idiomatic <rweikusat@mssgmbh.com>
Re: More idiomatic <whynot@pozharski.name>
Re: More idiomatic <rweikusat@mssgmbh.com>
Re: More idiomatic (Tony Mountifield)
Re: More idiomatic <ben@morrow.me.uk>
Re: More idiomatic <kst-u@mib.org>
Re: More idiomatic <source@netcom.com>
Re: More idiomatic <ben@morrow.me.uk>
Re: More idiomatic <source@netcom.com>
Re: More idiomatic <source@netcom.com>
Re: More idiomatic <ben@morrow.me.uk>
Re: More idiomatic <source@netcom.com>
musings about 'idiomatic' (was: More idiomatic) <rweikusat@mssgmbh.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 16 Apr 2013 21:47:21 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: clever fork
Message-Id: <kkk6c0$cqu$1@news.ntua.gr>
I want to utilize all the cpu cores as much as possible.
What I am thinking is to "break" my sql queries to as many parts as the
number of cpu cores , and then fork every part.
Do you think it is going to work ; Do you have any other idea ; Thanks.
------------------------------
Date: Wed, 17 Apr 2013 18:36:23 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: clever fork
Message-Id: <87haj52h60.fsf@sapphire.mobileactivedefense.com>
"George Mpouras"
<nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
writes:
> I want to utilize all the cpu cores as much as possible.
> What I am thinking is to "break" my sql queries to as many parts as
> the number of cpu cores , and then fork every part.
> Do you think it is going to work ;
Probably. The more interesting question is "Does this make
sense?". You could utilize more than one core for 'application
computing' in this way, however 'SQL query' usually implies RDBMS
which means that a lot of the 'computing' is done insided the
database management system which is unaffected by forks done in an
application and that I/O is necessary to move the queries to the
database and the results back to the application. I/O is also (at
best) unaffected by application forks and it is going to be a lot
slower than 'computing', hence, there's a non-negligible chance that
your application is either I/O bound or that 'the CPU-bound parts'
happen insided the RDBMS.
------------------------------
Date: Tue, 16 Apr 2013 08:54:48 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Find::File OS/2
Message-Id: <fV45K0OBJxbE-pn2-XEOcHy3mHUqs@paddington.bear.den>
On Mon, 15 Apr 2013 22:54:33 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
Hi Ben
>
> Quoth "Dave Saville" <dave@invalid.invalid>:
> > I have a script that needs to obtain a list of files. The script takes
> > an argument as to where to start looking in the directory tree. So I
> > issue
> >
> > find(\&wanted, $start);
> >
> > If $start equals drive and directory such as t:/foo then all is fine.
> > But if I need to start in the root of a drive such as t: then find
> > throws an error:
> >
> > Can't stat t:: No such file or directory
> >
> > Note the double colon.
> >
> > t: & t:/ both give the same error.
>
> Well, the first thing to say is that File::Find appears to strip a
> trailing slash off the path passed to it, unless that path is "/". The
> relevant bit of File::Find is (I think; the code's rather hard to
> follow) line 521, in sub _find_opt:
>
> if ($Is_Win32) {
> $top_item =~ s|[/\\]\z||
> unless $top_item =~ m{^(?:\w:)?[/\\]$};
> }
> else {
> $top_item =~ s|/\z|| unless $top_item eq '/';
> }
>
> so my first guess would be that this is an OS/2 portability bug, and
> OS/2 should be included in the first branch of the if. It might be worth
> changing your copy to see if that works, and checking all the other uses
> of $Is_Win32 in that file as well. If this fixes the problem, report a
> bug to p5p.
>
Still on 5.8.2 because I cannot upgrade due to module install not
working on OS/2 and there is no mention of Win32 anywhere in Find.pm
1.05. There are similar bits of code for MacOS and I tried tweaking
the bit that seemed to match but that just made things worse. My work
around works so untill we fix the install, that will do. We may be
back on the install problem soon BTW.
> > Just giving t gives a slightly different error with t: rather
than t::
> >
> > t:/. works as does t:. - but messes all subsequent returned fully
> > qualified paths as in t:/./foo.
>
> Out of interest, does OS/2 have the same behaviour as Win32, where "t:"
> is not the same path as "t:/"? On Win32 the system maintains a current
> directory per drive plus a current drive, and "t:" refers to the current
> directory on drive t rather than its root.
Yes it's the same as Win. Has caught me out several times in the past.
--
Regards
Dave Saville
------------------------------
Date: Tue, 16 Apr 2013 08:18:54 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: More idiomatic
Message-Id: <516ced4e$0$2582$e4fe514c@news2.news.xs4all.nl>
On 2013-04-15 22:31, David Harmon wrote:
> Tim McDaniel:
>> if ($_ eq '') {
>
> Concur. But please, can I write it
> if (eq '') {
> if not, why not?
You can make "if (eq '')" compile as "if ($_ eq '')".
You could also write a sub (like eq_), to do it for you at runtime.
You can even make "if ( LITERAL )" compile as "if ( $_ eq LITERAL )",
but consider how constants like in "if ( DEBUG )" should be treated.
--
Ruud
------------------------------
Date: Tue, 16 Apr 2013 09:33:08 +0200
From: Peter Makholm <peter@makholm.net>
Subject: Re: More idiomatic
Message-Id: <874nf7c4ln.fsf@vps1.hacking.dk>
Ben Morrow <ben@morrow.me.uk> writes:
> With a constant filename, it's not so important, but it's safer to get
> into the habit of using 3-arg open:
>
> open my $fin, "<", "t1.txt";
...
> It's usual (though not universal) to use variable names in all caps for
> filehandles.
Is it?
For lexical filehandles I would usually use lower case and only use all
caps for the global non-lexical filehandelse. That is either
open(my $fh, "<", "somefile.txt") or die
or
open(FH, "<", "somefile.txt") or die
Though I would only very rarely use the latter. This usage follows the
conventions in the 'perldof -f open' documentation and is also the style
I mostly find on CPAN.
//Makholm
------------------------------
Date: Tue, 16 Apr 2013 10:11:36 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: More idiomatic
Message-Id: <87k3o2c01j.fsf@sapphire.mobileactivedefense.com>
"J. Gleixner" <glex_no-spam@qwest-spam-no.invalid> writes:
> On 04/15/13 14:55, David Harmon wrote:
>> On Mon, 15 Apr 2013 14:04:32 -0500 in comp.lang.perl.misc, "J.
>> Gleixner"<glex_no-spam@qwest-spam-no.invalid> wrote,
[...]
>>>> }
>>> close( $fin );
>>
>> Does that matter?
>
> Again, it's idiomatic..
According to
http://oald8.oxfordlearnersdictionaries.com/dictionary/idiomatic
'idiomatic' means
containing expressions that are natural to a native speaker of
a language
It is somewhat unclear what this is supposed to mean in the context of
a programming language but it certainly doesn't mean "include useless
code because 'everyone else does it'". Perl supports proper stack
unwinding and because of this, explicitly closing filehandles stored
in lexical variables is never necessary. The perl runtime will also
close all filehandles before the script exists.
------------------------------
Date: Tue, 16 Apr 2013 10:24:52 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: More idiomatic
Message-Id: <slrnkmpv64.5ii.whynot@orphan.zombinet>
with <kkhlmq$i1i$1@reader1.panix.com> Tim McDaniel wrote:
> In article <bfmdneSZqe8Y2fHMnZ2dnUVZ_vWdnZ2d@earthlink.com>,
> David Harmon <bad@example.invalid> wrote:
*SKIP*
>> if (/Newsgroups: .*,/i) {
>
> Missing caret.
> if (/^Newsgroups: .*,/i) {
> I don't know header standards: there always going to be a space after
> the "Newsgroups:" keyword?
Quoting RFC3977, chapter 3.6, p.24:
The headers of an article consist of one or more header lines.
Each header line consists of a header name, a colon, a space,
the header content, and a CRLF, in that order.
> In this list, sometimes you require one, sometimes you don't.
Lack of symmetry suggests.
> I'd be inclined to not try to match the space just to be more
> accepting.
Agreed. Later in the same paragraph RFC3977 says "The content ...; it
MAY be empty". The name is "one or more printable US-ASCII characters
other then colon". Geez, is it a NNTP header?
.oO(Look-i'm-a-header!):
Nothing about after-colon-space.
*CUT*
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Tue, 16 Apr 2013 11:10:16 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: More idiomatic
Message-Id: <87zjwyairb.fsf@sapphire.mobileactivedefense.com>
"C.DeRykus" <derykus@gmail.com> writes:
> On Monday, April 15, 2013 2:24:17 PM UTC-7, Rainer Weikusat wrote:
>> "C.DeRykus" <derykus@gmail.com> writes:
[...]
>> The compelling reason is that execution continues with the next
>> statement after the if-elsif... cascade in case of such a cascade. But
>> when there is not such 'next statement', the whole construct is just
>> a blind: It forces someone who is not familiar with the code to go
>> looking for such common code only to find none.
>
> And the multiple "if...next" code forces you to read
> through them all anyway to determine if there's common
> code as well. After all, at some point, an "if..." may
> not have a "next". You'll be schleppen through lots of
> noisy "next" statements to ensure that's the case.
I've meanwhile managed to understand what you were writing about:
Considering the way the posted code was written, the only 'thing' the
next statements actually skipped where the subsequent if tests and the
only reason why 'subsequent if tests' exist at all on this code path
is because if - elsif ... else wasn't used.
But that's IMHO besides the point: The terminating next marks each
if-block as 'self-contained' similar to the way the 'break' statement
works in a switch(..) { } in C: For this case, no further code within
the current block will be executed. And this is different from if
.... which denotes a set of alternate 'sibling sub-blocks' with the
current block. One could visualize this as something like
------
| stmt |
------
------
| stmt |
------
------- ------- -------
| if | | elsif | | else |
------- ------- -------
------
| stmt |
------
There's a 'point' after the if .. -cascade where all the alternate
codepaths end up and if there is nothing at this point, the if ... is
misleading.
> There's no "One True Way".
It is possible to argue about objective properties of the various
alternatives and to form a reasoned opinion based on that.
------------------------------
Date: Tue, 16 Apr 2013 12:07:58 +0000 (UTC)
From: tony@mountifield.org (Tony Mountifield)
Subject: Re: More idiomatic
Message-Id: <kkjeuu$e04$1@softins.clara.co.uk>
In article <516c4f40$0$73617$815e3792@news.qwest.net>,
J. Gleixner <glex_no-spam@qwest-spam-no.invalid> wrote:
> On 04/15/13 13:17, David Harmon wrote:
> > Here is some code I wrote in another newsgroup. It is probably
> > obvious that it was written by an old C hacker. If anybody would
> > like to suggest how it could be better perl or more idiomatic,
> > go ahead.
> >
> >>>>
> >
> > use strict; use warnings;
> > open my $fin, 't1.txt';
>
> Use 3-argument open handle failure (die) if it can't open.
> perldoc -f open
>
> > my $fromline = '';
> > my $useragent = '';
> > my $hascont = 'n';
> > my $crosspost = 0;
> > my %statstab;
>
>
> >
> > while (<$fin>) {
> > chomp;
> > if (/Newsgroups: .*,/i) {
> > $crosspost = 1;
> > next;
> > }
>
> > if (/^Content-Type:/i) {
> > $hascont = 'y';
> > next;
> > }
>
> Even a C Hacker should have learned about using else...else if...
When appropriate :)
> Use elsif on the rest of these, since it can't start with more than one
> of these.. and avoids the need of 'next;' in every if. If none of these
> could also have 'Newsgroups: ' in it, then all of these, except for the
> first if, should be elsif's.
I disagree. To me, the use of "next;" or, in C, "continue;", is an explicit
and succinct way of saying "At this point, I'm done with this iteration".
It unambiguously tells the reader of the code that for this particular
case, there is nothing happening further down within the loop.
I find that MUCH clearer than having to read down through a long chain
of if/elseif statements.
Similarly for break and early return.
Cheers
Tony
--
Tony Mountifield
Work: tony@softins.co.uk - http://www.softins.co.uk
Play: tony@mountifield.org - http://tony.mountifield.org
------------------------------
Date: Tue, 16 Apr 2013 19:05:10 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: More idiomatic
Message-Id: <mfg04a-p4t.ln1@anubis.morrow.me.uk>
Quoth "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>:
> On 04/15/13 14:55, David Harmon wrote:
> > On Mon, 15 Apr 2013 14:04:32 -0500 in comp.lang.perl.misc, "J.
> > Gleixner"<glex_no-spam@qwest-spam-no.invalid> wrote,
> >>
> >> close( $fin );
> >
> > Does that matter?
>
> Again, it's idiomatic.. For ever open, there should be a close.
No, it's not. It's usual to omit the close for autoclosing lexical
filehandles which were opened read-only, because it doesn't tell you
anything.
Handles opened for writing should be explicitly closed, but there is no
point doing so unless you check the close succeeded.
> That's common in most languages. Or 'use autodie;'.
Unfortunately autodie does not catch errors from the implicit close, so
even with autodie a writing filehandle needs to be explicitly closed.
Ben
------------------------------
Date: Tue, 16 Apr 2013 15:19:20 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: More idiomatic
Message-Id: <lnvc7mgluf.fsf@nuthaus.mib.org>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth "Newsgroup only please, address is no longer replyable."
> <bad@example.invalid>:
[...]
>> Concur. But please, can I write it
>> if (eq '') {
>> if not, why not?
>
> No, you can't. As for why not: well, you just can't :). Some operators
> have optional arguments that default to $_, some do not; none of the
> binary operators are in the set that do, because that would be really
> confusing. (I'm not even sure they would parse unambiguously in the
> general case.)
For example, (+ 1) and (- 1) already have unambiguous meanings, so they
can't be made equivalent to ($_ + 1) and ($_ - 1), respectively --
unless $_ happens to be zero 8-)}.
Requiring two explicit operands for all binary operators is simpler and
less confusing than permitting an implicit $_ only for the cases where
it wouldn't be ambiguous.
(And it's not that hard to type $_.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Tue, 16 Apr 2013 17:55:56 -0700
From: David Harmon <source@netcom.com>
Subject: Re: More idiomatic
Message-Id: <XOSdnWXS78HPbvDMnZ2dnUVZ_g2dnZ2d@earthlink.com>
On Tue, 16 Apr 2013 03:03:33 +0100 in comp.lang.perl.misc, Ben
Morrow <ben@morrow.me.uk> wrote,
>With properly-structured data you need to work a little harder to get it
>out, unfortunately:
>
> for my $from (sort keys %statstab) {
> my $uas = $statstab{$from};
> for my $ua (sort keys %$ua) {
I don't understand that line. %$ua is what at that point?
> my $ctypes = $$uas{$ua};
> for my $ctype (sort keys %$ctypes) {
> my $count = $$ctypes{$ctype}
> or next;
> printf "%s %-24s %3d %s\n",
> ($ctype ? "y" : "n"), $ua, $count, $from;
> }
> }
> }
That's really a lot of work and complexity and cryptic variable
names. I don't see the corresponding benefit. And it still needs
next unless $count > 1;
------------------------------
Date: Wed, 17 Apr 2013 04:30:50 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: More idiomatic
Message-Id: <akh14a-kaa1.ln1@anubis.morrow.me.uk>
Quoth "Newsgroup only please, address is no longer replyable." <bad@example.invalid>:
> On Tue, 16 Apr 2013 03:03:33 +0100 in comp.lang.perl.misc, Ben
> Morrow <ben@morrow.me.uk> wrote,
> >With properly-structured data you need to work a little harder to get it
> >out, unfortunately:
> >
> > for my $from (sort keys %statstab) {
> > my $uas = $statstab{$from};
> > for my $ua (sort keys %$ua) {
>
> I don't understand that line. %$ua is what at that point?
A typo. The line should read
for my $ua (sort keys %$uas) {
that is, we're iterating over the keys of the second-level hash we've
just got a reference to. Sorry about that.
>
> > my $ctypes = $$uas{$ua};
> > for my $ctype (sort keys %$ctypes) {
> > my $count = $$ctypes{$ctype}
> > or next;
> > printf "%s %-24s %3d %s\n",
> > ($ctype ? "y" : "n"), $ua, $count, $from;
> > }
> > }
> > }
>
> That's really a lot of work and complexity and cryptic variable
> names. I don't see the corresponding benefit. And it still needs
> next unless $count > 1;
Yeah, I don't like it much, which is why I was looking for a cleaner
alternative. The core problem here is that Perl (unlike some other
languages) doesn't support hashes over arbitrary data structures, only
over strings. Possibly you were right that the 'smash it all into a
string and try to pick the pieces out again afterwards' approach is best
here, but I can't help feeling there must be a cleaner alternative.
Of course, one answer is to knock up a tied-hash implementation based on
Storable, but that's probably overkill...
Ben
------------------------------
Date: Tue, 16 Apr 2013 21:32:33 -0700
From: David Harmon <source@netcom.com>
Subject: Re: More idiomatic
Message-Id: <Y_KdnbczIJK7u_PMnZ2dnUVZ_sqdnZ2d@earthlink.com>
On Wed, 17 Apr 2013 04:30:50 +0100 in comp.lang.perl.misc, Ben
Morrow <ben@morrow.me.uk> wrote,
>over strings. Possibly you were right that the 'smash it all into a
>string and try to pick the pieces out again afterwards' approach is best
>here, but I can't help feeling there must be a cleaner alternative.
Perhaps instead of smashing them together with '##' I should use
"\n" which provably cannot occur in the component strings.
------------------------------
Date: Tue, 16 Apr 2013 22:16:17 -0700
From: David Harmon <source@netcom.com>
Subject: Re: More idiomatic
Message-Id: <k6ednWprk4rErfPMnZ2dnUVZ_oSdnZ2d@earthlink.com>
On Mon, 15 Apr 2013 19:50:50 +0000 (UTC) in comp.lang.perl.misc,
tmcd@panix.com (Tim McDaniel) wrote,
>In article <bfmdneSZqe8Y2fHMnZ2dnUVZ_vWdnZ2d@earthlink.com>,
>David Harmon <bad@example.invalid> wrote:
>
>> if (/Newsgroups: .*,/i) {
>
>Missing caret.
I found where it went to,
$useragent =~ s/^.*:\s*//;
------------------------------
Date: Wed, 17 Apr 2013 07:37:29 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: More idiomatic
Message-Id: <9is14a-ioc1.ln1@anubis.morrow.me.uk>
Quoth "Newsgroup only please, address is no longer replyable." <bad@example.invalid>:
> On Wed, 17 Apr 2013 04:30:50 +0100 in comp.lang.perl.misc, Ben
> Morrow <ben@morrow.me.uk> wrote,
> >over strings. Possibly you were right that the 'smash it all into a
> >string and try to pick the pieces out again afterwards' approach is best
> >here, but I can't help feeling there must be a cleaner alternative.
>
> Perhaps instead of smashing them together with '##' I should use
> "\n" which provably cannot occur in the component strings.
Thinking along those lines is certainly the right thing to do when
formatting-and-reparsing is the only option. You have to watch out for
changes which invalidate your assumptions, though: what about when you
modify it to handle RFC822 header folding, for instance?
I think the strategy I might go for here would be to concatenate the
pieces to get a unique key, but not try to pull them out again
afterwards. Instead put the individual pieces in a structure, like
my $key = "$from\n$whatever_it_was";
$statstab{$key} ||= {
from => $from,
...
};
$statstab{$key}{count}++;
so you can then iterate over 'values %statstab' and get at the fields
you want without parsing the key.
Ben
------------------------------
Date: Wed, 17 Apr 2013 07:54:31 -0700
From: David Harmon <source@netcom.com>
Subject: Re: More idiomatic
Message-Id: <0oCdnRteOodLKvPMnZ2dnUVZ_hGdnZ2d@earthlink.com>
On Wed, 17 Apr 2013 07:37:29 +0100 in comp.lang.perl.misc, Ben
Morrow <ben@morrow.me.uk> wrote,
>I think the strategy I might go for here would be to concatenate the
>pieces to get a unique key, but not try to pull them out again
>afterwards. Instead put the individual pieces in a structure,
Yes, I think that is a good answer.
------------------------------
Date: Tue, 16 Apr 2013 19:32:56 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: musings about 'idiomatic' (was: More idiomatic)
Message-Id: <87wqs2jpgn.fsf_-_@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid> writes:
>> On 04/15/13 14:55, David Harmon wrote:
>>> On Mon, 15 Apr 2013 14:04:32 -0500 in comp.lang.perl.misc, "J.
>>> Gleixner"<glex_no-spam@qwest-spam-no.invalid> wrote,
>
> [...]
>
>>>>> }
>>>> close( $fin );
>>>
>>> Does that matter?
>>
>> Again, it's idiomatic..
>
> According to
>
> http://oald8.oxfordlearnersdictionaries.com/dictionary/idiomatic
>
> 'idiomatic' means
>
> containing expressions that are natural to a native speaker of
> a language
>
> It is somewhat unclear what this is supposed to mean in the context of
> a programming language
The definition above could be paraphrased as 'using the language to
express a circumstance in a specific way which is familiar to people
with the same cultural background regarding language use as the
speaker but which can't be inferred from the rules of the language
itself'. The term also has a positive connotation. For instance "it
fell through the cracks" would be an idiom in English but - despite
the fact that listening to some 'native speakers' can leave one with
the impression that English contains only one articulated word,
namely, 'fuck', and a small set of auxiliary grunts supposed to mark
the topic of the conversation relative to 'fuck', provided it is
differentiated enough that such an intellectual endeavour makes any
sense - the conventional barrage of fucks and grunts one can easily
encounter in an English pub wouldn't be considered 'idiomatic use of
English'. In line with this observation, the so-called 'Schwartzian
transform' could be considered 'a Perl idiom', as could the be
use warnings;
use strict;
at the beginnig of every file but neither the mechanic insertion of
useless statements (like close($fin)) nor shunning all control flow
controlling constructs in favor of if - elsif - else ... would
qualify. The former suggest that the author's main cultural background
is actually something other than Perl, eg, Java, where the runtime
can't manage anything except memory automatically and the latter is
similar to the colloquial use of 'fuck' as universal adjective and
near-universal verb in some form of 'good enough for me'
English. There's even a term for 'restricted language subsets' of this
kind, although it is not usually used for native speakers, namely,
'pidgin English' or 'pidgin Perl' for the if ... case. Especially
considering that this construct isn't specific to Perl at all but of
similar universality in 'pidgin C' and - presumably - almost all other
languages with support for structured programming.
------------------------------
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 3927
***************************************
