Russ Abbott wrote:
I thought that the definition of Permute using thread
bombs (http://cs.calstatela.edu/~wiki/index.php/Courses/CS_460/Fall_2005/What_programmers_should_know_about_Oz#Using_the_thread_bomb
<http://cs.calstatela.edu/~wiki/index.php/Courses/CS_460/Fall_2005/What_programmers_should_know_about_Oz#Using_the_thread_bomb>)
was a very cool little illustration of the power of delayed evaluation
for implementing constraints without using extra constraint mechanisms.
Isn't anyone else tickled by it? Is it a technique that is so standard
that it seems like old hat to everyone else? I'm surprised at lack of
response--other than Raph's somewhat sour message.
Sorry if my message looked sour, that was not the intent.
I think you got the point. In an Oz programmer's eyes it looks way
unthrilling. I feel a bit like a C programmer using double pointers
every day, and looking at another programmer limiting him/herself to
arrays. And I start thinking: "Maybe pointers (huh, I mean constraints)
are not *that* trivial."
However from a pedagogical point of view, I think you are just right.
BTW there is a really bad idea in the definition of function Permute:
the argument is called List. Never call a list List! List is the
standard name of the list module. You'll experience an unexpected
suspension if you ever replace MakeList by List.make!
I also have a suggestion for the double loop in AllDistinct. I tend to
avoid indexed loops, and prefer loops on lists instead. You can write
AllDistinct as
proc {AllDistinct Xs}
%% each element in Xs is different from its successors in Xs
case Xs of X|Xr then
for Y in Xr do
thread X==Y = false end
end
{AllDistinct Xr}
else skip end
end
Cheers,
raph
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
