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

Ralph Becket rbeck at microsoft.com
Fri Jan 28 04:28:31 AEDT 2000

> > Can someone remind me again why EDCGs are not just a simple
> > source transformation and hence why there should be any problem
> > with integrating EDCG code with plain code?
> The main reasons are these:
>   - We want to support higher-order EDCG code.
>     If you want higher-order calls to look like ordinary
>     first-order EDCG code, then this requires keeping
>     track of hidden arguments in the type system.

One of the key reasons for using higher order code is
code re-use, so any higher order code in a library is
almost certainly not going to use the same EDCG thread 
name (if any) as a given application.

I for one wouldn't find the following terribly burdensome
to write:

p(F, X) -->> F(X) + hidden(changes(my_thread)).

although I'm sure we could find some less verbose way of
writing the same thing.

I'm not convinced that making higher order calls in an
EDCG context look like ordinary calls is sufficiently
useful to warrant complicating everything else.  Have you 
got an example to back up the requirement?

>   - We want to support inference of the `pred' declaration
>     for EDCG clauses.

This, I presume, is so that when someone adds a hidden
argument to some pred far down the call hierarchy, only
the declaration for both it and the top-level caller need 
be changed (the inference filling in for the preds in
between)?  Again, I'm skeptical about how useful this 
would be in the light of the complications it introduces.

> > Question: above I used a polymorphic htype - I presume that's
> > all right?
> Not in the current implementation, but yes we do plan
> to support it eventually.


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

More information about the developers mailing list