Re: hotplug regexes, other misc regex questions
Josh Jore wrote:
>>>Would it be correct for this to print 0? Would it be correct for this
>>>to print 2?
>>>
>>> my $n = 0;
>>> "aargh" =~ /a* { $n++ } aargh/;
>>> print $n;
>>
>>Yes. ;-)
>
> Wouldn't that print 2 if $n is lexical
Err. It *is* lexical in this example.
> and 0 if it's localized?
No. Without the C it would still print either 0 or 2, depending
on the implementation/optimization.
> Or are lexicals localized now?
They can be. But this example C<$n> isn't.
(Just because it's used in a nested closure doesn't mean it's
localized within the pattern).
>>>What possible outputs are legal for this:
>>>
>>> "aaa" =~ /( a { print 1 } | a { print 2 })* { print "\n" } x/
>>
>
> I take it that what I've learned from _Mastering_Regular_Expressions_
> doesn't quite apply here? From that interpretation I'd think it'd print
> "111\n" since the second part of the alternation wouldn't be tried.
No. It would fail to match the final C in the pattern and start
backtracking.
Damian
RE: Hyperoperators and dimensional extension
Dan Sugalski:
# Sort of, yes.
#
# Basically the behaviour of hyper-operated operators is delegated via
^
Spending time in England lately? ;^)
# multimethod dispatch to the hyper-operator functions. By default the
Well, yeah. But that doesn't really answer my question. :^) What's
the *language-level* behavior?
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
RE: Hyperoperators and dimensional extension
At 8:27 AM -0700 9/19/02, Brent Dax wrote: >Dan Sugalski: ># Sort of, yes. ># ># Basically the behaviour of hyper-operated operators is delegated via > ^ >Spending time in England lately? ;^) Why, yes, actually. :-P But I've been using Pompous English Spelling for years. ># multimethod dispatch to the hyper-operator functions. By default the > >Well, yeah. But that doesn't really answer my question. :^) What's >the *language-level* behavior? Well, it does, though. Saying it's delegated to the variables and they have a default behavior's different than saying "this is the behaviour". -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl 6 Summary for week ending 2002-09-15
On Wednesday, Sep 18, 2002, at 17:42 Europe/Berlin, Piers Cawley wrote: > IMCC / Mac OS X problem > Leon Brocard (yay! Still batting 100% on this one...) has been > having > problems building IMCC under Mac OS X. The individual .c files all > compile, but bad things happen at link time. Leo, Kevin Falcone, > and > Andy Dougherty all pitched in and, after a flurry of patches, IMCC > is > now building and working correctly under Mac OS X. > > http://makeashorterlink.com/?R591215D1 > Have those patches committed, yet? I tried last night (instead of sleeping...;-)) but failed utterly. Regards, Kay
Re: hotplug regexes, other misc regex questions
On Wed, 18 Sep 2002, Luke Palmer wrote:
> On Wed, 18 Sep 2002, Josh Jore wrote:
> > On Wed, 18 Sep 2002, Damian Conway wrote:
> > > > What possible outputs are legal for this:
> > > >
> > > > "aaa" =~ /( a { print 1 } | a { print 2 })* { print "\n" } x/
> >
> > I take it that what I've learned from _Mastering_Regular_Expressions_
> > doesn't quite apply here? From that interpretation I'd think it'd print
> > "111\n" since the second part of the alternation wouldn't be tried.
>
> The first time through, yes. But then it tries to match the "x", and says
> "oops, that's not what I have" and backtracks. That tries the second of
> the alternation, which doesn't work either. So it backtracks so the * is
> only getting two of the first one, et cetera...
>
> Or are you talking about something else from Mastering Regular
> Expressions? Like some kind of optimization that happens?
I missed the trailing 'x/' since my perl5 eyes read that as '/x'. My bad.
Joshua b. Jore -{ weird geeky madness }-> http://www.greentechnologist.org
Re: Perl 6 Summary for week ending 2002-09-15
Kay Röpke wrote: > > On Wednesday, Sep 18, 2002, at 17:42 Europe/Berlin, Piers Cawley wrote: > >> IMCC / Mac OS X problem > Have those patches committed, yet? I tried last night (instead of > sleeping...;-)) but failed utterly. No, sorry. I'm still waiting for my imcc 0.0.9 patch to be checked in, where these fixes are included. If urgent you could follow the mentioned thread. There were all the pieces to get it running. > Regards, > > Kay leo
Re: Passing arguments
On Sat, 2002-09-14 at 04:16, Luke Palmer wrote:
> When a bare closure is defined, it behaves the same as a signatureless
> sub. That is, it topicalizes the first argument, and hands them all over
> in @_. So your "topic passing" is just, well, passing the topic, like
> any ol' argument.
Ok, thanks. I was getting lost in the noise there, but this finally
makes sense.
Just to make 100% sure though, let me get these definitions clear:
topicalize: To default to C<$_> in a prototype (thus acquiring the
caller's current topic).
signatureless sub: A sub that does not specify a prototype, and thus has
a default prototype of:
sub($_//=$_){};
ne?
--
Aaron Sherman <[EMAIL PROTECTED]>
http://www.ajs.com/~ajs
RE: Passing arguments
Aaron Sherman:
# topicalize: To default to C<$_> in a prototype (thus
# acquiring the caller's current topic).
Well, to topicalize a region of code is actually to specify a different
topic, that is, a different value for $_. For example:
$foo = new X;
$bar = new Y;
given $foo {
print $_.type, "\n";#prints "X"
given $bar {
#XXX we're using 'given' for this too, right?
print $_.type, "\n";#prints "Y"
}
}
(An aside: it strikes me that you could use C as a scoped lexical
alias, i.e.
my $foo="foo";
my $bar="bar";
print $foo;
given $bar -> $foo {
print $foo;
}
print $foo;
#prints "foobarfoo"
Hmm...)
# signatureless sub: A sub that does not specify a prototype,
# and thus has a default prototype of:
#
# sub($_//=$_){};
#
# ne?
More like:
a sub that was created with the arrow (->) or a bare block and
does not specify a prototype, and thus has a default prototype
of:
-> ($_ //= $OUTER::_) { };
Or some such. (Maybe C<$_ //= $_> will work, but I have reservations
about that--especially about the possibility of that picking up $_
dynamically instead of lexically. In some cases you want $_
dynamically, in others lexically. Perhaps C<$_ is topic('lexical')> and
C<$_ is topic('dynamic')>?)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: Perl 6 Summary for week ending 2002-09-15
Piers Cawley wrote: > > Happy birthday to me! Congratulations. > ... by my turning 35 on the 15th 44 on 16th - yes Sept. and thanks for the kudos, leo
Regex query
Well, I've started my Perl 6 programming career already and I've got
stuck. :)
I'm trying to parse a Linux RAID table (/etc/raidtab), which looks a
bit like this:
raiddev /dev/md0
raid-level 5
option value
option value
...
device /dev/sde1
raid-disk 0
device /dev/sdf1
raid-disk 1
device /dev/sdg1
raid-disk 2
...
raiddev /dev/md1
...
Here's the grammar I have so far:
grammar Raidtab;
rule raidtab { + };
rule comment { \# .* |
# Or a blank line
^^ \n };
rule comm_eol { ? \n };
rule raiddev { *
* "raiddev" + $name := (/dev/md\d+)
( | | )+ };
rule option { * $key := (<[a-z]->+) * $value := (\w+) };
rule devicelayout { * device + $name := (/dev/\w+)
* $type := (raid|spare|parity) -disk *
$index := (\d+)
};
What I can't figure out is how to drill down into the returned match
object and get at individual devices. I'd expect to be able to say
something like
$matchobject{raiddev}[0]{devicelayout}[1]{name}
and get "/dev/sdf1". Is that how it works, with multiply-matched rules
being put into arrays, or is it stored differently somehow?
--
3rd Law of Computing:
Anything that can go wr
fortune: Segmentation violation -- Core dumped
Re: Regex query
> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> raiddev /dev/md0
SC> raid-level 5
SC> option value
SC> option value
SC> ...
SC> device /dev/sde1
SC> raid-disk 0
i have some comments/questions as i am trying to learn this myself. i
could be way off base but here goes:
SC> grammar Raidtab;
SC> rule raidtab { + };
SC> rule comment { \# .* |
shouldn't that . be \N so it won't eat the next line or even beyond?
also you have here and * below. i think the latter is correct.
SC># Or a blank line
SC>^^ \n };
shouldn't that have a inside the blank line?
SC> rule comm_eol { ? \n };
aren't those 's redundant? the first is overlapping with the one at
the beginning of comment. and the second is subsumed by the .* at the
end of comment.
SC> rule raiddev { *
i think that should be comm_eol as you want to skip all full comment lines.
SC>* "raiddev" + $name := (/dev/md\d+)
SC> ( | | )+ };
same as above, comm_eol instead of comment.
SC> rule option { * $key := (<[a-z]->+) * $value := (\w+) };
i think that char class should be <[a-z-]>. <[]> marks a class and the -
needs to be inside it.
the second * should be + as you need whitespace between the
option and value.
SC> rule devicelayout { * device + $name := (/dev/\w+)
the \w+ after /dev/ needs to be more accepting as i think some devices
could be in subdirs
SC> * $type := (raid|spare|parity) -disk *
SC> $index := (\d+)
SC> };
SC> What I can't figure out is how to drill down into the returned match
SC> object and get at individual devices. I'd expect to be able to say
SC> something like
SC> $matchobject{raiddev}[0]{devicelayout}[1]{name}
SC> and get "/dev/sdf1". Is that how it works, with multiply-matched rules
SC> being put into arrays, or is it stored differently somehow?
that is how i understand it. the grammar automatically build a tree of
the grabs with hash keys being the rule names and multiples (rules with
quantifiers) being arrays.
what about the case where you have a descending set of rules but no
quantifiers. would you just not have the [0] parts when you access it
from the match object?
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Re: Regex query
[EMAIL PROTECTED] (Uri Guttman) writes:
> shouldn't that have a inside the blank line?
Or *, yes.
> SC> rule comm_eol { ? \n };
>
> aren't those 's redundant? the first is overlapping with the one at
> the beginning of comment.
But only matches if there *is* a comment, and there may not
be, so I want to match optional space at the EOL anyway.
> SC> rule raiddev { *
> i think that should be comm_eol as you want to skip all full comment lines.
I thought the .* (or \N*) would skip the whole line. comm_eol just means
"comment at end of line".
> i think that char class should be <[a-z-]>. <[]> marks a class and the -
> needs to be inside it.
Oops, typo.
> the second * should be + as you need whitespace between the
> option and value.
Yes.
> SC> rule devicelayout { * device + $name := (/dev/\w+)
> the \w+ after /dev/ needs to be more accepting as i think some devices
> could be in subdirs
No, by stipulation. :) This is Linux, without devfs.
> that is how i understand it. the grammar automatically build a tree of
> the grabs with hash keys being the rule names and multiples (rules with
> quantifiers) being arrays.
Great.
--
You advocate a lot of egg sucking but you're not very forthcoming with the
eggs. - Phil Winterbottom (to ken)
Re: Regex query
> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> rule comm_eol { ? \n };
>>
>> aren't those 's redundant? the first is overlapping with the one at
>> the beginning of comment.
SC> But only matches if there *is* a comment, and there may not
SC> be, so I want to match optional space at the EOL anyway.
ok, but since comment is optional, if it doesn't match, the two *
are back to back. is that needed? i just see too many * and that
could lead to backtracking issues (something i recall from MRE1).
SC> rule raiddev { *
>> i think that should be comm_eol as you want to skip all full comment lines.
SC> I thought the .* (or \N*) would skip the whole line. comm_eol just means
SC> "comment at end of line".
i figured that was what it meant. but . matches any char now so .* will
eat all the text until it is forced to backtrack. so \N* will stop at
the newline which is what i think you want in comm_eol.
>> that is how i understand it. the grammar automatically build a tree of
>> the grabs with hash keys being the rule names and multiples (rules with
>> quantifiers) being arrays.
SC> Great.
actually i just had another thought. you don't need any of the $foo :=
stuff as the match tree will have it all for you. unless you need a
single var having some grabbed stuff, you might as well let the match
object hold it all. you do want a tree from this parser so the single
vars will do no good. unless they also put stuff into the tree based on
their names. also if you use a scalar to grab something which is in a
quantified outer rule what is put in the var? a ref to a list of the
grabbed things?
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Re: Regex query
[EMAIL PROTECTED] (Uri Guttman) writes:
> actually i just had another thought. you don't need any of the $foo :=
> stuff as the match tree will have it all for you.
Yes, but it's nice to be able to access the captured things by
name. Or should I be saying things like
rule raiddev { *
* "raiddev" +
( | | )+ };
rule name { /dev/md\d+ }
> their names. also if you use a scalar to grab something which is in a
> quantified outer rule what is put in the var? a ref to a list of the
> grabbed things?
*nod* Something I'd like to know.
--
"Even if you're on the right track, you'll get run over if you just sit there."
-- Will Rogers
Re: Perl 6 Summary for week ending 2002-09-15
Leopold Toetsch <[EMAIL PROTECTED]> writes: > Piers Cawley wrote: > >> Happy birthday to me! > > > Congratulations. > >> ... by my turning 35 on the 15th > > > 44 on 16th - yes Sept. Congrats to you too. So, should I start maintaining a birthday database for the summaries? Probably not. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
