use Perl

In a node about partially committed transactions, Larry has this to say:

Transactions are not just something that database programmers have to worry about. I think training in transactional thinking tends to fall through the paradigmatic cracks because transactions can't be classified as functions or events or objects. If anything, a transaction is most closely related to the logic programming paradigm, which is undertaught. A transaction can be viewed as a sort of hypothesis that can either be proven or disproven. A partially proven hypothesis is of little use.

This gives me hope that logic programming will be supported in Perl 6. I've seen many mentions of that though no practical examples. I confess that if I have seen practical examples, I've yet to recognize them.

Last night, I did a bit of benchmarking of my code. I used this maze solving code. A query which WProlog solved in .8 seconds (solve(p(8,8),L)) took about 4 times as long in AI::Prolog, despite my code being almost a straight port (I say "almost" because some Java constructs don't translate well into perl.) However, the killer was solve(p(2,2),L). That code has over 84 million unifications and took 131 seconds for WProlog to solve. I stopped the Perl version after 45 minutes. It still hadn't solved it.

I assume this means there is a bug in AI::Prolog. I'll find it, but that was disappointing (I may not have much time over the next week, though, so patches or advice are welcome :). However, there is an upside. First, the memory usage didn't increase, so I wasn't wasting any more memory than WProlog. This is very important as the code is rather memory intensive. More importantly, I've done no optimizations. I won't do anything until I get math implemented, though. It's very important that the basic features get covered. Once they're in, extending it is easy (well, relatively speaking.)

As for optimization, I need to do profiling to know what to target first. For now, though, I'm using hashes where I should use arrays and, curiously, I've discovered that there is no need for the actual code to be OO. I'll leave an OO interface as that solves certain problems, but the original code used no inheritance and the only polymorphism was via multi-method dispatch, something Perl doesn't support anyway. Thus, if internally I skip the OO sugar and convert most (not all) hashes to arrays I'll be in a fantastic position to port the core to C. Now to find a good C hashing algorithm.