Re: Fw: Logic Programming for Perl6 (Was Re: 3 Good Reasons... (typo alert!))
Hi, I used AI::Prolog once briefly, and that's the extent of my logic programming knowledge. There do seem to be a few Perl 6 features that may be useful for logic programming, although I'm not really qualified to judge. How would one assert facts and rules in Perl6? How would one know that a variable is a logic variable and not a normal one? Assignment to a logic variable which is still subject to rebinding could break code. On the other hand, using normal variables for logic variables could let us use objects for them and I think this might get us contraint programming (long story). "let" variables and "hypothetical" assignments within rules may be a good starting point. Hypothetical variables are mentioned here: http://dev.perl.org/perl6/doc/design/syn/S04.html#Definition_of_Success While they usually occur within rules, hypothetical assignments can be to a target variable: http://dev.perl.org/perl6/doc/design/syn/S05.html#External_aliasing and "let" can now be used in any other closure. More details in A05: http://dev.perl.org/perl6/doc/design/apo/A05.html#Hypothetical_Variables,_er_Values There's also the question of non-logical behavior in logic programming. What happens if you try to use math in Perl6 logic programming? Generally speaking, math is "non-logical" in the sense that it's used in Prolog (see the aforementioned article). Opening and reading from a file is also non-logical (you can't backtrack over it). How are those issues to be handled? Closures may have an "undo" trait which should be written to revert the side-effects of the closure when it receives an UNDO control exception (the block fails, see Definition of Success above). http://dev.perl.org/perl6/doc/design/syn/S04.html#Closure_traits For file reading the undo would seek back to the correct point. This does require the programmer to code the undo operation, which may not be possible (with non-seekable handles for examples). Are there other languages that blend logic and imperative styles that can be stolen from? Perl6 grammars may be able to assist with this, but grammars (as far as I can tell) are still based around strings and not data structures. Admittedly, Prolog is essentially a fancy string rewriting system, but it's not clear how the grammars would be applied to this problem. There's some information about this in S05, with more info promised: http://dev.perl.org/perl6/doc/design/syn/S05.html#Matching_against_non-strings Brad -- Dohaku's wife suffered some severed fingers. Dohaku's wound was a severed neck bone, and since only his throat remained intact, his head hung down in front. Now boosting his head up with his own hands, Dohaku went off to the surgeon's.-- Hagakure http://bereft.net/hagakure/
Re: packages vs. classes
--- Stevan Little <[EMAIL PROTECTED]> wrote: > On 5/23/06, Sam Vilain <[EMAIL PROTECTED]> wrote: > > People can diverge completely with completely incompatible > > metaclasses that don't .do those roles, the only side effect > > of which being that people who write code for the standard > > Perl 6 metamodel will be incompatible, and maybe some ways > > of setting up the class won't work without another layer of > > trickery. I *think* that's what you're getting at. Of course, > > it shouldn't be prohibited just because it smells. > > I am not sure I like this, incompatible metaclass issues are really > really tricky and hard to debug (aka - smells *really* bad). And the > system needed to support them really can bloat the metamodel > internals in a nasty way. There are several papers out there on the > subject, none of which IMO provide a satisfactory solution. The > problem then becomes compounded by introducing the Python and Ruby > metamodels into the fray. Having a single compatability level made > out of roles is not that much of a restriction really, and keeps > much of the system interals clean and orderly. It also makes it > much easier for use to add new metamodels from other languages by > just by writing a layer to map to the core metamodel roles. I'd say a more standard system is much better, so long as we leave a standard set of hooks by which someone can insert a nonstandard setup. A small API isn't a huge bloat, and is worth it, though I agree that a full system might actually be counterproductive. And by all that I've seen lately, the whole language is pretty malleable that way; those who really want the nonstandard model can take the small overhead hit of whatever internal shenanigans they need to implement, and just about anything like that can be stuffed into a module now, can't it? So the upshot is, a standardized metamodel seems like the way to go to me And Congrats again, gramps. May your new little one be as loved as the language you've also labored so much to guide to maturity. >;o] Paul "on est aisément dupé par ce qu'on aime" -- Molière (one is easily fooled by that which one loves) "Increase in wisdom can be measured accurately by the corresponding decrease in anger." -- Friedrich Nietzsche "There are trivial truths and there are great Truths. The opposite of a trival truth is obviously false. The opposite of a great Truth is also true." -- Neils Bohr "Real friends are those whom, when you must inconvenience them, are bothered less by it than you are." -- me. =o) Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a thumb. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: packages vs. classes
On 5/23/06, Sam Vilain <[EMAIL PROTECTED]> wrote: Right, but we should really ship with at least a set of Meta Object Protocol Roles, that covers the core requirements that we will need for expressing the core types in terms of themselves; - classes and roles - attributes and methods - subsets (ie constraints/subtypes) - generics (including, by induction, nested generics) I *think*, at this point, that's all that are necessary. I would maybe add a protocol for instance creation. We have recently added that to Moose, and found it very useful in terms of abstracting out the kind of instance storage used (ARRAY based storage currently Just Works given the right Instance sub(meta)class). I see the instance protocol as being an important component of cross language runtime thing. If all instances conform to, or can be made to conform to, an base instance protocol, making Perl 6 objects which inherit from Python objects should be fairly easy. People can instantiate the roles that cover all that to an actual metaclass in whatever way they like (eg, Moose::Meta::Class->isa(Class::MOP::Class)), but not having to detect the type and then figure out how to talk to it for at least the core of the object system would be good. I think the roles can serve as the core interface nessecary to function with the base object system. As long as my metaclass .does() the correct role, it should be able to function in the object system. Of course the old garbage-in garbage-out rule applies, we should give you enough meta-rope to shoot your meta-self in your meta-foot. People can diverge completely with completely incompatible metaclasses that don't .do those roles, the only side effect of which being that people who write code for the standard Perl 6 metamodel will be incompatible, and maybe some ways of setting up the class won't work without another layer of trickery. I *think* that's what you're getting at. Of course, it shouldn't be prohibited just because it smells. I am not sure I like this, incompatible metaclass issues are really really tricky and hard to debug (aka - smells *really* bad). And the system needed to support them really can bloat the metamodel internals in a nasty way. There are several papers out there on the subject, none of which IMO provide a satisfactory solution. The problem then becomes compounded by introducing the Python and Ruby metamodels into the fray. Having a single compatability level made out of roles is not that much of a restriction really, and keeps much of the system interals clean and orderly. It also makes it much easier for use to add new metamodels from other languages by just by writing a layer to map to the core metamodel roles. - Stevan
Re: [svn:perl6-synopsis] r9310 - doc/trunk/design/syn
> "l" == larry <[EMAIL PROTECTED]> writes: l> Log: shouldn't that be "grandpa's log, earth date 200605252055"? l> Deployment of julian++ at 200605252055, 8`lb + 7`oz, 20`in. l>Ref: http://www.wall.org/cgi-bin/photo/index.cgi?mode=view&album=/pix/Julian so when does he get his commit bits? :) congrats, grandpa! uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
[svn:perl6-synopsis] r9310 - doc/trunk/design/syn
Author: larry Date: Fri May 26 09:57:12 2006 New Revision: 9310 Modified: doc/trunk/design/syn/S06.pod Log: Clarifications of inner type from sam++. Deployment of julian++ at 200605252055, 8`lb + 7`oz, 20`in. Ref: http://www.wall.org/cgi-bin/photo/index.cgi?mode=view&album=/pix/Julian Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podFri May 26 09:57:12 2006 @@ -13,9 +13,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 21 Mar 2003 - Last Modified: 24 May 2006 + Last Modified: 26 May 2006 Number: 6 - Version: 36 + Version: 37 This document summarizes Apocalypse 6, which covers subroutines and the @@ -1405,14 +1405,20 @@ my $spot of Dog; In either case this sets the C property of the container to C. -Subroutines have a variant of the C property, C, that -sets the C property instead. The C property specifies -a constraint to be checked upon calling C that, unlike the C -property, is not advertized as the type of the routine: - -our Animal sub get_pet() {...} -sub get_pet() returns Animal {...} -sub get_pet() of Animal {...} + +Subroutines have a variant of the C property, C, that sets +the C property instead. The C property specifies a +constraint (or perhaps coercion) to be enforced on the return value (either +by explicit call to C or by implicit fall-off-the-end return). +This constraint, unlike the C property, is not advertised as the +type of the routine. You can think of it as the implicit type signature of +the (possibly implicit) return statement. It's therefore available for +type inferencing within the routine but not outside it. If no inner type +is declared, it is assumed to be the same as the C type, if declared. + +sub get_pet() of Animal {...} # of type, obviously +our Animal sub get_pet() {...} # of type +sub get_pet() returns Animal {...} # inner type A value type on an array or hash specifies the type stored by each element: @@ -1539,19 +1545,21 @@ =head2 Return types -On a scoped subroutine, a return type can be specified before or -after the name. We call all return types "return types", but distinguish -two kinds of return type, the C type from the C type, because -the C type must be an "official" named type, while the C type -is merely applied as a constraint to what may be returned by the routine. +On a scoped subroutine, a return type can be specified before or after +the name. We call all return types "return types", but distinguish +two kinds of return type, the C type and the C type, +because the C type is normally an "official" named type and +declares the official interface to the routine, while the C +type is merely a constraint on what may be returned by the routine +from the routine's point of view. +our sub lay returns Egg {...} # inner type our Egg sub lay {...} # of type -our sub lay returns Egg {...} # where type our sub lay of Egg {...} # of type our sub lay (--> Egg) {...}# of type +my sub hat returns Rabbit {...}# inner type my Rabbit sub hat {...}# of type -my sub hat returns Rabbit {...}# where type my sub hat of Rabbit {...} # of type my sub hat (--> Rabbit) {...} # of type @@ -1559,14 +1567,14 @@ namespace (module, class, grammar, or package), as if it's scoped with the C scope modifier. Any return type must go after the name: -sub lay returns Egg {...} # where type +sub lay returns Egg {...} # inner type sub lay of Egg {...} # of type sub lay (--> Egg) {...}# of type On an anonymous subroutine, any return type can only go after the C keyword: -$lay = sub returns Egg {...}; # where type +$lay = sub returns Egg {...}; # inner type $lay = sub of Egg {...}; # of type $lay = sub (--> Egg) {...};# of type @@ -1581,12 +1589,12 @@ The return type may also be specified after a C<< --> >> token within the signature. This doesn't mean exactly the same thing as C. The C type is the "official" return type, and may therefore be -used to do type inferencing outside the sub. The C type only +used to do type inferencing outside the sub. The C type only makes the return type available to the internals of the sub so that the C statement can know its context, but outside the sub we don't know anything about the return value, as if no return type had been declared. The prefix form specifies the C type rather than -the C type, so the return type of +the C type, so the return type of my Fish sub wanda ($x) { ... } @@ -1598,7 +1606,7 @@ my sub wanda ($x) returns Fish { ... } -It is possible for the C type to disagree with the C type: +It is possible for the
Re: Fw: Logic Programming for Perl6 (Was Re: 3 Good Reasons... (typo alert!))
From a language standpoint, I think this is a great solution. As Jonathan suggests, have a default knowledge base that is referenced by default, with the option to declare more knowledgebases. Each one can have facts set and queries exectued seperately. I have only a passing knowledge of Prolog, but I think this should handle Logic programming, as long as Perl facts and queries have the same elements as their Prolog equivalents. From an internal standpoint, I think this may be slightly harder to do. While this is a great syntax for the problem, some of the other issues David mentioned were internals oriented. Obviously, that's beyond this list, but the internal implementation of this may be a bit trickier. Sage On 5/25/06, Jonathan Lang <[EMAIL PROTECTED]> wrote: Hmm... How about this: Treat each knowledge base as an object, with at least two methods: .fact() takes the argument list and constructs a prolog-like fact or rule out of it, which then gets added to the knowledge base. .query() takes the argument list, constructs a prolog-like query out of it, and returns a lazy list of the results. There would be a default knowledge base, meaning that you wouldn't have to explicitly state which knowledge base you're using every time you declare a fact or make a query. -- Jonathan Lang
Re: perl.perl6.users on nntp.perl.org (was: Logic Programming for Perl6)
mAsterdam schreef: > Ovid: >> Larry pointed out that this topic is better suited >> for perl6-language instead of perl6-users, so I'm >> forwarding this along. > > Is there a reason perl6-users isn't fed through to nntp.perl.org ? > Maybe it is but I don't know to which group? news://nntp.perl.org/perl.perl6.users There is also perl.perl6.announce perl.perl6.compiler perl.perl6.documentation perl.perl6.internals perl.perl6.language -- Groet, Ruud
perl.perl6.users on nntp.perl.org (was: Logic Programming for Perl6)
Ovid wrote: Larry pointed out that this topic is better suited for perl6-language instead of perl6-users, so I'm forwarding this along. Is there a reason perl6-users isn't fed through to nntp.perl.org ? Maybe it is but I don't know to which group?