For this LP-style solution, Oz and Prolog are virtually identical. My Oz program could be translated fairly mechanically into a Prolog program, which could be translated fairly mechanically back into an Oz program.
Oz is nice in that it has functional notation, which this program used in every call to MakeNeighbor. Those would each have required an extra line and an extra variable in Prolog. I used ForAll in Neighbor, but forall/3 in Prolog would have done the same thing.
I didn't have to use negation in this program. So I'm not sure how I would do it. (I haven't needed negation in any of my Oz programs so far.) But here's where it might have been important.
In an earlier version of the solution, I found that I needed to ensure that no property value was used twice. (It isn't needed in the final solution because I noticed that the original problem statement included the fact that someone drinks water. The direct LP translation of the FD problem doesn't include that!) Here's what I wrote to ensure that no property value is used more than one.
proc {AllDistinct Ns}
{FoldR
Ns
fun {$ N OldPVs} PVs in
PVs = {Record.toList N}
{List.partition PVs fun {$ PV} {List.member PV OldPVs} end nil _}
{Append PVs OldPVs}
end
nil
_}
end
{FoldR
Ns
fun {$ N OldPVs} PVs in
PVs = {Record.toList N}
{List.partition PVs fun {$ PV} {List.member PV OldPVs} end nil _}
{Append PVs OldPVs}
end
nil
_}
end
Notice that I used List.member instead of IsMember. I did that because I needed a function that would return true or false. IsMember doesn't do that. It just succeeds or fails. If List.member had not been defined, I'm not sure how I would have written that using IsMember. It would be a shame to have to write a brand new proc that returns true or false depending on whether IsMember succeeds or fails.
Does that even work in Oz? Can I write a meta-predicate Fail which I can use something like the following.
local
fun {Fail P}
try P true
catch _ then false
end
end
proc {IsMember X Xs}
H Tail in
Xs = H | Tail
choice H = X [] {IsMember X Tail} end
end
in
{Browse {SearchAll
proc {$ Answer}
X Y in
Answer = X#Y
{List.partition [a b c d]
fun {$ X} {Fail {IsMember X [b c]}} end
X Y}
end}}
end
I apologise that the above doesn't work. I don't have time right now to get it running. When I try the above I get a syntax error complaining about P being an _expression_ in a statement position in Fail. How can I get around this?
In any event, the immediate point is that this attempts to convert succeed/fail into true/false. Is there a good way to do that in Oz?
Probably the more important point, at least for me, is that emacs is not a very good IDE. I like working in Eclipse and Java. Going back to emacs seems like going back to the middle ages. Fifteen years ago I was pretty good with emacs. But I've forgotten it all, and I don't want to learn it again. Besides Eclipse gives you so much more than emacs would anyway.
In my opinion, the most important thing that should be done for Oz is to build an Eclipse plugin for it so that one could develop software using modern techniques--including a debugger that works inside SearchAll.
The actual code for my two LP versions of Zebra is not that complex. But it took me far far too long to get it to work. The problem wasn't with the code. It was with the IDE. In my opinion, a poor IDE is a death sentence for a programming language these days. In that regard, Oz is no worse off than Prolog. The both need modern IDE's.
Now that Eclipse exists as a framework for IDE's why not use it and build a good Oz IDE in Eclipse.
-- Russ
On 10/8/05, Raphael Collet <[EMAIL PROTECTED]> wrote:
Russ Abbott wrote:
> Here
> ( http://cs.calstatela.edu/~wiki/index.php/Courses/CS_460/Fall_2005/Notes_for_Oct_8#Second_Zebra_solution
> < http://cs.calstatela.edu/~wiki/index.php/Courses/CS_460/Fall_2005/Notes_for_Oct_8#Second_Zebra_solution>)
> is my version of Zebra using the list of records representation:
>
> Nb = [neighbor(color:white dring:juice ...) neighbor(color:blue
> drink:tea ...) ...]
>
> It seems quite intuitive to me.
Indeed, this one looks more "natural" in logic programming style than
the FD-like coding. Each programming style favours certain kinds of
problem modeling.
The interesting question is: from your point of view, how does Oz
compare to Prolog, for *that* solution of the problem?
Cheers,
raph
_________________________________________________________________________________
mozart-users mailing list [email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
--
_____________________________________________
Professor, Computer Science
California State University, Los Angeles
o Check out my blog at http://russabbott.blogspot.com/
_________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users
