Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!usc!samsung!uunet!mcsun!ukc!edcastle!lfcs!jha From: jha@lfcs.ed.ac.uk (Jamie Andrews) Newsgroups: comp.lang.prolog Subject: Re: Fun. vs. Logic Message-ID: <1181@castle.ed.ac.uk> Date: 23 Nov 89 12:20:09 GMT References: <11500018@hpldola.HP.COM> <11500019@hpldola.HP.COM> Reply-To: jha@lfcs.ed.ac.uk (Jamie Andrews) Organization: Laboratory for the Foundations of Computer Science, Edinburgh U Lines: 130 Is it my imagination, or did Pat Chkoreff thrash through a remarkably similar discussion on fun. vs. logic a couple of years ago, on comp.ai or something? In article <11500019@hpldola.HP.COM> patch@hpldola.HP.COM (Pat Chkoreff) writes: >.... But here's what ticks me off about Prolog: >the danger of NON-TERMINATION is constantly rearing its ugly head. You mean it isn't in functional languages? > I write >a predicate, and then I immediately see how it is riddled with dangers when >I call it in certain ways. I'm not even talking about dangers due to the >lack of the occurs check: there's not a thing I can do about those. As far as I can tell, what you're saying is that the Prolog interpreter is difficult to understand, ie. that its operational semantics is more complicated than that of functional languages. I think we knew that already. We also know that its declarative semantics makes it a much more appropriate language for *certain* problems than any functional language. >I can either document these dangers in comments, mode declarations, or some >other "bag" on the side of the language,... Comments are a "bag" on the side of a language? >.... I suspect that these representations have a >lot in common with what is known as "constructive mathematics". Bing! Five points for Pat. The crowd goes wild. >But how do you determine the modes in which it works, how do you document >them in the language, and what does it mean to the compiler? What would you >end up with? A sort of hybrid functional/logic language? GREAT! I'd fill >out a purchase request for that. Double great! Send it to: Complete Logic Systems, Inc. 741 Blueridge Ave. North Vancouver, BC Canada V7R 2J5 Ask for a copy of Trilogy. >By the way, I'll bet that a lot of predicates which SEEM to have infinitely >many solutions in some directions can be recast so that they don't. The >problem is: it's a major pain in the ass. >Here's an example.... Hmm. So when a logic programmer encounters difficulties like this, he or she writes papers in conferences about them and how to solve them. When a functional programmer encounters difficulties like this, he or she throws up his or her hands and goes back to Interlisp. (No problems there!) I guess that's the real difference between funs. and logic? >Besides, what is "first-order logic" other than Horn clauses? (That's not a >rhetorical question.) Yet another example of the shocking absence of logic from our undergrad curricula. >... But "commitment" is >fundamentally syntactic sugar, whereas "cuts" are not. You could replace >"cuts" with negated conjunctions, but how do you define negation? In terms >of cuts, most likely. Wow! Cuts and negation cause semantic problems! Another five points for Pat. >Now pure Prolog is a slick little language, too. But then you add cuts, >negation, and findall. And then you add type checkers and mode >declarations. And then you invent extended languages. You stick all these >"bags" on the side of Prolog, and the result just doesn't cohere as well as >I'd like. Boy, sounds a lot like Interlisp, eh? -- Well, enough of this; I've obviously been reading too much alt.flame for my own good! The serious point I want to make is that logic progamming languages often have serious problems, many of which Pat has pointed out. But we shouldn't judge the logic programming paradigm by the performance of given systems, or assume that LP researchers are blind to the problems and don't care about solving them. Trilogy is only one of a number of examples of logic programming languages which try to address such problems as irreversability of predicates and the need for functional notation. (Standard disclaimer: Trilogy was developed by my M.Sc. advisor, Paul Voda, and I wrote the user manual, so I'm a little biased.) Functional languages have their problems too. I used the example of Interlisp above, which was about the most extreme example I could think of -- an ad hoc assembler-cum-operating- system masquerading as a functional programming language. That was a good many years ago now, and languages like Scheme and ML have come along since then. The logic programming paradigm is more complex, and has been around for a shorter time, so I don't think we can expect beautiful things like ML to come out of it for a while yet. But ML has problems too. The type system is just too rigid for some people's taste. The absence of EVAL (due to its non-typability) means that certain programming techniques are out. Whatever your distaste for destructive assignment, every programmer writing serious large applications will tell you that it's often an absolute necessity; ML has it but doesn't give it a dynamic semantics. (Trilogy, on the other hand, has it and accounts for it fully.) And, more to the point of this discussion, you can't program search for solutions, and stay as true to the logical structure of the problem, as well as you can in logic programming languages. So the summary of the summary is that all languages have problems; if there was one that didn't, everyone would use that one. You can reel off a litany of problems with a language or a class of languages, but the response should be ``let's integrate things and try to make everything work better'' rather than ``my paradigm is better than yours.'' My apologies if any of the flaming above caused serious offense. :-) --Jamie. jha@lfcs.ed.ac.uk "The sun and the moon, the wind and the rain"