Parsing text to array

[Philipp]

Hello
I would like to parse a piece of text to an array. Is there one of those
Perl-magical ways to do this? Or should I use split and iterate through
the lines?

Thank you for your answers
Phil


$content = "hello world\nthis should be parsed";

# do something here to parse words to columns
# and lines to lines of array

print $contentarray[0][0]; #should print "hello"
print $contentarray[1][2]; #should print "be"

 

[anno4000]

Hello
I would like to parse a piece of text to an array. Is there one of those
Perl-magical ways to do this? Or should I use split and iterate through
the lines?

Thank you for your answers
Phil


$content = "hello world\nthis should be parsed";

# do something here to parse words to columns
# and lines to lines of array

print $contentarray[0][0]; #should print "hello"
print $contentarray[1][2]; #should print "be"

my @contentarray = map [ split], split /\n/, $content;

What have you tried?

Anno

 

[usenet]

I would like to parse a piece of text to an array. Is there one of those
Perl-magical ways to do this?

I don't know about 'magical,' but of course it can be easily done in
Perl. It is, after all, a parsing language.

Or should I use split and iterate through

That would be the worst approach.

Anything else you wish to ask about?

 

[Philipp]

Hello
I would like to parse a piece of text to an array. Is there one of those
Perl-magical ways to do this? Or should I use split and iterate through
the lines?

Thank you for your answers
Phil


$content = "hello world\nthis should be parsed";

# do something here to parse words to columns
# and lines to lines of array

print $contentarray[0][0]; #should print "hello"
print $contentarray[1][2]; #should print "be"

my @contentarray = map [ split], split /\n/, $content;

What have you tried?

Hello and thanks for your answer.
I didn't know "map". Does exactly what I want...

I would have done a "for" loop on the lines, but I thought that some
smarter perl way existed (and was obviously right).
Thanks again
Phil

 

[Ala Qumsieh]

That would be the worst approach.

The worst in what sense? And compared to what?
It seems to me to be much easier to comprehend by someone else reading
the code, as compared with Anno's map() solution.

--Ala

 

[Ben Morrow]

The worst in what sense? And compared to what?
It seems to me to be much easier to comprehend by someone else reading
the code,

....who doesn't know Perl at all. If you're going to code for people like
that you might as well give up.

as compared with Anno's map() solution.

Which is entirely standard Perl. Not understanding map is nearly as bad
as not understanding hashes: it is a fundamental part of Perl.

Ben

 

[Ala Qumsieh]

...who doesn't know Perl at all. If you're going to code for people like
that you might as well give up.

Theoretically, I agree. Unfortunately, that is not the case. Most people
who learn Perl don't care about learning it inside out like you do, and
this is well evident from all the posts in this newsgroup. They just
want to scratch an itch and move on. I personally work with a lot of
people that fall into this category, and sometimes resort to more
verbose coding to aid comprehension (if I can't then I make sure to
document it properly).

Which is entirely standard Perl. Not understanding map is nearly as bad
as not understanding hashes: it is a fundamental part of Perl.

The OP admitted he didn't know about map(). You don't need to know about
map() to code Perl, and people on this newsgroup need to accept that.

--Ala

 

[Ted Zlatanov]

Which is entirely standard Perl. Not understanding map is nearly as bad
as not understanding hashes: it is a fundamental part of Perl.

I disagree. You can write very good Perl code without using map(),
for very complicated programs and modules. It's next to impossible to
write good Perl code without hashes (except in very limited situations
or short programs). I would say grep() is much more important than
map() actually, and for grep() the above statement holds true.

Ted

 

[Paul Lalli]

I disagree. You can write very good Perl code without using map(),
for very complicated programs and modules. It's next to impossible to
write good Perl code without hashes (except in very limited situations
or short programs). I would say grep() is much more important than
map() actually, and for grep() the above statement holds true.

map can be written using a for loop and a push
grep can be written using a for loop, an if statement, and a push

I do not believe either is more complicated, important, or fundamental
than the other.

Paul Lalli

 

[Ted Zlatanov]

On 14 Aug 2006, (e-mail address removed) wrote:

Ted Zlatanov wrote: > On 11 Aug 2006, (e-mail address removed) wrote: >

map can be written using a for loop and a push
grep can be written using a for loop, an if statement, and a push

We're not arguing about basics. I also didn't mention the speed
penalty of map()/grep(), assuming everyone knows about it, or the
decrease in legibility the use of map() incurs quite often.

I do not believe either is more complicated, important, or fundamental
than the other.

OK.

Ted

 

[anno4000]

map can be written using a for loop and a push
grep can be written using a for loop, an if statement, and a push

I do not believe either is more complicated, important, or fundamental
than the other.

I also think that deciding which of map() and grep() is more fundamental
is besides the point. They are builtins that make new lists of given
lists. sort() is a third one, and splice() could also be mentioned.
Other list-transformers, though not named functions, are hash-, array-
and list slices. Their common message is that arrays and/or lists can
be treated as the unit of computation instead of the scalars that make
them up.

Where applicable this simplifies the thought process and along with it
the program. The simplification is fundamental and usually results in
tight code, meaning a lot of stuff happens in just a few lines.

It also means that if you have understood a few lines, you have understood
a lot about the program. Tight code, in this sense, *will* take a few
extra reading skills and may still take more time to read than that many
lines of more pedestrian broader code. Some of the required techniques,
like reading parts of the code back-to-front, are admittedly awkward.

This is offset by the fundamental simplification that comes with working
with aggregates as units. Since the unit of computation is more complex
(hiding details), the thought process is simplified.

That is why I think this programming style is *good* style in the
sense of making it easier to understand the program. Where applicable.

Anno

 

[Ted Zlatanov]

I also think that deciding which of map() and grep() is more fundamental
is besides the point. They are builtins that make new lists of given
lists. sort() is a third one, and splice() could also be mentioned.
Other list-transformers, though not named functions, are hash-, array-
and list slices. Their common message is that arrays and/or lists can
be treated as the unit of computation instead of the scalars that make
them up.

Where applicable this simplifies the thought process and along with it
the program. The simplification is fundamental and usually results in
tight code, meaning a lot of stuff happens in just a few lines.

It also means that if you have understood a few lines, you have understood
a lot about the program. Tight code, in this sense, *will* take a few
extra reading skills and may still take more time to read than that many
lines of more pedestrian broader code. Some of the required techniques,
like reading parts of the code back-to-front, are admittedly awkward.

This is offset by the fundamental simplification that comes with working
with aggregates as units. Since the unit of computation is more complex
(hiding details), the thought process is simplified.

That is why I think this programming style is *good* style in the
sense of making it easier to understand the program. Where applicable.

Those are excellent points, Anno. In my experience map() and grep()
are very difficult for beginners, but that in no way takes away from
their general utility and beauty. In fact a while ago I wrote a
beginner-oriented article on functional programming in Perl ("it's
just as good if we fake it"):
http://www-128.ibm.com/developerworks/opensource/library/l-road4.html
which tries to explain FP gently (working up to the Schwartzian and
Guttman-Rosler transforms). Whether map() and grep() are fundamental
is, I think, a matter of personal opinion, but we can all agree they
are not easy to master.

Sadly, my second example in the article uses map() for the side
effect. The shame!

Anyhow, I'm just saying that I do agree with you, but think it's good
to either comment well or consider a simpler approach when you're
putting together FP and a beginner

Ted

 

[anno4000]

On 14 Aug 2006, (e-mail address removed)-berlin.de wrote:
[snip]

Those are excellent points, Anno. In my experience map() and grep()
are very difficult for beginners, ...
[...]

Sadly, my second example in the article uses map() for the side
effect. The shame!

You are in very good company there. Abigail will defend everyone's
right to use map() in void context. Also, AFAIK Tassilo's patch
is in place, which suppresses the building of a list in scalar and
void context.

Anyhow, I'm just saying that I do agree with you, but think it's good
to either comment well or consider a simpler approach when you're
putting together FP and a beginner

There have been courses for beginning programmers taught in Lisp,
so it can't be impossible. (I have no idea how successful these
courses were.)

Anyway, on clpm I don't necessarily post with an audience of beginners
in mind. Even if a majority of potential readers are beginners, the
highly significant minority of regulars (including regular lurkers)
are not. Clpm gives me the echo (or lack thereof) of programmers whose
skill I know. Selfishly, I want it to my original solution, not some
toned-down version in usum infanti.

I also value the comments by beginners to advanced code. The best
are, of course, of the "Please explain" nature. No, wrong, the best
ones would be "Oh, that's how it's done", but then people understandably
often move on without posting. "Please explain" means someone wants
to learn, which is good. Often I find someone else has given an
excellent explanation when I come back, which is also good Even
bad-tempered or hostile replies show me I have overstepped someone's
limit, not that I necessarily care.

So I think that posting advanced code serves a useful purpose in the
group, even if it is over the head of parts of the audience. As they
say, there's always the "n" key...

Anno