Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Can somebody explain?

Reply
Thread Tools

Can somebody explain?

 
 
Vittal
Guest
Posts: n/a
 
      08-10-2004
Hello All,

I am new to Perl and I have been going through some of the perl code.

In one of the file I found the following snippet:

$temp = qr{
\(
(?:
(?>[^()]+ )
|
(??{ $temp })
)*
\)
}x;

$cchat = qr/((\W)?(\*?\*?\w+)\s*($temp))/;

Can somebody explain me what these two lines do?

Thanks
-Vittal
 
Reply With Quote
 
 
 
 
Gunnar Hjalmarsson
Guest
Posts: n/a
 
      08-10-2004
Vittal wrote:
> In one of the file I found the following snippet:
>
> $temp = qr{
> \(
> (?:
> (?>[^()]+ )
> |
> (??{ $temp })
> )*
> \)
> }x;
>
> $cchat = qr/((\W)?(\*?\*?\w+)\s*($temp))/;
>
> Can somebody explain me what these two lines do?


Can't you read the explanation in the file where you found the code?

Just a thought.

Otherwise, the first (and the most complicated) part, is explained in
"perldoc perlre":
http://www.perldoc.com/perl5.8.4/pod...--%7b-code-%7d)

--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
 
Reply With Quote
 
 
 
 
Brian McCauley
Guest
Posts: n/a
 
      08-10-2004


Vittal wrote:
> I am new to Perl and I have been going through some of the perl code.
>
> In one of the file I found the following snippet:
>
> $temp = qr{
> \(
> (?:
> (?>[^()]+ )
> |
> (??{ $temp })
> )*
> \)
> }x;


This defines a precompiled regex such that pattern /$temp/ will match a
string starting with a '(' and ending at the _matching_ ')'. (i.e.
there can be any number of nested (...) in between).

To understand why you'd have to understand the (??{...}) (?:...) and
(?>...) regex constructs these are explained better in 'perlre' than I
could do. So look there.

The qr// operator is used to define precompiled regex and is documented
in perlop. (Note as with any quoute-like operator in Perl the so called
qr// operator can use alternate delimiters so can also be qr{}).

The /x regex qualifier on the end of the qr// makes unqouted whitespace
inside the regex non-significant so allows the regex to be laid out more
readably.


> $cchat = qr/((\W)?(\*?\*?\w+)\s*($temp))/;


This defines another pre-complied regex that matches something followed
by a ballenced (...).

The "something" is rather odd but there's no point trying to explain it.
All I'd be doing it telling you what each of the constructs mean.
Much better to just look up the constructs used in perlre. If there's
something you don't understand then come back and say what it is that
you don't understand.

 
Reply With Quote
 
Jeff 'japhy' Pinyan
Guest
Posts: n/a
 
      08-10-2004
On Tue, 10 Aug 2004, Brian McCauley wrote:

>> $cchat = qr/((\W)?(\*?\*?\w+)\s*($temp))/;

>
>This defines another pre-complied regex that matches something followed
>by a ballenced (...).
>
>The "something" is rather odd but there's no point trying to explain it.


I'd say it looks like it's matching a C function definition (although
ignoring the return *type* of the function, and only capturing the level
of dereferencing needed). But it does a poor job; it's too specific in
its formulation.

--
Jeff "japhy" Pinyan % How can we ever be the sold short or
RPI Acacia Brother #734 % the cheated, we who for every service
RPI Corporation Secretary % have long ago been overpaid?
http://japhy.perlmonk.org/ %
http://www.perlmonks.org/ % -- Meister Eckhart


 
Reply With Quote
 
J. Romano
Guest
Posts: n/a
 
      08-11-2004
http://www.velocityreviews.com/forums/(E-Mail Removed) (Vittal) wrote in message news:<(E-Mail Removed) om>...
>
> In one of the file I found the following snippet:
>
> $temp = qr{
> \(
> (?:
> (?>[^()]+ )
> |
> (??{ $temp })
> )*
> \)
> }x;
>
> $cchat = qr/((\W)?(\*?\*?\w+)\s*($temp))/;
>
> Can somebody explain me what these two lines do?


Dear Vittal,

The good news is that the programmer who wrote that script did not
create the first line him/herself. He/She just copied it straight
from the "prelre" documentation. To read what it does, type "perldoc
perlre" at a DOS or Unix prompt and search for the word "postponed".
You'll see the exact same piece of code and the explanation that this
regular expression matches a parenthesized group.

In other words, if you can use $temp like this:

if ("I saw a color (blue)." =~ m/$temp/)
{
print $&; # this prints the match "(blue)"
}

It will also work with nested parentheses, like this:

if ("I already ate (I ate one (1) pizza)." =~ m/$temp/)
{
print $&; # this prints "(I ate one (1) pizza)"
}

The bad news is that the programmer who wrote that script didn't feel
the need to add comments to explain the purpose of those regular
expressions. It has been said that it's almost always easier to
create your own regular expressions than to understand one that's
already written, and in this case that's definitely true. If it
wasn't for the fact that the first line was specifically mentioned in
"perldoc perlre", I'm sure that I would not have been able to figure
out what it was looking for.

The second regular expression is a little easier to figure out.
Let's take it a bit at a time:

> $cchat = qr/((\W)?(\*?\*?\w+)\s*($temp))/;


The only parts of the $cchat regular expression that are not optional
are the \w+ part (which matches at least one "word" character (that
is, a letter, digit, or underscore)) and $temp, which matches a
parenthesized expression. Optionally, there may be whitespace (any
amount) between the non-optional parts. Also, there may be one or two
asterisks before the \w+ part. There could also be an optional
non-"word" character before the word characters (which would appear
before the asterisks, if the asterisks happen to exist).

Was my explanation confusing? If you didn't think so, then you're
a super genuis. I didn't expect it to be very easy to follow (like it
is said, it's not very easy to understand a regular expression that
you didn't write), so I always recommend writing a few comments (with
any non-simple regular expression) that shows a few sample matches.
The writer of that program you're reading should have included a few
comments like this:

# The $temp regular expression was taken right out of
# the "perldoc perlre" documentation. It matches a
# parenthesized expression (that may or may not contain
# nested parentheses):
$ temp = ... ;

# The purpose of the $cchat regular expression is ...
# It matches all of the following lines:
# some_text(parenthesized expression)
# some_text (parenthesized expression)
# *some_text(parenthesized expression)
# **some_text (parenthesized expression)
# %*some_text (parenthesized expression)
# ^**some_text(parenthesized expression)
# &some_text (parenthesized expression)
# !some_text(parenthesized expression)
$cchat = qr/((\W)?(\*?\*?\w+)\s*($temp))/;

Because the original programmer didn't explain the purpose of the
$cchat regular expression, it's difficult for us to figure it out for
sure. The closest we can come to figuring it out is to examine sample
matches and deduce the purpose from there.

If you ever add more code to this program, do yourself and the
future maintainers of the program a favor and add comments to document
your regular expressions. Include the purpose of the regular
expression (in plain English or whatever language is the main language
spoken at work) and include a few sample matches (because sometimes
looking at sample matches helps a person understand much better than
looking at the regular expression itself). It also helps the
debugging process a lot.

When you write code, please put comments in your code that explains
to anyone who didn't write the code what the code is doing and its
purpose. A lot of coders avoid doing this, giving many excuses as to
why they shouldn't. Some of the excuses are:

* I don't need to include comments because I write
non-esoteric (simple) code that anyone can understand.

* Comments eventually become outdated (and outdated comments
are wrong) and wrong comments are worse than no comments
at all (because they are misleading).

* I don't need to include comments because I write
"self-documenting" code. Comments are a sign that the
code is impossible to understand without outside help,
and I don't write code like that.

Don't fall into those traps! I may be offending some die-hard
programmers here who adhere to one or more of the above traps I
listed, but I sincerely believe that comments and documentation are
vital to writing programs (especially when writing programs that will
be read by other people) -- even if the comments and documentation
become outdated (outdated comments and documentation may not be
correct in everything they say, but at least they provide important
hints to anyone trying to understand, debug, and maintain the code).

I hope this helps, Vittal.

-- Jean-Luc Romano
 
Reply With Quote
 
Anno Siegel
Guest
Posts: n/a
 
      08-11-2004
J. Romano <(E-Mail Removed)> wrote in comp.lang.perl.misc:
> (E-Mail Removed) (Vittal) wrote in message
> news:<(E-Mail Removed) om>...


[...]

> When you write code, please put comments in your code that explains
> to anyone who didn't write the code what the code is doing and its
> purpose. A lot of coders avoid doing this, giving many excuses as to
> why they shouldn't. Some of the excuses are:
>
> * I don't need to include comments because I write
> non-esoteric (simple) code that anyone can understand.
>
> * Comments eventually become outdated (and outdated comments
> are wrong) and wrong comments are worse than no comments
> at all (because they are misleading).
>
> * I don't need to include comments because I write
> "self-documenting" code. Comments are a sign that the
> code is impossible to understand without outside help,
> and I don't write code like that.
>
> Don't fall into those traps! I may be offending some die-hard
> programmers


I am one of the die-hard programmers who has occasionally offered points
of view that resemble those you misrepresent as "excuses" and "traps".

> here who adhere to one or more of the above traps I
> listed, but I sincerely believe that comments and documentation are
> vital to writing programs (especially when writing programs that will
> be read by other people) -- even if the comments and documentation
> become outdated (outdated comments and documentation may not be
> correct in everything they say, but at least they provide important
> hints to anyone trying to understand, debug, and maintain the code).


What is offensive is not your opposition but your misrepresentation.

Let me first set the scope. We are talking about *comments*, (not
documentation in general, as you chose to drag in), and, specifically,
I'm talking about micro-commenting single statements of code. So-called
block comments (as might precede a sub definition or a group of such)
are another issue altogether. Further, we are talking about comments
in Perl, or a similarly high-level language.

Within that scope, I maintain that comments should be the rare exception,
not the rule.

What you present as a stance of hubris ("I don't write code like that")
is really an exhortation not to write code that needs comments. That may
not be possible in assembler, but in Perl and similar languages it is.
Perl has complex data structures that can be treated as units and all
house-keeping (length of strings, number of elements in an array, keys
of a hash, etc.) is taken care of.

That allows a programmer to work in units that are meaningful in terms
of the overall process and not fiddle with stuff below that level. Usually,
what you do on the process level is obvious. If you feel the need to
explain some code, that is usually a sign that you haven't found the
right data structure and/or algorithm yet. So don't paste it over
with an explanatory comment, rewrite it so that it doesn't need one.

Anno
 
Reply With Quote
 
Vittal
Guest
Posts: n/a
 
      08-12-2004
Hello Jean,

Thank you very much for replying in deatil.

Yes, the person who has written the code has not give much comments
other than saying "matches the parenthesis".

I tried to break the two statements in samller chunks but could not.
These two statements took my night sleep away

Now I have got little understanding about these lines.

Thanks again!
-Vittal
(E-Mail Removed) (J. Romano) wrote in message news:<(E-Mail Removed). com>...
> (E-Mail Removed) (Vittal) wrote in message news:<(E-Mail Removed) om>...
> >
> > In one of the file I found the following snippet:
> >
> > $temp = qr{
> > \(
> > (?:
> > (?>[^()]+ )
> > |
> > (??{ $temp })
> > )*
> > \)
> > }x;
> >
> > $cchat = qr/((\W)?(\*?\*?\w+)\s*($temp))/;
> >
> > Can somebody explain me what these two lines do?

>
> Dear Vittal,
>
> The good news is that the programmer who wrote that script did not
> create the first line him/herself. He/She just copied it straight
> from the "prelre" documentation. To read what it does, type "perldoc
> perlre" at a DOS or Unix prompt and search for the word "postponed".
> You'll see the exact same piece of code and the explanation that this
> regular expression matches a parenthesized group.
>
> In other words, if you can use $temp like this:
>
> if ("I saw a color (blue)." =~ m/$temp/)
> {
> print $&; # this prints the match "(blue)"
> }
>
> It will also work with nested parentheses, like this:
>
> if ("I already ate (I ate one (1) pizza)." =~ m/$temp/)
> {
> print $&; # this prints "(I ate one (1) pizza)"
> }
>
> The bad news is that the programmer who wrote that script didn't feel
> the need to add comments to explain the purpose of those regular
> expressions. It has been said that it's almost always easier to
> create your own regular expressions than to understand one that's
> already written, and in this case that's definitely true. If it
> wasn't for the fact that the first line was specifically mentioned in
> "perldoc perlre", I'm sure that I would not have been able to figure
> out what it was looking for.
>
> The second regular expression is a little easier to figure out.
> Let's take it a bit at a time:
>
> > $cchat = qr/((\W)?(\*?\*?\w+)\s*($temp))/;

>
> The only parts of the $cchat regular expression that are not optional
> are the \w+ part (which matches at least one "word" character (that
> is, a letter, digit, or underscore)) and $temp, which matches a
> parenthesized expression. Optionally, there may be whitespace (any
> amount) between the non-optional parts. Also, there may be one or two
> asterisks before the \w+ part. There could also be an optional
> non-"word" character before the word characters (which would appear
> before the asterisks, if the asterisks happen to exist).
>
> Was my explanation confusing? If you didn't think so, then you're
> a super genuis. I didn't expect it to be very easy to follow (like it
> is said, it's not very easy to understand a regular expression that
> you didn't write), so I always recommend writing a few comments (with
> any non-simple regular expression) that shows a few sample matches.
> The writer of that program you're reading should have included a few
> comments like this:
>
> # The $temp regular expression was taken right out of
> # the "perldoc perlre" documentation. It matches a
> # parenthesized expression (that may or may not contain
> # nested parentheses):
> $ temp = ... ;
>
> # The purpose of the $cchat regular expression is ...
> # It matches all of the following lines:
> # some_text(parenthesized expression)
> # some_text (parenthesized expression)
> # *some_text(parenthesized expression)
> # **some_text (parenthesized expression)
> # %*some_text (parenthesized expression)
> # ^**some_text(parenthesized expression)
> # &some_text (parenthesized expression)
> # !some_text(parenthesized expression)
> $cchat = qr/((\W)?(\*?\*?\w+)\s*($temp))/;
>
> Because the original programmer didn't explain the purpose of the
> $cchat regular expression, it's difficult for us to figure it out for
> sure. The closest we can come to figuring it out is to examine sample
> matches and deduce the purpose from there.
>
> If you ever add more code to this program, do yourself and the
> future maintainers of the program a favor and add comments to document
> your regular expressions. Include the purpose of the regular
> expression (in plain English or whatever language is the main language
> spoken at work) and include a few sample matches (because sometimes
> looking at sample matches helps a person understand much better than
> looking at the regular expression itself). It also helps the
> debugging process a lot.
>
> When you write code, please put comments in your code that explains
> to anyone who didn't write the code what the code is doing and its
> purpose. A lot of coders avoid doing this, giving many excuses as to
> why they shouldn't. Some of the excuses are:
>
> * I don't need to include comments because I write
> non-esoteric (simple) code that anyone can understand.
>
> * Comments eventually become outdated (and outdated comments
> are wrong) and wrong comments are worse than no comments
> at all (because they are misleading).
>
> * I don't need to include comments because I write
> "self-documenting" code. Comments are a sign that the
> code is impossible to understand without outside help,
> and I don't write code like that.
>
> Don't fall into those traps! I may be offending some die-hard
> programmers here who adhere to one or more of the above traps I
> listed, but I sincerely believe that comments and documentation are
> vital to writing programs (especially when writing programs that will
> be read by other people) -- even if the comments and documentation
> become outdated (outdated comments and documentation may not be
> correct in everything they say, but at least they provide important
> hints to anyone trying to understand, debug, and maintain the code).
>
> I hope this helps, Vittal.
>
> -- Jean-Luc Romano

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can somebody please tell me how to validate E-mail Id in java? Pasha Java 4 04-28-2006 05:06 AM
Insert, Update and Delete. Can somebody please help me? Shapper ASP .Net 3 07-09-2005 04:43 AM
can somebody guide me through this step by step? Taquin Noel Wireless Networking 5 12-26-2004 01:31 AM
XML String Manipulation <--- Have somebody can help me? dd711 Java 6 10-01-2004 01:49 PM
How can I let somebody print only one copy of something? BruceJ HTML 3 09-20-2003 02:11 AM



Advertisments