Changes between Version 9 and Version 10 of Exceptions/PreciseExceptions


Ignore:
Timestamp:
Mar 27, 2017 10:09:51 PM (3 years ago)
Author:
dfeuer
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Exceptions/PreciseExceptions

    v9 v10  
    240240See [[Demand/IO-vs-ST]] for some discussion of why we don't want to use the `IO` hack or allow `has_side_effects` to affect
    241241demand analysis when we're working with strict `ST`.
     242
     243== `IO` transactions? ==
     244
     245Sometimes, we may not care about the distinctions above. Suppose we have an
     246action that performs several database operations in a transaction. If we hit
     247bottom performing any of the operations, then the whole sequence goes down
     248the drain (as long as we're careful to bracket appropriately to initiate and
     249terminate the transaction). In this case, it might be nice to allow the user
     250to state that these actions, despite being `IO`-like, are actually occurring
     251in an alternate universe. The trouble is that we could end up needing to compile
     252each action twice: once for when it is being performed as part of a transaction
     253and once for when it is being performed independently. I have no good story
     254for that as yet.
     255
     256== Dreams ==
     257
     258In my usual "let's break the entire world!" approach, I'd love to change the actual definition of `IO`
     259to something entirely different (one operational monad variant or another). I imagine the complaints
     260would be extremely loud. Aside from breaking the world, another potential downside of this approach is that it seems
     261likely harder to take advantage of knowledge that certain actions (e.g., `readIORef`) have no observable side effects.
     262On the plus side, we could remove absolutely all the I/O hacks from core-to-core that are necessary for
     263correctness, leaving only performance hacks.