Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!oberon!randvax!narain
From: narain@randvax.UUCP (Sanjai Narain)
Newsgroups: comp.lang.prolog
Subject: Re: Constraint satisfaction in LOG(F)
Message-ID: <1944@randvax.UUCP>
Date: 10 Apr 89 19:22:46 GMT
References: <1632@kulcs.kulcs.uucp> <1942@randvax.UUCP> <1353@murtoa.cs.mu.oz.au>
Organization: Rand Corp., Santa Monica, Ca.
Lines: 39


Thanks for the reference.

>> However, I think logic programming is a good implementation vehicle for
>> mixed "logic"/functional programming.

Precisely what LOG(F) accomplishes.

>> It might be easier to automate this kind of coroutining in a functional
>> environment because more information is known about modes.  However, one
>> of the prices to pay is that tests must explicitly return true or false
>> (rather than just succeeding or failing).  Predicates seem nicer than
>> functions for expressing "generate and test" problems.

In F* the rewriting system underlying LOG(F), there is a notion of failure
even when evaluating function applications.  This is why generate-and-test
programs are as natural in it as in logic.

>> It might be easier to automate this kind of coroutining in a functional
>> environment because more information is known about modes.

There is another reason why functional programming is more elegant
than logic programming, which has to do with manipulation of
infinite structures. Suppose one wants to compute the first 3 elements of
an infinite list l. In logic one may say:

	compute_list_l(L),first(3,L,X).

By coroutining compute_list_l and first, one may solve first(3,X), but
one would never be able to solve compute_list_l fully.  Thus, no theorem
would be proved, so within the strict framework of logic programming
one would not be entitled to infer anything.

In functional programming however, one may evaluate the term:

	first(3,compute_list_l)

which would neatly reduce to its normal form, namely the first 3 elements
of l.