Thanks, Simon. I've begun putting together some text describing very
simple STRef examples, as Bulat suggested earlier. I think I know how
to make it work, but I'll still need to work on typing subtleties. I'm
headed to bed now, but I'll go through this in detail when I get a
chance to try to get
Chad
| x = runST $ return (1::Int)
This code looks simple, but it isn't. Here are the types:
runST :: forall a. (forall s. ST s a) - a
($) :: forall b c. (b-c) - b - c
return 1 :: forall s. ST s Int
To typecheck, we must instantiate
b with (forall s. ST
Yes, largely the choice to define foreach was made to try and make it
look more imperative, I showed it to an imperative programmer to try and
convince him that you could program in an imperative way in Haskell if
you really wanted to, that and I thought it'd an imperative style would
make an
Not totally relevant to what the discussion has evolved to, but I wrote
a factorial function using STRefs (in the spirit of the Evolution of a
Haskell programmer) and I think it qualifies as a really simple example.
Code follows:
import Data.STRef
import Control.Monad.ST
foreach ::
On 7/21/06, S C Kuo [EMAIL PROTECTED] wrote:
Not totally relevant to what the discussion has evolved to, but I wrote
a factorial function using STRefs (in the spirit of the Evolution of a
Haskell programmer) and I think it qualifies as a really simple example.
Code follows:
import Data.STRef
Whoa. That changes everything I thought I knew about ($). Come to
think of it, one of the examples that does work it written
main = print $ runST f
where f is defined separtely. So that's consistent.
I'll take a look at the references. Thanks!
Indeed. The short answer: use
runST (long
Hi,
The short answer: use
runST (long expression)
rather than
runST $ long expression
when it comes to higher-ranked functions such as runST.
I suppose the same holds for runSTUArray, right? But this still gives
me that same error, about being less polymorphic than expected.
