[m-users.] Mode selection

[Paul Bone]

On Thu, Oct 16, 2014 at 10:31:48PM +1100, Mark Brown wrote:
> 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.

Thanks everyone.

This was also one of my concerns, that in a specification we don't want to
over-specify details that don't affect the declarative semantics.  However,
that depends on how much the reference manual is a "reference manual" and
how much it is a "specification".

I agree that this information should be in the reference manual but
with a note saying that Mercury implementations are free to choose their own
algorithm and that we're describing (rather than prescribing) the behaviour
of mmc.

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


-- 
Paul Bone