ECTED] On Behalf Of
| Chad Scherrer
| Sent: 19 July 2006 23:02
| To: haskell-cafe@haskell.org
| Subject: [Haskell-cafe] REALLY simple STRef examples
|
| I've looked around at the various STRef examples out there, but still
| nothing I write myself using this will work. I'm trying to figure
s no problem
if you don' use the higher order function $. Use parens instead
x = runST (return 1)
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
| Chad Scherrer
| Sent: 19 July 2006 23:02
| To: haskell-cafe@haskell.org
| Su
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 i
Hello Bryan,
Saturday, July 22, 2006, 4:40:58 AM, you wrote:
> Forgive me for not understanding, but I was hoping you would explain a
> choice you made in your code. Why did you define foreach and then use
>> foreach [1..n] (\x -> modifySTRef r (*x))
> Instead of simply using
>> mapM_ (\x -> mo
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
i
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 :: (M
The IO monad hasn't given me too much trouble, but I want to be sure
to structure things the way "they should be". If I get everything
running using IO first and then have type-checking problems with ST,
it will be tempting to just slap on an unsafePerformIO and call it
good. Sure, it's really doi
| > | ps: you successfully going through all the standard Haskell
troubles
| > in
| > | this area :) seems that making FAQ about using ST monad will be a
| > | good idea :)
|
| > Indeed. If someone would like to start one, a good place for it
would be
| > GHC's collaborative-documentation Wiki
|
Hello Simon,
Friday, July 21, 2006, 7:46:15 AM, you wrote:
> | ps: you successfully going through all the standard Haskell troubles
> in
> | this area :) seems that making FAQ about using ST monad will be a
> | good idea :)
> Indeed. If someone would like to start one, a good place for it would
| ps: you successfully going through all the standard Haskell troubles
in
| this area :) seems that making FAQ about using ST monad will be a
| good idea :)
Indeed. If someone would like to start one, a good place for it would be
GHC's collaborative-documentation Wiki
http://haskell.org/
Chad Scherrer wrote:
> But why should this...
>
> >sumArrays [] = error "Can't apply sumArrays to an empty list"
> >sumArrays (x:xs) = runSTArray (result x)
> >where
> >result x = do x0 <- thaw x
> > mapM_ (x0 +=) xs
> > return x0
>
> work differently tha
Ok, I see now why the return is necessary. For now I'll switch to
boxed arrays until I get the rest of this down better.
But why should this...
sumArrays [] = error "Can't apply sumArrays to an empty list"
sumArrays (x:xs) = runSTArray (result x)
where
result x = do x0 <- thaw x
Hello Chad,
Thursday, July 20, 2006, 9:38:43 PM, you wrote:
> I suppose the same holds for runSTUArray, right? But this still gives
> me that same error, about being less polymorphic than expected.
there is well-known problem with that _unboxed_ arrays aren't
polymorphic. Oleg Kiselyov proposed
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.
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
Chad Scherrer wrote:
> x = runST $ return 1
>
> y = runST $ do {r <- newSTRef 1; readSTRef r}
>
> Neither of these works in ghci
x = runST (return 1)
y = runST (do {r <- newSTRef 1; readSTRef r})
The escaping s is something to do with rank 2 polymorphism.
(Search for "rank" in the ghc user guid
I've looked around at the various STRef examples out there, but still
nothing I write myself using this will work. I'm trying to figure out
how the s is escaping in really simple examples like
x = runST $ return 1
y = runST $ do {r <- newSTRef 1; readSTRef r}
Neither of these works in ghci - th
17 matches
Mail list logo
