[m-dev.] Re: Visual vs total arity clash example [fwd]

[Ralph Becket]

> From: Fergus Henderson [mailto:fjh at cs.mu.OZ.AU]
> 
> > [...]
> > This is one of the reasons why I'd like to be obliged to
> > specify what variables are being passed to a call *at the 
> > call site*,
> > e.g.
> > 
> > prepend(Xs) -->>
> > 	(	Xs = []
> > 	;	Xs = [H | T], prepend(T) + changes(acc), $=acc 
> = [H | $acc]
> > 	).
> 
> I think there are some cases where you want that.
> I think there are also other cases where specifying that
> at every call site would be cumbersome.

Hmm.  In imperative languages, calls with hidden-effects (in 
the sense that there are few clues about what non-functional
changes occur at the call site) arise in three ways: 
1. the procedure being called changes the value of a global
(considered very poor practice);
2. the procedure is a method on an object and changes the
state of the object (we don't have non-functional mutable
state in Mercury),
3. the procedure is passed an aliased pointer whose referent
it changes (as you say, this can't happen with EDCGs).

So it seems to me that EDCG code is going to look and feel
very much like case 1, namely playing around with globals
and I believe that this facility will be abused.

If one eschews globals in C, say, then one has to add extra 
state arguments to functions and the programmer has
to thread these bits of mutable state throughout the program.
This is not generally considered a bad thing.

Indeed, the problem we're trying to solve is that of obfuscating
code when threading in/out argument pairs through Mercury code
and having to deal with all the messy state numbering X0, X1, 
..., X that goes with it.  My feeling is that the current EDCG
proposal goes too far in the other direction.  I don't mind
supplying a *single* symbolic name for a state thread in all
the relevant places (it's what I have to do in imperative
languages).  I don't mind doing that for the very reason that I
do my best to avoid writing code that uses global variables.

One of the few things that I find appealing about the current
EDCG idea (clarification: I think it's on the right track, I
just don't like the coding style) is the potential for hidden
arg inference.  That is, I should be able to extend the
hidden args declaration for a predicate, without having to
change the declarations for all but the top-level predicates
above it in the call hierarchy.  But, then, I might just as
well add global variables to the language and be done with it.

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