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

[Zoltan Somogyi]

On Tue, 19 Apr 2016 08:38:24 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> > To reflect these constraints in the grade structure, I also need to know
> > whether we support the combination of thread safety with either
> > (a) mprof-style profiling, using either the llds or the mlds backend, and
> 
> No, you cannot mix multithreaded code and mprof-style profiling.
> 
> > (b) the source-to-source debugger for hlc grades.
> 
> Ditto for this.

Thanks for that. That is what I guessed, but I wanted to know for sure.

Here are some other questions for which I am not certain of the answer:

(1) Since ssdebug doesn't work for multi-threaded programs, should we
allow it to coexist in a grade with the target language being C# or Java,
both of which *imply* thread safety? (The same problem will arise with Erlang
when that backend implements threading.)

At the moment, I am intending to say "no", for the purely technical reason
that the solver can implement "ssdebug = yes implies threadsafe = no",
but it cannot implement "ssdebug = yes and target = c implies threadsafe = no",
since it has no way to represent conjunctions.

Does anyone need or want the combination of ssdebug with C# or Java?
If yes, I could finesse the problem by replacing the threadsafe no/yes
dichotomy with something along the lines of no/yesnative/yesoptionalforc,
and using the rule "ssdebug = yes implies threadsafe in {no,yesnative}",
which the solver *can* express, but I would prefer not to add this complication
if it is not needed.

(2) Is trailing compatible with trailing, on either the llds or mlds backend?
My guess is no and no.

(3) Which mlds/elds target languages is the ll_debug grade component,
which turns on target language debugging, supported for? The code
for target_debug in compile_target_code.m is ambiguous for C#,
indicates support for Java, and no support for Erlang.

(4) There are two meanings of "ll" debugging in the Mercury system:
(a) the ".ll_debug" grade component asks the compiler for the target
language to turn on debug support, and(b) the MR_LOWLEVEL_DEBUG
macro changes the definition of a lot of the macros in the LLDS backend
to call functions to log things such as jumps, calls and returns, which was
absolutely essential once upon a time for debugging the LLDS code generator,
but which does not have much use since. I think one or the other
should be renamed to avoid confusion. I don't care much which one
we rename. Renaming MR_LOWLEVEL_DEBUG would be invisible to users,
while renaming ".ll_debug" would not be, but renaming it to e.g.
".targetdebug" may *help* users by making the name easier to remember.
Any opinions?

Zoltan.