On 19 September 2013 16:53, Sandro Magi <[email protected]> wrote: > The work arounds for I/O in optimistic STM are exactly the problem. They > tried to solve it by essentially eliminating the optimism without bringing > the conveniences of real pessimism, namely direct expression of programs with > I/O.
I think I would phrase 'the workarounds for I/O in ... STM' as 'unlike memory, optimistic rules for alias detection don't apply generally to IO', and consequently, they deserve unique treatment and finer-grained control. There are many cases where IO can be decomposed into interactions with different services, but this is not always the case. For most STM systems, if they even provide a mechanism for defining distinct services (that is, a way to describe the implied partial order on IO effects or separate them out into different monads), it usually lives outside the language. I don't think these are problems with existing AME scheduling mechanisms, rather, they are a problem with a lack of specification of the various algebrae that comprise IO. --- Nevertheless, what Carmack seems to be describing is GC (with card tables, I guess). He wants more control, but like many, doesn't quite seem to grasp what that control needs to be. There are allocation patterns where lifetime is almost statically determined by control flow, programmers can see these clearly, but sometimes have trouble describing what these patterns are in a composable way. Such thinking is where systems like Rust and linear types come from, but neither feel like they describe the full picture. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely may reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to deny you those rights would be illegal without prior contractual agreement. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
