[m-dev.] EDCGs

[Fergus Henderson]

On 21-Dec-1999, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> 
> Here's my attempt to be objective about the different proposals.  I'll
> also give my subjective catagorization of whether each aspect is a pro
> (+) or a con (-) of that approach, and put them in my estimated order
> of decreasing importance.  Corrections, additions, and other views
> welcome.
> 
> Status Quo (clausal syntax)
>      +	clean, simple semantics
>      -	necessary to modify many predicates to thread extra
> 	information through existing program
>      -	verbose (rat's nest of variables can obscure important part of
> 	code and makes it difficult to see which goal arguments match
> 	which head arguments)
>      -	variables must be "renumbered" when adding or rearranging
> 	goals involved in variable threads (this doesn't bother me
> 	that much:  I've got an emacs macro to do it automatically).

	+	supports overloading and type inference

> (regular old) DCGs
>      -	can only thead 1 variable through program
>      -	error-prone syntax (too easy to omit needed braces, unit
> 	clauses don't mean what you might expect).
>      -	can only thread pairs, no support for single-assignment threads

	+	supports overloading and type inference
	+	familiar to Prolog programmers

> Ralph's proposal
>      -	necessary to modify many predicates to thread extra
> 	information through existing program
>      -	verbose (rat's nest of variables can obscure important part of
> 	code and makes it difficult to see which goal arguments match
> 	which head arguments)

	+	supports overloading and type inference

> Latest EDCG proposal
>      -	indirect semantics (semantics can only be understood as a
> 	transformation of the code adding arguments, not by thinking
> 	about the code as written)

Same applies to Ralph's proposal.

>      -	setting or getting the variable currently associated with a
> 	name can only be done as a separate goal, not as part of a
> 	goal (eg, it takes two goals to increment a hidden variable:
> 	one to get the "current variable", and another to reset it)
>      -	bulky syntax and declarations

	-	does not support overloading or type inference

> My "global variables" proposal, modified to suit Mercury
>      -	necessary to look at declarations to see where some
> 	information comes from and goes to

How does this one interact with overloading and type inference?

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