Thanks. That clears it up. I hadn't realized (or didn't remember) that variables in patterns are implicitly declared as new local variables.
Also, it seems that you can unify variables in pattern arbiters with variables in patterns. You just can't unify variables in pattern arbiters with non-variables in patterns.
local A B
proc {One X}
case X of Z then Z = a end
end
in
{One A}
{Browse A}
end
produces 'a' as a value for A.
On 9/27/05, Fred Spiessens <[EMAIL PROTECTED]> wrote:
I think part of the confusion stems from ignoring the fact that the
case X of Y then.... end
statement DECLARES the variable Y
your procedure Pair can thus be rewritten like:
proc{Pair X Y}
case X of Z then {Browse 'in pair'#X#Z} end
end
This gives exactly the same results. The case always succeeds because
it is equivalent to:
case X of _
If you want to re-use the Y variable in the case statement, you have
to do it like this:
proc{Pair X Y}
case X of !Y then {Browse 'in pair'#X#Y} end
end
But the ! also causes the case statement to wait until Y becomes bound.
cheers,
Fred.
On 26 Sep 2005, at 23:49, Russ Abbott wrote:
> If you replace
> case X of Y then {Browse 'in pair'#X#Y} end
> with simple unification
> X = Y
> to get
> local A B
> proc {Pair X Y}
> X = Y
> end
> in
> {Pair a A}
> {Browse 1#A#B}
> {Pair A b}
> {Browse 2#A#B}
> {Pair A B}
> {Browse 3#A#B}
> A = z
> {Browse 4#A#B}
> end
>
> the output is
> 'in pair'#a#a
> 1#a#_
> followed by a tell a = b exception. This is what I would expect
> from straight unification.
>
> But then I tried:
> local A B
> proc {Pair X Y}
> {Browse 'before case'#X#Y}
> case X of Y then {Browse 'after case'#X#Y} end
> end
> in
> {Pair A b}
> {Browse 1#A#B}
> {Pair a A}
> {Browse 2#A#B}
> {Pair A B}
> {Browse 3#A#B}
> A = z
> {Browse 4#A#B}
> end
> and got
> 'before case'#z#b
> 'after case'#z#z
> 1#z#_
> 'before case'#a#z
> 'after case'#a#a
> 2#z#_
> 'before case'#z#_
> 'after case'#z#z
> 3#z#_
> 4#z#_
> How did Y change from b to z between the first line and the
> second? Similar questions arise for the rest of the execution. How
> should this be understood? Or is there a bug somewhere in the
> implementation ?
>
> -- Russ
> _____________________________________________
> Russ Abbott
> Professor, Computer Science
> California State University, Los Angeles
> o Check out my blog at http://russabbott.blogspot.com/
>
>
> On 9/26/05, Russ Abbott <[EMAIL PROTECTED]> wrote:
> Here's an extension of the program below, which I admit has me
> completely confused.
> local A B
> proc {Pair X Y}
> case X of Y then {Browse 'in pair'#X#Y} end
> end
> in
> {Pair a A}
> {Browse 1#A#B}
> {Pair A b}
> {Browse 2#A#B}
> {Pair A B}
> {Browse 3#A#B}
> A = z
> {Browse 4#A#B}
> end
>
> The output is
> 'in pair'#a#a
> 1#z#_
> 'in pair'#z#z
> 2#z#_
> 'in pair'#z#z
> 3#z#_
> 4#z#_
>
>
>
> On 9/26/05, Russ Abbott <[EMAIL PROTECTED] > wrote:
> Well, I'll admit to being a bit mind twisted. (Actually I like that
> state.) I learned prolog about 2 decades ago and have not kept up
> with newer developments. I think in terms of Edinburgh prolog. I
> use setof/3, etc. (But I don't do asserts.) But I'm still not
> convinced that the way case is defined is the best approach.
>
> For example, on p 80 in CTM we see that
> local <pattern> = <_expression_> in ... end
> does full unification even though it is not recommended to use it
> that way.
>
> In
> local X in
> case X of 3 then {Browse X} end
> case 3 of X then {Browse X} end
> end
> the first of these suspends while the second succeeds. And in
> local A
> proc {Pair X Y}
> case X of Y then {Browse X#Y} end
> end
> in
> {Pair 3 A}
> {Pair A 3}
> end
> both succeed although they give different results: 3#3 and _#_
> respectively! (Why didn't the second call not suspend, and since
> it didn't suspend, why didn't it bind Y to 3?)
>
> I still think the semantics of case should be re-analyzed.
>
> -- Russ
> _____________________________________________
> Russ Abbott
> Professor, Computer Science
> California State University, Los Angeles
> o Check out my blog at http://russabbott.blogspot.com/
>
>
> On 9/26/05, Raphael Collet <[EMAIL PROTECTED] > wrote:
> Russ Abbott wrote:
> > One solution would be to have two versions of the case statement
> (case
> > and caseunify), one that suspends if the pattern aribiter is not
> > completely bound and one that does full unification.
>
> No, this is definitely not a good idea. Prolog does pattern
> matching by
> *speculative* unification! It works only because Prolog is
> *sequential*
> and search is built-in.
>
> Oz is concurrent, and search is encapsulated. The latter makes
> that we
> don't need a "cut" statement in Oz. Unification is more the
> functional
> style one.
>
> > Not only would
> > that offer a nice feature, it would solve the problem that new-
> comers
> > tend to get confused about this. If both language features were
> > presented together in the documentation, there would be no
> confusion.
>
> Most newcomers are not from the Prolog world, and many find the "case"
> statement quite natural. Prolog programmers are sometimes a bit
> mind-twisted, and need some rehabilitation to normality ;-) I am sure
> you will quickly get used to Oz.
>
> Cheers,
> raph
>
> ______________________________________________________________________
> ___________
> mozart-users mailing list mozart-
> [EMAIL PROTECTED]
> http://www.mozart-oz.org/mailman/listinfo/mozart-users
>
> ______________________________________________________________________
> ___________
> mozart-users mailing list mozart-
> [EMAIL PROTECTED]
> http://www.mozart-oz.org/mailman/listinfo/mozart-users
>
--------------------
Fred Spiessens
Reseacher Software Security
Université catholique de Louvain
Louvain-la-Neuve Belgium
[EMAIL PROTECTED]
http://www.info.ucl.ac.be/people/fsp/fred.html
--
_____________________________________________
Russ Abbott
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
