[m-dev.] New release?

[Paul Bone]

On Thu, Oct 22, 2015 at 01:45:11PM +1100, Zoltan Somogyi wrote:
> 
> On Wed, 21 Oct 2015 10:49:16 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > Actually, I was thinking about grade options earlier today, prompted by the same
> > concern. I think I will have a proposal worked out in a day or two.
> 
> My proposal is attached. At the moment, it is a description
> of an approach, with some details missing, because it makes sense
> to work out those details only if there is agreement on the basic
> approach. I intend this proposal to start a discussion on its approach.
> 
> If someone wants to turn the proposal into a wiki, go ahead.
> 
> Zoltan.
> 

A related point of confusion are features supported by different grades.

The grades proposal might want to consider information from feature sets
found in a project's source code:

http://www.mercurylang.org/information/doc-latest/mercury_ref/Feature-sets.html#Feature-sets

Trailing is a nice simple one.  It corresponds directly to the trailing
variable in Zoltan's proposal.

A tricker one is parallel conjunction, it does not correspond directly to
any option.  It could be viewed as a separate variable that only serves to
constrain other variables.  It implies thread safe and low-level C.

A very tricky option is exactly how concurrency works.  This is something
I've been asked before and badly need to document.  (This is a perfect item
for the wiki incidentally).

Low level C:
    Thread safe:
        Some concurrency, but if you do IO you can block a whole Mercury
        engine, which might be your only engine.
    Non thread safe:
        I think concurrency is currently broken.  I don't think anyone has
        tested or used it.  I believe that it was intended to work.
High level C:
    Thread safe:
        It works, but you get one pthread per Mercury thread, which might be
        what you want, or it might not.
    Non-thread safe:
        Doesn't work.
Java & C#
    Same as high level C, thread safe.

If you want parallel conjunctions and concurrency that behaves properly with
IO then your only option is to use low level C with spawn_native.  But
that's not ideal.

The other solution is to implement proper behaviour with IO in low-level
grades, and parallel conjunctions in high level grades :-P

Anyway, we could either delay this until after Zoltan's idea or something
else is accepted and implemented.  Or create options such as --parallel-conj
that add sufficient constraints to Zoltan's proposal to choose a grade for
the user in those cases.


-- 
Paul Bone