All standard Prolog really does is matching up "trees with wildcards in them" with other "trees with wildcards in them". The matching process happens in a very

All standard Prolog really does is matching up "trees with wildcards in them" with other "trees with wildcards in them". The matching process happens in a very specific order and all I/O happens as side effects of small steps in the matching process (I/O operations are implemented as pseudo-constraints, i.e. small "twigs"). As a result, the order you write your constraints ("trees") in in Prolog is /very/ important. Things may not terminate or may blow up the stack or take far, far too long or produce the wrong I/O if the order isn't just right. So standard Prolog is not a nice language. But the idea of specifying constraints and let the computer find solutions is really nice. If only we didn't have those side effects weaved into the constraint solving process. And if we could specify the constraints separately from heuristics on how to solve them (i.e. the order in which to try things). Or if it could handle something more interesting than just "trees with wildcards". mini-Kanren seems to be such a better constraint solving language -- I haven't tried it yet, since I am not done with my Prolog studies but I'm very much looking forward to it. Some Prologs have extensions that ameliorate or completely fix some of the problems with Prologs. GNU Prolog, for example, has an extension to handle other kinds of finite domains (such as integers) than just trees: http://www.gprolog.org/manual/html_node/gprolog055.html http://www.gprolog.org/manual/html_node/gprolog055.html I think the same guy who wrote that code also has a nice paper on how to extend it (efficiently!) to floating-point variables.