[m-dev.] parallel conjunction

[Fergus Henderson]

Hi,

I've started writing some documentation in the language reference manual
and user guide for our support for parallel conjunction (and also for
multithreading, concurrency, etc.).

One thing I am trying to decide is whether to document the parallel
conjunction operator as a standard part of Mercury, or as an
implementation extension.

I certainly don't want to require Mercury implementations to support
parallelism.  However, the parallel conjunction operator is really
just like ordinary conjunction, with some additional restrictions
on the modes and determinism, and with the additional connotation that
the implementation should run the conjuncts in parallel if possible
(i.e. it's just a hint which the implementation is free to ignore).
The additional mode and determinism restrictions are not particularly
difficult to implement, so I think it would be reasonable to require
all Mercury implementations to support that syntax.  This argument
suggest that we should make it a standard part of Mercury, rather than
documenting it as an implementation extension.

The main drawback with this idea is that the particular choice of mode and
determinism restrictions that we have made is fairly implementation-specific.
In particular, currently we only allow *independant* AND-parallelism,
and the conjuncts must be model_det.  It would certainly be much
nicer to also support model_semi conjucts.  Supporting model_non
conjuncts is a lot less likely to be useful, but some implementations
might want to support that.  And some implementations might also
want to support dependent AND-parallelism.  So I think it would be
a bad idea to embed our current set of restrictions in the language
definition.

Another alternative would be to document `&' as a standard feature
equivalent to `,' with no additional restrictions on modes or
determinism -- just a hint to the implementation to try parallelizing
things here.  The implementation would then have to issue warnings
rather than errors if its implementation-specific restrictions are not
met, and to treat such parallel conjunctions which don't meet its
restrictions as if they were ordinary conjunctions.

The disadvantage of this approach is that it would require changes
to the current implementation, and that you'd only get warnings
rather than errors.  The advantage is that it would ensure portability
of programs using parallel conjunction to implementations (or grades ;-)
that don't support real parallelism.

Comments?

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------