[m-dev.] strict sequential semantics and committed choice
Tyson Dowd
trd at cs.mu.OZ.AU
Fri Apr 14 14:28:05 AEST 2000
On 14-Apr-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
>
> - Providing guaranteed portability is definitely not feasible,
> because it require require that we specify everything in full,
> which would overconstrain implementations.
>
> - There seem to be lots of features that are IMHO just far too useful
> to live without, for which we cannot guarantee strong reproducibility.
> So guaranteeing strong reproducibility looks like it is too much
> to ask.
>
> - There are also a few features that would be very nice,
> for which we cannot even guarantee weak reproducibility.
> Examples include benchmarking, timeouts and true concurrency.
>
> Threading io__states through these operations would allow us
> to meet the above guarantees. However, it wouldn't make these
> operations any more reproducible. At best it would perhaps
> make it a bit clearer to the user that the `--strict-sequential'
> option would not suffice to give these operations deterministic
> behaviour.
>
> For benchmarking, it would probably be fine to thread io__states
> through those operations. But for timeouts and true concurrency,
> forcing the user to thread io__states through these operations
> would hurt expressiveness significantly.
I agree with this summary.
While in my previous mail I talked about reducing expressiveness to meet
the "demands" of strict sequential semantics, the other option is to
reduce the demands of this semantics (by saying a little more about
what is reproducible).
Another option is to introduce into the language a concept to describe
the kind of non-determinism that cannot be avoided. This would work
like cc_multi or cc_nondet, but strict sequential semantics would only
have weak gurantees for it. You could give strong guarantees for
everything else. Then concurrency, timeouts, etc could use this
mechanism instead.
--
Tyson Dowd #
# Surreal humour isn't everyone's cup of fur.
trd at cs.mu.oz.au #
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------
More information about the developers
mailing list