<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div style="" class="markdown-here-wrapper"
data-md-url="Thunderbird">
<p style="margin: 1.2em 0px ! important;">Ok so deterministic and
semi-det functions and predicates requires that there can only
be 1 valid clause (mutually exclusive clauses). The thing I’m
confused about is how to reconcile this requirement with this
simple example:</p>
<pre style="font-size: 0.85em; font-family: Consolas,Inconsolata,Courier,monospace;font-size: 1em; line-height: 1.2em;margin: 1.2em 0px;"><code style="font-size: 0.85em; font-family: Consolas,Inconsolata,Courier,monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;white-space: pre; overflow: auto; border-radius: 3px; border: 1px solid rgb(204, 204, 204); padding: 0.5em 0.7em; display: block ! important;">:- func convert(int) = string.
convert(1) = "good".
convert(_) = "bad".
</code></pre>
<p style="margin: 1.2em 0px ! important;">The above kind of setup
would work in Erlang, in the sense I can pass 1, and then get
“good” and if I pass anything else I would get “bad”. However
such a thing is not possible in Mercury as if I pass 1, both
clauses execute which of course results in an error.</p>
<p style="margin: 1.2em 0px ! important;">I was suggesting that
perhaps a guard clause would help here, so that I can still do
pattern matching and ensure that there was only 1 valid clause
by guarding <em>against</em> 1 on the second convert clause.</p>
<blockquote style="margin: 1.2em 0px;border-left: 4px solid
rgb(221, 221, 221); padding: 0px 1em; color: rgb(119, 119, 119);
quotes: none;">
<p style="margin: 1.2em 0px ! important;">This leads to programs
that tend to use structual induction-like predicate
definitions. </p>
</blockquote>
<p style="margin: 1.2em 0px ! important;">Can you give me some
examples as to what you’re referring to?</p>
<p style="margin: 1.2em 0px ! important;">Thanks,<br>
Roger</p>
<p style="margin: 1.2em 0px ! important;">On 26/10/2014 5:55 PM,
Paul Bone wrote:</p>
<p style="margin: 1.2em 0px ! important;"></p>
<div class="markdown-here-exclude">
<p></p>
<blockquote cite="mid:20141026065517.GU21461@durif" type="cite">
<pre wrap="">On Sun, Oct 26, 2014 at 05:19:56PM +1100, Roger Qiu wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello everybody,
According to this:
<a class="moz-txt-link-freetext" href="http://stackoverflow.com/questions/7466833/mercury-determinism-and-pattern-matching">http://stackoverflow.com/questions/7466833/mercury-determinism-and-pattern-matching</a>
Mercury does not pattern match in a linear order. I'm used to the
pattern matching in Erlang, and it works by going by the first one that
matches. However this does not work in Mercury, all the clauses need to
be fully mutually exclusive.
</pre>
</blockquote>
<pre wrap="">That's not true, at least not that way you've stated it.
_Determinstic_ code requires all clauses to be mutually exclusive. But this
is not true of code that can succeed more than once (multi or nondet code).
It might be best to think of it more like this:
foo([], ...).
foo([X | Xs], ...) :-
something.
foo([X | Xs], ...) :-
something else.
If foo is passed a non empty list _both_ the second and third clauses are
executed. If both of them return results then all of those results may be
returned and foo is nondet or multi. If foo were declared as det then the
compiler would give you an error because a det predicate can't have more
than one answer and therefore it cannot have more than one clause that is
executed (and produce a solution).
So pattern matching is indeed different. The first clause to match _is_
executed, but so is every other matching clause. If there are multiple
clauses (or disjuncts) that could be executed then the procedure must be
multi or nondet. It could be semidet but only if it produces no variable
bindings - however that's another topic.
If you're only writing det code then only one valid clause may exist. In
our experience this is a good habbit/discipline for programmers and makes
program's meanings clearer. This leads to programs that tend to use
structual induction-like predicate definitions.
</pre>
<blockquote type="cite">
<pre wrap="">The pattern matching on the arguments are not sufficient enough to setup
mutually exclusive clauses. I have an idea that perhaps guard statements
on the clauses might help these situations, and allow one to retain
"clause-like" switches instead of defaulting on the if-then-else
pattern. What do you think?
</pre>
</blockquote>
<pre wrap="">I can see how guards could be used in Mercury but I've never felt that the
need for guards is particulary strong in either Mercury or Haskell.
Some prolog-like languages used guards, like Guarded Horne Clauses (yes
that's the language's name). In this case is was to address the
program's evaluation order making it safe for parallel programming. It
wasn't added to the language to help the programmer, but to help the
runtime.
</pre>
</blockquote>
<p></p>
</div>
<p style="margin: 1.2em 0px ! important;"></p>
<div
title="MDH:T2sgc28gZGV0ZXJtaW5pc3RpYyBhbmQgc2VtaS1kZXQgZnVuY3Rpb25zIGFuZCBwcmVkaWNhdGVzIHJlcXVpcmVzIHRoYXQgdGhlcmUgY2FuIG9ubHkgYmUgMSB2YWxpZCBjbGF1c2UgKG11dHVhbGx5
IGV4Y2x1c2l2ZSBjbGF1c2VzKS4gVGhlIHRoaW5nIEknbSBjb25mdXNlZCBhYm91dCBpcyBob3cg
dG8gcmVjb25jaWxlIHRoaXMgcmVxdWlyZW1lbnQgd2l0aCB0aGlzIHNpbXBsZSBleGFtcGxlOjxi
cj48YnI+YGBgPGJyPjotIGZ1bmMgY29udmVydChpbnQpID0gc3RyaW5nLjxicj5jb252ZXJ0KDEp
ID0gImdvb2QiLjxicj5jb252ZXJ0KF8pID0gImJhZCIuPGJyPmBgYDxicj48YnI+VGhlIGFib3Zl
IGtpbmQgb2Ygc2V0dXAgd291bGQgd29yayBpbiBFcmxhbmcsIGluIHRoZSBzZW5zZSBJIGNhbiBw
YXNzIDEsIGFuZCB0aGVuIGdldCAiZ29vZCIgYW5kIGlmIEkgcGFzcyBhbnl0aGluZyBlbHNlIEkg
d291bGQgZ2V0ICJiYWQiLiBIb3dldmVyIHN1Y2ggYSB0aGluZyBpcyBub3QgcG9zc2libGUgaW4g
TWVyY3VyeSBhcyBpZiBJIHBhc3MgMSwgYm90aCBjbGF1c2VzIGV4ZWN1dGUgd2hpY2ggb2YgY291
cnNlIHJlc3VsdHMgaW4gYW4gZXJyb3IuPGJyPjxicj5JIHdhcyBzdWdnZXN0aW5nIHRoYXQgcGVy
aGFwcyBhIGd1YXJkIGNsYXVzZSB3b3VsZCBoZWxwIGhlcmUsIHNvIHRoYXQgSSBjYW4gc3RpbGwg
ZG8gcGF0dGVybiBtYXRjaGluZyBhbmQgZW5zdXJlIHRoYXQgdGhlcmUgd2FzIG9ubHkgMSB2YWxp
ZCBjbGF1c2UgYnkgZ3VhcmRpbmcgKmFnYWluc3QqIDEgb24gdGhlIHNlY29uZCBjb252ZXJ0IGNs
YXVzZS48YnI+PGJyPiZndDsgVGhpcyBsZWFkcyB0byBwcm9ncmFtcyB0aGF0IHRlbmQgdG8gdXNl
CnN0cnVjdHVhbCBpbmR1Y3Rpb24tbGlrZSBwcmVkaWNhdGUgZGVmaW5pdGlvbnMuCjxicj48YnI+
Q2FuIHlvdSBnaXZlIG1lIHNvbWUgZXhhbXBsZXMgYXMgdG8gd2hhdCB5b3UncmUgcmVmZXJyaW5n
IHRvPzxicj48YnI+VGhhbmtzLDxicj5Sb2dlcjxicj48YnI+PGRpdiBjbGFzcz0ibW96LWNpdGUt
cHJlZml4Ij5PbiAyNi8xMC8yMDE0IDU6NTUgUE0sIFBhdWwgQm9uZSB3cm90ZTo8YnI+PC9kaXY+
PGJsb2NrcXVvdGUgY2l0ZT0ibWlkOjIwMTQxMDI2MDY1NTE3LkdVMjE0NjFAZHVyaWYiIHR5cGU9
ImNpdGUiPjxwcmUgd3JhcD0iIj5PbiBTdW4sIE9jdCAyNiwgMjAxNCBhdCAwNToxOTo1NlBNICsx
MTAwLCBSb2dlciBRaXUgd3JvdGU6CjwvcHJlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxwcmUg
d3JhcD0iIj5IZWxsbyBldmVyeWJvZHksCgpBY2NvcmRpbmcgdG8gdGhpczogIApodHRwOi8vc3Rh
Y2tvdmVyZmxvdy5jb20vcXVlc3Rpb25zLzc0NjY4MzMvbWVyY3VyeS1kZXRlcm1pbmlzbS1hbmQt
cGF0dGVybi1tYXRjaGluZwoKTWVyY3VyeSBkb2VzIG5vdCBwYXR0ZXJuIG1hdGNoIGluIGEgbGlu
ZWFyIG9yZGVyLiBJJ20gdXNlZCB0byB0aGUgIApwYXR0ZXJuIG1hdGNoaW5nIGluIEVybGFuZywg
YW5kIGl0IHdvcmtzIGJ5IGdvaW5nIGJ5IHRoZSBmaXJzdCBvbmUgdGhhdCAgCm1hdGNoZXMuIEhv
d2V2ZXIgdGhpcyBkb2VzIG5vdCB3b3JrIGluIE1lcmN1cnksIGFsbCB0aGUgY2xhdXNlcyBuZWVk
IHRvICAKYmUgZnVsbHkgbXV0dWFsbHkgZXhjbHVzaXZlLgo8L3ByZT48L2Jsb2NrcXVvdGU+PHBy
ZSB3cmFwPSIiPgpUaGF0J3Mgbm90IHRydWUsIGF0IGxlYXN0IG5vdCB0aGF0IHdheSB5b3UndmUg
c3RhdGVkIGl0LgoKX0RldGVybWluc3RpY18gY29kZSByZXF1aXJlcyBhbGwgY2xhdXNlcyB0byBi
ZSBtdXR1YWxseSBleGNsdXNpdmUuICBCdXQgdGhpcwppcyBub3QgdHJ1ZSBvZiBjb2RlIHRoYXQg
Y2FuIHN1Y2NlZWQgbW9yZSB0aGFuIG9uY2UgKG11bHRpIG9yIG5vbmRldCBjb2RlKS4KSXQgbWln
aHQgYmUgYmVzdCB0byB0aGluayBvZiBpdCBtb3JlIGxpa2UgdGhpczoKCmZvbyhbXSwgLi4uKS4K
Zm9vKFtYIHwgWHNdLCAuLi4pIDotCiAgICBzb21ldGhpbmcuCmZvbyhbWCB8IFhzXSwgLi4uKSA6
LQogICAgc29tZXRoaW5nIGVsc2UuCgpJZiBmb28gaXMgcGFzc2VkIGEgbm9uIGVtcHR5IGxpc3Qg
X2JvdGhfIHRoZSBzZWNvbmQgYW5kIHRoaXJkIGNsYXVzZXMgYXJlCmV4ZWN1dGVkLiAgSWYgYm90
aCBvZiB0aGVtIHJldHVybiByZXN1bHRzIHRoZW4gYWxsIG9mIHRob3NlIHJlc3VsdHMgbWF5IGJl
CnJldHVybmVkIGFuZCBmb28gaXMgbm9uZGV0IG9yIG11bHRpLiAgSWYgZm9vIHdlcmUgZGVjbGFy
ZWQgYXMgZGV0IHRoZW4gdGhlCmNvbXBpbGVyIHdvdWxkIGdpdmUgeW91IGFuIGVycm9yIGJlY2F1
c2UgYSBkZXQgcHJlZGljYXRlIGNhbid0IGhhdmUgbW9yZQp0aGFuIG9uZSBhbnN3ZXIgYW5kIHRo
ZXJlZm9yZSBpdCBjYW5ub3QgaGF2ZSBtb3JlIHRoYW4gb25lIGNsYXVzZSB0aGF0IGlzCmV4ZWN1
dGVkIChhbmQgcHJvZHVjZSBhIHNvbHV0aW9uKS4KClNvIHBhdHRlcm4gbWF0Y2hpbmcgaXMgaW5k
ZWVkIGRpZmZlcmVudC4gIFRoZSBmaXJzdCBjbGF1c2UgdG8gbWF0Y2ggX2lzXwpleGVjdXRlZCwg
YnV0IHNvIGlzIGV2ZXJ5IG90aGVyIG1hdGNoaW5nIGNsYXVzZS4gIElmIHRoZXJlIGFyZSBtdWx0
aXBsZQpjbGF1c2VzIChvciBkaXNqdW5jdHMpIHRoYXQgY291bGQgYmUgZXhlY3V0ZWQgdGhlbiB0
aGUgcHJvY2VkdXJlIG11c3QgYmUKbXVsdGkgb3Igbm9uZGV0LiAgSXQgY291bGQgYmUgc2VtaWRl
dCBidXQgb25seSBpZiBpdCBwcm9kdWNlcyBubyB2YXJpYWJsZQpiaW5kaW5ncyAtIGhvd2V2ZXIg
dGhhdCdzIGFub3RoZXIgdG9waWMuCgpJZiB5b3UncmUgb25seSB3cml0aW5nIGRldCBjb2RlIHRo
ZW4gb25seSBvbmUgdmFsaWQgY2xhdXNlIG1heSBleGlzdC4gIEluCm91ciBleHBlcmllbmNlIHRo
aXMgaXMgYSBnb29kIGhhYmJpdC9kaXNjaXBsaW5lIGZvciBwcm9ncmFtbWVycyBhbmQgbWFrZXMK
cHJvZ3JhbSdzIG1lYW5pbmdzIGNsZWFyZXIuICBUaGlzIGxlYWRzIHRvIHByb2dyYW1zIHRoYXQg
dGVuZCB0byB1c2UKc3RydWN0dWFsIGluZHVjdGlvbi1saWtlIHByZWRpY2F0ZSBkZWZpbml0aW9u
cy4KCjwvcHJlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxwcmUgd3JhcD0iIj5UaGUgcGF0dGVy
biBtYXRjaGluZyBvbiB0aGUgYXJndW1lbnRzIGFyZSBub3Qgc3VmZmljaWVudCBlbm91Z2ggdG8g
c2V0dXAgIAptdXR1YWxseSBleGNsdXNpdmUgY2xhdXNlcy4gSSBoYXZlIGFuIGlkZWEgdGhhdCBw
ZXJoYXBzIGd1YXJkIHN0YXRlbWVudHMgIApvbiB0aGUgY2xhdXNlcyBtaWdodCBoZWxwIHRoZXNl
IHNpdHVhdGlvbnMsIGFuZCBhbGxvdyBvbmUgdG8gcmV0YWluICAKImNsYXVzZS1saWtlIiBzd2l0
Y2hlcyBpbnN0ZWFkIG9mIGRlZmF1bHRpbmcgb24gdGhlIGlmLXRoZW4tZWxzZSAgCnBhdHRlcm4u
IFdoYXQgZG8geW91IHRoaW5rPwo8L3ByZT48L2Jsb2NrcXVvdGU+PHByZSB3cmFwPSIiPgpJIGNh
biBzZWUgaG93IGd1YXJkcyBjb3VsZCBiZSB1c2VkIGluIE1lcmN1cnkgYnV0IEkndmUgbmV2ZXIg
ZmVsdCB0aGF0IHRoZQpuZWVkIGZvciBndWFyZHMgaXMgcGFydGljdWxhcnkgc3Ryb25nIGluIGVp
dGhlciBNZXJjdXJ5IG9yIEhhc2tlbGwuCgpTb21lIHByb2xvZy1saWtlIGxhbmd1YWdlcyB1c2Vk
IGd1YXJkcywgbGlrZSBHdWFyZGVkIEhvcm5lIENsYXVzZXMgKHllcwp0aGF0J3MgdGhlIGxhbmd1
YWdlJ3MgbmFtZSkuICBJbiB0aGlzIGNhc2UgaXMgd2FzIHRvIGFkZHJlc3MgdGhlCnByb2dyYW0n
cyBldmFsdWF0aW9uIG9yZGVyIG1ha2luZyBpdCBzYWZlIGZvciBwYXJhbGxlbCBwcm9ncmFtbWlu
Zy4gIEl0Cndhc24ndCBhZGRlZCB0byB0aGUgbGFuZ3VhZ2UgdG8gaGVscCB0aGUgcHJvZ3JhbW1l
ciwgYnV0IHRvIGhlbHAgdGhlCnJ1bnRpbWUuCgoKPC9wcmU+Cgo8L2Jsb2NrcXVvdGU+PGJyPg=="
style="height:0;font-size:0em;padding:0;margin:0;"></div>
</div>
<pre class="moz-signature markdown-here-signature" cols="72">--
Founder of Matrix AI
<a class="moz-txt-link-freetext" href="http://matrix.ai/">http://matrix.ai/</a>
+61420925975</pre>
</body>
</html>