[m-dev.] New release?

[Mark Brown]

Hi Zoltan,

On Thu, Oct 22, 2015 at 1:45 PM, Zoltan Somogyi
<zoltan.somogyi at runbox.com> wrote:
> My proposal is attached. At the moment, it is a description
> of an approach, with some details missing, because it makes sense
> to work out those details only if there is agreement on the basic
> approach. I intend this proposal to start a discussion on its approach.

There are several related but distinct issues that have come up in
this and the other thread. It is worth listing these issues to check
also that there is agreement on the problems at hand, and to be clear
on which of these problems each proposal addresses.

1. When compiling or linking, the user needs to choose exactly one
grade. Command line options impose constraints on this choice, in
additional to the constraints as to which grades are valid, available
on the platform, and installed. If the constraints are not
satisfiable, it is up to the compiler to explain why.

2. When installing (either a user library or Mercury itself), the user
needs to choose a set of grades. Ideally this will cover any grade
that may be chosen when compiling or linking. Julien's thread is
addressing this problem.

3. With the current installation method you don't want to install too
many grades up front because of the installation time, so this is
closely connected with 2. But incremental installation - something
that was mentioned a while ago - would break this connection,
therefore installation time is a separate problem.

4. When adding a new feature that is binary incompatible hence
requires its own grade component, the developer may end up adding a
large number of grades. They need to do so in a way that minimizes the
impact on the users who are dealing with issues 1 and 2, meaning that
existing uses of command line options don't change the selection.

Your proposal addresses problems 1 and 4. I strongly agree with the
approach for the latter, and moreover I don't see any feasible
alternative.

While I agree with the approach for problem 1, including a
comprehensive and systematic form of command-line options, I'd also
like to see something even higher-level. For example, a --feature
option that chooses features such as mdb debugging, profiling, etc.
The additional challenge for such constraints would be in providing an
explanation of what to do if they are not satisfiable.

There ought to be a correspondence between the command-line options
and the features that are referred to in pragma require_feature_set,
since the concepts being expressed have much in common. This is why I
suggested the above option. I think it is also worth considering
whether the pragma should be extended to cover your proposed form of
command-line options.

Cheers,
Mark.