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

[Peter Driscoll]

> are you suggesting a fix for a problem with DCGs ('fraid I still don't
> see what the problem is with them in this context!)?

Hey I love DCG's.  However I see them as an implementation strategy, that
could be hidden behind the scenes, in a still better world.  What I don't
like about them is that they expose state.  With an input variable and
output variable, which are hidden, we are almost programming in C++.

> Okay, so you'd have to use juxtaposition since ++ is already taken.  And
> you're also leaving the DCG arguments implicit.

I am only trying to desribe the optimisation steps that might happen in the
compiler.  None of this has to be seen by the user. ++ or juxtaposition is
just syntactic sugar.  I just prefer juxtaposition because it is more
intuitive to me.  But I am not religious about it.

> Which, on top of your
> translation, means you really just want a different syntax for DCGs.
> DCG syntax is already pretty lightweight as far as grammars are
> concerned.

Actually I am saying the Prolog/Mercury already had a syntax for doing DCG
like things even without an explicit DCG implementation.  What I am
suggesting is to use the existing syntax, but behind the scenes, in the
compiler, use the DCG idea as an implementation strategy.

> Also, how could the compiler know if
>
>	term(Factor) :- ...
>
> should be translated by your scheme or treated literally?

That is a good question.  I think the rule should be that where a
unification of the form,

	InputList = FrontList ++ SomeOtherList

occurs then the transformation may be valid, as it provides a way of
delaying the unification of SomeOtherList until it's starting position is
known.

> Your Result is just the prefix that was consumed - why would you want to
> reproduce it?  Usually you want to return the result of some processing
> of that prefix (e.g. a parse tree.)

This is just a simple example.  There is no reason why processing can't be
added to the body.

In my response to Peter Schalte I gave an example of building a syntax tree.

Regards

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 Ralph Becket
Sent: Wednesday, 3 April 2002 4:47 PM
To: mercury-users at cs.mu.OZ.AU
Subject: Re: [mercury-users] Is DCG really appropriate, even for the
things it does well?


Hi,



Peter Driscoll, Wednesday,  3 April 2002:
>
> I am really suggesting that the compiler would see,
>
> term(Factor ['*'] Term) :-
> 	factor(Factor), term(Term).
>
> and translate it (internally) into,
>
> term --> factor, ['*'], term.
>
> How.  Sorry if this is a little informal.
>
> Step 1:
> 	Identify that predicate is a candidate.
> 	-	Has a list(T) parameter.
> 	-	Formal parameter is like list(T) ++ list(T) ... (If space operator like

[Point of style: please stick to 80 character columns as God intended.]

> list(T) list(T) ...).
> 	-	Other checks?

Okay, so you'd have to use juxtaposition since ++ is already taken.  And
you're also leaving the DCG arguments implicit.  Which, on top of your
translation, means you really just want a different syntax for DCGs.
DCG syntax is already pretty lightweight as far as grammars are
concerned.

Also, how could the compiler know if

	term(Factor) :- ...

should be translated by your scheme or treated literally?

> Step 2:
> 	Change list(T) parameter to a DCG form.
> 	-	Replace the parameter with a list(T)::out parameter used to return the
> text read from DCG.
> 	-	Add two parameters for DCG.
>
> :- pred term(list(char)::out, list(char)::in, list(char)::out) is semidet.
> term(Result) -->
> 	(
> 		Factor, ['*'], Term			%	The DCG bit.
> 	),
> 	(
> 		Result = Factor ++ ['*'] ++ Term	%	Calculate the result
> 	),
> 	(
> 		factor(Factor), term(Term)		%	The body.
> 	).

Your Result is just the prefix that was consumed - why would you want to
reproduce it?  Usually you want to return the result of some processing
of that prefix (e.g. a parse tree.)

Cheers,

Ralph

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