[m-dev.] Fw: Replacement syntax for DCGs

[Ralph Becket]

Fergus Henderson, Thursday, 29 November 2001:
> On 26-Nov-2001, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> > Here's yet another DCG-replacement suggestion.
> ...
> > we would make ! an infix binary operator and write
> > 
> > io ! foo :-
> > 	p(...),
> > 	q(...),
> > 	io ! io__print(...),
> > 	r(...),
> > 	io ! io__print(...).
> 
> One nice thing about DCGs, IMHO, is that they have a declarative
> semantics as well as a translation semantics.  I think EDCGs also have
> that property.  But your proposal doesn't.
[...]
> The declarative semantics for DCGs can be given by treating DCG rules as
> ordinary clauses for '-->'/2 and treating phrase/3 as a meta-interpreter:
> 
> 	phrase(X, S0, S) :-
> 		(X --> Y),
> 		phrase(Y, S0, S).
> 	phrase((A,B), S0, S) :-
> 		phrase(A, S0, S1),
> 		phrase(B, S1, SS).
> 	phrase((if A then B else C), S0, S) :-
> 		(if phrase(A, S0, S1) then phrase(B, S1, S)
> 		else phrase(C, S0, S)).
> 	phrase({G}, S, S) :-
> 		call(G).
> 	phrase(=(S), S, S).

I think this is a red herring.  I can also give a declarative semantics
to the _!_ proposal by supplying the appropriate meta-interpreter -
okay, I might have to replace `:-' with `:--' or whatever, but that's
neither here nor there.

The thing is that 99.9% of places using DCG notation in the compiler,
standard library and code I've written, at least, does so to avoid
explicitly threading state pairs - that is, where the code is largely
"imperative" in style.

I think DCG notation is being *abused* in these cases since it does not
make it clear what aspect of state is being manipulated.  I think my
proposal is clearer, more general and more appropriate for state
threading than DCGs.

Which notation has the shortest meta-interpreter is a non-issue, IMHO;
what counts is the transparency of the resulting code.  I suppose I
might sum up my point of view as follows: "raw" code that does extensive
state threading is obscured by all the explicit state variables; DCG
code goes too far in the opposite direction by almost hiding the fact
that any state is being threaded; the _!_ proposal falls somewhere
between these two extremes, making explicit what is being threaded and
where, without requiring an excess of syntax or state variables.

- 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
--------------------------------------------------------------------------