[m-dev.] EDCGs

[Peter Nicholas MALKIN]

On 18-Dec-1997, Fergus Henderson <fjh at cs.mu.oz.au> wrote:
>
> > 2)
> > An alteration to occasionally avoid having to use the -->> notation is to
> > enable functors with hidden arguments to be called in the usual fashion
> > with the hidden arguments expressed in the head of the goal after
> > the visual arguments. For identification the name of the hidden argument
> > should be attached to the appropriate parameter.
> 
> When you say "functors", you mean "predicates", right?

Yes I do, sorry.

> > 3)
> > A complication arises with the proposed notation if a predicate is
> > called, and there are hidden arguments initiated, then the predicate MUST
> > use them. However a situation may arise where you wish some of the hidden
> > argument(s) to skip this predicate but remain active after. For this to be
> > done, the unusefull arguments must be killed with their values stored, new
> > arguments created, the predicate called, and then the new ones destroyed
> > and the old ones reinstated.
> > 
> > Expressing hidden arguments in the argument list of a goal should be made
> > to restrict the scope of the hidden variable to the goal hence making it
> > is possible to override existing hidden arguments for the duration
> > of a goal easily and hence preventing the before said excessive code.
> > Restricting the scope means less scope violations and also information
> > hiding.
> 
> This is really another consequence of (2), rather than a separate issue,
> yes?
> 

Not quite another consequence, but part of yes. I suppose 2) and 3) are
subpoints with regard to the idea of being able to use non EDCG notation.
I guess I just had to reach the number 5.

%%%%%%%%%%%%%%%%%%%%%%%%% My EDCG Notation %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

> I found this description difficult to follow;
> in a lot of cases, new constructs were defined by means
> of giving an example, without clearly stating the
> semantics of the new construct; it is difficult to
> generalize from a single example.

Sorry. I felt that if I was too thorough in my explanation then the email
would have been so long that no one would have bothered to read it all.

I will send another email soon after this which will (hopefully) be more
succinct and complete. I will address your other queries there.

> ~pnmalk/edcg/append.e:
>  | :- htype acc(T)
>  |         ---> acc(list(T)::in, list(T)::out).
>  | 
>  | :- type accumulator(T::in, acc(T)).
>  | accumulator(X,Y,[X|Y])).
> 
> Shouldn't that be `:- pred' rather than `:- type'?
> 
>  | :- pred append(list(T)::in, acc).
>  | append([], acc(Y,Y)).
>  | append([X|Xs]) -->
>  |         accumulator(X),
>  |         append(Xs).
> 
> Shouldn't that `-->' be `-->>'?
> 
>  | rev(L,R) -->>
>  |        revapp(L, list_of_elements([], R)).
> 
> Shouldn't that `-->>' be `:-'?

You are right on all accounts, my notation sometimes is a little wayward.
I have fixed the errors in the example files. I will try to put more
examples there for you. If anyone has a program that they would like to
see converted to my notation please email it to me.

> > Disadvantages over proposed method;
> > ANY SUGGESTIONS?
> 
> I suggest you ask Peter Szeredi and Martin Kosa for their comments.

I would like more feedback from mercury developers before I send it to
them.

Peter Malkin