[mercury-users] Is DCG really appropriate, even for the things it does well?

[Peter Driscoll]

Interesting.  I have noticed the benefits of getting the semidet (as against
nondet) stamp of approval.

The determinism checking (and the compilers other checking) is starting to
impress me.

Initially I was frustrated by the constant stream of error messages that I
didn't understand.

But I have just been lead by the nose to correct a whole lot of problems
that I may never have picked up otherwise.

I think you need to do something to make things easier for the first time
user, but actually I don't know what.  The average mug punter like myself
may balk at the first hirdle and not see what you have achieved here.

I take it that I can define a number of operators, but I don't remeber
seeing this documented.

Thank for your assistance.

Peter Driscoll

-----Original Message-----
From: owner-mercury-users at cs.mu.OZ.AU
[mailto:owner-mercury-users at cs.mu.OZ.AU]On Behalf Of Fergus Henderson
Sent: Wednesday, 3 April 2002 8:43 PM
To: mercury-users at cs.mu.OZ.AU
Subject: Re: [mercury-users] Is DCG really appropriate, even for the
things it does well?


On 03-Apr-2002, Peter Driscoll <peter_driscoll at bigpond.com> wrote:
> With stronger compiler support for list appending could we do without DCG?

Perhaps, but this would require significant extensions to determinism
analysis.

> Note: "Mercury using concatenation" below won't compile under mercury
> because
> 	mode list_append(in, in) = out.

Actually the list__append/3 predicate has several modes.
The function versions of list__append in the standard library don't --
I'm not sure why, exactly.  But you can easily write your own function
version which does, e.g. using "+" or "`app`":

	:- func list(T) + list(T) = list(T).
	:- mode in + in = out is det.
	:- mode out + out = in is multi.
	X + Y = Z :- list__append(X, Y, Z).

However, the problem that you run into for code like you suggest,

	term(Factor + ['*'] + Term) = times_term(factor(Factor), term(Term)).
	term(Factor + ['/'] + Term) = divide_term(factor(Factor), term(Term)).
	term(Factor) = simple_term(factor(Factor)).

is that the compiler's determinism analysis can't tell that there
won't be more than one result; the different clauses might not be
mutually exclusive, and the calls to the `out + out = in' mode of `+'
might succeed more than once.

In this case, the determinism analysis required would have to be
a non-local analysis, since whether or not this grammar is ambiguous
depends on the definition of `factor'.

Maybe the best solution for cases like this would be to have a simple
mechanism for telling the compiler to check the determinism at run-time
rather than at compile-time.

--
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------