[m-rev.] for review: avoid using some "keywords" 5

[Zoltan Somogyi]

On Mon, 16 May 2016 10:26:30 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> > Unifications (x = y) have long had two descriptions of their modes.
> > One is the unify_mode, which used to look like this:
> >     (initx -> finalx) - (inity -> finaly)
> > and other is the uni_mode, which used to look like this:
> >     (initx - inity) -> (finalx - finaly)
> > Each unification has one unify_mode, and the unifications that includes
> > a function symbol has one uni_mode per argument of that function symbol.
> 
> That last sentence doesn't parse.

I meant:

  Each unification has one unify_mode, and each unification that includes
  a function symbol has one uni_mode per argument of that function symbol.

Fixed.

> > +:- type unify_mode
> > +    --->    unify_modes_lhs_rhs(mer_mode, mer_mode).
> > +
> > +:- type uni_insts
> > +    --->    uni_insts_lhs_rhs(mer_inst, mer_inst).
> > +            % Respectively, the insts of the left and right hand sides
> > +            % of the unification.
> >  :- type uni_mode
> > -    --->    pair(mer_inst) -> pair(mer_inst).
> > -            % Each uni_mode maps a pair of insts to a pair of new insts
> > -            % Each pair represents the insts of the LHS and the RHS
> > -            % respectively.
> > +    --->    from_to_uni_insts(uni_insts, uni_insts).
> > +            % The initial insts of the two sides of the unification,
> > +            % and their final insts.
> 
> I would prefer not to abbreviate "unify" or "unification" to "uni" as in a
> system that also deals with "unique" or "uniqueness" all over the place, it's
> confusing. 

I take your point.

> I suggest the following for the above:
> 
>      :- type unify_modes
>          --->    unify_modes_lhs_rhs(mer_mode, mer_mode).
> 
>      :- type unify_insts
>          --->    unify_insts_lhs_rhs(mer_inst, mer_inst).
> 
>      :- type unify_mode
>          --->    from_to_unify_insts(unify_insts, unify_insts).

However, this would be even MORE confusing, because it conflates
two even more closely related concepts that are nevertheless still
distinct: the modes of the argument unifications, and of the whole
unification.

Since "uni" is too easily confused with both "unify" and "unique",
how about replacing "uni_mode" with "arg_mode" or "sub_mode",
with a similar substitution applied to "uni_insts", "uni_insts_lhs_rhs"
and "from_to_uni_mode"?

"arg_mode" sounds more appropriate, but that type name is already
taken. We could rename the old arg_mode type to e.g. arg_top_mode
or arg_kind.

> The rest of the diff looks ok.

Thanks for the review.

Zoltan.