[m-dev.] EDCGs

[Fergus Henderson]

On 18-Dec-1997, Peter Nicholas MALKIN <pnmalk at students.cs.mu.oz.au> wrote:
> 
> Here are some possible improvements to the proposed edcg syntax by Peter
> Szeredi and Martin Kosa. First I will suggest a few improvements on the
> proposed syntax presented then I will present my completely different
> version for edcgs which I believe to correspond more closely to the
> current mercury style as well as including these improvements.
> 
> 1)
> There is of course Zoltan's suggestion that any edcg should involve the
> functor -->> instead of :-.

I strongly support this.

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

> This extra syntax option means that a functor involving hidden arguments
> need not be called as an EDCG rule, hence making the hidden argument
> notation entirely optional, as with DCG's, which is nice.

I agree this is nice.

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

> 4)
> I deem that the accumulator hidden argument notation is redundant.
> [...] instead of writing AccName <+ [X], write AccPred(X).

I'm inclined to agree.

> 5)
> The proposed version does not support polymorphism between hidden
> arguments and other arguments either hidden or not.
> 
> This can be cured by attaching an argument to htype definitions, as in
> normal type definitions.

This is definitely a good idea.

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

> The 'htype' declaration is almost the same as the standard 'type'
> declaration.
> 
> Syntax;
> 
> :- htype hidden_type_name[(...)] --->   hidden_constructor_name(...).

You need to be more specific here: what goes in the `...' places?

> Hidden type names and data constructors must be uniquely named with
> respect to other hidden type names and data constructors respectively to
> prevent ambiguity.
> 
> Equivalence types may not be used because of ambiguities.

Could you be more specific about the ambiguities?

What's the difference between `:- htype' and `:- type'?

> On expansion of the EDCGs the hidden data constructor would be broken up
> into it constituent parts and hence only one data constructor is allowed
> for a hidden argument.

Why not allow multiple constructors, and break the hidden arguments
into their constituent parts only if there is a single constructor?

> For more examples see the directory ~pnmalk/edcg/ and view any files with
> .e as the suffix.

~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 `:-'?

> Disadvantages over proposed method;
> ANY SUGGESTIONS?

I suggest you ask Peter Szeredi and Martin Kosa for their comments.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.