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

[Zoltan Somogyi]

On Tue, 19 Apr 2016 11:59:06 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> There's no such thing as non-threaded C#, Java (or indeed Erlang) grade.

Actually, as long as thread.m does not implement spawn for Erlang,
Mercury-generated Erlang code is effectively non-threaded, or at least
that is what I understood from Peter's last mail on this topic.

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

OK, I will make the grade library differentiate thread safety in C from
thread safety in the other target languages.

This raises another question. It seems that among the alternatives
llds C, mlds C, C#, Java, and Erlang, the only two that behave the same
wrt threading are C# and Java. The others all differ in some respect or
other: support for parallel conjunctions separates llds vs mlds C, whether
ssdebug makes sense separates C from the other languages, and the
inability to spawn separates Erlang from the others. Should we use the
same grade component, .par, to refer to such a range of distinct things?

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

Yes. I meant: is trailing compatible with thread safety, in llds or mlds?

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

Thanks.

Zoltan.