[mercury-users] Libraries and DCG convenience...

[Richard A. O'Keefe]

Luke Evans wrote:

	I take the point about DCG's being designed for parsing (and I
	remember doing the standard banal exercises with them many years
	ago now for my AI/Prolog course).  However, they ARE pressed
	into service for IO in Mercury

If you consider a Mercury predicate that only does input,
and that from a single stream,
you will realise that DCG syntax is _not_ "pressed into service"
for input.  Input *is* parsing.
If you consider a Mercury predicate that only does output,
and that to a single stream,
you will realise that DCG syntax is _not_ "pressed into service"
for output.  Output *is* generation, just like the other natural
and normal use of DCGs for language processing.

There are two ways in which the use of DCG notation for Mercury
IO _does_ introduce a metaphoric extension (I insist that using
DCG rules to parse or generate a single stream is *not* an extension;
sequence description is precisely what DCG rules are for):
 - working on multiple streams
 - doing input and output with the same predicate.
Even then, it is no more than *co-ordinated* parsing/generation;
rather like the way KIMMO rules parse one sequence and generate
another at the same time using finite automata.

It's when the sequence that is described is not a "stored"
sequence but a sequence of *states* that the metaphor starts to
buckle under the strain.

One of the things I like about Clean is not just that it lets
you write a function Start :: *World -> *World, but that it
lets you break a World into pieces and pass the pieces around
*separately*.  The type system then enforces the separation,
and Clean functions working on separate parts of the state are
*not* serialised; they may be arbitrarily interleaved by the
compiler and run-time system.  To put it in a Mercury-ish way,
if we could write

    :- pred p(x, y, istate, istate, ostate, ostate).
    :- mode p(in, out, di, uo, di, uo) is semi_det.
    :- pred q(y, istate, istate).
    :- mode q(out, di, uo) is semi_det.
    :- pred r(x, ostate, ostate).
    :- mode r(in, di, uo) is semi_det.

    p(X, Y, I0, I, O0, O) :- q(Y, I0, I), r(X, O0, O).

then q/3 and r/3 could be run concurrently.  But as long as you
have to do _everything_ via the (one and only) io__state, then
you have to serialise _everything_.

So this is an argument for a Schachte-style generalisation, not
just for syntactic convenience, but in order to fit in with a
richer state model where independence can be stated, enforced,
and perhaps some day exploited.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------