[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