On Fri, Feb 27, 2009 at 11:10 PM, Ryan Ingram ryani.s...@gmail.com wrote:
It's obvious that anything that accesses the STT constructor will
potentially not be typesafe; the question I have is that whether you
can construct something that isn't typesafe just via the use of runSTT
lift.
To my
Ryan Ingram ryani.s...@gmail.com wrote in article
2f9b2d30902151615n1e8e25e8ubbee20d93c8ec...@mail.gmail.com in
gmane.comp.lang.haskell.cafe:
You can roll your own pure STT monad, at the cost of performance:
Do you (or anyone else) know how to prove this STT implementation
type-safe? It seems
Hmm, that's a really good question now that you mention it.
So, the implementation given is trivially *not* type-safe; eventually
the Int index will wrap around and reuse indices at the potentially
wrong type.
But lets say you replaced IntMap with Map Integer, to avoid this problem.
A simple
I note that all of your broken issues revolve around calls that
can't be written in terms of lift; that is, you need access to the STT
constructor in order to create these problems.
It's obvious that anything that accesses the STT constructor will
potentially not be typesafe; the question I have
Louis Wasserman wasserman.lo...@gmail.com wrote in article
ab4284220902160801x51e6c3b6m3a7ee0698ac97...@mail.gmail.com in
gmane.comp.lang.haskell.cafe:
The point here is that a MonadST instance guarantees that the bottom monad
is an ST -- and therefore single-threaded of necessity -- and
