gmane.comp.lang.haskell.beginners

Re: Stymied by mutable arrays in the ST monad

Matthew Moppett — 2012-05-25T18:25:37

Brilliant. I think I've got it now. Thanks heaps, Tobias.

On Sat, May 26, 2012 at 4:01 AM, Tobias Brandt <tob.brandt< at >googlemail.com>wrote:

Re: Stymied by mutable arrays in the ST monad

Matthew Moppett — 2012-05-25T17:43:04

Thanks, Tobias.

I guess my eyes kind of glazed over when I read "getElems :: (MArray a e
m, Ix i) => a i e -> m [e]" in the docs, and didn't relate that to the
meaning of "return"... lesson learnt.

About the extra type info needed -- what part of the type "ST s (STArray s
Int Int)" is the compiler unable to infer?

I've worked out from this that the error message "no instance for"... might
signal a missing type signature, but I'm having trouble working out the
general lesson of when the compiler needs some extra hints.


On 25 May 2012 18:50, Matthew Moppett <matthewmoppett< at >gmail.com> wrote:

'getElems array' already has type 'ST s [Int]', you don't need
another 'return'. Furthermore you need to help out with the type
inference a little bit (it's similar to the read-show problem).
This should work:

idST :: [Int] -> [Int]
idST xs = runST $ do
   array <- newListArray (1, (length xs)) xs :: ST s (STArray s Int Int)
   getElems array

(You could also replace STArray by STUArray.)

Re: Stymied by mutable arrays in the ST monad

Tobias Brandt — 2012-05-25T17:05:01

'getElems array' already has type 'ST s [Int]', you don't need
another 'return'. Furthermore you need to help out with the type
inference a little bit (it's similar to the read-show problem).
This should work:

idST :: [Int] -> [Int]
idST xs = runST $ do
    array <- newListArray (1, (length xs)) xs :: ST s (STArray s Int Int)
    getElems array

(You could also replace STArray by STUArray.)

Stymied by mutable arrays in the ST monad

Matthew Moppett — 2012-05-25T16:50:57

I've been trying to use mutable arrays in the ST monad, and wrote out a
little proof of concept function:

idST :: [Int] -> [Int]
idST xs = runST $ do
    array <- newListArray (1, (length xs)) xs
    return (getElems array)

Re: Missing some functions in Hoogle

Ken Kawamoto — 2012-05-25T14:04:26

Thanks Paulo for your comment and sorry for late reply.

On Tue, May 22, 2012 at 11:09 PM, Paulo Pocinho <pocinho< at >gmail.com> wrote:

What does this part mean?
With Hoogle package, you can generate databases for any library, but
the search works only for standard libraries?

Although this is consistent with what I experienced, it's a bit
surprising because this means generating database doesn't make any
sense, does it?

Hayhoo seems to suit what I want.

Re: Help!,was Re: Trouble with "import qualified"

Brandon Allbery — 2012-05-24T17:46:06



In particular, it was recently found that GHC doesn't ignore the byte order
marks that some versions of Notepad and friends prepend to text files even
in UTF8 mode.

Re: Help!, was Re: Trouble with "import qualified"

Brent Yorgey — 2012-05-24T17:43:11

When you say "had this up", what do you mean?  I don't see any other
messages from you to the haskell-beginners list.


It's impossible to tell what's wrong only from this description.  If
you upload an *exact* copy of your file somewhere (e.g. hpaste.org)
I'm sure someone could take a look.  Some general things to watch out
for:

  * the real error could be in the previous line to the one being
    reported

  * all the imports have to come at the very beginning of a module

  * don't put any spaces or tabs before "import"

-Brent

Re: Help!,was Re: Trouble with "import qualified"

Michael Orlitzky — 2012-05-24T17:35:49

For a second I was sure I sent this to the wrong list =)

If the OP doesn't see any misplaced whitespace at the beginning of the
file, I'd also check that there's isn't any unicode junk there.

Re: Help!,was Re: Trouble with "import qualified"

Tim Perry — 2012-05-24T17:23:45

It sounds mostly likely that there were spaces or tabs in the wrong place.

Good luck....

On Thu, May 24, 2012 at 9:58 AM, Keshav Kini <keshav.kini< at >gmail.com> wrote:

Re: Help!,was Re: Trouble with "import qualified"

Keshav Kini — 2012-05-24T16:58:53

I doubt this really matters when it comes to import statements, but note
that the Haskell platform's latest release is using GHC/GHCi version
7.0.4.

(hi mjo :) )

-Keshav

Re: Help!,was Re: Trouble with "import qualified"

Michael Orlitzky — 2012-05-24T16:49:59

Try starting from a fresh file? I just tried the simplest thing I could
think of to reproduce this, but it worked:

jumba ~ $ echo "import qualified Data.Map as Map" >> test.hs
jumba ~ $ echo "main = print \"Hello, World\"" >> test.hs
jumba ~ $ runhaskell test.hs
"Hello, World"
jumba ~ $ ghci
GHCi, version 7.4.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :l test.hs
[1 of 1] Compiling Main             ( test.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package containers-0.4.2.1 ... linking ... done.
"Hello, World"
*Main>

Help!, was Re: Trouble with "import qualified"

Dudley Brooks — 2012-05-24T16:34:22

Hi.  I've had this up for over a week, and haven't received any 
response.  Any help would be greatly appreciated.

On 5/16/12 10:04 PM, Dudley Brooks wrote:

Re: Traverse tree with computing current level using Foldable instance.

Brent Yorgey — 2012-05-24T12:54:23

By the way, for this sort of pattern where you change the state for
some subcomputation and then restore it after the subcomputation
returns, it can be much nicer to use the Reader monad with the 'local'
function instead of the State monad.  That might actually go a long
way towards making the monadic version nicer to read. =)

-Brent

Re: Traverse tree with computing current level using Foldable instance.

Dmitriy Matrosov — 2012-05-24T11:09:24

Hi, Chaddaï. Thanks for the clarification!

Now i think i get it. Here is three my solutions. First one is (as you 
suggest)
without monads:

 > import Data.Monoid
 > import Control.Monad.State
 >
 > data Tape a             =  Tape a [Tape a]
 >
 > foldTape :: (a -> [b] -> b) -> Tape a -> b
 > foldTape f (Tape name ts)
 >                         = f name (map (foldTape f) ts)
 >
 > foldTapeD :: (Monoid m) => (Int -> a -> m) -> Tape a -> m
 > foldTapeD f t           = (foldTape (go f) t) 0
 >   where
 >     go :: (Monoid m) => (Int -> a -> m) -> a -> [(Int -> m)] -> (Int 
-> m)
 >     go f name xs        = \cs ->
 >                           foldr (mappend . ($ (cs + 1))) (f cs name) xs

second one with monadic go function:

 > foldTapeD1 :: (Monoid m) => (Int -> a -> m) -> Tape a -> m
 > foldTapeD1 f t          = fst $ runState (foldTape (go f) t) 0
 >   where
 >     go :: (Monoid m) => (Int -> a -> m) -> a -> [State Int m] -> 
State Int m
 >     go f name xs        = do
 >                             cs <

Re: [Haskell-cafe] Most C++ compilers will not optimize x^2.0 as x*x but instead will do an expensive ...

Bardur Arantsson — 2012-05-24T03:33:38

I don't think anyone's disputing that, it's just that the form of many
of his/her messages + lack of threading means that they'll get ignored
(because they don't make sense without context... which is unavailable)
or that KC will get killfiled (after seeing enough "meaningless"
messages from a person this tends to happen). Which would be a shame.

Regards,

Re: [Haskell-cafe] Most C++ compilers will not optimize x^2.0 as x*x but instead will do an expensive ...

Tom Murphy — 2012-05-24T03:24:04

Just to play devil's advocate, if you look back at the list, KC has
written a lot of helpful and informative messages in the past.

Tom

On 5/23/12, Bardur Arantsson <spam< at >scientician.net> wrote:

Re: [Haskell-cafe] Most C++ compilers will not optimize x^2.0 as x*x but instead will do an expensive ...

Bardur Arantsson — 2012-05-24T02:39:34

Right. I was actually just about to respond to (only) KC in person, but
perhaps unwisely, decided to "hijack" your response to add a little
explanation for everyone.

You are of course right that not quoting context and just randomly
spewing out small bits of text is not really suitable for a mailing list.

Re: [Haskell-cafe] Most C++ compilers will not optimize x^2.0 as x*x but instead will do an expensive ...

Brandon Allbery — 2012-05-24T02:31:32


That, however, ignores the rest of it; the lack of references in this case
forms a pattern with the other things I noted, in that a conversation is
apparently being held in the form of single observations emitted at the
point of observation instead of being collected and presented *as* a
conversation.

Re: Most C++ compilers will not optimize x^2.0 as x*x but instead will do an expensive ...

Brandon Allbery — 2012-05-24T02:13:33


Is it me or is this style of message — content broken between subject and
body, no reference information tying it to the presumed topic (or possibly
a /non sequitur/) — better suited to Twitter than a mailing list?

Most C++ compilers will not optimize x^2.0 as x*x but instead will do an expensive ...

KC — 2012-05-24T01:47:31

exponentiation and logarithm.

So, I believe this C++ versus Haskell versus (your language of choice) is a
Penn & Teller misdirection.

Whereas, another level of indirection solves everything.

Re: Traverse tree with computing current level using Foldable instance.

Chaddaï Fouché — 2012-05-23T16:48:27

So, you wrote it correctly :


This appears desperate since there's no mention of Int anywhere in
this function and the function applied stay the same whatever the
level : the initially given f parameter.
But there's a trick to this, we'll have to treat some of our type
variable like functions, here only b can vary freely (a is imposed by
the Tape a inputted), so let's see what it looks like if we make it a
functional type (with Int parameter):


much more promising wouldn't you say ? The solution now looks like that :


I let you write your solution (if you didn't find before tomorrow
evening, I'll give you the answer).

You can then call foldTapeD thus :


(much nicer than your initial solution, is it not ?)