[m-dev.] EDCGs

[Peter Schachte]

On Mon, Dec 20, 1999 at 02:06:00AM -0800, Ralph Becket wrote:
> As I see it, one of the key reasons why one would use
> Mercury is that it is declarative, which can be read as meaning that
> each `statement' can be interpreted without reference to its context.
> This is why we frown on destructive assignment and, in particular, global
> variables in imperative languages.

I think it's mainly destructive assignment you object to, not so much
"global variables."  Global variables really just correspond to
quantification to a scope larger than a single clause.  For example,
one could imagine that a variable `Argv', a list of atoms present on
the command line of the program invocation, could be made visible
everywhere in the program.  Logically speaking, what harm is there in
that?  Alright, it's unusual, and it's certainly not worth making a
special case for the few such things that could sensibly made global,
but it's still perfectly declarative.

> I just want to throw an old idea of mine back into the melting pot again
> ...  Basically, if one sees a
> `primed' variable X` then it may be referred to subsequently 
> (i.e. "lexically later") as just X.  There would be the obvious tie-up
> rules for variables in the head.  So one would write
> 
> main(IO, IO`) :-
> 	io__write_string("Hello, World!", IO, IO`),
> 	io__nl(IO, IO`).

(First, to get it out of the way, backquote is now taken.  You'll have
to find another syntax.)

This *is* destructive assignment.  One can no longer see the variable
IO in different places in the code and know they're the same.  One can
no longer reorder goals in a conjunction without changing the meaning.
So this approach avoids global variables, which I claim are not a
problem for declarativeness, but does use destructive assignment,
which *is* a problem.

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

(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

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)

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

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


-- 
Peter Schachte                     Behind every great fortune there is a
mailto:schachte at cs.mu.OZ.AU        crime.
http://www.cs.mu.oz.au/~schachte/      -- Honroe de Balzac 
PGP: finger schachte at 128.250.37.3  
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------