[m-dev.] EDCGs implementation method

[Peter Nicholas MALKIN]

Fergus (and interested others),

There are two choices with regards to when to implement EDCGs:
(i) Before type checking (this is how it is currently implemented)
(ii) After type checking

The benefits of performing the implementation after type check are:
	- Type inference of hidden variable types
	- overloading of predicates based upon name, arity (if done before type
	  check the module must be specified)
	- hidden variable interface with higher order calls


Also, Fergus you mentioned implementing EDCGs at the same time as typecheck
(this still has the benefits of implementing EDCGs after typecheck), the
arguments for and against this are:

For:
	- faster
	- less code
Against:
	- cannot turn off EDCG processing easily (this is only really a gain if
	  it is not to be used often, which will not be the case if it replaces
	  DCGs which I am hoping will happen)
	- hidden variable form inference for predicates may not be able to be
	  done at the same time because it may require a different way of 
	  traversing the HLDS. In fact I am not sure that this will be able to
	  be done at the same time as the translation anyway. I am not
	  completely certain about this, I will look into it some more. Do we
	  want inference? See below.


Hidden Variable Inference
-------------------------
This is exactly what is contained in Peter Schachte's paper on global 
variables. 

Hidden variable inference is useful because it means that predicate declarations
can also be inferred, unlike currently where if a predicate uses EDCGs it must
have a predicate declaration. 

However inference is not required to check existing declarations for correctness
(if all hidden variables are declared completely in predicate declarations),
however it can be used to do so, but will probably be slower.

Inference is particularly helpful with information hiding. If a hidden
variable is initialised in a predicate and then is threaded through numerous
intermediate predicates before being used, it would be nice to not have to list
the hidden variable in the declarations of the intermediate predicates (but
listing it in the declarations of predicates where it is explicitly used is
preferrable and may be better to be enforced).

This can be a problem when an intermediate predicate is part of the module's
interface. In this case the hidden variable must be listed in the predicate's
declaration, otherwise difficulties arise.


As as aside
----------- 
At the moment hidden variables are declared through a one to many mapping of
predicates to hidden variables (predicate -> hidden variables). It would be
possible to reverse this mapping (hidden variable -> predicates).  i.e.  Instead
of declaring what hidden variables a predicates uses in its declation, a hidden
variable can have all the predicates it is used in declared with its
declaration.

The advantage of hidden variable -> predicates is that is provides a complete
overall picture of the use of the hidden variable. The disadvantage is that it
is only an overall picture, and hence when examining sections of code it may be
unclear what hidden variables are involved (this especially will a problem in
module interfaces). However, the functor '-->>' will still be present and the
hidden variables will be obvious when listed (because of the operators '$' and
'$='), so maybe this is not so much of a problem.

Peter

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