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

[Luke Evans]

Thanks for the full reply (enjoyed the Maslow quote!).  

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
- so it's natural to think (as one learning the language), that they're
considered a 'respectable' tool for other similar tasks.  If this isn't the
case, then it seems to me that Mercury should have the appropriate
'respectable tool' - fit for purpose.

I've read the abstract and intro from your document, and I can't help but
agree with the opening points.  I'll read the rest over lunch today.

As a relative newcomer to the Mercury language (and certainly to creating
'real' programs which do things I would normally program in Java), my
comments are observational.  The particular code that brought it all to a
head creates 9 graph nodes and 10 links between them to initialise my (not
very big) graph.  Of course (just as you imply in your document), I end up
with 36 variables which I don't really care about but I have to 'manage' (by
typing in and 'renumbering' if I edit the lines).  IMHO this is exactly as
if I'd coded all my IO long-hand (non-DCG), yet we don't do this - we're
advised to use DCG's in this case.

In the absence of the 'respectable tool' for this, I AM going to add wrapper
predicates which move the 'GraphIn', 'GraphOut' variables to the end of the
argument list, and then employ DCG's to make my list of Graph deltas much
more approachable (and more easily modified).

Now, where did I put that hammer...

Lwe

 
-----Original Message-----
From: Peter Schachte [mailto:schachte at cs.mu.OZ.AU]
Sent: 22 June 1999 06:59
To: mercury-users at cs.mu.OZ.AU
Subject: Re: [mercury-users] Libraries and DCG convenience...


On Mon, Jun 21, 1999 at 07:12:56PM +0100, Luke Evans wrote:
> There's clearly a convention with predicates (visible in the standard
> libraries) where predicate arguments are presented as:
> <ADT state before> [arguments describing the delta] <ADT state after>

[snip]

> Threading the graph variables through all this is painful and seems (IMHO)
> to be exactly what DCG's were designed for.

Actually, it's not.  DCGs were designed for natural language parsing.
Pressing them into use for this sort of thing does them a real
disservice, I believe, as it makes them seem awkward.  They are
actually quite comfortable for parsing.

	If you only have a hammer, you tend to see every problem
	as a nail.
		-- Maslow

The problems with using DCGs for hiding argument threads include:

     o	they can only hide one thread (one pair of arguments)
     o  they only hide the last two arguments
     o	the need to insert braces to avoid adding a thread to some
	goals is easily forgotten
     o	unit clauses don't get the thread added; you have to use a
	different syntax for unit clauses
     o	in Mercury, you have a pred declaration for a predicate with
	arity n, but the clauses have arity n-2

I still think that the DCG idea of introducing a special notation in
which the sequence of goals is significant is the right one, because
sequence is a comfortable way to present threading (just as it's good
for presenting complex conditionals as if-then-elses).  But most of
the other design details of DCGs aren't right for this purpose.  My
proposal is put forth in

	http://www.cs.mu.oz.au/~schachte/papers/iclp97.ps.gz

but it won't do you much good, because my implementation is for
Prolog.  I do believe it could be adapted to Mercury without much
trouble, but that hasn't been done yet.  So everyone keeps hammering
those wood screws, and wishing they weren't threaded (sorry for the
egregious pun :-).


-- 
Peter Schachte                     Things are only impossible until they're
mailto:schachte at cs.mu.OZ.AU        not. -- Jean-Luc Picard, Star Trek: The
http://www.cs.mu.oz.au/~schachte/  Next Generation 
PGP: finger schachte at 128.250.37.3  
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------