[m-dev.] questions about grades

[Paul Bone]

On Wed, Feb 24, 2016 at 03:43:40AM +1100, Zoltan Somogyi wrote:
> 
> On Tue, 23 Feb 2016 14:21:04 +1100, Paul Bone <paul at bone.id.au> wrote:
> > I think it's fine if this goes away.  As of 2015 MC havn't been doing any
> > new projects in C (where MercuryFile is relevent), and if they recompile an
> > old project with a new Mercury this is just one of the many things that may
> > have changed.  I think the cost of maintaining it is higher than the risk of
> > it breaking something and the cost of that breakage.
> 
> Actually, I haven't seen any "cost of maintaining it" until this email thread.

It is very low, but I think the benefit is probably lower (zero).

I agree, a note on the users' list is a good idea.

> -------------------------------------------------------------
> 
> There were some things I forgot to ask about in the earlier email.
> 
> Was Ralph's history gc intended to be used in LLDS grades? Do we care?

I think so.

It never got to a point at which it worked.  It's very much a developer
experimental option.

> We allow a .par grade component to be added to a grade regardless of
> what language we are targeting, but I have used only the LLDS .par grades
> For those, the .par grade component means: multiple engines, reserve a register
> for thread local data, and support for executing code in parallel, both
> code that explicitly spawns off processes with thread.spawn, and code that
> just uses parallel conjunctions. However, I vaguely remember that the .par
> grade component means something different for the other targets: high level C,
> Java, C# and Erlang, and not just in that they don't have a register to
> reserve. Can the people who have implemented and/or used .par for these
> targets tell me what the differences are, if there are any?

At least for the Java grade, and probably for the others, .par makes no
difference.  These platforms are always thread safe (and always pay whatever
their thread safety costs may be), therefore there's no point in us
distinguishing between with and without .par: we might as well enable things
like thread.spawn() in all cases.


-- 
Paul Bone