[GHC] #8680: In STM: Variables only in left branch of orElse can invalidate the right branch transaction

[GHC]

#8680: In STM: Variables only in left branch of orElse can invalidate the right
branch transaction
--------------------------------------------+------------------------------
        Reporter:  jberryman                |            Owner:
            Type:  bug                      |           Status:  new
        Priority:  normal                   |        Milestone:
       Component:  Compiler                 |          Version:  7.6.3
      Resolution:                           |         Keywords:
Operating System:  Unknown/Multiple         |     Architecture:
 Type of failure:  Runtime performance bug  |  Unknown/Multiple
       Test Case:                           |       Difficulty:  Unknown
        Blocking:                           |       Blocked By:
                                            |  Related Tickets:
--------------------------------------------+------------------------------

Comment (by jberryman):

 Replying to [comment:2 ezyang]:
 > I haven't checked your program, but what you have textually described is
 the behavior I would expect for orElse (and is consistent with the
 semantics): the 'else' branch is only valid if the 'if' branch retries; so
 if the first branch is invalidated, it may not be retrying anymore.

 So I think I got caught up in the details and convinced myself that there
 wasn't really a way to do any useful reasoning with this behavior. But I
 suppose it lets you say e.g. "if we're in the right branch then our view
 of the world is one where predicate P from the left branch is False", even
 if the two branches share no variables and the first is rolled back.

 > This suggests there might be a useful nondeterministic version of
 orElse, which relaxes this restriction.

 Now I'm not even sure that the current `orElse` behavior won't work for
 me. Would it be better to update this ticket when I have a clearer idea,
 or just consider opening a new feature request ticket in the future?

 Thanks for the feedback.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8680#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler