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

[Julien Fischer]

On Tue, 19 Apr 2016, Zoltan Somogyi wrote:

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

There's no such thing as non-threaded C#, Java (or indeed Erlang) grade.
And yes, ssdebug does need to be supported with them since there is not
another option for debugging them (save dropping down into the target
language debugger).  Obviously, things may go a bit pear shaped if the
program you are debugging calls thread.spawn, but fixing that is future
work.

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

IIRC, the entire point of ssdebug was to allow non-C grade programs to
be debugged at the Mercury level.

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

Is trailing compatible with trailing?  (I bloody well hope so!)
You presumably meant something else there.

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

High-level C, C# and Java; I suspect the latter two are not used
terribly much, if at all.

> (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?

I'm happy to rename .ll_debug to .targetdebug.

Julien.