[m-users.] Mode selection

[Mark Brown]

On Thu, Oct 16, 2014 at 7:53 PM, Julien Fischer <jfischer at opturion.com> wrote:
> Hi Michael,
>
> On Thu, 16 Oct 2014, Michael Richter wrote:
>
>> Documenting something as fundamental as the selection algorithm used
>> deep in compiler internals or on an ephemeral construct like a mailing
>> list seems a bit whimsical.
>
>
> Whimsical is probably not the right word, but I take your point.
>
>> Does this not belong in the reference manual under the modes chapter?

No, mostly, but good question.

Remember that Mercury's operational semantics is constrained, but not
fully specified. The language itself doesn't require implementations
to use any particular mode selection strategy; implementations are
allowed to use all the cleverness they can muster in choosing the best
modes. (There is, however, a "strict sequential semantics" in the
Semantics chapter, for which the resolution steps are intended to be
fully specified. Maybe this ought to specify a minimal mode selection
algorithm as part of its minimal reordering.)

It is not completely obvious what an optimal selection strategy
actually entails. For example, you might be tempted to say that
implementations must not use an implied mode if a matching mode is
available, but this constraint is not always satisfiable. Consider the
case where two conjuncts bind the same output variable: either could
have a matching mode in which case the other would have to be implied,
violating the constraint.

It does, however, make sense to constrain mode selection to make
choices that are "locally optimal" in some way. For example, saying
that *in a given ordering of conjuncts* an implied mode will not be
selected when a matching mode is available. Such a constraint, if
added, would belong in the modes chapter.

>
>
> It could certainly stand a more detailed explanation of how procedures
> are selected at call sites; I'll have a go at adding something.

Thanks Julien.

Having said all the above, it would still be good idea to add to the
modes chapter a section on the limitations of the current
implementation (e.g., where unique modes must be placed) and document
the selection strategy the implementation actually uses, or point to
the strict sequential semantics if you add it there.

Cheers,
Mark.