[m-dev.] parallel conjunction

[Peter Ross]

On Thu, Sep 28, 2000 at 12:59:07AM +1100, Fergus Henderson wrote:
> 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?
> 
I think that the approach with the most implementation work is the best
approach (as long as I don't have to do the implementation ;)).  I think
that we should make every effort to make programs written in Mercury as
portable as possible across implementations (or should I say grades as
well).

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