[32943] in Perl-Users-Digest
Perl-Users Digest, Issue: 4219 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu May 22 09:09:24 2014
Date: Thu, 22 May 2014 06:09:04 -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, 22 May 2014 Volume: 11 Number: 4219
Today's topics:
Re: A question about grep <news@lawshouse.org>
Re: Help with an operator precedence (?) puzzle <rm-dash-bau-haus@dash.futureapps.de>
Re: Help with an operator precedence (?) puzzle <rweikusat@mobileactivedefense.com>
Re: Help with an operator precedence (?) puzzle <rm-dash-bau-haus@dash.futureapps.de>
Re: Push regex search result into hash with multiple va <PointedEars@web.de>
regular expressions and matching delimeters (hymie!)
Re: regular expressions and matching delimeters <rweikusat@mobileactivedefense.com>
Re: regular expressions and matching delimeters <PointedEars@web.de>
Re: regular expressions and matching delimeters <*@eli.users.panix.com>
Re: regular expressions and matching delimeters <PointedEars@web.de>
Re: regular expressions and matching delimeters <ben.usenet@bsb.me.uk>
Re: regular expressions and matching delimeters <justin.1401@purestblue.com>
Re: regular expressions and matching delimeters <justin.1401@purestblue.com>
Re: regular expressions and matching delimeters <ben.usenet@bsb.me.uk>
Re: regular expressions and matching delimeters <rweikusat@mobileactivedefense.com>
Re: search.cpan.org <justin.1401@purestblue.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 21 May 2014 18:20:33 +0100
From: Henry Law <news@lawshouse.org>
Subject: Re: A question about grep
Message-Id: <0K6dnfnt35T8feHOnZ2dnUVZ8h-dnZ2d@giganews.com>
On 21/05/14 12:22, Rainer Weikusat wrote:
> the habit to make
> uncalled for nasty remarks about others for no particular reason
RW: are you familiar with the English expression "That's the pot calling
the kettle black"? If not, go and look it up, and think about it.
--
Henry Law Manchester, England
------------------------------
Date: Wed, 21 May 2014 17:40:08 +0200
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <537cc8d7$0$6672$9b4e6d93@newsspool3.arcor-online.net>
On 20.05.14 23:01, Rainer Weikusat wrote:
>> A first group comprises programmers who take an interest in "clever"
>> uses of syntax, usually called "geeks" or logicians or similar.
>> Or Perl hackers just enjoying the odd parts of TIMTOWTDI. (I wouldn't
>> be surprised to read "elegant" in this context.)
>
> Did it already occur to you that something you consider to be clever,
> possibly from a position of relative ignorance, might not at all seem
> 'clever' to anyone else?
Absolutely, taking "you" as a universally quantifying pronoun;
relative ignorance really is the point of the thread, since that
kind of ignorance is legitimate in professional programming.
Given a need to express
"IF bla-bla THEN <assign>; <return>; FI",
then the relative cleverness of statements S1 and S2 both
stating the above can be measured by how many programmers
(excluding absolute beginners) using Perl can understand
either, without error, and with ease. Time is money!
(And it's not about a million flies not knowing Perl's comma
operator. I like to think it is about an opportunity to enjoy
knowledge of a feature that just happens to be part of Perl
by historic incident, one that invites quiz questions, but
does not really change the world.)
The number of programmers understanding with ease, and correctly,
will grow by the number of programmers who haven't yet learned
(or are confused about) how to use Perl's comma operator.
I doubt that the growth rate is going to be enough to prevent
precedence puzzles etc. It does increase the price of scarce
Perl knowledge, though.
If there is confusion about the comma operator---and this thread
undeniably demonstrates there is---then using the comma operator
in 1-liners (S1) can be listed as clever, assuming that fewer
programmers will have difficulty recognizing (correctly, easily)
the control structure of S2 below. (Cf. Subject)
if (bla-bla) {
...;
return;
}
The result does not mean that after more learning, programmers
may want to, uhm, abbreviate communication using what happens
to be a part of Perl (comma), becoming one of a select group
of well payed cognoscenti. Just describing. Programmers
who easily and correctly know the meaning and implications
of a `,' in the currently used programming language, and context.
> The programming language is there to help me and whoever came up with
> the features considered them useful, presumably, based on some
> experience he had I might still be lacking
No, you take the programming language to be that, Perl itself
is just what it is. And while Perl has changed (e.g. $[),
the comma operator has survived. I don't see how *absolute*
usefulness or not follows from either, only *relative* (to
language version, say, after discussion).
> (it took me more than five
> years of writing a lot of C before I encountered an "Oh! I really need
> a postincrement here!" situation for the first time). Random 'first
> example' of a statement similar to the one under discussion I found
>
> $rc = rmdir($_[0]);
> $rc or $sysc = "rmdir $_[0]", last;
>
> That's part of a multi-step algorithm for deleting a directory
> including its contents. It contains a few more 'error handling'
> statements of the general form
>
> <success> or sysc = <description of failure>, last
>
> and turning these into
>
> if ($rc) {
> $sysc = "rmdir $_[0]";
> last;
> }
> wouldn't exactly make the code easier to read as the
> not-really-important parts would take up a lot more space.
Not to mention make it incorrect, am I right? (! $rc) It does
remove the "natural" ambiguity of forming groups by comma
discussed previously, though, which needs looking up what
this thread's Subject line is indicating does need looking up.
By what criteria do you arrive at "easier to read"?
Subjectively, objectively, statistically, ..., or based
on your later mention of it: inherently?
>> The first group does not need motivation. Its programmers
>> create correct, although "clever", code. (Even when the task is
>> simply to conditionally (assign and then return) ...)
>
> Something which happens to be familiar to you isn't necessarily
> inherently simpler than something else which isn't (although "familiar"
> ::= "good", "unfamiliar" ::= "bad" is an erroneous assumption many
> people will happily make).
How do "inherent"/"familiar" apply here? As you have explained,
it takes years of learning to, well what if not become _familiar_
with Perl's operators?
------------------------------
Date: Wed, 21 May 2014 18:53:30 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <87wqdfuig5.fsf@sable.mobileactivedefense.com>
"G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
> On 20.05.14 23:01, Rainer Weikusat wrote:
>
>>> A first group comprises programmers who take an interest in "clever"
>>> uses of syntax, usually called "geeks" or logicians or similar.
>>> Or Perl hackers just enjoying the odd parts of TIMTOWTDI. (I wouldn't
>>> be surprised to read "elegant" in this context.)
>>
>> Did it already occur to you that something you consider to be clever,
>> possibly from a position of relative ignorance, might not at all seem
>> 'clever' to anyone else?
>
> Absolutely, taking "you" as a universally quantifying pronoun;
> relative ignorance really is the point of the thread, since that
> kind of ignorance is legitimate in professional programming.
>
> Given a need to express
>
> "IF bla-bla THEN <assign>; <return>; FI",
>
> then the relative cleverness of statements S1 and S2 both
> stating the above can be measured by how many programmers
> (excluding absolute beginners) using Perl can understand
> either, without error, and with ease. Time is money!
Given the need to express
if (bla-bla) {
<assign>;
<return>;
}
how many "people who might have learnt anything but surely not Algol
68 [or the Bourne shell language]" will understand the clever
if bla-bla
then
<assign>;
<return>;
fi
which is mainly a workaround for deficiencies in non-at-all-WYSIWYG text
editors which started to fall out of common use 30 years ago "with
ease"? Considering that "time is money", how many illiterate, illegal
immigrants willing to work 96 h/week for 'food, shelter and the
occasional hiding' will?
I can repose the nonsensical rethorical question for any number of other
groups of people without any relevant qualification but the answer
remains always: Every member of $random_group willing to learn how to do
it, after having done so.
I'm ignoring the rest of this because I'm somewhat sick at the moment
and not in the mood for 'mental exercises for the sake of performing
them'.
------------------------------
Date: Thu, 22 May 2014 14:48:35 +0200
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <537df222$0$6611$9b4e6d93@newsspool4.arcor-online.net>
On 21.05.14 19:53, Rainer Weikusat wrote:
[Algol 68, sh]
> I can repose the nonsensical rethorical question for any number of other
> groups of people without any relevant qualification but the answer
> remains always: Every member of $random_group willing to learn how to do
> it, after having done so.
Then don't do that ;-) (Or rephrase them to be meaningful to
the discussion.) My question was about empirical evidence of Perl
programmers spending/wasting time on precedence puzzles (as, e.g.
this thread, cf. Subject line), and those likely caused by comma.
> I'm ignoring the rest of this because I'm somewhat sick at the moment
> and not in the mood for 'mental exercises for the sake of performing
> them'.
Have a good rest!
------------------------------
Date: Thu, 22 May 2014 00:43:57 +0200
From: Thomas 'PointedEars' Lahn <PointedEars@web.de>
Subject: Re: Push regex search result into hash with multiple values
Message-Id: <17743918.ci6CqVxxbi@PointedEars.de>
Dr.Ruud wrote:
> On 2014-05-19 19:22, Thomas 'PointedEars' Lahn wrote:
>> Dr.Ruud wrote:
>>> On 2014-05-19 11:42, Thomas 'PointedEars' Lahn wrote:
>>>> it appears to be prudent to create a hash whose keys are the
>>>> original keys, and the corresponding values are the quoted keys
>>>
>>> Or use the compiled regular expressions as values. Also because Perl
>>> keeps moving forward with them.
>>
>> What do you mean by that?
>
> It is mainly about the speed. In previous versions of Perl, keeping the
> simple string version of a regular expression in a variable,
> performed faster. So for a /$re/ in big loops, it paid off to use:
>
> my $re = "some-regex";
>
> in stead of:
>
> my $re = qr/some-regex/;
How can that be?
,----[perlop(1)
| […]
| Since Perl may compile the pattern at the moment of
| execution of the qr() operator, using qr() may have speed
| advantages in some situations, notably if the result of
| qr() is used standalone:
|
| sub match {
| my $patterns = shift;
| my @compiled = map qr/$_/i, @$patterns;
| grep {
| my $success = 0;
| foreach my $pat (@compiled) {
| $success = 1, last if /$pat/;
| }
| $success;
| } @_;
| }
|
| Precompilation of the pattern into an internal
| representation at the moment of qr() avoids a need to
^^^^^^^^^^^^^^^^
| recompile the pattern every time a match "/$pat/" is
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| attempted. (Perl has many other internal optimizations,
^^^^^^^^^
| but none would be triggered in the above example
| if we did not use qr() operator.)
| […]
`----
and
| m/PATTERN/msixpodualgc
| /PATTERN/msixpodualgc
| […]
| PATTERN may contain variables, which will be interpolated
| every time the pattern search is evaluated, except for
| when the delimiter is a single quote. (Note that $(, $),
| and $| are not interpolated because they look like end-of-
| string tests.) Perl will not recompile the pattern unless
^^^^^^
| an interpolated variable that it contains changes.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
By algorithm, the value of $key *always* changes here, so if you use
/\b\Q$key\E\b/ and the like in the loop, IIUC Perl will have to recompile
the pattern *every* time.
The most efficient approach should be to precompile the expression:
$ perl -e '
use strict;
use warnings;
use Data::Dumper;
my %keys = map { $_ => qr/\b\Q$_\E\b/ } qw(foo.bar bar.baz);
my @phrases = qw(foo.bar baz foo bar.baz foo.bar.baz);
my %found;
print Dumper(\%keys);
foreach my $phrase (@phrases) {
while (my ($key, $key_expr) = each %keys) {
push @{ $found{ $key } }, $phrase
if $phrase =~ $key_expr;
}
}
print Dumper(\%found);'
$VAR1 = {
'bar.baz' => qr/(?^:\bbar\.baz\b)/,
'foo.bar' => qr/(?^:\bfoo\.bar\b)/
};
$VAR1 = {
'bar.baz' => [
'bar.baz',
'foo.bar.baz'
],
'foo.bar' => [
'foo.bar',
'foo.bar.baz'
]
};
> But effort has been, and is still being, put in to make the qr// variant
> the right choice in all normal contexts.
-v please
--
PointedEars
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
------------------------------
Date: 21 May 2014 19:38:35 GMT
From: hymie@lactose.homelinux.net (hymie!)
Subject: regular expressions and matching delimeters
Message-Id: <537d00ba$0$58143$862e30e2@ngroups.net>
Greetings.
I may be asking the wrong question, so I'll start here:
Is it possible, through regular expressions or some other method,
to parse a string based on matching delimeters?
The "string" that I have is actually a variable declaration for a
Javascript program. I don't want to actually *run* Javascript. All
I want is the data, and right now, this is the only way I can get the
data. It looks something like this:
var list = [{"item":1,"tags":["tag1","tag2"],"day":"Friday",
"people":[{"name":"Joe","id":"1"},{"name":"Larry","id":"2"}],
"loc":"Room 100"}, {"item":2,"tags":["tag2","tag3"],"day":"Friday",
"people":[{"name":"Joe","id":"1"},{"name":"Tom","id":"3"}],
"loc":"Room 101"}];
So I can't just look for {(.*?)} because the braces will not
necessarily be a matched pair. I want to ensure that I can pull out an
entire record, and then pull entire fields out of the record. I'm also
not in a position to guarantee any specific maximum level of nesting.
My vi clone can find matching braces and brackets and parentheses,
so I know it's **possible**. The question is, am **I** good enough
to do it? :)
Can somebody give me the push I need to work this out?
--hymie! http://lactose.homelinux.net/~hymie hymie@lactose.homelinux.net
-------------------------------------------------------------------------------
------------------------------
Date: Wed, 21 May 2014 21:13:38 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: regular expressions and matching delimeters
Message-Id: <87oayqvqj1.fsf@sable.mobileactivedefense.com>
hymie@lactose.homelinux.net (hymie!) writes:
> I may be asking the wrong question, so I'll start here:
>
> Is it possible, through regular expressions or some other method,
> to parse a string based on matching delimeters?
>
> The "string" that I have is actually a variable declaration for a
> Javascript program. I don't want to actually *run* Javascript. All
> I want is the data, and right now, this is the only way I can get the
> data. It looks something like this:
>
> var list = [{"item":1,"tags":["tag1","tag2"],"day":"Friday",
> "people":[{"name":"Joe","id":"1"},{"name":"Larry","id":"2"}],
> "loc":"Room 100"}, {"item":2,"tags":["tag2","tag3"],"day":"Friday",
> "people":[{"name":"Joe","id":"1"},{"name":"Tom","id":"3"}],
> "loc":"Room 101"}];
This looks very suspiciously like JSON ('Javascript Object
Notation'). Unsurprisingly, there's a module for dealing with that (the
first one I found),
http://search.cpan.org/~makamaka/JSON-2.53/lib/JSON.pm
NB: I can't comment on the code itself.
------------------------------
Date: Thu, 22 May 2014 00:34:51 +0200
From: Thomas 'PointedEars' Lahn <PointedEars@web.de>
Subject: Re: regular expressions and matching delimeters
Message-Id: <3012765.guVeODLbBg@PointedEars.de>
hymie! wrote:
^^^^^^
This is Usenet. Please fix that.
> Is it possible, through regular expressions or some other method,
> to parse a string based on matching delimeters?
Yes.
> The "string" that I have is actually a variable declaration for a
> Javascript program.
There is no Javascript. <http://PointedEars.de/es-matrix>
> I don't want to actually *run* Javascript. All I want is the data, and
> right now, this is the only way I can get the data.
Unlikely.
> It looks something like this:
>
> var list = [{"item":1,"tags":["tag1","tag2"],"day":"Friday",
> "people":[{"name":"Joe","id":"1"},{"name":"Larry","id":"2"}],
> "loc":"Room 100"}, {"item":2,"tags":["tag2","tag3"],"day":"Friday",
> "people":[{"name":"Joe","id":"1"},{"name":"Tom","id":"3"}],
> "loc":"Room 101"}];
The RHS is most certainly JSON (JavaScript Object Notation) data. This code
only makes sense in client-side context; very likely it has been generated
by server-side code. So your situation is unclear.
> So I can't just look for {(.*?)} because the braces will not
> necessarily be a matched pair. I want to ensure that I can pull out an
> entire record, and then pull entire fields out of the record. I'm also
> not in a position to guarantee any specific maximum level of nesting.
Whenever it occurs to you that a single application of a single regular
expression could be sufficient to parse a word from a context-free language,
you should review your Chomsky hierarchy. That said, Perl supports an
extension of regular expressions that can parse recursive structures as far
as stack and memory permits. RTFM.
> My vi clone can find matching braces and brackets and parentheses,
> so I know it's **possible**. The question is, am **I** good enough
> to do it? :) Can somebody give me the push I need to work this out?
To both questions: Improbable, but not impossible.
<http://www.catb.org/~esr/faqs/smart-questions.html>
> --hymie! http://lactose.homelinux.net/~hymie
> hymie@lactose.homelinux.net
Signatures are to be delimited with “-- ” (hyphen-hyphen-space)
--
PointedEars
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
------------------------------
Date: Wed, 21 May 2014 23:09:18 +0000 (UTC)
From: Eli the Bearded <*@eli.users.panix.com>
Subject: Re: regular expressions and matching delimeters
Message-Id: <eli$1405211852@qz.little-neck.ny.us>
In comp.lang.perl.misc, Thomas 'PointedEars' Lahn <usenet@PointedEars.de> wrote:
> hymie! wrote:
> ^^^^^^
> This is Usenet. Please fix that.
There is nothing wrong there. The original header was:
From: hymie@lactose.homelinux.net (hymie!)
Which is prefectly legit.
>> Is it possible, through regular expressions or some other method,
>> to parse a string based on matching delimeters?
> Yes.
Regular expressions can match based on "matching delimeters" but not
on arbritrarily nested "matching delimeters". (What perl's "regular
expressions" can do is more than "regular", but it is ill-advised to
try to code for that madness.)
For stuff like hymie has shown, I'd use the JSON module to extract
data. For general purpose parsers, Parse::RecDescent is the way to go.
>> The "string" that I have is actually a variable declaration for a
>> Javascript program.
> There is no Javascript. <http://PointedEars.de/es-matrix>
:r! lynx -source -dump http://PointedEars.de/es-matrix | grep -c javascript
292
A quick perusal of the source of your webpages shows that you use
javascript in them, so I call bullshit on your claim. When your site
has <script type="text/[SOMETHING BESIDES JAVASCRIPT]"> tags, please
do tell us. Until then your semantic games are tiresome.
Elijah
------
also not a fan of seeing two images encoded in Usenet post headers
------------------------------
Date: Thu, 22 May 2014 02:22:24 +0200
From: Thomas 'PointedEars' Lahn <PointedEars@web.de>
Subject: Re: regular expressions and matching delimeters
Message-Id: <1809176.xtA9eLKuQX@PointedEars.de>
Eli the Bearded wrote:
> In comp.lang.perl.misc, Thomas 'PointedEars' Lahn […] wrote:
It's attribution *line*, _not_ attribution novel. There is no crosspost, so
there is no need to specify the newsgroup. I use Reply-To so that I am less
spammed there; in the best case, only e-mails from real people using real
newsreaders would go there. Thanks to clueless idiots like you, crawlers
can now just harvest that carefully hidden address on any Web site mirroring
this newsgroup and spam me. FOAD.
>> hymie! wrote:
>> ^^^^^^
>> This is Usenet. Please fix that.
>
> There is nothing wrong there.
Wrong, there is no real name. Impolite.
> The original header was:
> […]
> Which is prefectly legit.
Internet is the thing with cables. Usenet is the thing with *people*.
>>> Is it possible, through regular expressions or some other method,
>>> to parse a string based on matching delimeters?
>> Yes.
>
> Regular expressions can match based on "matching delimeters" but not
> on arbritrarily nested "matching delimeters". (What perl's "regular
> expressions" can do is more than "regular", but it is ill-advised to
> try to code for that madness.)
Next time, read and post with your mind switched on, if any. TIA.
> […]
>>> The "string" that I have is actually a variable declaration for a
>>> Javascript program.
>> There is no Javascript. <http://PointedEars.de/es-matrix>
>
> :r! lynx -source -dump http://PointedEars.de/es-matrix | grep -c
> :javascript
> 292
>
> A quick perusal of the source of your webpages shows that you use
> javascript in them, so I call bullshit on your claim. When your site
> has <script type="text/[SOMETHING BESIDES JAVASCRIPT]"> tags, please
> do tell us. Until then your semantic games are tiresome.
I could not care less what pseudonymous wannabes like you call my claims.
If you had actually *read* what I referred to (a decade of work now) you
would have spared us reading and me replying to your stupid posting.
> Elijah
> ------
Which part of “properly delimited signature” did you not understand?
> also not a fan of seeing two images encoded in Usenet post headers
They are standards-compliant, and customary here.
--
PointedEars
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
------------------------------
Date: Thu, 22 May 2014 02:45:54 +0100
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Subject: Re: regular expressions and matching delimeters
Message-Id: <0.91f4f66819c971a525fb.20140522024554BST.87wqdesi0d.fsf@bsb.me.uk>
Eli the Bearded <*@eli.users.panix.com> writes:
<snip>
> Regular expressions can match based on "matching delimeters" but not
> on arbritrarily nested "matching delimeters". (What perl's "regular
> expressions" can do is more than "regular", but it is ill-advised to
> try to code for that madness.)
Is it? Can you explain?
I had a use-case to parse (and then interpret) a very simple lisp-like
language and I thought I'd give Perl's self-referential patterns a try.
It turned out to provide a very simple solution.
<snip>
--
Ben.
------------------------------
Date: Thu, 22 May 2014 10:16:55 +0100
From: Justin C <justin.1401@purestblue.com>
Subject: Re: regular expressions and matching delimeters
Message-Id: <7tr05b-1v1.ln1@zem.masonsmusic.co.uk>
On 2014-05-22, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Eli the Bearded <*@eli.users.panix.com> writes:
> <snip>
>> Regular expressions can match based on "matching delimeters" but not
>> on arbritrarily nested "matching delimeters". (What perl's "regular
>> expressions" can do is more than "regular", but it is ill-advised to
>> try to code for that madness.)
>
> Is it? Can you explain?
>
> I had a use-case to parse (and then interpret) a very simple lisp-like
> language and I thought I'd give Perl's self-referential patterns a try.
> It turned out to provide a very simple solution.
I think the suggestion of "madness" is because it's been done before
and the truly sensible method would be to use a module and just get
one with what you really want to be doing. I believe Text::Balanced
may also work for you if Parse::RecDescent hasn't solved the problem
already.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Thu, 22 May 2014 10:14:09 +0100
From: Justin C <justin.1401@purestblue.com>
Subject: Re: regular expressions and matching delimeters
Message-Id: <1or05b-1v1.ln1@zem.masonsmusic.co.uk>
On 2014-05-22, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
Absolutely nothing worth reading at all.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Thu, 22 May 2014 12:34:40 +0100
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Subject: Re: regular expressions and matching delimeters
Message-Id: <0.1dedc4b948e3eed711c2.20140522123440BST.87fvk2rqr3.fsf@bsb.me.uk>
Justin C <justin.1401@purestblue.com> writes:
> On 2014-05-22, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Eli the Bearded <*@eli.users.panix.com> writes:
>> <snip>
>>> Regular expressions can match based on "matching delimeters" but not
>>> on arbritrarily nested "matching delimeters". (What perl's "regular
>>> expressions" can do is more than "regular", but it is ill-advised to
>>> try to code for that madness.)
>>
>> Is it? Can you explain?
>>
>> I had a use-case to parse (and then interpret) a very simple lisp-like
>> language and I thought I'd give Perl's self-referential patterns a try.
>> It turned out to provide a very simple solution.
>
> I think the suggestion of "madness" is because it's been done before
> and the truly sensible method would be to use a module and just get
> one with what you really want to be doing. I believe Text::Balanced
> may also work for you if Parse::RecDescent hasn't solved the problem
> already.
OK, but (forgive me) that's standard advice. I got the feeling that
something more was being suggested, specifically aimed at Perl's
non-regular pattern matching.
--
Ben.
------------------------------
Date: Thu, 22 May 2014 13:22:17 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: regular expressions and matching delimeters
Message-Id: <87fvk2vw92.fsf@sable.mobileactivedefense.com>
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Eli the Bearded <*@eli.users.panix.com> writes:
> <snip>
>> Regular expressions can match based on "matching delimeters" but not
>> on arbritrarily nested "matching delimeters". (What perl's "regular
>> expressions" can do is more than "regular", but it is ill-advised to
>> try to code for that madness.)
>
> Is it? Can you explain?
>
> I had a use-case to parse (and then interpret) a very simple lisp-like
> language and I thought I'd give Perl's self-referential patterns a try.
> It turned out to provide a very simple solution.
The given case was somewhat different from that, namely, an
array-literal written in Javascript notation which contained 'Javascript
object literals' (equivalent to 'Perl hashes' for this case), which, in
turn, contained other object literals and other array literals
containing object literals, which, in turn, contained ... and so on.
There's the additional issue of quoting in here because there's exactly
one (AFAIK) sensible quoting syntax on this planet, namely, the one used
in HTML, which guarantees that 'special characters' don't appear
literally inside quoted constructs and whose quoted strings can thus be
analyzed by looking for the next ", but nobody uses that, likely
because that would make too much sense.
It is presumably possible to create a description of an automaton
capable of analyzing this correctly using the Perl 'regex' sub-language
but that's going to end up as insanely complex (but surely
'compressed'!) way to solve a relatively simple problem. Using a
recursive-descent parser which, in turn, uses regexes for lexical
analysis, will end up being more code but it will also be a lot more
accessible and flexible code and while 'optimizing this to the hilt in pure
Perl' may count as 'seriously manly deed', the result is going to be
beaten hands down by a much less "clevificient" C implementation and it
won't be necessary, anyway.
------------------------------
Date: Thu, 22 May 2014 10:19:36 +0100
From: Justin C <justin.1401@purestblue.com>
Subject: Re: search.cpan.org
Message-Id: <82s05b-1v1.ln1@zem.masonsmusic.co.uk>
On 2014-05-21, George Mpouras <gravitalsun@hotmail.foo> wrote:
> what is going on with search.cpan.org , is it down ? e.g.
> http://search.cpan.org/~cindy/AnyEvent-MySQL-v1.1.1/
It's been like a yo-yo for a little while now. https://metacpan.org
is an alternative.
Justin.
--
Justin C, by the sea.
------------------------------
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 4219
***************************************
