My little Prolog adventure shed some light on why the language has had even less popularity than such relative box-office duds as LISP and Ada.

What I thought was cool about Prolog was that you could define a function in pieces. In one part of your program, you could have

(taking a little pedagogical license). In another part, you could have:

valid_uri("tag://" + authority + "," + date + ":" + opaque_portion) :- valid_authority_component(authority), iso_date(date);

Now you've got a function "valid_uri" which will tell you whether it's argument is a valid tag or http URI. I thought this was neat because if you don't know everything, you could just write what you know now, and later on, elsewhere, you or someone else could write what you or she knows then. This, I thought, would support a more improvisatory mode of programming.

The problem is that it's just not a good idea to code that way. When your function valid_uri starts misbehaving, you've got to go and hunt down all the places where it's partially defined, which could be anywhere. Likewise, if you need to change the interface, you've got to go hunt those down. Object-oriented programming offers more or less the same feature in a better way. Generally speaking, you can inspect an OOP object to see what type it is; and the method that gets invoked is determined by the type. OOP programmers almost universally keep their stuff together by putting all of a class's methods in one file (and in Java this is forced). That way you if you see that a function Pet::NeedsFeeding misbehaves for some objects, and if you determine that the faulty Pet objects are actually of type Cat, you know where to go to find the code for Cat::NeedsFeeding. This is good. Hunting through your code trying to imagine where it went wrong is bad (cf. GOTO).

So if you have any sense, you'll write your Prolog code with all of the partial definitions together, like this:

nth(n, []) :- throw Empty;
nth(0, H :: T) :- H;
nth(n, H :: T) :- nth(n-1, T);

Funny, but that's a lot like the way Standard ML's pattern matching works on terms:

fun nth(n, []) = raise Empty
  | nth(0, H::T) = H
  | nth(n, H::T) = nth(n-1, T);

Quite the same, eh? But with ML the cases of the pattern match are syntactically required to be together (foiling those runabouts who'd define the cases in different files!) and this pattern-matching construct can be pulled into a local scope without creating a top-level function (or any function at all). One thing this permits is easier debugging, if you need to print out the arguments at the beginning of the function before doing the pattern matching:

fun nth(n, Lyst) = (
    print Int.toString(n) ^ List.toString(Lyst);
    case (n, Lyst) of
        (n, []) => raise Empty
      | (0, H::T) => H
      | (n, H::T) => nth(n-1, T)
);

I never thought I'd say that ML had a feature that's good for debugging, but when it's got a lead over Prolog, you gotta give props where props be due.

I had originally wanted to experiment with Prolog, and with so-called unification, because I wanted to screw around with the OpenMind CommonSense database, and see what kinds of connections it could make. But doing searching/unification on a database of natural language terms is somewhat different from doing it in a programming language context. The core searching/unification algorithm is probably about the same (haven't tried it yet!) but I bet there are lots of pragmatics that make none of the code transfer over. To say the least, you've got the database interface (much unlike my in-memory data structure), and you've got differring notions of what a variable is, and that's not getting into the issues around understanding a parsed natural language structure. that will have to be my next project. Anyway, just wanted to share my realizations about the Prolog approach to programming. I'm a bit ignorant of Prolog outside the theoretical realm, so I might be underestimating its usability; this is just from my experience with a rudimetary faux-prolog interpreter of my own design.