[m-rev.] the grade library is ready for review

[Zoltan Somogyi]

On Tue, 5 Apr 2016 12:26:57 +1000, Paul Bone <paul at bone.id.au> wrote:
> Cool.  Can (should?) the grade library distinguish between sensible grades
> (for users) / grades that work / grades that do not work?

The grade library must handle all valid grades, since it will be used by
developers as well as users.

As for distinguishing the developer-only and intended-for-users grades:
what distinction did you have in mind? If you intend to protect users from
grades that e.g. combine debugging and deep profiling, there is no need.
Since the defaults are no debugging and no deep profiling, the only time
the solver will generate a grade that combines debugging and deep profiling
is when the user has *asked* for both.

> > > I also made it crash:
> > > 
> > >     $ ./choose_grade pregen=pregen
> > >     ...
> > >     Uncaught Mercury exception:
> > >     Software Error: function
> > >     `grade_lib.grade_structure.encode_low_tags_floats'/3: Unexpected: pregen
> > >     but MercFloat != boxed double
> > >     Stack dump not available in this grade.
> > 
> > That is strange. I just tried that command, and for me,
> > it worked just fine. Did you test the current version
> > of the library?
> 
> Yes, I tried this yesterday against the current "master":

Sorry, I missed the ellipses in your mail, and thought my output
worked because the exception came at the end of a long printout.
I have now both reproduced and fixed the problem.

> It didn't occur to me that ssdebug will work with llds.  However that's
> something I'd consider to be "not sensible".

In this case, the requirements think so too.

> init_requirement_specs in grade_spec.m: specifically the use of the
> constructors 'being' 'is_one_of' etc in the infix notation.  I didn't look
> to see if they were actually combinators (I don't think they are).

No, they are not combinators.

> Anyway,
> what I was referring to was this infix style with English names.  It's a
> style that can be used to great effect and IMHO can often be overdone,
> making code less readable.  This style has made your code _more_ readable,
> so I like it.

I also don't like most uses of it, but in this case, I thought it made the rules
significantly more readable. Glad you agree.

> These preferences make sense, including the version parameter.  We may want to
> tweak the order of the variables if constraints between them are added or other
> preferences change.  If we decide to make thread safety the default then it
> needs to be moved ahead of stack segments, so that we don't commit to a fixed
> size stack before labeling thread safety.

Since we agreed that we will make stack segments the default, the above
scenario won't happen. I think we should make that switch soon after
we switch over to the compiler using the grade library.

> Hrm, this is a form of weak constraint: thread safety in the llds backend
> weakly implies a segmented stack.  It's still okay to use fixed size stacks,
> but a segmented one improves performance.

True, but since (due to robustness concerns) we already prefer a segmented stack,
it is not a *conditional* constraint.

> > On that basis, I tentatively conclude that backtracking should never be needed
> > to find the best solution. I would have to revisit that conclusion if anyone adds
> > some tests to test_grades.m that cause it to generate INCONSISTENT.
> 
> That may also change if we add constraints or change preferences.  But maybe
> not, the more I think about this problem the more I believe that propagation
> handles many of the "important" variables early on - the variables that are
> likely to break constraints.

I think it is unlikely that we will need to use backtracking in relative searches,
but since the code is already there, we can keep it there even if we don't use it.
The cost is negligible.
 
> I don't see
> > any situation whatever in which printing them all would help the user, and
> > without that, I don't see why the grade library should ever compute them all.
> 
> Depends how the grade library is used to choose a grade relative to the
> installed grades.  If the installed grades are used to setup the constraint
> problem (need only first solution) or filter the results of the problem (may
> need all solutions).

I don't understand the second sentence, since it is incomplete.

> While writing this e-mail I thought of other instances of this kind of
> thing:
> 
>     The user wants "debugging", but doesn't care which debugger is used.
>     This relieves the user from needing to know that different debuggers are
>     available (to some extent).
> 
>         debugging -> debug=debug \/ debug=decldebug \/ debug=ssdebug

Yes, we discussed that a few months ago. I agree that the above is a
good idea *if* the source-to-source debugger is ready for users. I don't use it
myself, but the last time the question came up, the answer was that it wasn't
ready.

>     Of course the user still needs to know which debugger or profiler they
>     got so that they can invoke it.

Yep. The question is: *when* should we tell them? Telling them every time
the grade library chooses for them will get old *really* fast. I don't think we
can make a good decision on this without trying out some algorithms and seeing
how we like them.

Zoltan.