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 C'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 $ 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 {$ »=« @values} )>/
which would have the net effect of $/ 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: [Parrot 0.1.2] examples/assembly/ncurses_life.imc error
Matt Diephouse <[EMAIL PROTECTED]> wrote: > Here's a first pass at that. I've changed it to: >- make use of the shortcuts for calling subroutines >- use ".sub" >- use ".local" Thanks, applied. 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 C'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 $ 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 {$ Â=Â @values} )>/
You could do all of this with a library of rules.
/ $:= )> /
How the 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()
/ $ := [EMAIL PROTECTED] <( test($) )> { say $; 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 &foo 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: foo(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ß)
error using gcov2perl
Hi,
I am getting following error when I try to convert my gcov output files
to Devel::Cover output format.
[EMAIL PROTECTED] src]$ cover
Reading database from /home/manishs/tcpflow-0.21/src/cover_db
Argument "\x{2f}\x{30}..." isn't numeric in addition (+) at
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Devel/Cover/DB.pm
line 393.
Argument "\x{2f}\x{30}..." isn't numeric in addition (+) at
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Devel/Cover/DB.pm
line 393.
A
[EMAIL PROTECTED] src]$ gcov -v
gcov (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
Copyright (C) 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[EMAIL PROTECTED] src]$ cover -v
/usr/bin/cover version 0.52
Is there anything obvious that I am missing here.
Any help will be appreciated. I am a perl beginer and could not figure
out whats going wrong in DB.pm.
Thanks and Regards,
Manish
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< "" ~~ // >, or more likely just C< // >. 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 $ 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 {$ Â=Â @values} )>/
You could do all of this with a library of rules.
/ $:= )> /
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 $.
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 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()
/ $ := [EMAIL PROTECTED] <( test($) )> { say $; 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< )> >, not C<
<(test($))> > 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 the spot.
I don't see wh
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: error using gcov2perl
On Wed, Mar 09, 2005 at 05:16:31PM +0530, Manish Sapariya wrote:
> Hi,
> I am getting following error when I try to convert my gcov output files
> to Devel::Cover output format.
>
> [EMAIL PROTECTED] src]$ cover
> Reading database from /home/manishs/tcpflow-0.21/src/cover_db
> Argument "\x{2f}\x{30}..." isn't numeric in addition (+) at
> /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Devel/Cover/DB.pm
> line 393.
> Argument "\x{2f}\x{30}..." isn't numeric in addition (+) at
> /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Devel/Cover/DB.pm
> line 393.
> A
That's very strange. I have line 393 in that file as a comment. Line
390 might produce that error however.
> [EMAIL PROTECTED] src]$ gcov -v
> gcov (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
> Copyright (C) 2001 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> [EMAIL PROTECTED] src]$ cover -v
> /usr/bin/cover version 0.52
>
> Is there anything obvious that I am missing here.
> Any help will be appreciated. I am a perl beginer and could not figure
> out whats going wrong in DB.pm.
Your perl and gcov are both a little old but I wouldn't expect problems
there. You're not somehow running cover with a different release of
Devel::Cover to that which ran gcov2perl?
Other than that, I'm not sure what to suggest. If you can send me
enough to reproduce the problem I'd be glad to look into it.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: [perl #xxxxx] [PATCH] garbage characters in a comment
Indeed curious. The first version was the gzip file, but utf8 encoded. Double weird that it would only happen once. Did you do it the same way both times, Jarkko?
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: error using gcov2perl
My apologies.
The error is at line 390.
[EMAIL PROTECTED] src]$ cover
Reading database from /home/manishs/CodeCoverage/tcpflow-0.21/src/cover_db
Argument "\x{2f}\x{30}..." isn't numeric in addition (+) at
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Devel/Cover/DB.pm
line 390.
I was trying to check whats causing the error and pasted the output of
modified file.
Sorry for inconvinience.
I basically wanted to convert my gcov profiling data to Devel::Cover
format to get unified
coverage report of my c and perl code. To experiment I chose tcpflow
open source c code
and while getting coverage info I ran into this problem.
I can provide you all the gcov file if it helps. (I am not sure whether
I can attach files
when CCing to the list.)
Thanks and Regards,
Manish
On 03/09/2005 06:20 PM, Paul Johnson wrote:
On Wed, Mar 09, 2005 at 05:16:31PM +0530, Manish Sapariya wrote:
Hi,
I am getting following error when I try to convert my gcov output files
to Devel::Cover output format.
[EMAIL PROTECTED] src]$ cover
Reading database from /home/manishs/tcpflow-0.21/src/cover_db
Argument "\x{2f}\x{30}..." isn't numeric in addition (+) at
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Devel/Cover/DB.pm
line 393.
Argument "\x{2f}\x{30}..." isn't numeric in addition (+) at
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Devel/Cover/DB.pm
line 393.
A
That's very strange. I have line 393 in that file as a comment. Line
390 might produce that error however.
[EMAIL PROTECTED] src]$ gcov -v
gcov (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
Copyright (C) 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[EMAIL PROTECTED] src]$ cover -v
/usr/bin/cover version 0.52
Is there anything obvious that I am missing here.
Any help will be appreciated. I am a perl beginer and could not figure
out whats going wrong in DB.pm.
Your perl and gcov are both a little old but I wouldn't expect problems
there. You're not somehow running cover with a different release of
Devel::Cover to that which ran gcov2perl?
Other than that, I'm not sure what to suggest. If you can send me
enough to reproduce the problem I'd be glad to look into it.
Strings - takers wanted
1) ICU should be optional If configured --without-icu the Makefile shouldn't contain ICU stuff, and function calls to ICU (mainly in string_primitives) should be wrapped inside #if PARROT_HAS_ICU. 2) complete src/encoding.c encoding registering, lookup, deinit, and opcodes can follow the scheme used in src/charset.c. 3) trans_encode opcodes to change a strings encoding (s. trans_charset) 4) imcc syntax to specify encoding. I'm thinking of: [charset:][encoding:]"string" so both charset and encoding are optional but can be specified. Usually just one is needed: iso-8859-1:"Tötsch" but utf8:"T\xc3\xb6tsch" Currently only a charset can be specified. 5) implement UTF-16 encodings. Takers wanted, leo
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. > > > > / $:= )> / > > > > > 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 $. You're right. We probably need something like: / , @values)> )> / I don't know when $ 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
Another task for the interested - t/pmc/pmc.t
The test file t/pmc/pmc.t is full of Perl* tests. These should be factored out into t/pmc/perl*.t. The file itself should contain just common PMC functionality tests, like the range or type checks. Thanks, leo
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. C 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
[perl #34391] [TODO] thr-primes.imc should not use PerlUndef
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #34391] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=34391 > Hi, the example 'thr-primes.imc' should not use the PerlUndef PMC, as the Perl* PMCs are being moved into 'dynclasses'. Replacing the PerlUndef PMC with the standard Undef PMC mostly works. However, after 499 is found as a prime, an infinite loop seems to be entered. CU, Bernhard -- /* [EMAIL PROTECTED] */ SMS bei wichtigen e-mails und Ihre Gedanken sind frei ... Alle Infos zur SMS-Benachrichtigung: http://www.gmx.net/de/go/sms
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: committed first Perl 6 port of a non-core CPAN module
Darren Duncan wrote: I didn't say that per se. I said "non-core". As far as I know, Test.pm is a core module. Indeed, hooray! So when can we expect a port of Rosetta? ;-) Sam.
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: committed first Perl 6 port of a non-core CPAN module
At 11:31 AM +1300 3/10/05, Sam Vilain wrote: Indeed, hooray! So when can we expect a port of Rosetta? ;-) Sam. In somewhere between 2 weeks and 2 months. I still have to make some significant changes to the Perl 5 version and get feedback on that, prior to translating it. However, its main dependency SQL::Routine is more or less complete and stable (as of r0.46) and I can start translating it any week now. But first, 1-2 Perl 5 releases go up. Note that the core 'Rosetta' module will quite possibly become a 'Role' in Perl 6 since its main purpose is to define an interface ala the 'DBI' core module. Or maybe 'Role' is the wrong word. Essentially it is an interface definition. -- Darren Duncan
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
Re: Test::Builder->create
On Tue, Mar 08, 2005 at 10:30:36PM -0500, Randy W. Sims wrote:
> What about the "resource aquisition is initialization" approach?
Oh ick no. Means on every subroutine entry you have to call a magic,
mysterious TB method.
> package TB;
> sub new { bless { level => \my $level }, shift }
> sub obtain { TB::_level->new( shift->{level} ) }
> 1;
>
> package TB::_level;
> sub new { ${$_[1]}++; bless { level => $_[1] }, $_[0] }
> sub DESTROY { ${shift()->{level}}-- }
> 1;
>
> package main;
> use Data::Dumper;
>
> my $tb = TB->new;
> print Dumper $tb;
> {
> my $l = $tb->obtain;
> print Dumper $tb;
> {
> my $inner_l = $tb->obtain;
> print Dumper $tb;
> }
> }
> print Dumper $tb;
>
> __END__
Re: Test::Builder->create
On Tue, Mar 08, 2005 at 10:11:09PM -0500, Michael Graham wrote: > Well, all I was going to do was try to shave a few seconds off the > running time of my test suite (which is now climbing up to the 10 minute > mark). I figured I could do the mod_perl thing: preload all my modules > and do most of my setup at startup and then require each of the test > scripts. Dunno if it will be worth the effort but it was something > I was going to play with for a couple of hours. Spend 5 minutes profiling it before you spend a couple hours playing with it. Also this means you must now be very careful about your initialization within your test scripts... all the caveats assocated with attempting to run a script as a daemon.
New Pugs Banner
Autrijus, While I like the current Pugs banner, it's basically a variation of the Hugs banner. So I put my years of art school training to work, and some help from FIGlet I created a new banner. __ / \ __ \ \ \ \/\ \ __ __ __ __ (P)erl6 \ \ __/ \ \/\ \/\ __ \/\ ___\(U)ser's \ \ \/\ \ \_\ \ \ \/\ \ \___ \ (G)olfing \ \_\ \ \/\ \ \/\_\ (S)ystem \/__/ \// \/___/\ \// /\/Version: 6.0.10 (r565) \/___/Copyright 2005 by Autrijus Tang - www: http://autrijus.org/pugs email: [EMAIL PROTECTED] I have also included the patch to src/Help.hs in this mail as well. I did not commit this since I did not want to do it unless you liked it first. - Steve banner.patch Description: Binary data
Re: New Pugs Banner
See also http://use.perl.org/~LTjake/journal/23570 =) -scott On 0, Stevan Little <[EMAIL PROTECTED]> wrote: > Autrijus, > > While I like the current Pugs banner, it's basically a variation of the > Hugs banner. So I put my years of art school training to work, and some > help from FIGlet I created a new banner. > >__ > / \ __ \ > \ \ \/\ \ __ __ __ __ (P)erl6 > \ \ __/ \ \/\ \/\ __ \/\ ___\(U)ser's >\ \ \/\ \ \_\ \ \ \/\ \ \___ \ (G)olfing > \ \_\ \ \/\ \ \/\_\ (S)ystem > \/__/ \// \/___/\ \// >/\/Version: 6.0.10 (r565) >\/___/Copyright 2005 by Autrijus Tang > - > www: http://autrijus.org/pugs email: [EMAIL PROTECTED] > > I have also included the patch to src/Help.hs in this mail as well. I > did not commit this since > I did not want to do it unless you liked it first. > > - Steve >
Re: New Pugs Banner
On Wed, Mar 09, 2005 at 09:39:35PM -0500, Stevan Little wrote: > While I like the current Pugs banner, it's basically a variation of the > Hugs banner. So I put my years of art school training to work, and some > help from FIGlet I created a new banner. Thanks, committed as r567 with a little tweak on the final line (different URL and capitalization). Amazing work! :) Thanks, /Autrijus/ pgpwEgaJ2imtT.pgp Description: PGP signature
Re: [perl #xxxxx] [PATCH] garbage characters in a comment
Robert wrote: >>Indeed curious. The first version was the gzip file, but utf8 encoded. > > > Double weird that it would only happen once. Did you do it the same way > both times, Jarkko? > Yup. Mac OS X, Thunderbird, Attach file, the same file. -- Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There is this special biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
Re: Strings - takers wanted
Steven Schubiger wrote: I'll try, although I've never worked on the core before, but I have a broad knowledge concerning perl guts and implementation. WRT both mails: select one task that is familar to you, having some knowledge of Parrot core is really helpful, then look into the referenced files. E.g. t/pmc/pmc.t starts with a test to create a "PerlInt" PMC. This truely belongs to t/pmc/perlint.t and so on. It's probably better to continue discussion on p6l, as my task descriptions might have been too terse. So if there are any specific questions please ask on the list. It's also good to know, who approaches what to get minimal interfering. Bye, Steven Thanks, leo
Regarding status of Parrot and pure perl Perl6 compiler
What is the current status of the development of the Parrot and the Perl 6 compiler written in Perl? I hope that producing a Perl 6 compiler written in Perl 6 and the Parrot VM is still a high priority and is being actively developed as the premier compiler and VM for the Perl 6 language. A Perl 6 compiler written in Perl 6 I believe is an extremely useful and essential component since it will allow Perl programmers to participate and assist in the development of the Perl 6 compiler. Also where is the CVS/SVn repisitory for Perl6 compiler kept these days? Also, what is the status of Ponie and providing complete interoperability between Perl 5 language and documented XS support and Parrot and Perl 6? I believe that assuring that all Perl 5 language code and all XS code that follows the documented interfaces can be called from Perl 6 and vice versa is extremely important and should be taken seriously. There is a very large body of Perl 5 code and modules and it should remain possible to continue to use them all from Perl 6, and for Perl 5/Ponie to be able to use all Perl 6 modules, so both Perl 5 and Perl 6 can leverage a shared base of modules and leverage the momentum of each others module base and so programs can be written in a hybrid of both Perl 5 and Perl 6 modules. Hopefully it is obvious that the large and rich library of Perl 5 modules needs to be retained and reused on Perl 6, since it would be impractical and innefficient to rewrite them all in Perl 6, and also that Perl 5 programs need to be able to benefit from new Perl 6 modules. Thank you for you attention to this letter, and keep up the great work.
committed whole LKT test suite, improved the module itself
A status report ... I have now ported and committed the whole Locale::KeyedText test suite to Perl 6, and made a bunch of improvements to the Perl 6 version of that module itself. As of now, I see nothing further that needs doing with this module in the short term, except for inevitable small fixes. I have done about the most I could considering that Pugs lacks some of the features required to execute it. Once the necessary features are added, I'll revisit the module and make sure it executes correctly. During this exercise I also discovered issues and made some improvements to the Perl 5 version of the module and its test suite (and also to some other Perl 5 modules of mine), that could be considered a back-port; this should find its way to CPAN shortly under the release number v1.02. This said, I welcome any feedback on the module code, should you see anything in LKT that doesn't look like proper Perl 6 code. In a few weeks, I'll start porting SQL::Routine to Perl 6. This module's Perl 5 code size is about 25 times the size of the Perl 5 Locale::KeyedText (135K vs 6K), so the task is orders of magnitude larger. That said, SQL::Routine is a heavily data-driven module, and a full third of its code line count is a "data dictionary" structure definition; porting that component is trivial. To cut down on the space used in the Pugs distro, I'll forgo moving over most of the SRT POD, which is two-thirds of the SRT distribution size; users can refer to the Perl 5 version for documentation. I want to make some significant improvements to the Perl 5 version (up to v0.57 at least) and other modules that depend on it, and get user feedback on those, prior to porting it. Thanks to the rest of you who are working on driving Perl 6 in some fashion; we're much better off for your contributions. Have a good day. -- Darren Duncan
