Front page | perl.perl6.language |
Postings from April 2003
--- Jonathan Scott Duff <duff@cbi.tamucc.edu> wrote:
> On Wed, Apr 09, 2003 at 09:01:25PM -0400, Joseph F. Ryan wrote:
> > And then you could do:
> >
> > use Colorific qw(Blue Cloud);
> >
> > my Colorific @skysamples = peek_with_some_hardware;
> > my $clear_day = @skysamples ~~ /<Blue>* <Cloud>/;
> >
> > Which ain't too bad, in my book. (-:
>
> That is pretty nifty, but how would you say something like "match 2
> blue
> things, then a thing that isa Bird, then something that can fly"?
rule nifty()
{
(/./ <(.color == "Blue")>)<2>
/./ <(.isa(Bird))>
/./ <(.can(Fly))>
}
> Your
> way puts all of the logic in the pattern method when it's probably
> better in the rule itself, especially if the stream of objects we're
> matching against is heterogeneous:
>
> @things ~~ /<.color(Blue)><2><.isa(Bird)><.can(fly)>/;
>
> versus
>
> @things ~~ /<Blue><2><Bird><fly>/;
>
> Imagine that @things contains 2 X objects and 2 Y objects that would
> cause the match to succeed. The pattern method for the Y object would
> have to somehow handle both the .isa and .can ideas. How would it
> know which to apply when?
Presumably that's up to the match engine. There's an old text searching
algorithm that used to use an inverted frequency table to find the
"least common characters" in the query string, then search for them in
the body of text. If it found them, it would back up the appropriate
number of places and try a match, if no match, it would move forward a
bit and try again.
That behavior is up to the parse engine. Remember that throwing an
exception will cause a backtrack, so if the Blue objects don't know how
to handle a .can(Fly) request, they'll "die" or the dispatcher will,
and the rx engine will backtrack and try a different configuration.
=Austin
Thread Previous