Send Beginners mailing list submissions to beginners@haskell.org To subscribe or unsubscribe via the World Wide Web, visit http://www.haskell.org/mailman/listinfo/beginners or, via email, send a message with subject or body 'help' to beginners-requ...@haskell.org
You can reach the person managing the list at beginners-ow...@haskell.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Beginners digest..." Today's Topics: 1. database question (Gaius Hammond) 2. Re: database question (Daniel Fischer) 3. Re: database question (Gaius Hammond) 4. Re: database question (Daniel Fischer) 5. Re: The cost of generality, or how expensive is realToFrac? (Greg) ---------------------------------------------------------------------- Message: 1 Date: Sat, 18 Sep 2010 19:40:58 +0100 From: Gaius Hammond <ga...@gaius.org.uk> Subject: [Haskell-beginners] database question To: Haskell Beginners List <beginners@haskell.org> Message-ID: <2351cb72-36c6-411d-b0c8-3cc33bb0c...@gaius.org.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hi all, I am trying to write the simplest possible database program in a monadic style. The aim of the program is to connect to the database, run a query, then print the results. My approach is - use the Reader monad to pass around the connection handle (lda) to the database - use the Writer monad to store the result set (rs) on its way back out - converted into [String] (one String per row) My code is: module Main where import Control.Monad.Reader import Control.Monad.Writer import Database.HDBC import Database.HDBC.Sqlite3 runDbApp lda f = do (a, rs) <- runWriterT (runReaderT f lda) return rs doQuery::MonadIO m => ReaderT Connection (WriterT [String] m) () doQuery = do lda <- ask -- get the database handle from the Reader rs <- quickQuery lda "select datetime ('now')" [] let rs' = map convRow rs mapM_ tell rs' -- store the results in the Writer where convRow [x] = (fromSql x)::String main = handleSqlError $ do lda <- connectSqlite3 "test.db" rs <- runDbApp lda $ doQuery mapM_ putStrLn rs -- end of file And the error is home/gaius/Projects/MonadDb/MonadDb.hs:15:2: Couldn't match expected type `IO [[SqlValue]]' against inferred type `ReaderT Connection (WriterT [String] m) [[SqlValue]]' In a stmt of a 'do' expression: rs <- quickQuery lda "select datetime ('now')" [] Why does it think that that is the final expression of the function? Any advice greatly appreciated. I have been struggling with this since lunchtime! Thanks, G ------------------------------ Message: 2 Date: Sat, 18 Sep 2010 22:03:42 +0200 From: Daniel Fischer <daniel.is.fisc...@web.de> Subject: Re: [Haskell-beginners] database question To: beginners@haskell.org Message-ID: <201009182203.42356.daniel.is.fisc...@web.de> Content-Type: text/plain; charset="iso-8859-1" On Saturday 18 September 2010 20:40:58, Gaius Hammond wrote: > Hi all, > > > > I am trying to write the simplest possible database program in a > monadic style. The aim of the program is to connect to the database, > run a query, then print the results. My approach is > > > - use the Reader monad to pass around the connection handle (lda) to > the database > - use the Writer monad to store the result set (rs) on its way back > out - converted into [String] (one String per row) > > > > My code is: > > > > module Main where > > import Control.Monad.Reader > import Control.Monad.Writer > import Database.HDBC > import Database.HDBC.Sqlite3 > > runDbApp lda f = > do (a, rs) <- runWriterT (runReaderT f lda) > return rs > > doQuery::MonadIO m => ReaderT Connection (WriterT [String] m) () > doQuery = do > lda <- ask -- get the database handle from the Reader > rs <- quickQuery lda "select datetime ('now')" [] > > let rs' = map convRow rs > mapM_ tell rs' -- store the results in the Writer > > where convRow [x] = (fromSql x)::String > > main = handleSqlError $ do > lda <- connectSqlite3 "test.db" > rs <- runDbApp lda $ > doQuery > > mapM_ putStrLn rs > > -- end of file > > > > > And the error is > > > > > home/gaius/Projects/MonadDb/MonadDb.hs:15:2: > Couldn't match expected type `IO [[SqlValue]]' > against inferred type `ReaderT > Connection (WriterT [String] m) > [[SqlValue]]' > In a stmt of a 'do' expression: > rs <- quickQuery lda "select datetime ('now')" [] > > > > > > Why does it think that that is the final expression of the function? It doesn't, but you said the do-expression had type ReaderT Connection (WriterT [String] m) () while quickQuery :: IConnection conn => conn -> String -> [SqlValue] -> IO [[SqlValue]] The types don't match, hence the error. But you have a MonadIO constraint, so rs <- liftIO $ quickQuery ... should fix it. > Any advice greatly appreciated. I have been struggling with this since > lunchtime! > Hopefully it didn't stop you from eating. Cheers, Daniel ------------------------------ Message: 3 Date: Sat, 18 Sep 2010 21:30:46 +0100 From: Gaius Hammond <ga...@gaius.org.uk> Subject: Re: [Haskell-beginners] database question To: Daniel Fischer <daniel.is.fisc...@web.de> Cc: beginners@haskell.org Message-ID: <7c43e05f-3480-4e54-a06a-f1f053c3b...@gaius.org.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On 18 Sep 2010, at 21:03, Daniel Fischer wrote: >> >> >> Why does it think that that is the final expression of the function? > > It doesn't, but you said the do-expression had type > ReaderT Connection (WriterT [String] m) () > while > > quickQuery :: IConnection conn => > conn -> String -> [SqlValue] -> IO [[SqlValue]] > > The types don't match, hence the error. But you have a MonadIO > constraint, > so > > rs <- liftIO $ quickQuery ... > > should fix it. > Aha! It does indeed, thanks :-) I had assumed that with the rs <- quickQuery I was getting the [[SqlValue]] "out" of the IO Monad - but I have to lift it into the IO Monad first, since I am in a monadic context? This would be the non- monadic version module Main where import Database.HDBC import Database.HDBC.Sqlite3 main:: IO () main = do lda <- connectSqlite3 "test.db" rs <- quickQuery lda "select datetime ('now')" [] mapM_ putStrLn (map convRow rs) where convRow [x] = (fromSql x)::String -- EOF Oh, but I am already in the IO monad there aren't I.... And doQuery *isn't* but I have declared that it *should be* (e.g. an instance of typeclass MonadIO). Is that accurate? >> Any advice greatly appreciated. I have been struggling with this >> since >> lunchtime! >> > > Hopefully it didn't stop you from eating. Nothing could do that :-) Cheers, G ------------------------------ Message: 4 Date: Sat, 18 Sep 2010 22:49:41 +0200 From: Daniel Fischer <daniel.is.fisc...@web.de> Subject: Re: [Haskell-beginners] database question To: Gaius Hammond <ga...@gaius.org.uk> Cc: beginners@haskell.org Message-ID: <201009182249.41831.daniel.is.fisc...@web.de> Content-Type: text/plain; charset="iso-8859-1" On Saturday 18 September 2010 22:30:46, Gaius Hammond wrote: > On 18 Sep 2010, at 21:03, Daniel Fischer wrote: > >> Why does it think that that is the final expression of the function? > > > > It doesn't, but you said the do-expression had type > > ReaderT Connection (WriterT [String] m) () > > while > > > > quickQuery :: IConnection conn => > > conn -> String -> [SqlValue] -> IO [[SqlValue]] > > > > The types don't match, hence the error. But you have a MonadIO > > constraint, > > so > > > > rs <- liftIO $ quickQuery ... > > > > should fix it. > > Aha! It does indeed, thanks :-) > > > > I had assumed that with the rs <- quickQuery I was getting the > [[SqlValue]] "out" of the IO Monad Sort of, but only in a do-block of type IO something, you had it in a do- block of type ReaderT Connection (WriterT [String] m) something There it doesn't type-check. Remember, do a <- act otherAct a is syntactic sugar for act >>= otherAct The type of (>>=) says the monads on both sides must be the same. > - but I have to lift it into the IO > Monad first, since I am in a monadic context? No, you have to lift the IO-action (quickQuery args) into the MonadIO ReaderT Connection (WriterT [String] m), liftIO :: MonadIO m => IO a -> m a lifts IO-actions to another monad. > This would be the non- > monadic version > > > > > module Main where > > import Database.HDBC > import Database.HDBC.Sqlite3 > > main:: IO () > main = do lda <- connectSqlite3 "test.db" > rs <- quickQuery lda "select datetime ('now')" [] > > mapM_ putStrLn (map convRow rs) > where convRow [x] = (fromSql x)::String > > -- EOF > > > > Oh, but I am already in the IO monad there aren't I. Yup, in main, you're in IO. > ... And doQuery > *isn't* but I have declared that it *should be* (e.g. an instance of > typeclass MonadIO). Is that accurate? > No, MonadIO says, you can run IO-actions from inside that monad, but you have to lift them in order to run them (except the MonadIO you use is IO itself). You said that you wanted to be able to do that, but forgot the lifting. > >> Any advice greatly appreciated. I have been struggling with this > >> since > >> lunchtime! > > > > Hopefully it didn't stop you from eating. > > Nothing could do that :-) Glad to read that. ------------------------------ Message: 5 Date: Sat, 18 Sep 2010 17:41:36 -0700 From: Greg <gregli...@me.com> Subject: Re: [Haskell-beginners] The cost of generality, or how expensive is realToFrac? To: beginners@haskell.org Message-ID: <4eea6603-57e5-4f1f-a53c-4a87205ba...@me.com> Content-Type: text/plain; charset="us-ascii" > It would be interesting to see what core GHC produces for that (you can get > the core with the `-ddump-simpl' command line flag [redirect stdout to a > file] or with the ghc-core tool [available on hackage]). > If it runs as fast as realToFrac :: Double -> Float (with optimisations), > GHC must have rewritten realToFrac to double2Float# and it should only do > that if there are rewrite rules for GLclampf. I'm not sure if you literally meant you wanted to see the output or not, but I've attached a zip of the dump files and my simple source file. The dump file naming is cryptic, but the first letters refer to the definition of 'convert' where: fTF: use the floatToFloat function in the source file rTF: use the standard realToFrac fRtR: use (fromRational . toRational) The next three characters indicate the type signature of convert: d2f: Double -> Float d2g: Double -> GL.GLclampf I'd summarize the results, but apparently I took the blue pill and can't make heads or tails of what I'm seeing in the dump format... > In that case, the problem is probably that GHC doesn't see the realToFrac > applications because they're too deeply wrapped in your coordToCoord2D > calls. > If that is the problem, it might help to use {-# INLINE #-} pragmas on > coordToCoord2D, fromCartesian2D and toCartesian2D. > Can you try with realToFrac and the {-# INLINE #-} pragmas? I tried inlining the functions you suggest with little effect. The realToFrac version (in this case I just set floatToFloat=realToFrac to save the search and replace effort) is just too heavily loaded to see any difference at all (98+% of CPU is spent in realToFrac). The same inlining using my definition of floatToFloat gave me a 10% improvement from 50% -> 46% of the CPU spent in floatToFloat and an inverse change in allocation to match. Best I can tell, the inlining is being recognized, but just not changing much. >> >> And still ran faster than floatToFloat. However there's no denying that >> floatToFloat runs *much* faster than realToFrac in the larger >> application. Profiling shows floatToFloat taking about 50% of my CPU > > That's too much for my liking, a simple conversion from Double to Float > shouldn't take long, even if the Float is wrapped in newtypes (after all, > the newtypes don't exist at runtime). Agreed. The rest of the application right now isn't doing a lot of work yet though-- I'm generating (pre-calculating, if Haskell is doing it's job) a list of 360*180 points on a sphere and dumping that to OpenGL which should be doing most of the dirty work in hardware. I'm not entirely sure why floatToFloat recalculates every iteration and isn't just cached, but I'm guessing it's because the floatToFloat is being done in an OpenGL callback within the IO monad. Eventually I'll be providing time-varying data anyway, so the conversions will have to be continuously recalculated in the end. That comes out to 65000 conversions every 30ms, or about 2 million conversions a second. I'd probably just leave it at that except, as you've demonstrated, there is at least a factor of 3 or 4 to be gained somehow-- realToFrac can provide it under the right conditions. >> {-# RULES >> "floatToFloat/id" floatToFloat=id >> "floatToFloat x2" floatToFloat . floatToFloat = floatToFloat >> #-} >> >> Neither of which seems to fires in this application, > > GHC reports fired rules with -ddump-simpl-stats. > Getting rules to fire is a little brittle, GHC does not try too hard to > match expressions with rules, and if several rules match, it chooses one > arbitrarily, so your rules may have been missed because the actual code > looked different (perhaps because other rewrite rules fired first). Yeah, I've been looking at the -ddump-simp-stats output. If I'm reading the documentation right, rules are enabled simply by invoking ghc with -O or -O2, right? I'm now not convinced any of my rewrite rules are firing-- or at least I can't seem to get them to again. >> I get a compile time error that I can't make sense of. It's asking me >> to put a context on my rule, but I can't find any references on how to >> do that... >> >> ----------- >> >> Could not deduce (Num a) >> from the context (Coord2D (Vertex2 a), Coord2D (a, a)) >> arising from a use of `pair2vertex' >> at GCB/OpenGL/Geometry.hs:32:40-50 >> Possible fix: >> add (Num a) to the context of the RULE "coordToCoord2D/p2v2" >> In the expression: pair2vertex >> When checking the transformation rule "coordToCoord2D/p2v2" > > Yes, there's a Num constraint on pair2vertex, but not on coordToCoord2D, so > it's not type correct. > You could try removing the Num constraint from pair2vertex or add the > constraint to the rule, > > {-# RULES > "coordToCoord2D/p2v2" forall a. Num a => (coordToCoord2D :: (a,a) -> > GL.Vertex2 a) = pair2vertex > #-} > > (well, I don't know whether that's the correct way, but you can try). No, that doesn't do it. I tried a few variations on that and it always chokes on the => symbol or whatever other syntax I try to use. The Num constraint was added because it was needed on related functions (3 element vertices where the z was stuffed with 0, for example), so I got rid of those and the Num constraint. Doesn't matter, the rule still doesn't fire... =( Cheers-- Greg -------------- next part -------------- A non-text attachment was scrubbed... Name: TypeConversions.zip Type: application/zip Size: 8904 bytes Desc: not available Url : http://www.haskell.org/pipermail/beginners/attachments/20100918/ad811812/TypeConversions.zip ------------------------------ _______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners End of Beginners Digest, Vol 27, Issue 43 *****************************************