Lambda the Ultimate

that's rather shrill. it's a paper on prolog. the only other language referenced (that i saw) was mercury, in the specific context of adding a more structured approach to the language.

isn't oz intended more as a multi-paradigm language than the next step in prolog's development?

there are two classes of people. those that divide people into classes, and the rest of us.

For many, logic programming ==def Prolog. In fact, many don't realized that there are any logic programming languages other than Prolog.

I think this is bad for the LP paradigm, so it's a myth well worth debunking.

On a more general note, I'd say that it's important to have languages which specialize in a particular form of programming: such as Prolog with the predicate calculus and Erlang with it's messages and threads. It's also important to have languages which are a synthesis of seemingly incompatible paradigms such as Oz which started from a logic based paradigm and extended it's reach far and wide. Mercury is kind of combination of the two in that it seeks to remaily firmly planted in the logic paradigm but reconciles this with functional programming.

anecdotal evidence: i just switched from ocaml to ml because ocaml seemed to offer too many ways of doing the same thing (and this is despite reading and understanding, i believe, the careful description of the way modules and classes complement each other in the ocaml docs). i don't know if i'm getting more stupid as i get older, but it just seemed like too much fuss (vaguely related, and even more vague - does anyone else find that ml feels like c in some strange way? simple, and direct, i think).

Yes, I have the same feeling about O'Caml. I once read that the ML and Clean folks try hard to offer the comfortable features of functional programming while staying close to the machine.

That's kind of abstract, so let me give an example. Suppose that you have a term like "forall X. two * sin(X) * cos(X)". In a logic language or theorem prover, 'two', '*', 'sin' and 'cos' are just symbols that don't have a specific meaning. This means that your prover cannot employ any semantics-based transformations, like rewriting it to "forall X. sin(two*X)". It can only do transformations that are logically valid no matter how you interpret the symbols (for example, turning "z & z" into "z"). But a constraint system that knows that X is a number, *can* do such a rewriting.

Obviously, a constraint programming language can solve much harder complex problems, since it has more transforms at its disposal -- but only *if* your problem falls into one of the constraint domains it knows how to handle. And while the obvious holy grail would be to take a theorem prover and bolt on constraint solvers for every domain you can find, this turns out to be really hard, because you have to take all the interactions of the different domains into account. :(

As a matter of interest, are there any examples of any attempts to harmonise functional and logic programming which come from the functional programming community, or is exclusively from the logic programming community?

Curry is a functional-logic language which, roughly, extends Haskell.

i was thinking more of "crude, with limited libraries", but in a good way....

andrew: that's rather shrill. it's a paper on prolog. the only other language referenced (that i saw) was mercury, in the specific context of adding a more structured approach to the language.

isn't oz intended more as a multi-paradigm language than the next step in prolog's development?

First, what was Peter reacting to? "From the text: The language that comes closest to this ideal is Mercury."

OK, what ideal would that be?

From the text:

For the sake of a balanced presentation let us discuss now Prolog's shortcomings...

• Lack of Types
• Subtle Arithmetic
• Complex semantics of various built-ins
• No Modules and no Objects

... However, no single programming language proposal emerged yet that could be seen as a natural successor to Prolog in which the above shortcomings are properly taken care of. The language that comes closest to this ideal is Mercury.

Given that Oz does address the issues outlined above, and that Peter is aware that the author is aware of Oz, having presented Oz to the author, it seems to me that Peter's critique is warranted. And having spent a lot of time in AI programming circles, which basically means the Lisp/Prolog/ML/Haskell communities, I regret to report that even Peter's "the cosy little world of Prolog-style logic programming" taken as a generalization is quite apt, in my experience. Getting many of these folks to admit that there's anything in the world beyond Horn clauses is like pulling teeth.

andrew quoting Chris Rathman: I'd say that it's important to have languages which specialize in a particular form of programming

andrew: anecdotal evidence: i just switched from ocaml to ml because ocaml seemed to offer too many ways of doing the same thing (and this is despite reading and understanding, i believe, the careful description of the way modules and classes complement each other in the ocaml docs). i don't know if i'm getting more stupid as i get older, but it just seemed like too much fuss (vaguely related, and even more vague - does anyone else find that ml feels like c in some strange way? simple, and direct, i think).

O'Caml (IMHO) really has two foci, one of which is theoretical, and one of which is pragmatic. The theoretical focus was on combining Hindley-Milner-style type inferencing and a class-based object model in a sound, uniform fashion. I think O'Caml succeeds admirably at that, but how much does it affect me as an O'Caml programmer? The answer is: not much at all. Like virtually all O'Caml programmers I know, I don't use objects. So why use O'Caml? Here we come to O'Caml's pragmatic focus: performance. O'Caml is just one of the best, if not the best, performer in the functional language family. As a former professional game developer, I can think about using O'Caml + OCamlSDL + LablGl without bursting out laughing. I can't say the same for any other member of the family.

Going beyond that, I'm not even sure I accept the single-paradigm thesis. The thesis would suggest that Oz has no value beyond being a proof of concept that the various embodied paradigms are strongly isomorphic. I think even a casual glance at CTM, let alone working through it, lends lie to that notion rather quickly: it's more valuable to have all of these tools in one toolbox, and to be able to mix and match tools without wasting energy on their integration, than it is to have a single, highly-focused tool that may or may not be the best tool for the entirety of the job at hand.

and i still see no justification at all for snide comments like cozy little world.

as for ocaml - i moved to mlton, which is also supposed to generate fast code. i'd be interested to know if you have any data comparing the two.

finally, i certainly wasn't arguing that the "single-paradigm thesis" was always, certainly, better. i can see the advantages of oz. i was just giving an anecdotal data point - that i found ocaml cluttered. something that presumably, by your account, most people agree with, since they apparently don't use one of the two ways it provides to structure large scale programming.

i took it to mean that oz should be in that paper when, it seems to me, the author of the paper was not thinking about something like oz at all - presumably pvr was arguing that he *should* have been thinking about something like that (which is a more interesting point, i concede). and i guess there's some previous bad blood because normally pvr's posts are not quite as "emphatic".

maybe we can just forget it? perhaps you all already have?

Let me just say that I do think that you interpret "successor" in a more strict fashion than I do, and I don't believe such an interpretation to be invalid (whatever on earth that would mean). Perhaps the author of the paper intended that interpretation as well.

Unfortunately, I see a great deal of bad blood among language designers and promoters; it's not unusual, and no doubt I've been guilty of it myself at times.

MLton does indeed seem a very nice compiler. I haven't done a head-to-head comparison with O'Caml, but I have to imagine that the combination of your favorite interactive Standard ML environment for development plus MLton for its whole-program analysis yields good results. I'd love to see a combination of MLton and the MLKit's region-based memory management—then perhaps we could even see realistic embedded real-time Standard ML with performance competitive with C/C++.

Thanks for making an effort to maintain a balanced, thoughtful discussion!

Do we need more people that are passionately rigorous, or is it the rigorously passionate that we want?