Logic Programming with Rules
There's been rumblings on this list lately about making Perl perform more
Logic based programming functions, a la Prolog. Having done some work
with Prolog in academia, I fully understand why this is desirable.
It occurs to me that underlying functionality of Prolog is moderately
similar to the P6RE.
In particular, they both:
- ultimately declare a given assertion as true, or fail.
- backtrack like crazy, if needed, to get a given assertion to be true.
- have concepts of sub-assertions that take parameters.
- bind various variables to given values along the way, and report those
values along the way.
Indeed, a great deal of logical testing can be performed with the
current P6RE definition.
For instance:
rule Equal ($x, $y) {{ $x ~~ $y or fail }};
rule Substr (Str $str, Str $in) {{ $in ~~ /$str/ or fail }};
rule IsAbsValue (Num $x, Num $y) {
{$x == $y or fail} |
{$x == -$y or fail} };
There are some things that are lacking, however. The first is that all
of the Cor fail's will get very old for typing and viewing. I would
propose that we add :a/:assert as a rule modifier, making all closures
assertions that behave exactly as if you typed a C or fail at the end
of each of them.
Also, since matching null is going to be rather common should one go
this route, I'd add a :z/:zerolength modifier, disabling that
restriction. It would probably make sense to have :a imply :z.
The really big problem, however, is the lack of generators.
I'll establish a working definition of generator as something which
offers a possible value, giving the new value each time the
expression is backtracked over, and fails when there are no more
values to give. Clearly, desirable generators include lazy lists,
arrays, and closures. All of which P6RE supports as ways of attempting
different rules/strings to match against, but not as different values to
assign a given $var to feed into later rules. Capturing assumes a
string to match and capture against. Capturing the null string that I
match is not terribly useful.
The only suggestion I can give for how to do this is by introducing the
hyper operator. I'm very open to other ideas, because this one does not
sit well with me, but it's all I've got at the moment. So, to give an
array as a generator, one could write:
/:a {$x »=« @values} test($x)/
which would have the net effect of $/x holding the first value in
@values that made the test work, assuming any of them did. I didn't use
the regular C = assignment because it would not distinguish between a
single function call and a function as an iterator.
After all that, I need multi-rules. Most specificly, I need to know if the
parameters being fed to me are already bound/defined. The purpose of
this is to write rules which act as both tests and pseudo-generators.
multi rule Equal ($x where defined(),
$y where defined())
:a
{{$x ~~ $y}};
multi rule Equal ($x where defined(),
$y where {!defined()} is rw)
{{$y = $x}};
multi rule Equal ($x where {!defined()} is rw,
$y where defined())
{{$x = $y}};
Ideally I'd like something more like C is Bound and C is Unbound
more than those crufty C where defined() , but I don't think that
would mesh well with the rest of Perl6.
It's a lot more work to build than the equiv Prolog statement, but I
can't justify the level of effort it would take to define and implement
the auto-generation capabilities.
-- Rod Adams
Re: Argument Patterns
Luke Palmer [EMAIL PROTECTED] wrote: I think we should replace our multimethod system with a more general pattern matcher, a variadic multimethod system of sorts. Multimethods need to be variadic anyway, because we want pugs's quicksort example to work. I'd not say replace. The dispatcher will very likely be a Parrot PMC. The default dispatcher dispatches on types, matching variadic signatures should be possible too. All infix operators are multi subs. I can't imagine that we want to pay the penalty for simple operations like: $a = $b + $c to inspect the values of operands, constraints, rules and what not. [ dispatching on rules ] If the involved types need a more fancy dispatcher, their meta-class should say so. Luke leo
Re: Argument Patterns
Leopold Toetsch writes: Luke Palmer [EMAIL PROTECTED] wrote: I think we should replace our multimethod system with a more general pattern matcher, a variadic multimethod system of sorts. Multimethods need to be variadic anyway, because we want pugs's quicksort example to work. I'd not say replace. The dispatcher will very likely be a Parrot PMC. The default dispatcher dispatches on types, matching variadic signatures should be possible too. All infix operators are multi subs. I can't imagine that we want to pay the penalty for simple operations like: $a = $b + $c to inspect the values of operands, constraints, rules and what not. Having written several multi dispatch systems, I know that this is easy to optimize. If nobody has defined + on any fancy subtypes, then we can quickly fall back to a bitset-intersection dispatch algorithm on the types (or even, eew, direct lookup). If + has been defined on fancy subtypes, then we compile the quickest way to figure out whether none of the arguments are one of them, and fall back. This is a little tricky, but some elementary graph theory gets us there. Essentially, what dispatcher we're using for + depends on what kinds of +s people have defined. That's how it should be; otherwise you'll get people globally overriding + so they can stick their own dispatcher in there, which isn't a portable solution. But we always have enough knowledge to optimize the hell out of this, and they're not not handwavy we can probably optimizations. They're real, and they're pretty darn easy. Luke
Re: Argument Patterns
Luke Palmer wrote: But we always have enough knowledge to optimize the hell out of this, and they're not not handwavy we can probably optimizations. They're real, and they're pretty darn easy. I fully agree. But I like to add that a single 'where' on general types like Int, Str or even Any can seriously harm performance because than the dispatcher has to check it always and everywhere! So the Perl 6 type system let's you have your rope and tie yourself. Well, that is late binding :) -- TSa (Thomas Sandla)
Re: Logic Programming with Rules (and Argument Patterns)
Rod Adams writes:
Indeed, a great deal of logical testing can be performed with the
current P6RE definition.
For instance:
rule Equal ($x, $y) {{ $x ~~ $y or fail }};
rule Substr (Str $str, Str $in) {{ $in ~~ /$str/ or fail }};
rule IsAbsValue (Num $x, Num $y) {
{$x == $y or fail} |
{$x == -$y or fail} };
There are some things that are lacking, however. The first is that all
of the Cor fail's will get very old for typing and viewing. I would
propose that we add :a/:assert as a rule modifier, making all closures
assertions that behave exactly as if you typed a C or fail at the
end of each of them.
Or you could avoid the global modifier and write your tests in ( )
blocks instead... after all, that's what it's there for.
The really big problem, however, is the lack of generators.
I'll establish a working definition of generator as something which
offers a possible value, giving the new value each time the expression
is backtracked over, and fails when there are no more values to give.
One generator is the * combinator. It gives the longest string, then
the next shorter, then the next shorter...
Clearly, desirable generators include lazy lists, arrays, and
closures. All of which P6RE supports as ways of attempting different
rules/strings to match against, but not as different values to assign
a given $var to feed into later rules. Capturing assumes a string to
match and capture against. Capturing the null string that I match is
not terribly useful.
The only suggestion I can give for how to do this is by introducing the
hyper operator. I'm very open to other ideas, because this one does not
sit well with me, but it's all I've got at the moment. So, to give an
array as a generator, one could write:
/:a {$x = @values} test($x)/
You could do all of this with a library of rules.
/ $x:=generate(@values) test($x) /
How the generate rule is actually written is getting into some rule
engine internal stuff, but we're making sure that the rule engine has
enough hooks to do that.
I think you'll be interested in where my 'Argument Patterns' proposal
was going next, before I ran off to class (and got scared of posting it,
because people would get scared of me). But it seems to be related to
what you're talking about. Maybe we could unify the pattern proposal
and your generation ideas for logic programming.
[WARNING: highly speculative, abstract, scary content ahead]
You can create patterns outside of argument lists, too. One kind of
pattern that we're already familiar with is the junction (that's right,
I just redefined what a junction is). If you give a pattern to an array
as a subscript, it returns the pattern that matches each thing
referenced by any subscript pattern, if that makes sense.
Now, certain types of patterns can be generated. What exactly can be
generated depends on what types of patterns implement a GENERATE method
that succeeds when you call it.
Allow me to use $^ as a 'pattern variable' marker for outside of
parameter lists.
@array[$^i] # returns a lazy pattern of everything in @array, bound
# together with the corresponding $i
(@array[$^i]).GENERATE # generates every element of @array
Now, let's just combine that with another array pattern:
@a[$^i] + @b[$^i] # returns lazy pattern of everything in @a
# added to its corresponding element in @b
(@a[$^i] + @b[$^i]).GENERATE # vector sum
Now if we just spell .GENERATE with :
@a[$^i] + @b[$^i]
We have my tensor-hyper proposal back.
Not only does it work with arrays, it works with any combination of
things that can be generated. This includes arrays whose shapes are not
declared, hashes, even roles if their implementor decides to implement
GENERATE.
Now could have a similar meaning within rules, which would give you
your generator.
# print everything in @array that matches test()
/ $x := [EMAIL PROTECTED] ( test($x) ) { say $x; fail } /
Of course, that can much more easily be done with a grep, but hey,
TMTOAWTDI*, right?
The biggest question is how this interacts with sub calls. We can't
really expect sub calls to be pattern-aware: that puts constraints on
what we're allowed to do in a sub (no side-effect constraints; gee,
those kinds of constraints really go a long way). But test could
certainly implement a GENERATE method:
sub is_prime(
$x will GENERATE { primes() }
)
{
?grep { $_ == $x } primes()
}
The will generate says that the sub can accept a generic pattern and
will fill it in on the spot.
That's my first-order approximation. There is probably some higher
order stuff that proves that I'm way off.
In particular, it would be great if this stuff could be crammed into a
library, but I understand that that would be very hard for such
features...
Luke
* A = Awkward
Re: Argument Patterns
Thomas Sandla writes: Luke Palmer wrote: But we always have enough knowledge to optimize the hell out of this, and they're not not handwavy we can probably optimizations. They're real, and they're pretty darn easy. I fully agree. But I like to add that a single 'where' on general types like Int, Str or even Any can seriously harm performance because than the dispatcher has to check it always and everywhere! So the Perl 6 type system let's you have your rope and tie yourself. Well, that is late binding :) Only if you define an AUTOLOAD on your subtypes. The way to think about multimethod implementation problems is inside-out from how you think about single dispatch. The *method* is the one that knows everything, not the object. So definitions on subtypes of general types only check for those subtypes when dispatching to the methods defined in them. Luke
Re: some misc Perl 6 questions
Darren Duncan [EMAIL PROTECTED] wrote:
A question: Would has PkgNameArray @.tmpl_set_nms; do what I
expect, where the array as a whole is the sub-type, or would it make
an array where each element is the sub-type?
I think this declares an array of PkgNameArrays, but has
@.tmpl_set_nms is PkgNameArray; will do what you want.
New question: Is there a way to say that two classes have a
privileged relationship, sort of like a marriage, such that each can
see and/or change otherwise private attributes in objects of the
other class, and yet the attribute list of each class is completely
different from the other? Neither of the two objects is a subclass
of the other, nor fulfills a role defined by the other.
S12:
Attributes are never visible outside a class definition, so a multi
method can only directly access the attributes of a class it's defined
within. However, it may call the private attribute accessors from a
different class if that other class has indicated that it trusts the
class the multi method is defined in:
class MyClass {
trusts Yourclass;
...
}
(end quote)
So for the relationship to work both ways, each class would have to
mark the other as trusted.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: Argument Patterns
HaloO Luke, you wrote: [..] The *method* is the one that knows everything, not the object. So definitions on subtypes of general types only check for those subtypes when dispatching to the methods defined in them. I stand corrected. Lax usage of Any is fair. Defining subtypes of general types and using them to constrain e.g. params of subs is fine, too. But defining a multi branch on a very common operator like +, * or grep for a predicate---i.e. using where---subtype is penalized. Sounds reasonable to me. MfG -- TSa (Thomas Sandla)
splat operator and context
I was trying to implement unary * (list flatten or splat operator) in pugs yesterday, and I came to the conclusion that I really don't grok how context works in Perl6 (I also really don't grok Haskell, but this is another story...). if I understand correctly, all these are equivalents: my @a = 1,2,3; my @a = (1,2,3); my @a = list 1,2,3; my @a = [1,2,3]; # or does it make @a[0] = (1,2,3)? and all these are too (they make $a a reference to an array): my $a = 1,2,3; my $a = (1,2,3); my $a = list 1,2,3; my $a = [1,2,3]; I'm not sure what the following do (assign 1 to $a maybe?): my $a = [EMAIL PROTECTED]; my $a = *(1,2,3); # or is this a syntax error? my $a = *(list 1,2,3); my $a = *[1,2,3]; and I have absolutely no clue about the following: my *$a = @a; my *$a = [EMAIL PROTECTED]; my *$a = (1,2,3); my *$a = [1,2,3]; thanks for any help. cheers, Aldo
Re: splat operator and context
Aldo Calpini skribis 2005-03-09 12:12 (+0100): my @a = 1,2,3; my $a = 1,2,3; These are (my @a = 1), 2, 3; (my $a = 1), 2, 3; if I understand precedence correctly. (S03) my $a = [EMAIL PROTECTED]; my $a = *(1,2,3); # or is this a syntax error? my $a = *(list 1,2,3); my $a = *[1,2,3]; I hope this will emit some kind of too-many-arguments warning in addition to assigning 1 to $a. and I have absolutely no clue about the following: my *$a = @a; my *$a = (1,2,3); 1, I hope. I think the * provides list context to the RHS as * in a sub signature does to the arguments. 1 would be consistent with my ($a) = @a; in Perl 5 my *$a = [1,2,3]; Arrayref. (I don't like @a = []. It makes @a = ([]) be counter-intuitive (parens only group for precedence), and @a = [[]] feels VERY weird. Besides that, it makes @a = $b completely unpredictible if the type of $b is unknown. If it's an arrayref, @a gets all its elements, but if it's a normal value, @a gets only one element. That's a problem for general purpose modules/subs. I guess they could all use @a = [$b], but I find that ugly.) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: MMD as an object.
Rod Adams wrote:
It seems to me that there are several advantages to making a group of
multi with the same short name a single object, of type
MultiSub|MultiMethod, which internally holds references to the all the
various routines that share that short name.
It doesn't have to be junctive because for a multi it's irrelevant
if it's a method or a sub. This distinction is used only at compile
time of the class closure. So I guess there is a
class Multi is Code {...}
in Perl 6.
It would behave like a tied sub (or method), with a .dispatch method to
decide which of the contained routines should be called this particular
time. Manhattan would be the default. However, one can override the
dispatch logic; implementing Luke's Patterns idea, for example.
I see. Something like
use MMD::Manhattan;
use MMD::Symmetric;
use MMD::Pattern;
...
[..] I don't think there has
been syntax introduced thus far that enables this ability. But it's
likely I missed it along the way, like I seem to be missing several
other things lately.
I interpret the hash like syntax fooInt,Array[Int] such that
foo represents the complete set of branches of multi sub foo.
The only thing I wonder is this also supported for calling particular
subs without dispatching: fooInt(17)? Or even partial dispatching
on the sliced multi? This would BTW be something the optimizer would
use as well.
Another thing I haven't seen is how to declare a new multi at runtime.
Non-multi's can be created via C func := sub {...}; , but that's
destructive to any other routines that might have occupied that
namespace.
If the above is correct than it would be more like hash assignment.
There are likely several rough edges in here, and I've by no means
convinced myself that this is the Right Thing, but I thought I'd throw
the idea out there to what others thought of it.
I see some convergence and choices where that is not the case.
MfG
--
TSa (Thomas Sandlaß)
Re: Logic Programming with Rules (and Argument Patterns)
Luke Palmer wrote:
Rod Adams writes:
Or you could avoid the global modifier and write your tests in ( )
blocks instead... after all, that's what it's there for.
I *knew* I had seen a syntax for that before... I just didn't see it
when I scanned S05 for it.
I still want the :z modifier for matching zero length strings. That
makes sense to be global.
The really big problem, however, is the lack of generators.
I'll establish a working definition of generator as something which
offers a possible value, giving the new value each time the expression
is backtracked over, and fails when there are no more values to give.
One generator is the * combinator. It gives the longest string, then
the next shorter, then the next shorter...
I agree that * works that way... when you're matching against a
string... which I'm not. I intend for the basic call to be something
like C ~~ /test(1)/ , or more likely just C /test(1)/ . I
won't care what the current topic is. I'll match the empty string, and
everything that includes it, or nothing at all. My entire rule set will
be a series of really complex zero-length assertions.
Clearly, desirable generators include lazy lists, arrays, and
closures. All of which P6RE supports as ways of attempting different
rules/strings to match against, but not as different values to assign
a given $var to feed into later rules. Capturing assumes a string to
match and capture against. Capturing the null string that I match is
not terribly useful.
The only suggestion I can give for how to do this is by introducing the
hyper operator. I'm very open to other ideas, because this one does not
sit well with me, but it's all I've got at the moment. So, to give an
array as a generator, one could write:
/:a {$x = @values} test($x)/
You could do all of this with a library of rules.
/ $x:=generate(@values) test($x) /
I don't think this does what I want. In this, generate returns a rule
or string of some kind, matches the string being tested, captures what
matches, and then binds the capture to $x.
I have no underlying string, so the match fails right there. I want to
bind/assign to the variable _without_ matching, but _with_ backtracking
and iteration over several values.
I also now notice that I would need a C let in my example above.
How the generate rule is actually written is getting into some rule
engine internal stuff, but we're making sure that the rule engine has
enough hooks to do that.
There were some thoughts in the back of my head about how I actually
wanted a closure to be handled as a generator. I see the need to
initialize it many separate times, once on each forward attempt, can be
repeated if something after it fails, and something before it has an
alternative. But I wanted the basic concept out there before I tried
diving into that kind of detail.
Maybe we could unify the pattern proposal and your generation ideas for logic programming.
There might be unification with logical programming to be had, but I'm
not sure it's with the generation part of things.
@array[$^i] # returns a lazy pattern of everything in @array, bound
# together with the corresponding $i
How is this any different from just @array ?
(@array[$^i]).GENERATE # generates every element of @array
Now, let's just combine that with another array pattern:
@a[$^i] + @b[$^i] # returns lazy pattern of everything in @a
# added to its corresponding element in @b
(@a[$^i] + @b[$^i]).GENERATE # vector sum
Now if we just spell .GENERATE with :
@a[$^i] + @b[$^i]
We have my tensor-hyper proposal back.
This example is easily done as:
@a + @b
But it's also not terribly far removed from my hyperthreader operator in
the Junctions thread (oh, when, oh when is Damian coming back?). There
are differences, but see if that does what you need.
Not to mention that are already taken in that context as q:w//
operators.
Now could have a similar meaning within rules, which would give you
your generator.
# print everything in @array that matches test()
/ $x := [EMAIL PROTECTED] ( test($x) ) { say $x; fail } /
Problems with this:
1) in RE's are already taken for non-capturing meta's. And binding
doesn't work if you don't capture.
2) you're still trying to match the value against the string.
Not really a problem, but I had C test($x) , not C
(test($x)) on purpose. I was feeding into a rule, not a function.
The biggest question is how this interacts with sub calls. We can't
really expect sub calls to be pattern-aware: that puts constraints on
what we're allowed to do in a sub (no side-effect constraints; gee,
those kinds of constraints really go a long way). But test could
certainly implement a GENERATE method:
sub is_prime(
$x will GENERATE { primes() }
)
{
?grep { $_ == $x } primes()
}
The will generate says that the sub can accept a generic pattern and
will fill it in on
Re: MMD as an object.
Thomas Sandlaß wrote:
Rod Adams wrote:
It seems to me that there are several advantages to making a group of
multi with the same short name a single object, of type
MultiSub|MultiMethod, which internally holds references to the all
the various routines that share that short name.
It doesn't have to be junctive because for a multi it's irrelevant
if it's a method or a sub. This distinction is used only at compile
time of the class closure. So I guess there is a
class Multi is Code {...}
in Perl 6.
I wasn't intending it to be junctive. I was just noting that you needed
separate holders for subs and methods, since you shouldn't be able to
stuff a method into a multi sub.
It would behave like a tied sub (or method), with a .dispatch method
to decide which of the contained routines should be called this
particular time. Manhattan would be the default. However, one can
override the dispatch logic; implementing Luke's Patterns idea, for
example.
I see. Something like
use MMD::Manhattan;
use MMD::Symmetric;
use MMD::Pattern;
...
I was thinking more along the lines of :
use MMD::Pattern;
our func is MMD::Pattern;
multi func (...) {...}
multi func (... ...) {...}
multi func (... ... ...) {...}
multi func2 (...) {...}
multi func2 (... ...) {...}
multi func2 (... ... ...) {...}
Where func would get Pattern MMD, and func2 would get Manhattan MMD.
-- Rod Adams
Re: Comma in (sub) traits?
On Mon, Mar 07, 2005 at 08:40:19AM -0800, Larry Wall wrote:
Here are some alternatives you don't seem to have considered:
[...]
my Str sub greeting (Str $person) is export {
Hello, $person;
}
my Str
sub greeting (Str $person) is export {
Hello, $person;
}
Do these declare the subroutine in the lexical scope only?
And I try to believe six foolish consistencies before breakfast each day. :-)
I'm glad you do! I value consistency a lot, but I do realise one has to
choose the _right_ consistencies.
Anyway, thanks for replying. I think I can live with the issue. :) It seems to
center on the fact that Perl 6 allows you to put a lot of stuff into the
signature. This isn't helped much by any potential Haskell-style pattern
matching, at least not in a way I can see.
I still do want to match against constants in the signature, however:
sub foo ( 0 ){ ... }
sub foo ( $bar ) { ... }
So I'm very confused about my opinion on the issue of pattern matching..
Larry
--
wolverian
signature.asc
Description: Digital signature
Re: splat operator and context
Juerd wrote: my @a = 1,2,3; my $a = 1,2,3; These are (my @a = 1), 2, 3; (my $a = 1), 2, 3; if I understand precedence correctly. (S03) right, sure. I vaguely remember something about comma instead of parens being the list constructor, but maybe it was just in my fantasy. and thanks for the other clarifications too. to summarize, I think a decent implementation of splat should do the following: if the argument to unary * is... a normal value force list context and cast to 1-elem list a list nop an array cast to list an arrayrefderef and cast to list (I don't know if the use of cast is appropriate here. looks more like AST munging...). (I don't like @a = []. It makes @a = ([]) be counter-intuitive (parens only group for precedence), and @a = [[]] feels VERY weird. Besides that, it makes @a = $b completely unpredictible if the type of $b is unknown. If it's an arrayref, @a gets all its elements, but if it's a normal value, @a gets only one element. That's a problem for general purpose modules/subs. I guess they could all use @a = [$b], but I find that ugly.) in fact, S03 states: In list context, a scalar reference to an array does not flatten. so I think @a = [1,2,3] should leave you with @a[0] = [1,2,3]. and you should use one of: @a = *$b; @a = @$b; @a = $b[]; to make @a get all the elements of the arrayref in $b. cheers, Aldo
Re: some misc Perl 6 questions
On Tue, Mar 08, 2005 at 10:29:30PM -0800, Darren Duncan wrote: [...] By using subtypes in this way, I could remove a lot of explicit input checking code from my methods, which is great. Also, the where clause is not being repeated for every argument or attribute or variable declaration. (I like SQL domains for the same reasons.) That's very cool. I start to see the appeal of AOP. New question: Is there a way to say that two classes have a privileged relationship, sort of like a marriage, such that each can see and/or change otherwise private attributes in objects of the other class, and yet the attribute list of each class is completely different from the other? Neither of the two objects is a subclass of the other, nor fulfills a role defined by the other. [...] Also, does my request sound like something that would be reasonable to do, or a bad practice to avoid? FYI, in C++, the keyword 'friend' precisely describes the relationship you are discussing (and appears to be homologus to P6 'trusts'). There are good and bad things to be said about these relations but, IME, they are usually used because they have to be in order to achieve certain behavior, not because it is the cleanest or most appropriate way to build the model. Therefore, I would be very cautious about using 'trusts'. YMMV. --Dks -- [EMAIL PROTECTED]
Re: splat operator and context
Aldo Calpini writes: my @a = [1,2,3]; # or does it make @a[0] = (1,2,3)? Yes, @a[0] = [1,2,3]; and I have absolutely no clue about the following: my *$a = @a; my *$a = [EMAIL PROTECTED]; my *$a = (1,2,3); my *$a = [1,2,3]; Those are all illegal. You need to use binding for those to make any sense. my *$a := @a; # $a = @a[0] my *$a := [EMAIL PROTECTED]; # same my *$a := (1,2,3); # $a = 1 my *$a := [1,2,3]; # $a = [1,2,3] Luke
Re: Logic Programming with Rules (and Argument Patterns)
Rod Adams writes: You could do all of this with a library of rules. / $x:=generate(@values) test($x) / I don't think this does what I want. In this, generate returns a rule or string of some kind, matches the string being tested, captures what matches, and then binds the capture to $x. You're right. We probably need something like: / generate($x, @values) test($x) / I don't know when $x is hypotheticalized there, if at all. It needs to be. Maybe we could unify the pattern proposal and your generation ideas for logic programming. There might be unification with logical programming to be had, but I'm not sure it's with the generation part of things. I was decently insane last night. This generator stuff probably isn't going anywhere. It's too abstract, and not precise enough, to be a truly powerful part of the language. Luke
Re: MMD as an object.
Rod Adams writes:
I wasn't intending it to be junctive. I was just noting that you needed
separate holders for subs and methods, since you shouldn't be able to
stuff a method into a multi sub.
Keep in mind that the two following definitions are equivalent:
class A { method foo () {...} }
multi sub foo (A $a) {...}
I think stuffing a method into a multi sub should be just fine.
Luke
List constructors
Hi all, reading [AS]02 left me a bit unclear on list construction. Specifically, as comma still seems to be the list constructor, what do these produce: my $a = (1, 2); # a List object of 1, 2? my $a = (1); # Int 1? my $a = (1,); # List of 1? my ($a) = (1, 2); # Int 1? Or does it need *? my ($a,)= (1, 2); # Same as above, I hope... my ($a, $b) = (1); # $a == 1, I presume Also what do these rather esoteric cases do: my () = (); my $a = (); my ($a) = (); Syntax errors in a few of those are welcome. :) -- wolverian signature.asc Description: Digital signature
Re: some misc Perl 6 questions
On Tue, Mar 08, 2005 at 10:29:30PM -0800, Darren Duncan wrote:
: The biggest change is that, upon a re-reading Synopsis 12 (and 9)
: that was inspired by your above comment, I created some subtypes
: which I now use everywhere; the declarations and some examples of use
: are:
:
: subtype KeyName of Str where { $_.defined and $_ ne '' and $_ !~ m/\W/ }
:
: subtype KeyNameHash of Hash is shape(KeyName) of Str; # keys are of
: type KeyName, values of type Str
:
: subtype PkgName of Str where { $_.defined and $_ ne '' and $_ !~
: m/-[a-zA-Z0-9_:]/ }
:
: subtype PkgNameArray of Array of PkgName;
Those seem to by syntactically correct. What they don't allow you to
distinguish is whether you're using the constraints for MMD pattern matching
or validation--the practical difference being that you want to give
good error feedback if you're doing validation, and you want to silently
fail if you're doing MMD, and let the default routine spit out error
messages. I'm not sure how to solve that problem offhand. Using
different subtypes for ordinary methods vs multi methods seems like
about twice as many subtypes as you need. Hmm, perhaps it's just another
failure context dependency. So you write
subtype Foo of Bar where { .defined or fail Undefined Foo }
and then the ordinary method dispatch can report the error, while
the MMD can suppress it and keep going.
My other quibble is that you seem to be prone to stating things in the
negative for at least two of your three tests here:
subtype KeyName of Str where { $_.defined and $_ ne '' and $_ !~ m/\W/ }
and it seems to me that you could simplify all that to just
subtype KeyName of Str where { m/^\w+$/ }
If that succeeds, you know it's defined and non-null. You might argue that
the m/\W/ short-circuits, but I would counter-argue that failure is
supposed to be the exceptional case, and in every successful call you have
to scan the whole string anyway. Plus it's just easier to understand.
And it lets you write the constraint without explicit reference to $_,
which I will admit was my first motivation in wanting to rewrite your
constraint. The negatives and redundancies I only noticed later.
: class Locale::KeyedText::Message {
:
: has KeyName $.msg_key; # str - the machine-readable key that
: uniquely identifies this message
That's fine.
: has KeyNameHash %.msg_vars; # hash (str,str) - named variables
: for messages, if any, go here
That's not. As pointed out in another message want
has %.msg_vars is KeyNameHash; # hash (str,str) - named variables
or maybe just
has Str %.msg_vars is shape(KeyName); # hash (str,str) - named variables
and avoid cluttering up the symbol table.
: method new( $class: KeyName $msg_key, KeyNameHash ?%msg_vars )
: returns Locale::KeyedText::Message {
: my $message = $class.bless( {} );
: $message.msg_key = $msg_key;
: $message.msg_vars = %msg_vars; # copy list values
: return( $message );
: }
I'd write
return $message;
but that's just stylistic. Creturn is actually a list operator (at
least syntactically), so the parens are optional. But I personally
prefer to view return as more of a keyword than a function.
: ...
:
: class Locale::KeyedText::Translator {
:
: has PkgNameArray @.tmpl_set_nms; # array of str - list of
: Template module Set Names to search
:
: has PkgNameArray @.tmpl_mem_nms; # array of str - list of
: Template module Member Names to search
Here too, I'd probably just write
has PkgName @.tmpl_set_nms;
has PkgName @.tmpl_mem_nms;
: method new( $class: PkgNameArray @set_names, PkgNameArray
: @member_names ) returns Locale::KeyedText::Translator {
method new( $class: PkgName @set_names, PkgName @member_names )
returns Locale::KeyedText::Translator {
or maybe even just
method new( $class: @set_names, @member_names )
returns Locale::KeyedText::Translator {
and rely on the assignment to do the validation. (But having the type
names will work better under MMD.)
And yes, trusts bestows trust on another class. I have no opinion
on its suitability for any particular task. I'm just the language
designer--my job is to shoot you in the foot and make you think
you did it to yourself. :-)
Larry
Re: Comma in (sub) traits?
On Wed, Mar 09, 2005 at 02:15:56PM +0200, wolverian wrote:
: On Mon, Mar 07, 2005 at 08:40:19AM -0800, Larry Wall wrote:
: Here are some alternatives you don't seem to have considered:
:
: [...]
:
: my Str sub greeting (Str $person) is export {
: Hello, $person;
: }
:
: my Str
: sub greeting (Str $person) is export {
: Hello, $person;
: }
:
: Do these declare the subroutine in the lexical scope only?
Yes, but if you're exporting the sub, references to it are potentially
escaping the lexical scope.
: And I try to believe six foolish consistencies before breakfast each day.
:-)
:
: I'm glad you do! I value consistency a lot, but I do realise one has to
: choose the _right_ consistencies.
:
: Anyway, thanks for replying. I think I can live with the issue. :) It seems to
: center on the fact that Perl 6 allows you to put a lot of stuff into the
: signature. This isn't helped much by any potential Haskell-style pattern
: matching, at least not in a way I can see.
:
: I still do want to match against constants in the signature, however:
:
: sub foo ( 0 ){ ... }
: sub foo ( $bar ) { ... }
:
: So I'm very confused about my opinion on the issue of pattern matching..
Well that's just shorthand for:
sub foo ( Int $bar where { $_ == 0 } ){ ... }
sub foo ( $bar ) { ... }
except, of course, you'd have to mark them both as multi before you
get MMD. As it is, you'll get a warning about redefinition.
Larry
Re: Comma in (sub) traits?
On Wed, Mar 09, 2005 at 09:13:27AM -0800, Larry Wall wrote:
: sub foo ( Int $bar where { $_ == 0 } ){ ... }
Well, I'm not sure about that syntax. It might have to be either
sub foo ( Int where { $_ == 0 } $bar ){ ... }
or
sub foo ( $bar of Int where { $_ == 0 } $bar ){ ... }
But if even I fall into that syntactic trap, maybe we'll end up allowing
it as a special DWIM case.
Larry
Re: MMD as an object.
Luke Palmer wrote:
Keep in mind that the two following definitions are equivalent:
class A { method foo () {...} }
multi sub foo (A $a) {...}
Except for attribute access, I think.
For public attrs the accessor is not used and private ones are available:
class A
{
has $.pub = pub;
has $:priv = priv;
method foo ()
{
say pub = $.pub;
say priv = $:priv;
}
}
multi sub foo( A $a )
{
say pub = $a.pub();
}
Another subtlety is that the method call syntax prefers single dispatch:
my $obj = A.new;
$obj.foo();
foo( $obj );
I think stuffing a method into a multi sub should be just fine.
Me too. The above is irrelevant for the call site.
MfG
--
TSa (Thomas Sandla)
Re: List constructors
On Wed, Mar 09, 2005 at 05:56:25PM +0200, wolverian wrote: : Hi all, : : reading [AS]02 left me a bit unclear on list construction. Specifically, : as comma still seems to be the list constructor, what do these produce: : : my $a = (1, 2); # a List object of 1, 2? Same as my $a = [1, 2]; though I'd call in an anonymous array object. I tend to use List to mean the lazy internal data structure that hasn't yet been bound to formal parameters, so it doesn't even know yet which of its arguments might be taken in scalar or list context. By the time the assignment happens above, it knows the whole list is in scalar context, and the scalar comma implies the existence of [...] around it. : my $a = (1); # Int 1? Same as: my $a = 1; : my $a = (1,); # List of 1? my $a = [1]; : my ($a) = (1, 2); # Int 1? Or does it need *? List assignment works as in Perl 5 so the 2 is discarded silently, so yes, you end up with 1 in $a. You only need * when you're using := to do binding (or the equivalent parameter binding of functions/methods). : my ($a,)= (1, 2); # Same as above, I hope... Yes. : my ($a, $b) = (1); # $a == 1, I presume Just like Perl 5. : Also what do these rather esoteric cases do: : : my () = (); I expect the compiler could reasonably either complain or optimize it away. If the right side has side effects: my () = (foo()) it could be reduced to list(foo()) : my $a = (); : my ($a) = (); Same as Perl 5. : Syntax errors in a few of those are welcome. :) Depends on whether you want the edge cases to complain or DWIM with stupid code that is spit out by a code generator. A person would never write my () = (), but a code generator might very well. On the other hand, if someone has a defective text macro, then my (fancy_stuff($a,$b,$c)) = (fancy_stuff($x,$y,$z)); might reduce to my () = () and that would be a difficult kind of error to catch. Well, maybe not, since you'd notice undefined variables pretty quickly... Anyway, I'd lean toward not complaining on such, or maybe just issuing a warning, which the code generator can suppress if it likes. I put it in the same category as Useless use of ... in a void context. Larry
Re: some misc Perl 6 questions
Larry Wall wrote:
and it seems to me that you could simplify all that to just
subtype KeyName of Str where { m/^\w+$/ }
If that succeeds, you know it's defined and non-null.
My view is that typing strings by means of patterns should always
exhaust the string as the above pattern does. I can imagine some
magic that lets
my KeyName @a = First Second;
allow to actually have two entries @a[0] eq First
and @a[1] eq Second by somehow morphing the pattern into
continued matching mode where the next index continues where
the previous left off---and skipping whitespace.
Just an idea...
--
TSa (Thomas Sandlaß)
Re: Decorating Objects with Roles (was Re: Optional binding)
On Tue, Mar 08, 2005 at 05:49:54PM -0800, chromatic wrote: : On Tue, 2005-03-08 at 17:39 -0800, Larry Wall wrote: : : On Tue, Mar 08, 2005 at 03:23:14PM -0800, chromatic wrote: : : : I could make the argument that it should be possible to decorate an : : object with a role. If that means generating a new anonymous class just : : to have a vtable to munge, so be it. : : Er, how is that different from what we already said? : : I didn't think it was, but this explanation used simple words that : didn't rely on me pretending to care about weird mathematics. Well, okay, we're in violent agreement on that, but I was also trying to answer the question about whether and when low-level types like int behave as objects or not. And the basic answer is that they do as long as you don't try to change their storage representation. You probably aren't allowed to say my bit @array is shape(10_000_000); @array[42] = 1; @array[42] does AddExtraAttributes; since a low-level declaration is making certain representations to the optimizer that would be likely be invalid if we suddenly promoted the entire array to holding Bit instead of bit. People start getting a little edgy when they make one function call and their process size unexpectedly goes from 2 megs to 200 megs... On the other hand, while I can see us decorating my bit $maybe = 1; $maybe does AddOnlyMethods; it's also a little problematic (I almost said a bit problematic) to say: my bit @array is shape(10_000_000); @array[42] = 1; @array[42] does AddOnlyMethods; insofar as we'd have to decide whether to decorate the return type of the entire array or not. So maybe we allow decoration of low-level types only for entire containers. The above would be illegal, but this would not: my bit @array is shape(10_000_000); @array[42] = 1; @array does AddOnlyMethods; I'm just trying to strike a balance between practicality and purity here. Larry
Re: some misc Perl 6 questions
On Wed, Mar 09, 2005 at 06:51:43PM +0100, Thomas Sandlaß wrote:
: Larry Wall wrote:
: and it seems to me that you could simplify all that to just
:
: subtype KeyName of Str where { m/^\w+$/ }
:
: If that succeeds, you know it's defined and non-null.
:
: My view is that typing strings by means of patterns should always
: exhaust the string as the above pattern does. I can imagine some
: magic that lets
:
: my KeyName @a = First Second;
:
: allow to actually have two entries @a[0] eq First
: and @a[1] eq Second by somehow morphing the pattern into
: continued matching mode where the next index continues where
: the previous left off---and skipping whitespace.
That's...sick... I love it. *Please* don't tell Damian.
Larry
Re: splat operator and context
On Wed, Mar 09, 2005 at 12:22:37PM +0100, Juerd wrote: :my $a = [EMAIL PROTECTED]; :my $a = *(1,2,3); # or is this a syntax error? :my $a = *(list 1,2,3); :my $a = *[1,2,3]; : : I hope this will emit some kind of too-many-arguments warning in : addition to assigning 1 to $a. Nope, list assignment works just like in Perl 5. The motivation for that in Perl 5 is that returned list values are treated as extensible, and you don't want to break code when the module decides to return a little more information. Think of how caller() has been extended over the years. I'd like to keep that extensibility in Perl 6. However, you can always get stricter argument counting by using binding instead of list assignment, just like with regular parameter binding for function calls. Hmm, next thing you know, someone's going to suggest applying MMD to the left side of a binding. Ow. Larry
Re: MMD as an object.
On Wed, Mar 09, 2005 at 06:19:25AM -0600, Rod Adams wrote:
: I was thinking more along the lines of :
:
:use MMD::Pattern;
:
:our func is MMD::Pattern;
:
:multi func (...) {...}
:multi func (... ...) {...}
:multi func (... ... ...) {...}
:
:multi func2 (...) {...}
:multi func2 (... ...) {...}
:multi func2 (... ... ...) {...}
:
: Where func would get Pattern MMD, and func2 would get Manhattan MMD.
Might be better to define some modifiers other than multi just for the
documentation value, if you're going to have different policies in the
same file like that. I expect that's a rarity, though. Most files
would have a single MMD policy.
But the main problem I see with all this is that MMD is supposedly
combining short names from potentially many different scopes across
*multiple* files, and what do you do if those have different policies?
Plus the OP assumed that all instances of a particular short name are
represented by a single object, which is not necessarily the case,
since different lexical scopes can see different (and potentially
overlapping) sets of multis with the same short name. I suppose one
could get around that by placing an implicit constraint on multis
you're not supposed to be able to see, though. Except that you really
need unique long names as well within one of these objects, and two
completely distinct lexical scopes could have long names that would
be confused with each other. Oh wait, the lexical scope constraint
would be part of the long name, just like any other constraint.
Nevermind. Though maybe you still want to have separate objects
since it's a performance hit to actually evaluate constraints at
run time.
But we still have the problem of conflicting policies in different
scopes. Maybe it's not a problem if we view different policies as just
different ways of marking autogenerated signatures with distance, if
we can come up with a single underlying *scalar* distance measure that
different policies can map multidimensional distances to differently.
Some policies might only choose between 0 and Inf for the scalar
distance, for instance, while others might try to finesse additional
distance values. It seems to me that both the manhattan scheme and
the pure scheme can be subsumed under that, but I could be wrong.
Larry
Re: Logic Programming with Rules (and Argument Patterns)
On Wed, Mar 09, 2005 at 08:56:22AM -0700, Luke Palmer wrote: : I was decently insane last night. This generator stuff probably isn't : going anywhere. It's too abstract, and not precise enough, to be a : truly powerful part of the language. I suspect it's another one of the many things we just try to stay within hailing distance of without trying to solve for 6.0.0. The worst that can happen is that someone later defines use coolness to turn their program into something that doesn't interoperate with standard Perl 6. Then we either bend Perl 6 to where it is interoperable, or someone rewrites all the libraries for coolness. Biologically, it comes down to more sex and a bigger gene pool, or less sex and more speciation and specialization. Sex is fun, but it probably doesn't solve all your problems. Larry
Re: some misc Perl 6 questions
At 10:03 AM -0800 3/9/05, Larry Wall wrote:
On Wed, Mar 09, 2005 at 06:51:43PM +0100, Thomas Sandlaß wrote:
: Larry Wall wrote:
: and it seems to me that you could simplify all that to just
:
: subtype KeyName of Str where { m/^\w+$/ }
:
: If that succeeds, you know it's defined and non-null.
:
: My view is that typing strings by means of patterns should always
: exhaust the string as the above pattern does. I can imagine some
: magic that lets
:
: my KeyName @a = First Second;
:
: allow to actually have two entries @a[0] eq First
: and @a[1] eq Second by somehow morphing the pattern into
: continued matching mode where the next index continues where
: the previous left off---and skipping whitespace.
That's...sick... I love it. *Please* don't tell Damian.
Larry
However, with my particular use I wouldn't want
that to happen; I would want the assignment to
just fail with an error.
If we're going to do what you want, we should
have some way of specifying which of the
behaviours we want using different syntax around
the rule definition.
Incidentally, I noticed that '@a = First
Second' looked a lot like the reverse of what
'$b = @a' did in Perl 5.
-- Darren Duncan
Re: MMD as an object.
Larry Wall wrote:
On Wed, Mar 09, 2005 at 06:19:25AM -0600, Rod Adams wrote:
: I was thinking more along the lines of :
:
:use MMD::Pattern;
:
:our func is MMD::Pattern;
:
:multi func (...) {...}
:multi func (... ...) {...}
:multi func (... ... ...) {...}
:
:multi func2 (...) {...}
:multi func2 (... ...) {...}
:multi func2 (... ... ...) {...}
:
: Where func would get Pattern MMD, and func2 would get Manhattan MMD.
Might be better to define some modifiers other than multi just for the
documentation value, if you're going to have different policies in the
same file like that. I expect that's a rarity, though. Most files
would have a single MMD policy.
Well, my intent was that one should be assigning the policy to a given
multi, not a given scope. If people wish to change the default policy
for multis defined in a given scope, I have no problems with that.
The reason for binding the policy to a given multi was so people could
write a package Foo with a pack of multi sub bar's, using policy
MMD::Random, and export into a different scope, but still have the
caller use the Random policy when calling bar.
But the main problem I see with all this is that MMD is supposedly
combining short names from potentially many different scopes across
*multiple* files, and what do you do if those have different policies?
Plus the OP assumed that all instances of a particular short name are
represented by a single object, which is not necessarily the case,
since different lexical scopes can see different (and potentially
overlapping) sets of multis with the same short name. I suppose one
could get around that by placing an implicit constraint on multis
you're not supposed to be able to see, though. Except that you really
need unique long names as well within one of these objects, and two
completely distinct lexical scopes could have long names that would
be confused with each other. Oh wait, the lexical scope constraint
would be part of the long name, just like any other constraint.
Nevermind. Though maybe you still want to have separate objects
since it's a performance hit to actually evaluate constraints at
run time.
I'm going to interpret this as This is a solvable problem that just
needs a little optimization in the compiler.
Please correct me if this a poor interpretation.
But we still have the problem of conflicting policies in different
scopes. Maybe it's not a problem if we view different policies as just
different ways of marking autogenerated signatures with distance, if
we can come up with a single underlying *scalar* distance measure that
different policies can map multidimensional distances to differently.
Some policies might only choose between 0 and Inf for the scalar
distance, for instance, while others might try to finesse additional
distance values. It seems to me that both the manhattan scheme and
the pure scheme can be subsumed under that, but I could be wrong.
The problem with this is that it requires people to be very cooperative
with how they assign their scalar values. And that feels like asking for
trouble.
I think a better solution is to make it where a given short name can
only have one policy. Trying to assign two policies to the same multi
would be a warning at least, and preferably an error.
There lingers the case of:
use Foo; # from above, exports bar is MMD::Random
multi sub bar {...}
Does this generate an error, since one could expect this particular bar
to be Manhattan? Or does it assume Random, since there's already a bar
in existence? In my head, it currently makes sense to say that the new
bar inherits the Random policy. Only something like:
use Foo;
our bar is MMD::Manhattan;
multi sub bar {...}
Would trigger an error.
-- Rod Adams
Re: Logic Programming with Rules (and Argument Patterns)
Larry Wall wrote: I suspect it's another one of the many things we just try to stay within hailing distance of without trying to solve for 6.0.0. That's cool. I was just relaying the observation that the P6RE was fairly close to being able to implement Logical Programming, which several people seem to be trying to get into Perl in some fashion or another. I can easily wait until 6.2 for this to happen (for now at least). -- Rod Adams
Re: Logic Programming with Rules (and Argument Patterns)
--- Rod Adams [EMAIL PROTECTED] wrote: I was just relaying the observation that the P6RE was fairly close to being able to implement Logical Programming, which several people seem to be trying to get into Perl in some fashion or another. When I get a chance to talk to someone about logic programming, there's frequently an aha! moment where they start to see some of the potential, but then I inevitably get the question if it's so powerful, why ain't it rich? (or something like that.) The answer, I think, is that it's generally not available in the tools that most people use. SQL, regexen and makefiles all dance around logic programming -- well, makefiles sort of stumble -- but if LP was more readily available, people would be more likely to appreciate it. Unfortunately, while Prolog is a piece of cake to learn, this thread made my head hurt. Cheers, Ovid If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Logic Programming with Rules
Ovid wrote: --- Rod Adams [EMAIL PROTECTED] wrote: I was just relaying the observation that the P6RE was fairly close to being able to implement Logical Programming, which several people seem to be trying to get into Perl in some fashion or another. When I get a chance to talk to someone about logic programming, there's frequently an aha! moment where they start to see some of the potential, but then I inevitably get the question if it's so powerful, why ain't it rich? (or something like that.) The answer, I think, is that it's generally not available in the tools that most people use. And I think there's a decent reason for that. They are two fundamentally different ways of processing. One way is the strict following of commands, the other is kind a quest for truth, with only a limited notion of order. I know SWI-Prolog has the ability to merge into C++, but I can't imagine the C++ side being what one would consider a smooth integration. What made me post the thread was the observation that Rules share a great deal of the mentality of LP. Unfortunately, while Prolog is a piece of cake to learn, this thread made my head hurt. I was starting off with getting the basic functionality present. After that, one could write a library of macros to clean it up a great deal. But come to think of it, it almost definitely makes more sense to port Prolog or some other LP engine to Parrot, and then intermingle the languages at that level. I don't think very many of us have fully grasped what Parrot can do for Perl yet. -- Rod Adams
Re: Logic Programming with Rules
--- Rod Adams [EMAIL PROTECTED] wrote: But come to think of it, it almost definitely makes more sense to port Prolog or some other LP engine to Parrot, and then intermingle the languages at that level. I don't think very many of us have fully grasped what Parrot can do for Perl yet. I've been thinking that this would be a fun project for me to cut my Parrot teeth on. Specifically, porting AI::Prolog. However, porting a proper WAM (Warren Abstract Machine) would be a better choice. Now to find the tuits :) Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
using Rules with undefined values (was Re: some misc Perl 6 questions)
At 9:08 AM -0800 3/9/05, Larry Wall wrote:
My other quibble is that you seem to be prone to stating things in the
negative for at least two of your three tests here:
subtype KeyName of Str where { $_.defined and $_ ne '' and $_ !~ m/\W/ }
and it seems to me that you could simplify all that to just
subtype KeyName of Str where { m/^\w+$/ }
If that succeeds, you know it's defined and non-null. You might argue that
the m/\W/ short-circuits, but I would counter-argue that failure is
supposed to be the exceptional case, and in every successful call you have
to scan the whole string anyway. Plus it's just easier to understand.
And it lets you write the constraint without explicit reference to $_,
which I will admit was my first motivation in wanting to rewrite your
constraint. The negatives and redundancies I only noticed later.
Okay, I have gone and replaced the $_ ne '' and $_ !~ m/\W/ with a
m/^\w+$/.
However, unless Perl 6 is different than Perl 5 in its treatment of
undefined values, I still need the .defined part, meaning I end up
with:
subtype KeyName of Str where { .defined and m/^\w+$/ }
In Perl 5, running something like the un-gated $msg_key =~ m/^\w+$/
gives this warning:
Use of uninitialized value in pattern match (m//) at
Locale/KeyedText.pm line 85.
To avoid that, I do defined( $msg_key ) and $msg_key =~ m/^\w+$/ in Perl 5.
You have mentioned before that Perl 6 still treats the use of
undefined values other than in boolean context as an error. So would
applying a Rule against an undefined value produce a warning in Perl
6 or not? (A quick scan of S12 didn't say.)
-- Darren Duncan
