Re: Fw: Logic Programming for Perl6 (Was Re: 3 Good Reasons... (typo alert!))
- Original Message From: Brad Bowman [EMAIL PROTECTED] let variables and hypothetical assignments within rules may be a good starting point. Hi Brad, Caveat: I'm also tremendously underqualified to to make serious proposals here. Interesting idea. As I understand hypothetical variables, they are similar in concept to variables in Prolog, but they still have the problem that they really are variables which can be assigned to. Thus, if you have a logical iterator binding values to variables and someone else assigns a value, what then? You can break everything in very mysterious ways. That's why Luke Palmer (I think it was Luke) suggested a twigil for the variables: let $`x = 3; That could be a logic variable which could only be assigned to hypothetically. Any initial assignment to a logical variable would effectively be declaring a constant. 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). Hmm, the only real problem, as you noted, is having to explicitly code the UNDO behavior, but for non-logical behaviors, maybe that's not too bad? Still, what would happen with deleting a file? It's very likely that you can't easily UNDO that, so certain behaviors can't be backtracked over. I wonder how Mercury and Haskell handle issue like this? (I realize Haskell is functional and not logical, but I still don't know how their monads work or if they would be applicable :) 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 Ooh, looks promising. In that scenario, is a hash viewed as an array of pairs? If so, we could potentially have logic programming matching just about any abitrary data structure. 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: 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: 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: Fw: Logic Programming for Perl6 (Was Re: 3 Good Reasons... (typo alert!))
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
