--- Andrew Wilson <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 02, 2003 at 10:16:37AM -0800, Austin Hastings wrote:
> > And the Colorific class supposedly has a way to determine if two
> colors
> > look about like each other. Again, I don't know how that works, but
> I
> > don't need to.
> >
> >> AH> rule same_color($color is Colorific)
> >> AH> {
> >> AH> <color> ::: { fail unless $1.looks_like($color); }
> >> AH> }
> >
> > This is really probably bad code. Maybe a better rule would be:
> >
> > rule same_color($color is Colorific)
> > {
> > <color> ::: { fail unless $color.looks_like($1); }
> > }
> >
> > I KNOW that $color is an object-of-type-Colorific, while I'm not
> sure,
> > frankly, what <color> is returning. Let Colorific handle that.
>
> It's my understanding (such as it is) of regexen that subrules called
> via <rule> capture their result in hypothetical variables. In
> same_color, by the time you get into the code after the :::, $color
> contains what was matched by <color>. So, if <color> matched at all,
> I don't think you can call looks_like on $color because it's the
> hypothetical result of <color> not a Colorific. Either that or it
> fails because you said it was a Colorific and it's not. Or you tried
> to assign to it but you can't because it's not C<is rw>.
More bad code on my part.
I had not intended that there be any correlation between the C<<color>>
rule result and the C<$color> named argument -- that's just
coincidental evidence of my poor design skills.
If you'll replace $color with $c, and try again?
rule same_color($c is Colorific)
{
<color> ::: { fail unless $c.looks_like($1); }
}
The intention here is that the result of C<<color>> is actually bound
to $1, per E5. So the idea is that C<Colorific $c> is asked to run its
.looks_like method on the C<<color>> that was just recognized.
> I think we need a P6 regexen engine to play with to get used to all
> this new stuff properly :-) Oh, and I really, really don't like all
> this extraneous type information that everybody seems to be
> sprinkling around their Perl6 code.
I know someone's working on P6::Rexen or some such (NOT regex, per LW).
As for the type info, I think that the compiler won't be able to do too
much with the low level of information that we're specifying here, so
it's mostly codereader hints. But Damian has suggested that using types
at all opens the yawning void of contamination up the call tree, so
your implicit preference for no-type-info may wind up being the norm.
=Austin
