[32171] in Perl-Users-Digest
Perl-Users Digest, Issue: 3436 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jul 7 18:09:27 2011
Date: Thu, 7 Jul 2011 15:09:10 -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 Thu, 7 Jul 2011 Volume: 11 Number: 3436
Today's topics:
return value of do{ given(){} } <w.c.humann@arcor.de>
Re: return value of do{ given(){} } <uri@StemSystems.com>
Re: return value of do{ given(){} } <brian.d.foy@gmail.com>
Re: return value of do{ given(){} } <brian.d.foy@gmail.com>
Re: sort scientific notation value after alphabet <rweikusat@mssgmbh.com>
Re: sort scientific notation value after alphabet <jurgenex@hotmail.com>
Re: sort scientific notation value after alphabet <cartercc@gmail.com>
Re: sort scientific notation value after alphabet <uri@StemSystems.com>
Re: sort scientific notation value after alphabet <cartercc@gmail.com>
Re: sort scientific notation value after alphabet <uri@StemSystems.com>
Re: sort scientific notation value after alphabet <cartercc@gmail.com>
Re: sort scientific notation value after alphabet <uri@StemSystems.com>
Re: sort scientific notation value after alphabet <cartercc@gmail.com>
Re: sort scientific notation value after alphabet <uri@StemSystems.com>
Re: sort scientific notation value after alphabet <jurgenex@hotmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 7 Jul 2011 09:58:16 -0700 (PDT)
From: Wolfram Humann <w.c.humann@arcor.de>
Subject: return value of do{ given(){} }
Message-Id: <07231aff-5eab-4172-bd07-e5658cb7acd6@u42g2000yqm.googlegroups.com>
I expected this
perl -E'say do{ given(3){ when(2){'two';continue} when(3)
{'three';continue} default{'foo'} } }'
to print 'three' for being the last thing executed inside do{}.
However, it prints nothing. Can someone tell me why?
------------------------------
Date: Thu, 07 Jul 2011 13:38:02 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: return value of do{ given(){} }
Message-Id: <87ipreat51.fsf@quad.sysarch.com>
>>>>> "WH" == Wolfram Humann <w.c.humann@arcor.de> writes:
WH> I expected this
WH> perl -E'say do{ given(3){ when(2){'two';continue} when(3)
WH> {'three';continue} default{'foo'} } }'
WH> to print 'three' for being the last thing executed inside do{}.
WH> However, it prints nothing. Can someone tell me why?
i just read the docs on given and nowhere did i see a mention of a
return value. it is a flow control structure and those generally don't
return values. the if/else construct doesn't return a value but in a sub
the last evaluated expression is returned by default (i teach to always
use explicit returns for several reasons). that will likely work with
given as well but as i said, implicit return values are poor coding.
uri
--
Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
------------ Perl Developer Recruiting and Placement Services -------------
----- Perl Code Review, Architecture, Development, Training, Support -------
------------------------------
Date: Thu, 07 Jul 2011 16:12:31 -0500
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: return value of do{ given(){} }
Message-Id: <070720111612318158%brian.d.foy@gmail.com>
In article <87ipreat51.fsf@quad.sysarch.com>, Uri Guttman
<uri@StemSystems.com> wrote:
> i just read the docs on given and nowhere did i see a mention of a
> return value.
Read the docs for the *latest* version of Perl.
------------------------------
Date: Thu, 07 Jul 2011 16:16:47 -0500
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: return value of do{ given(){} }
Message-Id: <070720111616473545%brian.d.foy@gmail.com>
In article
<07231aff-5eab-4172-bd07-e5658cb7acd6@u42g2000yqm.googlegroups.com>,
Wolfram Humann <w.c.humann@arcor.de> wrote:
This also breaks for me:
> perl -E'say do{ given(3){ when(2){'two';continue} when(3)
> {'three';continue} default{'foo'} } }'
This works fine for me in a file. I suspect that all of those single
quotes confuse the shell. Indeed, this works when I change to q()
instead of single quotes:
$ perl5.14.1 -E'say do{ given(3){ when(2){q(two);continue} when(3)
{q(three);continue} default{q(foo)} } }'
foo
------------------------------
Date: Thu, 07 Jul 2011 16:16:36 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: sort scientific notation value after alphabet
Message-Id: <87sjqice97.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Jim Gibson <jimsgibson@gmail.com> writes:
>> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
[...]
>>> A slightly modified statement, 'it is only misleading to people who
>>> "subscribe to the belief" that a text whose content isn't already
>>> known to them in sufficient detail to actually judge that likely has
>>> a meaning', IOW, to people who have learnt to read, makes some logical
>>> sense (although not more practical sense than "I wasn't effectively
>>> blocking the emergency exit since no emergency occured[*]".
>>
>> I don't see the analogy.
>
> That's because there is no analogy.
Slight correction: There is an analogy but it just refers back to
initial statement, not to the context of this statement. Consequently,
it is a tangential matter.
------------------------------
Date: Thu, 07 Jul 2011 08:21:58 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: sort scientific notation value after alphabet
Message-Id: <b4ib17psieii51fn18gq6sthg8e169vftq@4ax.com>
Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>ccc31807 <cartercc@gmail.com> writes:
>> On Jul 6, 8:14 pm, Jim Gibson <jimsgib...@gmail.com> wrote:
>>> Personally, I would rather see this:
>>>
>>> my( $first, $last, $address, $city, $state, $zip, $email ) =
>>> split(' ',$record);
>>>
>>> than this:
>>>
>>> my( $first, $last, undef. undef, undef, undef, $email ) =
>>> split(' ',$record);
>>
>> And who would want to see this?
Me! I prefer very much to know that the programmer was actually thinking
when he wrote this code and that he determined that only the first
element, the last element, and the email element are relevant and that
whatever those other 4 elements are of no importance for this algorithm,
and therefore I don't have to bother with them.
If for whatever reason I want to document what those omitted elements
are (maybe it took a long time to figure out what some other function
returned or something like that), then a proper comment with the full
set of record elements is always welcome.
>> my @line = split(' ', $_);
>> # then, later on, you have this
>> if ($line[98] =~ /G\d\d/) { ... )
>> elsif ($line[98] =~ /H\d\d/) { ... }
>> elsif ($line[54] !~ /\d{7}/) { ... }
>> else { print "Error for $line[54], $line[98], ID: $line[3]\n"; }
>>
>> And yes, I have written such code, and still have some left that I
>> have to maintain. It's truly a nightmare.
You reap what you sow. I am just glad that it's not me who has to
maintain that code.
>> My strategy to maintaining
>> this sort of stuff is to name every field from the outset.
Why? Why would you possibly want to invent 98 names if -in your example
above- you are using only 3 elements?
>>Then, I
>> never have to think about whether I have named the variable or what
>> the name is
If I had determined that only those three elements are relevant for my
algorithm, then I would name exactly those three, in this case with an
array slice (almost 100 'undef' look just as silly as almost 100
variables that are never used).
Or if you don't like array slices or don't know how to use them then use
individual assignments:
my @line = split(' ', $_);
my $thisvalue = $line[98];
my $someMeaningfullName = $line[54];
my $someOtherMeaningfullName = $line[3];
This is still orders of magnitude better than assigning almost 100
variables, out of which 97% are never used again.
Actually, doesn't perl even generate a warning "Variable used only once"
or something like that if a variable is never accessed again?
jue
------------------------------
Date: Thu, 7 Jul 2011 09:17:17 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: sort scientific notation value after alphabet
Message-Id: <3e165969-dc96-48bb-b7d3-ae2785f81164@e21g2000vbz.googlegroups.com>
On Jul 7, 11:21=A0am, J=FCrgen Exner <jurge...@hotmail.com> wrote:
> >> And yes, I have written such code, and still have some left that I
> >> have to maintain. It's truly a nightmare.
>
> You reap what you sow. I am just glad that it's not me who has to
> maintain that code.
And I'm doing my damnest to rewrite this kind of code whenever I have
the opportunity.
> >> My strategy to maintaining
> >> this sort of stuff is to name every field from the outset.
>
> Why? Why would you possibly want to invent 98 names if -in your example
> above- you are using only 3 elements?
Good question. Here's a good answer: Let's say you have to munge a
datafile that's 103 columns wide, each column with a unique identifier
in a header row, and your target fields are scattered at random across
the file's width. You MUST identify your target fields -- you have to
do that anyway, regardless of whatever else you do. But, having
identified your target fields by name, you can automate the munging of
the files easily by creating an array of the header, and assigning
each record in turn to the named variables, and stuff the named
variables in a hash element without seeing them or thinking about
them.
My point is this: programmer time is much more valuable than CPU time
or memory space. If I can save an hour of time at the cost of perhaps
a couple of milliseconds of run time and maybe a few megabytes of run
space, it's a deal I'll take in a heartbeat.
To answer Uri's point about a maintainer puzzling over whether named
variables are used, or not used, THE VARIABLES ARE NEVER SEEN!!! Yes,
in the example I gave earlier I named the variables, but in a real
application, you never explicitly name the variables. All you have is
an array (named @header, perhaps) which you used as the key in an
array slice.
> If I had determined that only those three elements are relevant for my
> algorithm, then I would name exactly those three, in this case with an
> array slice (almost 100 'undef' look just as silly as almost 100
> variables that are never used).
In reality, if you are munging a data file, then you would want to
manipulate the data items, and if your requirements are ambiguous or
unknown, you want to have the ability to access particular datums.
Using the technique described above, all the datums are available,
without an atom's worth of additional work.
In a simple case, let's say you are printing a report for each record
and a summary, and your user says, "I want these two items reversed,
and a third item added." Since you already have ALL the data in named
slots, it's easy and quick. I'd hate to take Uri's advice, which would
entail going back to the beginning, undefing a variable non-
assignment, and making all the other changes necessary.
There's no right or wrong way to do in. You use particular techniques
for particular jobs. I've learned the hard way, and while I agree with
Uri's rationale, it's not a universal solution to every problem,
> Or if you don't like array slices or don't know how to use them then use
> individual assignments:
> =A0 =A0 =A0 =A0 my @line =3D split(' ', $_);
> =A0 =A0 =A0 =A0 my $thisvalue =3D $line[98];
> =A0 =A0 =A0 =A0 my $someMeaningfullName =3D $line[54];
> =A0 =A0 =A0 =A0 my $someOtherMeaningfullName =3D $line[3];
>
> This is still orders of magnitude better than assigning almost 100
> variables, out of which 97% are never used again.
Again:
my %records;
open IN ...;
#assign the first row to an array
my @header =3D <IN>;
while (<IN>)
{
#assign each record to it's own array
@record =3D $_;
#assume that the first field is the unique key
$records{$record[0]}{@header} =3D @record;
}
At this point, %records contains all records having a key which
consists of the record key, and a value which consists of a reference
to an anonymous hash (I think) of keys named after the header columns
and values consisting of the record values corresponding to the field
name.
If you look at this code, you only have TWO variables declared that
live on after the while loop, @header and %records, and any Perl
programmer worth his salt shouldn't have any trouble understanding
what's going on.
CC.
------------------------------
Date: Thu, 07 Jul 2011 12:41:51 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: sort scientific notation value after alphabet
Message-Id: <8739iicab4.fsf@quad.sysarch.com>
>>>>> "c" == ccc31807 <cartercc@gmail.com> writes:
c> my %records;
c> open IN ...;
c> #assign the first row to an array
c> my @header = <IN>;
c> while (<IN>)
c> {
c> #assign each record to it's own array
c> @record = $_;
c> #assume that the first field is the unique key
c> $records{$record[0]}{@header} = @record;
c> }
c> At this point, %records contains all records having a key which
c> consists of the record key, and a value which consists of a reference
c> to an anonymous hash (I think) of keys named after the header columns
c> and values consisting of the record values corresponding to the field
c> name.
that is a classic flat file record to hash conversion. you read the csv
(assuming that for now) header line and you can automatically get the
names for the hash keys. it is fine and dandy coding. it is NOT the
same as assigning all the values to individually named
scalars. comparing those is apples and oranges. my point was only about
declaring variables you never use again. if you did the hash records, i
wouldn't have any problem and i have done this myself many times. in
some cases you don't even have a header line so i would write an array
of those names with qw.
uri
--
Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
------------ Perl Developer Recruiting and Placement Services -------------
----- Perl Code Review, Architecture, Development, Training, Support -------
------------------------------
Date: Thu, 7 Jul 2011 10:34:56 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: sort scientific notation value after alphabet
Message-Id: <50244986-b4b3-4708-b334-bdd629fcf829@ct4g2000vbb.googlegroups.com>
On Jul 7, 12:41=A0pm, "Uri Guttman" <u...@StemSystems.com> wrote:
> that is a classic flat file record to hash conversion. =A0you read the cs=
v
> (assuming that for now) header line and you can automatically get the
> names for the hash keys. it is fine and dandy coding. it is NOT the
> same as assigning all the values to individually named
> scalars.
This is a distinction without a difference.
Assuming that @fields contains the following:
("firstname","lastname","address","city","state","zip")
there is no difference between:
@records{@fields} =3D @record;
and
@records{"firstname","lastname","address","city","state","zip"} =3D
@record.
As to your point about declaring variables that you never use again,
this strikes me as simply a matter of personal style. I would agree
that one should be promiscuous in creating needless variables. I would
also go a little further and say that if you are dealing with a glob
of data it's cheap and easy to specifically identify every datum,
ESPECIALLY when your requirements are unclear, liable to sudden
change, or even unknown. In my case, I usually have to deal with
ambiguous or unknown requirements -- and in fact have already dealt
with two such cases this morning. Unknown requirements don't prevent
you from writing code, but they strongly hint that the code that you
do write be flexible and adaptable.
CC.
------------------------------
Date: Thu, 07 Jul 2011 13:41:22 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: sort scientific notation value after alphabet
Message-Id: <87d3hmaszh.fsf@quad.sysarch.com>
>>>>> "c" == ccc31807 <cartercc@gmail.com> writes:
c> On Jul 7, 12:41 pm, "Uri Guttman" <u...@StemSystems.com> wrote:
>> that is a classic flat file record to hash conversion. you read the csv
>> (assuming that for now) header line and you can automatically get the
>> names for the hash keys. it is fine and dandy coding. it is NOT the
>> same as assigning all the values to individually named
>> scalars.
c> This is a distinction without a difference.
huh??
c> Assuming that @fields contains the following:
c> ("firstname","lastname","address","city","state","zip")
c> there is no difference between:
c> @records{@fields} = @record;
c> and
c> @records{"firstname","lastname","address","city","state","zip"} =
c> @record.
huh?? that is not the issue. there are no scalars in that code. the list
of keys could be in an array or literal and there are still no scalar
variables there. keep to the main point here. it is about declaring
a list with unused variables holding the values from a split.
c> As to your point about declaring variables that you never use again,
c> this strikes me as simply a matter of personal style. I would agree
c> that one should be promiscuous in creating needless variables. I would
c> also go a little further and say that if you are dealing with a glob
c> of data it's cheap and easy to specifically identify every datum,
c> ESPECIALLY when your requirements are unclear, liable to sudden
c> change, or even unknown. In my case, I usually have to deal with
c> ambiguous or unknown requirements -- and in fact have already dealt
c> with two such cases this morning. Unknown requirements don't prevent
c> you from writing code, but they strongly hint that the code that you
c> do write be flexible and adaptable.
so use the hash record slice design. that is always acceptable and
doesn't pollute the code with variable names.
uri
--
Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
------------ Perl Developer Recruiting and Placement Services -------------
----- Perl Code Review, Architecture, Development, Training, Support -------
------------------------------
Date: Thu, 7 Jul 2011 11:01:08 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: sort scientific notation value after alphabet
Message-Id: <bd771ac8-6352-45e7-bfd0-9cadf4e441b9@w24g2000yqw.googlegroups.com>
On Jul 7, 1:41=A0pm, "Uri Guttman" <u...@StemSystems.com> wrote:
> huh?? that is not the issue. there are no scalars in that code.
A variable is a container for a value. Instead of using string
literals, I used scalar variables. There's no real difference, only a
superficial one.
> =A0 c> As to your point about declaring variables that you never use agai=
n,
> =A0 c> this strikes me as simply a matter of personal style. I would agre=
e
> =A0 c> that one should be promiscuous in creating needless variables.
Left out the little word 'not' after 'should' in the above. My
apology.
> so use the hash record slice design. that is always acceptable and
> doesn't pollute the code with variable names.
Again, when it's cheap and easy to create variables, which may or may
not be used, I do so. Particularly when I have found from experience
that users don't specify requirements until after several iterations
of the code. IOW, if I don't know whether or not I'll use a variable,
it's much less hassle for me to assume the worst and prepare for it
than assume the best and not prepare for it.
I'm NOT disagreeing with you. All I'm saying is that there exceptions
to even the best rules, and that we need to focus on the essence of
the task rather than stick to needless formalisms. 'A foolish
consistency is the hobgoblin of small minds.' This means that we
shouldn't mindlessly apply the same rule to every situation, but allow
each situation to determine which rules we apply. You don't use a
hammer to set screws and you don't use a screwdriver to drive nails.
CC.
------------------------------
Date: Thu, 07 Jul 2011 14:09:43 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: sort scientific notation value after alphabet
Message-Id: <871uy2aro8.fsf@quad.sysarch.com>
>>>>> "c" == ccc31807 <cartercc@gmail.com> writes:
c> On Jul 7, 1:41 pm, "Uri Guttman" <u...@StemSystems.com> wrote:
>> huh?? that is not the issue. there are no scalars in that code.
c> A variable is a container for a value. Instead of using string
c> literals, I used scalar variables. There's no real difference, only a
c> superficial one.
not at all. this is not superficial. keys in a hash are not the same as
variable names from a coding perspective. hash keys are dynamic and
can't be checked at compile time. you can add more at run time. variable
names can at least be checked for spelling with strict. they have
scoping, etc. totally different things and you can't conflate them. sure
there is more than one way to do it but declaring unused variables for
placeholders is not a good thing IMNSHO.
c> Again, when it's cheap and easy to create variables, which may or may
c> not be used, I do so. Particularly when I have found from experience
c> that users don't specify requirements until after several iterations
c> of the code. IOW, if I don't know whether or not I'll use a variable,
c> it's much less hassle for me to assume the worst and prepare for it
c> than assume the best and not prepare for it.
it has nothing to do with cost. it is about style and clearly expressing
what is going on.
c> I'm NOT disagreeing with you. All I'm saying is that there exceptions
c> to even the best rules, and that we need to focus on the essence of
c> the task rather than stick to needless formalisms. 'A foolish
c> consistency is the hobgoblin of small minds.' This means that we
c> shouldn't mindlessly apply the same rule to every situation, but allow
c> each situation to determine which rules we apply. You don't use a
c> hammer to set screws and you don't use a screwdriver to drive nails.
i am not being foolishly consistant. you are just being lazy in
declaring now and maybe using them later. it is a case of attitude
towards the quality of your code. my claim is misleading the reader is a
bad thing. all the other rules here derive from that. you want to make
the reader understand your code with the least possible effort. anything
else and you are not doing your job properly. it is a view of what code
is supposed to be for, not what it does in the computer.
uri
--
Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
------------ Perl Developer Recruiting and Placement Services -------------
----- Perl Code Review, Architecture, Development, Training, Support -------
------------------------------
Date: Thu, 7 Jul 2011 13:26:10 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: sort scientific notation value after alphabet
Message-Id: <ac5b7b95-a8dc-4963-838f-f89c44c39ec0@v10g2000yqn.googlegroups.com>
On Jul 7, 2:09=A0pm, "Uri Guttman" <u...@StemSystems.com> wrote:
> not at all. this is not superficial. keys in a hash are not the same as
> variable names
I was saying that scalar variables and array variables are still
variables, whether you assign a list of string literals to the same
number of scalars, or a list of string literals to an array. My
evidence was use of the variables as keys in a hash.
In point of fact, if you want to get picky, if you are munging a file,
sooner or later you will likely use every datum in the file. The case
of the OP is more of a one off case than business as usual.
> i am not being foolishly consistant. you are just being lazy
Isn't laziness one of the three cardinal virtues of the programmer?
The other two being hubris and impatience? If you charge me with
laziness, I'll plead guilty. With pride!
CC.
------------------------------
Date: Thu, 07 Jul 2011 16:34:33 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: sort scientific notation value after alphabet
Message-Id: <87hb6x96ee.fsf@quad.sysarch.com>
>>>>> "c" == ccc31807 <cartercc@gmail.com> writes:
c> On Jul 7, 2:09 pm, "Uri Guttman" <u...@StemSystems.com> wrote:
>> not at all. this is not superficial. keys in a hash are not the same as
>> variable names
c> I was saying that scalar variables and array variables are still
c> variables, whether you assign a list of string literals to the same
c> number of scalars, or a list of string literals to an array. My
c> evidence was use of the variables as keys in a hash.
you can't call things what you want. array and hash elements are NOT
variables. they are scalar values. a scalar variable is a container
which can hold one value. not the same so don't call them the same.
c> In point of fact, if you want to get picky, if you are munging a file,
c> sooner or later you will likely use every datum in the file. The case
c> of the OP is more of a one off case than business as usual.
>> i am not being foolishly consistant. you are just being lazy
c> Isn't laziness one of the three cardinal virtues of the programmer?
c> The other two being hubris and impatience? If you charge me with
c> laziness, I'll plead guilty. With pride!
there are many flavors to lazy! :)
uri
--
Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
------------ Perl Developer Recruiting and Placement Services -------------
----- Perl Code Review, Architecture, Development, Training, Support -------
------------------------------
Date: Thu, 07 Jul 2011 13:50:58 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: sort scientific notation value after alphabet
Message-Id: <1j6c17lt594q8u4us7pcouvfq387ojeq0j@4ax.com>
"Uri Guttman" <uri@StemSystems.com> wrote:
>>>>>> "c" == ccc31807 <cartercc@gmail.com> writes:
>
> c> On Jul 7, 2:09 pm, "Uri Guttman" <u...@StemSystems.com> wrote:
> >> not at all. this is not superficial. keys in a hash are not the same as
> >> variable names
>
> c> I was saying that scalar variables and array variables are still
> c> variables,
So far I agree 100%
> c> whether you assign a list of string literals to the same
> c> number of scalars, or a list of string literals to an array.
No! In the first case you assign to a set of different variables, in the
second case you assign to a single variable. Two very different things.
> c> My evidence was use of the variables as keys in a hash.
???
This doesn't make much sense. Keys in a hash are scalars or actually
even more restrictive they are strings. You cannot use a variable as a
key.
> c> In point of fact, if you want to get picky, if you are munging a file,
> c> sooner or later you will likely use every datum in the file.
Depends on what you mean by "munging".
Converting the whole file into a different format: then certainly yes.
Extracting and processing data: hardly, no matter for which application
field.
jue
------------------------------
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 3436
***************************************
