Dear Russ,
Here is an alternative definition of =/3. {UnifyR X Y B} has the
desired semantics B <-> (X = Y).
proc {UnifyR X Y B}
B = {Combinator.'reify' proc {$} X = Y end}
end
Here, unification is defined as a reified constraint: X and Y are
arbitrary values and the 'boolean' value B is an 0/1-integer, i.e. a FD
with the domain 0#1 where 0 represents false and 1 represents true.
(The advantage of this representation for a boolean is that you can
apply arbitrary further FD-int constraints to it. For example, you may
FD.sum a number of 0/1-ints to constrain how many of them are true. See
the docs for more information on reified constraints, e.g., the FD
constraints tutorial).
Combinator.'reify' expects a nullary procedure as argument and
constraints B according whether the body of the procedure is entailed
or not.
Best,
Torsten
--
Torsten Anders
Sonic Arts Research Centre
Queen's University Belfast (UK)
www.torsten-anders.de
On 05.10.2005, at 21:05, Russ Abbott wrote:
I'm confused. My message wasn't talking about backtracking. It only
suggested that it would be useful to define a =/3, which returned true
or false as a value depending on whether its first two argument could
be unified. As a side effect, it would unify those first two arguments
if possible. Since =/2 is defined as part of the base language, this
would not require anything new. It could be defined easily as in my
example.
-- Russ
On 10/5/05, Raphael Collet <[EMAIL PROTECTED]> wrote:
Russ Abbott wrote:
> Define a proc Unify/3 that attempts to unify its first two arguments
and
> sets its third argument to true/false depending on whether not it
succeeds.
>
> local
> proc {Unify X Y Z}
> try X = Y Z = true
> catch _ then Z = false
> end
> end
> A B
> in
> if {Unify [A b a] [a B B]} then {Browse 1#A#B}
> elseif {Unify [A b] [a B]} then {Browse 2#A#B}
> end
> end
>
> It would be even nicer if value.'=' were defined as both =/2 and =/3,
> with the latter being defined as above.
Sorry, the logic part of Oz is not an inclusion of Prolog. Unification
and testing for equality are distinct in Oz. The base model of Oz
(concurrent constraints) requires to distinguish between both.
The statement X=Y tells the constraint X=Y to the store, while X==Y
asks
whether the store entails X=Y. The latter blocks if the constraint
store does not contain enough information.
This behavior combines very naturally with concurrency. Testing
equality cannot tell extra constraints to the store (like Prolog
would).
A "speculative" unification is problematic, because backtracking one
thread would require to backtrack all threads in the system. That is
unreasonable to implement.
Cheers,
raph
_______________________________________________________________________
__________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
_______________________________________________________________________
__________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
