[mercury-users] Handy Programming tool for Mercury.

[Ralph Becket]

Richard A. O'Keefe wrote on 12 May:
> 
> I have two comments.
> First, when I've done things like this by hand in Prolog, I have
> found a *four* argument version
> 	a_varies(Old_Foo, Old_A, New_Foo, New_A)
> extraordinarily useful.

I agree completely.

> For example, to increment a > field, you'd do
> 	a_varies(F0, A0, F, A), succ(A0, A)
> which is of course bidirectional.
> It's not clear to me whether something like this could work
> in Mercury, given that whichever mode of a_varies/4 is chosen
> you want to fill in the changed field _after_ building the
> rest of the record.  Of course, if it were split into two
> unifications,
>     (since
> 	a_varies(foo(A0,B,C,D), A0, foo(A,B,C,D), A)
>      therefore
> 	a_varies(F0, A0, F, A), succ(A0, A)
>      is equivalent to
> 	F0 = foo(A0,B,C,D), F = foo(A,B,C,D), succ(A0, A)
>     )
> then Mercury _would_ be able to handle it by reordering.

This is what the mutable option is for.  If field a is marked
`mutable' then state2m will generate the following:

:- pred chg_a(foo(T), pred(T, T), foo(T)).
:- mode chg_a(in, pred(in, out) is det, out) is det.

chg_a(foo(X, X1, X2, X3), F, foo(Y, X1, X2, X3)) :-
        F(X, Y).

So your example above would reduce to

	chg_a(Foo0, succ, Foo)

assuming succ/2 has only the one `forward' mode.  I think the func
version of this makes things clearer:

:- func chg_a(foo(T), func(T) = T) = foo(T).

chg_a(foo(X, X1, X2, X3), F) = foo(F(X), X1, X2, X3).

> The other comment is that I would have thought that
> 	set_a(New_A_Value, Old_Foo, New_Foo)
> would have fitted into DCG notation rather better, so that
> one could do
> 	change_all(X) -->
> 	    set_a(1),
> 	    set_b('c'),
> 	    set_c("dee"),
> 	    set_d(X).

Again, I'm in complete agreement.  However, many of the library
predicates have the in/out `state' arguments as their first and last
arguments respectively.  I favour having `state' arguments paired
together at the end of the argument list for two reasons:
(1) it makes it possible to exploit DCG notation and
(2) it is generally more useful for higher order programming since
you'd generally rather curry the non-`state' arguments first.

I can think of two ways to make everyone happy.  The first is to
simply recode the generator so that arguments appear in a manner
suitable for DCGs.  The second is to add an option, 'DCG' say, to
select this sort of behaviour.

Any opinions?

Cheers,

Ralph

-- 
Ralph Becket  |  rwab1 at cam.sri.com  |  http://www.cam.sri.com/people/becket.html
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------