[m-dev.] EDCGs and Higher Order Programming

Ralph Becket rbeck at microsoft.com
Thu Jan 27 22:48:25 AEDT 2000


> From: Fergus Henderson [mailto:fjh at cs.mu.OZ.AU]
> 
> > The functional programming community seem to avoid the
> > need for this sort of thing by having good mechanisms
> > for boxing up bits of state;
> 
> I think the recent introduction of dynamically scoped
> variables in Hugs/ghc suggests the opposite; the existing
> mechanisms in Haskell 98 are _not_ sufficient, it seems.

I've just had a chat with the Haskell compiler gurus at
the other end of the corridor.  I mentioned the substance of
the problem to them and they shouted "Monads!" at me
(predictably).  I mentioned the fact that we often had multiple
state threads running through our code and they went quiet.

Having thought some more about the matter, it seems to me that
EDCGs are primarily useful in places where one is throwing
around a lot of state, so I'm prepared to give 'em a go.  In
particular, it *is* painful writing code like

p(X0, X, Y0, Y, Z0, Z) :-
	a(X0, X1, Y0, Y1),
	b(Y1, Y2, Z0, Z1),
	c(Z1, Z, Y2, Y, X1, X).

That, it has to be said, probably has a negative score on the
perspicuometer.

On the other hand, using EDCGs, as currently suggested, I
would be able to write

p -->> a, b, c.

My problem with this is that there's no record *here* of what
the `side effects' of a, b, and c are.  Perhaps it might be
better to add some annotation:

p -->>
	a changes(x, y),
	b changes(y, z),
	c changes(x, y, z).

Here, at least, I'm making it quite explicit what is going on.

I suspect I'm getting altogether too het up about this one.
Maybe it just is a fact of life that "unadorned declarative
code" + "lots of state munging" = "unreadable mess" and that
we have to throw away "unadorned" in order to get "readable
code" on the RHS.

Ralph
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list