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

[Paul Bone]

On Fri, Apr 01, 2016 at 08:57:40PM +1100, Zoltan Somogyi wrote:
> The changes I have made over the last few days have made
> the grade library ready for review. I would appreciate your feedback
> on it before I start integrating it into the compiler. (I won't
> commit any changes that do that without a separate review.)
> 
> You will probably want to start with compiler/notes/grade_library.html,
> which gives an overview of the library. The grade_lib directory
> contains the library itself (the grade_lib.m package and its submodules,
> all of which have names starting with "grade_"), and three standalone
> programs.
> 
> The test_grades program poses 160 problems to the solver and prints
> the results (some fail, some succeed); you should check whether the
> successes AND failures seem reasonable to you.
> 
> The try_all_grade_structs program is a sanity check; it tests whether
> the grade library can properly process all valid grades (of which there
> are more than one million!). This takes a bit less than a minute on
> my laptop, which shows that the grade library can handle the kinds
> of problems that this test poses in about 50 microseconds each.
> (I expect that solving partial, not full, grade specifications takes longer.)
> 
> The choose_grade program is for interactive testing: you give it
> a partial grade specification in the form of a command line such as
> 

So far this all looks good.

> ./choose_grade target=erlang stack_len!=stseg
>
> and see what the solver does with it.

I've been checking some compilation model combinations.  I found that it was
okay with:

    $ ./choose_grade thread_safe=thread_safe debug=debug
    $ ./choose_grade thread_safe=thread_safe deep_prof=deep_prof

AFAIK these don't work with multiple threads.  Is there a missing
constraint?

How about:

    $ ./choose_grade debug=debug deep_prof=deep_prof

This also succeeds.  But does this grade work?  Even if it does work it
probably doesn't make sense.

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.

Twice:

    $ ./choose_grade ssdebug=ssdebug tscope_prof=tscope_prof 
    Uncaught Mercury exception:
    Software Error: predicate
    `grade_lib.grade_solver.accumulate_why_var_is_not_values'/5: Unexpected:
    is_possible
    Stack dump not available in this grade.


> I tried to make the code of the grade library itself easy to read.
> Please tell me whether I succeeded.

I've looked over parts of it.  It seems fine.  I like the combinators in
grade_solve.m.

There's a typo in grade_state.m line 63: "auconfiguration"


Some additional questions:

 + Does labeling in the solver choose the "best" grade?
 
 + Does it attempt to evaluate all possibilities or will it commit to the
   first valid solution?

 + Can we add / do you plan to add support for other requirements that
   aren't compilation model things.  For example, it'd be nice if the user
   could say "I want parallel conjunctions", even though this is not a
   compilation model setting it implies other settings, in this case:

     backend=llds
     thread_safe=thread_safe

   Likewise "threading model" might be another thing.  The LLDS has an N:M
   threading model while the MLDS grades have 1:1 threading (unless their
   targets override this, some old JVMs used to implement N:M).

   This could be connected with the concept of feature sets:
   http://www.mercurylang.org/information/doc-latest/mercury_ref/Feature-sets.html#Feature-sets



-- 
Paul Bone