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

Peter Schachte schachte at cs.mu.OZ.AU
Sat Dec 1 01:05:06 AEDT 2001


> Problem 1: DCG syntax is ugly and puts the cart before the horse (it's
> very common to see the majority of a DCG clause { escaped } with only a
> few unescaped goals.)
> 
> Problem 2: DCGs are weak because they only support a single threaded
> pair.

I agree completely; these problems should be fixed.

> we would make ! an infix binary operator and write
> 
> io ! foo :-
> 	p(...),
> 	q(...),
> 	io ! io__print(...),
> 	r(...),
> 	io ! io__print(...).

Details, please.

How can a new state be created (ie, how does a predicate without a state
thread call one with one)?  How does one access and set the current value of a
state thread?  What if a predicate is declared to take a state thread foo but
I call it as bar!pred(...)?  Is it OK to mix clauses?  Can I write one clause
with 4 arguments, andother with 2 and a state thread foo, and another with 2
and a state thread bar?

Is there reason to believe that users are less likely to forget to put foo! in
front of a goal than they are to forget to surround one with braces?  I don't
see this proposal helping the error-prone nature of DCGs.  In fact, this
proposal adds the complication of multiple possible threads, while users are
unlikely to spell {} wrong.

I think it would be better to put the thread name at the end rather than the
front (foo(X) ! bar rather than bar !  foo(X)) because it puts the thread,
which is really just arguments, with the arguments of the goal.  It also puts
the emphasis on the predicate name, rather than the thread name (which is less
important).

I'd also like to see some description of the mental model I'm supposed to have
as I read and write code using this facility.  I agree with Fergus that
defining it solely by translation isn't so helpful.

> The chaining expansion does impose an order on the argument pairs (e.g.
> here io argument pairs must come before array argument pairs.)  This
> doesn't seem like a big deal, but if it is, we can just make the
> obvious change to the algorithm rather than using simple DCG expansion.

I don't see a reason to require users to get the order right, and doing so
makes the system more error-prone (though of course ordinary argument passing
is just as error-prone).  I think it would be better to consider the threads
passed to a predicate as a set.

> If we want to access the values of the threaded parameters we can
> use the existing DCG notation:
> 
> 	array ! =(X)	% Unifies X with the current array value.

I think a functional-style syntax (ie, a term rather than a goal) for
accessing the current value would be preferable.  I propose the syntax $array
for access, and $array := Value for setting.

-- 
Peter Schachte              In a democratic time culture, everyone's time is
schachte at cs.mu.OZ.AU        valueable and no one's time is any more
www.cs.mu.oz.au/~schachte/  expendable than another's.
Phone: +61 3 8344 9166          -- Jeremy Rifkin 
--------------------------------------------------------------------------
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