From paolo.veronelli at gmail.com Thu Jan 1 02:01:57 2009 From: paolo.veronelli at gmail.com (Paolino) Date: Thu Jan 1 01:53:50 2009 Subject: [Haskell-cafe] WriterT [w] IO is not lazy in reading [w] In-Reply-To: <1230757192.31199.4.camel@derek-laptop> References: <1230757192.31199.4.camel@derek-laptop> Message-ID: I must ask why runWriterT k :: State s (a,[Int]) is working. Looks like I could runIO the same way I evalState there. In that case I wouldn't wait for the State s action to finish. Thanks 2008/12/31 Derek Elkins > On Wed, 2008-12-31 at 21:48 +0100, Paolino wrote: > > As someone suggested me, I can read the logs from Writer and WriterT as > computation goes by, > > if the monoid for the Writer is lazy readable. > > This has been true until I tried to put the IO inside WriterT > > > > > > > {-# LANGUAGE FlexibleContexts #-} > > > import Control.Monad.Writer > > > > > > > k :: (MonadWriter [Int] m) => m [Int] > > > > > k = let f x = tell [x] >> f (x + 1) in f 0 > > > > > > > works :: [Int] > > > works = snd $ runWriter k > > > > > > > hangs :: IO [Int] > > > hangs = snd `liftM` runWriterT k > > runWriterT :: MonadWriter w m a => WriterT w m a -> m (a, w) > > which is to say runWriterT k :: IO (a, [Int]) > > It's not going to return anything until the IO action terminates, which is > to say never. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090101/bea54add/attachment.htm From paolo.veronelli at gmail.com Thu Jan 1 02:20:47 2009 From: paolo.veronelli at gmail.com (Paolino) Date: Thu Jan 1 02:12:39 2009 Subject: [Haskell-cafe] WriterT [w] IO is not lazy in reading [w] In-Reply-To: <2f9b2d30812311301y1068b499u77fa12ef0cd44647@mail.gmail.com> References: <2f9b2d30812311301y1068b499u77fa12ef0cd44647@mail.gmail.com> Message-ID: How do I read "IO is not lazy" ? Is IO (>>=) forcing the evaluation of its arguments, causing the unwanted neverending loop? And, this happens even in (MonadTrans t => t IO) (>>=) ? Thanks paolino 2008/12/31 Ryan Ingram > IO is not lazy; you never make it to "print". > > Consider this program: > > > k = f 0 where > > f n = do > > lift (print n) > > tell [n] > > f (n+1) > > > weird :: IO [Int] > > weird = do > > (_, ns) <- runWriterT k > > return (take 20 ns) > > What should "weird" print? According to "k", it prints every Int from > 0 up. Aside from the extra printing, it has the same behavior as your > writer. > > For the result of a WriterT to be lazy readable, you need both the > monoid to be lazy readable, and the transformed monad to be lazy, > which IO isn't. > > -- ryan > > 2008/12/31 Paolino : > > As someone suggested me, I can read the logs from Writer and WriterT as > > computation goes by, > > if the monoid for the Writer is lazy readable. > > This has been true until I tried to put the IO inside WriterT > > > > > >> {-# LANGUAGE FlexibleContexts #-} > >> import Control.Monad.Writer > > > > > >> k :: (MonadWriter [Int] m) => m [Int] > > > >> k = let f x = tell [x] >> f (x + 1) in f 0 > > > > > >> works :: [Int] > >> works = snd $ runWriter k > > > > > >> hangs :: IO [Int] > >> hangs = snd `liftM` runWriterT k > > > > > >> main = take 20 `liftM` hangs >>= print > > > > > > > > The main hangs both interpreted and compiled on ghc 6.10.1. > > > > The issue is not exposing with IO alone as > > > > main = print "test" >> main > > > > is a working program. > > > > Thanks for explanations. > > > > > > paolino > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090101/2a100b82/attachment.htm From max.cs.2009 at googlemail.com Thu Jan 1 02:32:13 2009 From: max.cs.2009 at googlemail.com (Max.cs) Date: Thu Jan 1 02:24:14 2009 Subject: [Haskell-cafe] definition of data Message-ID: <72BD3446DDCA468BB5237C62EA7B780B@hxzhao> hi all, I want to define a data type Tree a that can either be a or Branch (Tree a) (Tree a)? I tried data Tree a = a | Branch (Tree a) (Tree a) deriving Show but it seems not accpetable in haskell ? any way I could achieve this ? Thanks max -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090101/11fad6a9/attachment.htm From allbery at ece.cmu.edu Thu Jan 1 02:35:55 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Jan 1 02:28:11 2009 Subject: [Haskell-cafe] definition of data In-Reply-To: <72BD3446DDCA468BB5237C62EA7B780B@hxzhao> References: <72BD3446DDCA468BB5237C62EA7B780B@hxzhao> Message-ID: On 2009 Jan 1, at 2:32, Max.cs wrote: > data Tree a = a | Branch (Tree a) (Tree a) deriving Show > > but it seems not accpetable in haskell ? You need a constructor in both legs of the type: > data Tree a = Leaf a | Branch (Tree a) (Tree a) deriving Show -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090101/8ddd680d/attachment.htm From aneumann at inf.fu-berlin.de Thu Jan 1 02:37:30 2009 From: aneumann at inf.fu-berlin.de (Adrian Neumann) Date: Thu Jan 1 02:29:43 2009 Subject: [Haskell-cafe] definition of data In-Reply-To: <72BD3446DDCA468BB5237C62EA7B780B@hxzhao> References: <72BD3446DDCA468BB5237C62EA7B780B@hxzhao> Message-ID: <5196B98D-8E43-4916-AB27-FE66808E7873@inf.fu-berlin.de> You need some type constructor: data Tree a = Leaf a | Branch (Tree a) (Tree a) Am 01.01.2009 um 08:32 schrieb Max.cs: > hi all, I want to define a data type Tree a that can either be a > or Branch (Tree a) (Tree a)? > > I tried > > data Tree a = a | Branch (Tree a) (Tree a) deriving Show > > but it seems not accpetable in haskell ? > > any way I could achieve this ? > > Thanks > > max > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: Signierter Teil der Nachricht Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090101/f8acc911/PGP.bin From max.cs.2009 at googlemail.com Thu Jan 1 03:36:24 2009 From: max.cs.2009 at googlemail.com (Max.cs) Date: Thu Jan 1 03:28:29 2009 Subject: [Haskell-cafe] pattern matching on date type In-Reply-To: References: <72BD3446DDCA468BB5237C62EA7B780B@hxzhao> Message-ID: <3D524BA96876446CA9B57BDB8E09605E@hxzhao> thanks! suppose we have > data Tree a = Leaf a | Branch (Tree a) (Tree a) deriving Show and how I could define a function foo :: a -> Tree a that foo a = Leaf a where a is not a type of Tree foo b = b where b is one of the type of Tree (Leaf or Branch) ? The following code seems not working...... foo (Leaf a) = a foo a = Leaf a saying 'Couldn't match expected type `a' against inferred type `Btree a'' any idea? Thanks, Max From: Brandon S. Allbery KF8NH Sent: Thursday, January 01, 2009 7:35 AM To: Max.cs Cc: Brandon S. Allbery KF8NH ; beginners@haskell.org ; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] definition of data On 2009 Jan 1, at 2:32, Max.cs wrote: data Tree a = a | Branch (Tree a) (Tree a) deriving Show but it seems not accpetable in haskell ? You need a constructor in both legs of the type: > data Tree a = Leaf a | Branch (Tree a) (Tree a) deriving Show -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090101/f7240635/attachment.htm From alexander.dunlap at gmail.com Thu Jan 1 04:44:33 2009 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Thu Jan 1 04:36:25 2009 Subject: [Haskell-cafe] Re: [Haskell-beginners] pattern matching on date type In-Reply-To: <3D524BA96876446CA9B57BDB8E09605E@hxzhao> References: <72BD3446DDCA468BB5237C62EA7B780B@hxzhao> <3D524BA96876446CA9B57BDB8E09605E@hxzhao> Message-ID: <57526e770901010144o45750683o37dad7a207f5d8db@mail.gmail.com> On Thu, Jan 1, 2009 at 12:36 AM, Max.cs wrote: > thanks! > > suppose we have > >> data Tree a = Leaf a | Branch (Tree a) (Tree a) deriving Show > > and how I could define a function foo :: a -> Tree a that > > foo a = Leaf a where a is not a type of Tree > foo b = b where b is one of the type of Tree (Leaf or > Branch) ? > > The following code seems not working...... > > foo (Leaf a) = a > foo a = Leaf a > > saying 'Couldn't match expected type `a' against inferred type `Btree a'' > > any idea? > > Thanks, > Max You can't define such a function. foo :: a -> Tree a, but the definition foo b = b has the type a -> a, which is why the compiler says it can't match type "a" against "Tree a". In general, Haskell functions can't "look" at the type of their arguments: they are either monomorphic or are polymorphic, in which case you can only use polymorphic functions that match the polymorphic type. For the problem you are trying to solve, you probably need to encode this logic higher up in the overall function (e.g. have one function to deal with "a"s and another to deal with "Tree a"s). Hope that helps, Alex From bulat.ziganshin at gmail.com Thu Jan 1 04:51:52 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Jan 1 04:45:13 2009 Subject: [Haskell-cafe] pattern matching on date type In-Reply-To: <3D524BA96876446CA9B57BDB8E09605E@hxzhao> References: <72BD3446DDCA468BB5237C62EA7B780B@hxzhao> <3D524BA96876446CA9B57BDB8E09605E@hxzhao> Message-ID: <62282978.20090101125152@gmail.com> Hello Max.cs, Thursday, January 1, 2009, 11:36:24 AM, you wrote: seems that you come from dynamic languages :) Haskell has static typing meaning that your function can accept either Tree or a as arguments. so you should convert a to Tree explicitly, using Leaf > > > thanks! > > ? > > suppose we have > > ? > >> data Tree a = Leaf a | Branch (Tree a) (Tree a) deriving Show > > ? > > and how I could define a function foo :: a -> Tree a that > > ? > > foo a = Leaf a?????????where a is not a type of Tree > > foo b = b?????????????????where b is one of the type of Tree (Leaf or Branch) ? > > ? > > The following code seems not working...... > > ? > > foo (Leaf a) = a > > foo?a = Leaf a > > ? > > saying 'Couldn't match expected type `a' against inferred type `Btree a'' > > ? > > any idea? > > ? > > Thanks, > > Max > > ? > > > > > From: Brandon S. Allbery KF8NH > > Sent: Thursday, January 01, 2009 7:35 AM > > To: Max.cs > > Cc: Brandon S. Allbery KF8NH ; beginners@haskell.org ; haskell-cafe@haskell.org > > Subject: Re: [Haskell-cafe] definition of data > > > > On 2009 Jan 1, at 2:32, Max.cs wrote:? > > > > data Tree a = a |?Branch (Tree a) (Tree a) deriving Show > > ? > > but it seems not accpetable in haskell ? > > > You need a constructor in both legs of the type: > > >> data Tree a = Leaf a | Branch (Tree a) (Tree a) deriving Show > > > > -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From apfelmus at quantentunnel.de Thu Jan 1 05:03:56 2009 From: apfelmus at quantentunnel.de (Apfelmus, Heinrich) Date: Thu Jan 1 04:55:43 2009 Subject: [Haskell-cafe] Re: Updating doubly linked lists In-Reply-To: References: <495B6E91.8050809@van.steenbergen.nl> <2f9b2d30812311311k51d2a5adq48697976cb48af75@mail.gmail.com> Message-ID: S. G?nther wrote: > Untying the knot was (and still is) exactly the problem I was facing. > I knew that the whole list had to be rebuild and wasn't concerned > with performance since at that point I just wanted to know how to > do it and if it is possible at all. After I realized that it maybe just to > hard in the circular case I tried my hand on a non circular version > coming up with the following. > > data DList a = > DLNode {left::(DList a), value::a, right::(DList a)} | > Leaf Whether circular or not, sharing values by using a "back pointer" is problematic for any update. Why not use a zipper instead? data Zipper a = Zip [a] a [a] value :: Zipper a -> a value (Zip _ x _) = x right, left :: Zipper a -> Zipper a left (Zip (l:ls) x rs) = Zip ls l (x:rs) right (Zip ls x (r:rs)) = Zip (x:ls) r rs update :: Zipper a -> a -> Zipper a update (Zip ls _ rs) x = Zip ls x rs In other words, you don't have to implement left and right as record labels, implementing them as normal functions may be better. For more about zippers, see also http://en.wikibooks.org/wiki/Haskell/Zippers There are also some ready-made packages on hackage, like ListZipper . Regards, H. Apfelmus From tom.davie at gmail.com Thu Jan 1 05:04:23 2009 From: tom.davie at gmail.com (Thomas Davie) Date: Thu Jan 1 04:56:18 2009 Subject: [Haskell-cafe] Re: [Haskell-beginners] pattern matching on date type In-Reply-To: <3D524BA96876446CA9B57BDB8E09605E@hxzhao> References: <72BD3446DDCA468BB5237C62EA7B780B@hxzhao> <3D524BA96876446CA9B57BDB8E09605E@hxzhao> Message-ID: <0DF9BA91-8F11-42CA-964C-131A626571EA@gmail.com> On 1 Jan 2009, at 09:36, Max.cs wrote: > thanks! > > suppose we have > > > data Tree a = Leaf a | Branch (Tree a) (Tree a) deriving Show > > and how I could define a function foo :: a -> Tree a that > > foo a = Leaf a where a is not a type of Tree > foo b = b where b is one of the type of Tree (Leaf > or Branch) ? > > The following code seems not working...... > > foo (Leaf a) = a > foo a = Leaf a > > saying 'Couldn't match expected type `a' against inferred type > `Btree a' Hi again Max, I'm assuming this is continuing from the concatT example, and that you're struggling with first function you must pass to foldTree. Remember the type of the function ? it's not a -> Tree a, but Tree a - > Tree a, because your leaves in the parent tree all contain trees to glue on at that point. So, the function you want, is the function which looks at the parameter it's given, goes "oh, that's interesting", does nothing to it, and hands it back to replace the Leaf. I recommend searching hoogle for functions of type a -> a, the function you're looking for is built in. Bob From ryani.spam at gmail.com Thu Jan 1 05:17:59 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Jan 1 05:09:52 2009 Subject: [Haskell-cafe] WriterT [w] IO is not lazy in reading [w] In-Reply-To: References: <1230757192.31199.4.camel@derek-laptop> Message-ID: <2f9b2d30901010217l37ee34b7ve27ce845f78cd672@mail.gmail.com> 2008/12/31 Paolino : > I must ask why runWriterT k :: State s (a,[Int]) is working. > Looks like I could runIO the same way I evalState there. > In that case I wouldn't wait for the State s action to finish. > > Thanks Assuming you have Control.Monad.State.Lazy (which I think is the default), here is the difference: (>>=) for State: ma >>= f = State $ \s0 -> let (a, s1) = runState ma s0 in runState (f a) s1 The "let" is a lazy pattern match; in particular, consider this code: runState (do put 0 put 1) 2 -> desugar runState (put 0 >> put 1) 2 The rest is lazy evaluation in action! -> apply >> runState (put 0 >>= \_ -> put 1) 2 -> apply >>= runState (State $ \s0 -> let (a, s1) = runState (put 0) s0 in runState (put 1) s1 ) 2 -> apply runState (\s0 -> let (a,s1) = runState (put 0) s0 in runState (put 1) s1 ) 2 -> beta reduce let s0 = 2 in let (a,s1) = runState (put 0) s0 in runState (put 1) s1 -> apply put let s0 = 2 in let (a,s1) = runState (put 0) s0 in runState (State $ \_ -> ((), 1)) s1 -> apply runState let s0 = 2 in let (a,s1) = runState (put 0) s0 in (\_ -> ((), 1)) s1 -> beta reduce let s0 = 2 in let (a,s1) = runState (put 0) s0 in ((), 1) -> garbage collect ((), 1) Note that at no point were s0, a, or s1 evaluated; so there was no need to evaluate the state at all! Furthermore, even if you replace (put 0) with a computation that loops and looks at the state at each point, the result is immediately a pair, so future computation can continue. Now lets contrast with IO: (>>=) for IO (taking out the "unboxed pairs" stuff which muddles the issue) ma >>= f = IO $ \s0 -> case (unIO ma s0) of (a, s1) -> unIO (f a) s1 (Note that this is the basically the same as Control.Monad.State.Strict) Consider main = do putStrLn "hello" putStrLn "world" We'll use this definition of putStrLn for simplicity's sake: > -- primitive, unsafe, side-effecting function. > putStrLn# :: String -> () > > putStrLn :: String -> IO () > putStrLn s = IO $ \w -> seq (putStrLn# s) ((), w) So putStrLn is an IO action which takes a "world" (a dummy value that doesn't really exist) as input, and before it gives any output, forces the evaluation of a side-effecting primitive function via seq. It then returns a pair containing the result (), and the original "world" argument as the state. Desugar: main = (putStrLn "hello" >> putStrLn "world") Send to the runtime: unIO (putStrLn "hello" >> putStrLn "world") world# Now lets evaluate it. -> Apply >> unIO (putStrLn "hello" >>= \_ -> putStrLn "world") world# -> Apply >>= unIO (IO $ \w0 -> case unIO (putStrLn "hello") w0 of (a, w1) -> unIO ((\_ -> putStrLn "world") a) w1 -> Apply unIO and beta-reduce case unIO (putStrLn "hello") world# of (a, w1) -> unIO ((\_ -> putStrLn "world") a) w1 Note that the evaluation order is different here; since we have a case statement, we must force the evaluation of the first putStrLn to make sure it evaluates to a pair! -> Apply putStrLn case unIO (IO $ \w -> seq (putStrLn# "hello") ((), w)) world# of (a, w1) -> unIO ((\_ -> putStrLn "world") a) w1 -> apply unIO & beta-reduce case seq (putStrLn# "hello") ((), world#) of (a, w1) -> unIO ((\_ -> putStrLn "world") a) w1 -> seq evaluates putStrLn#, side effect happens here! case ((), world#) of (a, w1) -> unIO ((\_ -> putStrLn "world") a) w1 -> pattern match in case succeeds now let a = () w1 = world# in unIO ((\_ -> putStrLn "world") a) w1 -> beta reduce & garbage collect unIO (putStrLn "world") world# -> apply putStrLn unIO (IO $ \w -> seq (putStrLn# "world") ((), w)) world# -> apply unIO & beta reduce seq (putStrLn# "world") ((), world#) -> seq evaluates putStrLn#, side effect happens here! ((), world#) Now, you are probably wondering for the reason behind the use of "case" vs. "let". It's pretty simple; lets evaluate that last code using the lazy method like State. Everything is the same up to "apply >>=", so start there: unIO (putStrLn "hello" >>= \_ -> putStrLn "world") world# -> Apply >>= unIO (IO $ \w0 -> let (a, w1) = unIO (putStrLn "hello") w0 in unIO (putStrLn "world") w1 ) world# -> apply unIO and beta-reduce let (a, w1) = unIO (putStrLn "hello") world# in unIO (putStrLn "world") w1 -> apply putStrLn (the second one!) let (a, w1) = unIO (putStrLn "hello") world# in unIO (IO $ \w -> seq (putStrLn# "world") ((), w)) w1 -> apply unIO and beta-reduce let (a, w1) = unIO (putStrLn "hello") world# in seq (putStrLn# "world" w1) ((), w1) Now we call putStrLn# which causes a side effect. It ignores the "world" argument and just returns it unchanged, of course. We could also add extra machinery to the compiler to force it to treat the "world" argument as strictly, but you can see that using "lazy" really changes the order of evaluation, which ends up making the code much harder to optimize. -> seq evaluates putStrLn# (printing "world", oops!) let (a,w1) = unIO (putStrLn "hello" world#) in ((), w1) We need w1 here, so we have to force evaluation of the pair to extract it. -> apply putStrLn let (a,w1) = unIO (IO $ \w -> seq (putStrLn# "hello") ((), w)) world# in ((), w1) -> apply unIO & beta-reduce let (a,w1) = seq (putStrLn# "hello") ((), world#) in ((), w1) -> seq evaluates putStrLn#, printing "hello" let (a,w1) = ((), world#) in ((), w1) -> garbage-collect ((), world#) I've omitted some of the details, and this isn't exactly how it works. In particular, I believe GHC's primitive operations take the World# argument directly, so you can argue that this behavior wouldn't happen as long as that argument was considered "strict". But the "lazy" behavior makes the order of evaluation much harder to predict, which I think is considered to be bad for IO, which lives on the "imperative" side of the imperative/functional divide. In particular, unsafeInterleaveIO (and its friend getContents) would be even more difficult to use correctly if IO used a "lazy state" monad. It might be possible to build a "lazy-ify" monad transformer which would make this work. In particular, I think Oleg's LogicT transformer[1] does something of the sort, only applying side effects where they are required in order to get "the next result" in a nondeterministic computation. -- ryan [1] http://okmij.org/ftp/Computation/monads.html#LogicT From sfvisser at cs.uu.nl Thu Jan 1 09:04:11 2009 From: sfvisser at cs.uu.nl (Sebastiaan Visser) Date: Thu Jan 1 08:56:06 2009 Subject: [Haskell-cafe] [ANN] Haskell web server + wiki: salvia-0.0.4 + orchid-0.0.6 Message-ID: <6EE42792-F9CD-4028-AF4A-2880E5D322EE@cs.uu.nl> Happy new year, you all! I'm pleased to announce three new packages on Hackage: * salvia-0.0.4: A lightweight modular web server framework. * orchid-0.0.6: A(nother) Wiki written in Haskell, currently using Darcs as a versioning back-end and Salvia as the application server. Orchid ships as a library that can be installed as a server module for the Salvia framework. * orchid-demo-0.0.4: A simple demo application using Salvia and Orchid to serve an example darcs repository. An online demo of the wiki can be found at [1]. The front-end is a typical Ajax application and heavily relies on the availability of JavaScript. A more plain (REST like) web interface to system can be found at [2]. You can signup, login and edit/create some pages. Feel free to play around, it's just a demo. Orchid has an abstract notion of a versioning back-end, theoretically allowing for multiple versioning systems. Currently only a Darcs back- end is available, but it shouldn't be too much work to implement a liaison for Git, Subversion, Mercurial etc. The Wiki uses its own experimental document system with printers to HTML, LaTeX, PDF via LaTeX and some others in the making. The system makes us of the UUAGC [3] attribute grammar system, but is not required in order to build the package. The document system is plug-in based allowing easy addition of new structures. There are currently plug-ins for inline LaTeX formulae, HSColour'ed Haskell code snippets and a table of contents. Some others in the making. Be aware, this is an early release to allow people the play around with the packages and enable me to see how this all behaves in the wild. The tools are not yet finished and I cannot guarantee any form of stability. But, in my experience, they seem to `just work'. Most of the time. I had some trouble getting all dependencies right on systems other than my own. Using `cabal install' seems to behave differently from `./ Setup install' in the package directory, but this may vary from system to system. It is known to work at least on Macosx and Linux with GHC 6.8, 6.10 or even 6.11. Pdflatex is needed for PDF generation, dvipng for inline formulas. Have fun and best wishes for this new year! -- Sebastiaan [1] http://funct.org/wiki/ [2] http://funct.org/wiki/data/Index.html [3] http://www.cs.uu.nl/wiki/HUT/AttributeGrammarSystem From gwern0 at gmail.com Thu Jan 1 13:15:32 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Thu Jan 1 13:07:26 2009 Subject: [Haskell-cafe] [ANN] Haskell web server + wiki: salvia-0.0.4 + orchid-0.0.6 In-Reply-To: <6EE42792-F9CD-4028-AF4A-2880E5D322EE@cs.uu.nl> References: <6EE42792-F9CD-4028-AF4A-2880E5D322EE@cs.uu.nl> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, Jan 1, 2009 at 9:04 AM, Sebastiaan Visser wrote: > Happy new year, you all! > > I'm pleased to announce three new packages on Hackage: > > * salvia-0.0.4: A lightweight modular web server framework. > > * orchid-0.0.6: A(nother) Wiki written in Haskell, currently using Darcs as > a versioning back-end and Salvia as the application server. Orchid ships as > a library that can be installed as a server module for the Salvia framework. > > * orchid-demo-0.0.4: A simple demo application using Salvia and Orchid to > serve an example darcs repository. > > An online demo of the wiki can be found at [1]. The front-end is a typical > Ajax application and heavily relies on the availability of JavaScript. A > more plain (REST like) web interface to system can be found at [2]. You can > signup, login and edit/create some pages. Feel free to play around, it's > just a demo. > > Orchid has an abstract notion of a versioning back-end, theoretically > allowing for multiple versioning systems. Currently only a Darcs back-end is > available, but it shouldn't be too much work to implement a liaison for Git, > Subversion, Mercurial etc. > > The Wiki uses its own experimental document system with printers to HTML, > LaTeX, PDF via LaTeX and some others in the making. The system makes us of > the UUAGC [3] attribute grammar system, but is not required in order to > build the package. The document system is plug-in based allowing easy > addition of new structures. There are currently plug-ins for inline LaTeX > formulae, HSColour'ed Haskell code snippets and a table of contents. Some > others in the making. > > Be aware, this is an early release to allow people the play around with the > packages and enable me to see how this all behaves in the wild. The tools > are not yet finished and I cannot guarantee any form of stability. But, in > my experience, they seem to `just work'. Most of the time. > > I had some trouble getting all dependencies right on systems other than my > own. Using `cabal install' seems to behave differently from `./Setup > install' in the package directory, but this may vary from system to system. > It is known to work at least on Macosx and Linux with GHC 6.8, 6.10 or even > 6.11. Pdflatex is needed for PDF generation, dvipng for inline formulas. > > Have fun and best wishes for this new year! > > > [1] http://funct.org/wiki/ > [2] http://funct.org/wiki/data/Index.html > [3] http://www.cs.uu.nl/wiki/HUT/AttributeGrammarSystem Miscellaneous comments: 1) You're right about cabal-install versus runhaskell etc. There seems to be a(nother) Control.Exception issue with cabal-install using base-4: src/Network/Orchid/Backend/DarcsBackend.hs:91:29: Couldn't match expected type `IOException' against inferred type `Exception' Expected type: IO (Either IOException String) Inferred type: IO (Either Exception String) In the second argument of `()', namely `(try (U.readFile (repo /+ file)) :: IO (Either IOException String))' In the expression: eitherToMaybe (try (U.readFile (repo /+ file)) :: IO (Either IOException String)) 2) Have you looked into integrating with Pandoc for generating TeX, PDFs, etc. (instead of rolling your own)? Seems to work fairly well for Gitit. 3) Is it just me, or is the fancy AJAX interface - as nice as it is - rather slow? 4) In orchid-demo, I notice it by default looks in /tmp for its datafiles. Is there some particular reason why a better default wouldn't be looking in ./? I was wondering how orchid-demo would do for a personal wiki, where it makes most sense to have a ~/wiki directory to keep all the files in. 5) Setting up orchid-demo is not all that clear; I figured out that you want to run 'orchid-demo --extract' to set up a stock configuration and repo, and then one can just run 'orchid-demo', but I think a better way would be to look in the default location for files and if orchid-demo doesn't find any, then fall back to --extract and look again. - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkldCEAACgkQvpDo5Pfl1oIsmQCdFjQ4Kr4Diocy1F1e1Pk1wies kdUAn27z8lixH8t9POBDV0FbV4VeVyp7 =T6lQ -----END PGP SIGNATURE----- From pgavin at gmail.com Thu Jan 1 13:32:08 2009 From: pgavin at gmail.com (Peter Gavin) Date: Thu Jan 1 13:24:01 2009 Subject: [Haskell-cafe] hackage, gtk2hs In-Reply-To: <1ff5dedc0812231231m450b7de5r66ef9c1330ab48d1@mail.gmail.com> References: <1ff5dedc0812231231m450b7de5r66ef9c1330ab48d1@mail.gmail.com> Message-ID: <495D0C28.8080609@gmail.com> Cetin Sert wrote: > Hi, > > A package I want to upload only builds with the unreleased gtk2hs > version from the darcs repository and not the latest released version > 0.9.13 or any lesser. But the repository version seems to not have > changed, so if I say in my cabal file: > > gtk >= 0.9.14 > > it does not even build with the gtk2hs version from the repos, on the > other hand > > if I say: > > gtk >= 0.9.13 > > people using 0.9.13 may be surprised to see the package does not build. > > What should I do o__O? Wait for the next gtk2hs release before releasing > my package? Or is there a way to notify _potential users/those > interested_ of the need to use the latest gtk2hs they can get from the > darcs repos. > It's not good practice to make releases that depend on unreleased packages. On the other hand, I plan on doing a release real soon now (hopefully by Monday or so). So I would suggest that you wait just a few more days. I think we're going to make this one 0.10.0, btw. Pete > Best Regards, > Cetin Sert > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From sfvisser at cs.uu.nl Thu Jan 1 13:39:58 2009 From: sfvisser at cs.uu.nl (Sebastiaan Visser) Date: Thu Jan 1 13:31:53 2009 Subject: [Haskell-cafe] [ANN] Haskell web server + wiki: salvia-0.0.4 + orchid-0.0.6 In-Reply-To: References: <6EE42792-F9CD-4028-AF4A-2880E5D322EE@cs.uu.nl> Message-ID: <4C8A43D6-2346-4B70-BB3E-CAEF2D57423B@cs.uu.nl> On Jan 1, 2009, at 7:15 PM, Gwern Branwen wrote: > On Thu, Jan 1, 2009 at 9:04 AM, Sebastiaan Visser wrote: >> Happy new year, you all! >> >> I'm pleased to announce three new packages on Hackage: >> ... > > Miscellaneous comments: > 1) You're right about cabal-install versus runhaskell etc. There seems > to be a(nother) Control.Exception issue with cabal-install using > base-4: > src/Network/Orchid/Backend/DarcsBackend.hs:91:29: > Couldn't match expected type `IOException' > against inferred type `Exception' > Expected type: IO (Either IOException String) > Inferred type: IO (Either Exception String) > In the second argument of `()', namely > `(try (U.readFile (repo /+ file)) :: > IO (Either IOException String))' > In the expression: > eitherToMaybe > > (try (U.readFile (repo /+ file)) :: IO (Either IOException > String)) I tried to enable building against both the old and the new Exception libraries by using some preprocessor statements. It seems this attempt failed. > 2) Have you looked into integrating with Pandoc for generating TeX, > PDFs, etc. (instead of rolling your own)? Seems to work fairly well > for Gitit. Nope haven't really looked into Pandoc, rolling my was just more fun. > 3) Is it just me, or is the fancy AJAX interface - as nice as it is - > rather slow? No, it's not really the Ajax that is the performance bottleneck here. It is the slow machine the demo is running on currently, the LaTeX tools running in the background and the poor caching. When I would cache all the generated documents (and images) there will probably a big speedup. This is in my todo. > 4) In orchid-demo, I notice it by default looks in /tmp for its > datafiles. Is there some particular reason why a better default > wouldn't be looking in ./? I was wondering how orchid-demo would do > for a personal wiki, where it makes most sense to have a ~/wiki > directory to keep all the files in. The /tmp directory is just world writable by default, being a good candidate to get the demo running quick. The command line options allow you to have more control. The demo is only one single `Main.hs', so adapting it to your own needs is also possible. > 5) Setting up orchid-demo is not all that clear; I figured out that > you want to run 'orchid-demo --extract' to set up a stock > configuration and repo, and then one can just run 'orchid-demo', but I > think a better way would be to look in the default location for files > and if orchid-demo doesn't find any, then fall back to --extract and > look again. A better way to roll your own wiki is: $ echo "show signup" > user.db $ echo "myusername mypassword loginfo show edit create signup" >> user.db $ mkdir repo $ cd repo $ darcs init $ orhid-demo --data-dir=. --user-db=../user.db > - -- > gwern Thanks for the feedback. Sebastiaan From derek.a.elkins at gmail.com Thu Jan 1 14:04:55 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Thu Jan 1 13:56:52 2009 Subject: [Haskell-cafe] WriterT [w] IO is not lazy in reading [w] In-Reply-To: <2f9b2d30901010217l37ee34b7ve27ce845f78cd672@mail.gmail.com> References: <1230757192.31199.4.camel@derek-laptop> <2f9b2d30901010217l37ee34b7ve27ce845f78cd672@mail.gmail.com> Message-ID: <1230836695.31199.19.camel@derek-laptop> On Thu, 2009-01-01 at 02:17 -0800, Ryan Ingram wrote: > 2008/12/31 Paolino : > > I must ask why runWriterT k :: State s (a,[Int]) is working. > > Looks like I could runIO the same way I evalState there. > > In that case I wouldn't wait for the State s action to finish. > > > > Thanks > > Assuming you have Control.Monad.State.Lazy (which I think is the > default), here is the difference: [...] There's a much simpler way of understanding why you must wait for an IO computation to finish before you can use the result. In IO you can throw exceptions (IOErrors), so you must wait until an IO computation is finished to know that there is any result at all. From gwern0 at gmail.com Thu Jan 1 14:09:26 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Thu Jan 1 14:01:17 2009 Subject: [Haskell-cafe] [ANN] Haskell web server + wiki: salvia-0.0.4 + orchid-0.0.6 In-Reply-To: <4C8A43D6-2346-4B70-BB3E-CAEF2D57423B@cs.uu.nl> References: <6EE42792-F9CD-4028-AF4A-2880E5D322EE@cs.uu.nl> <4C8A43D6-2346-4B70-BB3E-CAEF2D57423B@cs.uu.nl> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, Jan 1, 2009 at 1:39 PM, Sebastiaan Visser wrote: > On Jan 1, 2009, at 7:15 PM, Gwern Branwen wrote: >> >> On Thu, Jan 1, 2009 at 9:04 AM, Sebastiaan Visser wrote: >>> >>> Happy new year, you all! >>> >>> I'm pleased to announce three new packages on Hackage: >>> ... >> >> Miscellaneous comments: >> 1) You're right about cabal-install versus runhaskell etc. There seems >> to be a(nother) Control.Exception issue with cabal-install using >> base-4: >> src/Network/Orchid/Backend/DarcsBackend.hs:91:29: >> Couldn't match expected type `IOException' >> against inferred type `Exception' >> Expected type: IO (Either IOException String) >> Inferred type: IO (Either Exception String) >> In the second argument of `()', namely >> `(try (U.readFile (repo /+ file)) :: >> IO (Either IOException String))' >> In the expression: >> eitherToMaybe >> >> (try (U.readFile (repo /+ file)) :: IO (Either IOException >> String)) > > I tried to enable building against both the old and the new Exception > libraries by using some preprocessor statements. It seems this attempt > failed. > >> 2) Have you looked into integrating with Pandoc for generating TeX, >> PDFs, etc. (instead of rolling your own)? Seems to work fairly well >> for Gitit. > > Nope haven't really looked into Pandoc, rolling my was just more fun. > >> 3) Is it just me, or is the fancy AJAX interface - as nice as it is - >> rather slow? > > No, it's not really the Ajax that is the performance bottleneck here. It is > the slow machine the demo is running on currently, the LaTeX tools running > in the background and the poor caching. When I would cache all the generated > documents (and images) there will probably a big speedup. This is in my > todo. I am unsure that's the explanation. When I switched to look at the simple non-AJAX view, it ran speedily enough; further, when I began using AJAX locally, it felt as sluggish and slow as before, and I do not consider my machine to be slow. >> 4) In orchid-demo, I notice it by default looks in /tmp for its >> datafiles. Is there some particular reason why a better default >> wouldn't be looking in ./? I was wondering how orchid-demo would do >> for a personal wiki, where it makes most sense to have a ~/wiki >> directory to keep all the files in. > > The /tmp directory is just world writable by default, being a good candidate > to get the demo running quick. The command line options allow you to have > more control. The demo is only one single `Main.hs', so adapting it to your > own needs is also possible. > >> 5) Setting up orchid-demo is not all that clear; I figured out that >> you want to run 'orchid-demo --extract' to set up a stock >> configuration and repo, and then one can just run 'orchid-demo', but I >> think a better way would be to look in the default location for files >> and if orchid-demo doesn't find any, then fall back to --extract and >> look again. > > A better way to roll your own wiki is: > > $ echo "show signup" > user.db > $ echo "myusername mypassword loginfo show edit create signup" >> user.db > $ mkdir repo > $ cd repo > $ darcs init > $ orhid-demo --data-dir=. --user-db=../user.db > >> - -- >> gwern > > Thanks for the feedback. > > Sebastiaan I hadn't looked at the config before; I guess another suggestion would be to hash the password! - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkldFNsACgkQvpDo5Pfl1oIAAwCeNe+3+oPsa1NIop+47yT3fk+R yP4AnRwzWOlYft3Ne8aqgbuKI/AhzAhb =P6q9 -----END PGP SIGNATURE----- From dave at zednenem.com Thu Jan 1 14:16:40 2009 From: dave at zednenem.com (David Menendez) Date: Thu Jan 1 14:08:33 2009 Subject: [Haskell-cafe] WriterT [w] IO is not lazy in reading [w] In-Reply-To: <2f9b2d30901010217l37ee34b7ve27ce845f78cd672@mail.gmail.com> References: <1230757192.31199.4.camel@derek-laptop> <2f9b2d30901010217l37ee34b7ve27ce845f78cd672@mail.gmail.com> Message-ID: <49a77b7a0901011116s44d397ddj708cef5a66dc6867@mail.gmail.com> On Thu, Jan 1, 2009 at 5:17 AM, Ryan Ingram wrote: > It might be possible to build a "lazy-ify" monad transformer which > would make this work. In particular, I think Oleg's LogicT > transformer[1] does something of the sort, only applying side effects > where they are required in order to get "the next result" in a > nondeterministic computation. LogicT is continuation-based, so it's strict in the first argument to (>>=). observeT $ undefined >>= \_ -> return () will throw an exception. On the other hand, LogicT is non-strict in the second argument to mplus if the transformed monad is non-strict in (>>=). take 4 . runIdentity . observeAllT . msum $ map return [0..] should return [0,1,2,3]. (My implementation does. I assume the LogicT on Hackage is the same.) -- Dave Menendez From bhurt at spnz.org Thu Jan 1 14:25:38 2009 From: bhurt at spnz.org (Brian Hurt) Date: Thu Jan 1 14:17:40 2009 Subject: [Haskell-cafe] Stupid question #852: Strict monad Message-ID: First off, let me apologize for this ongoing series of stupid newbie questions. Haskell just recently went from that theoretically interesting language I really need to learn some day to a language I actually kinda understand and can write real code in (thanks to Real World Haskell). Of course, this gives rise to a whole bunch of "wait- why is it this way?" sort of questions. So today's question is: why isn't there a Strict monad? Something like: data Strict a = X a instance Monad Strict where ( >>= ) (X m) f = let x = f m in x `seq` (X x) return a = a `seq` (X a) (although this code doesn't compile for reasons I'm not clear on- I keep getting: temp.hs:4:0: Occurs check: cannot construct the infinite type: b = Strict b When trying to generalise the type inferred for `>>=' Signature type: forall a b1. Strict a -> (a -> Strict b1) -> Strict b1 Type to generalise: forall a b1. Strict a -> (a -> Strict b1) -> Strict b1 In the instance declaration for `Monad Strict' as a type error. Feel free to jump in and tell me what I'm doing wrong.) Obviously, there would also be a StrictT monad transformer. The point here is that there are some monads (State being the obvious one) that come in both strict and lazy variants- the two variants could be eliminated, and the strict variant would just become a StrictT (State x) a. Or maybe a StateT x Strict a. Hmm. Which raises the interesting question of what, if any, semantic difference there is between a StrictT (State x) a and a StateT x Strict a. In any case, the idea came when I was thinking about monads being "code regions"- that we can talk about such and such a function being "in" the IO monad or STM monad. The idea was that one could define a "strict" code region you could put code in. Brian From deduktionstheorem at web.de Thu Jan 1 15:02:38 2009 From: deduktionstheorem at web.de (Stephan Friedrichs) Date: Thu Jan 1 14:54:33 2009 Subject: [Haskell-cafe] Stupid question #852: Strict monad In-Reply-To: References: Message-ID: <495D215E.9080607@web.de> Hello Brian, Brian Hurt wrote: > > [...] > > So today's question is: why isn't there a Strict monad? Something like: > > data Strict a = X a > > instance Monad Strict where > ( >>= ) (X m) f = let x = f m in x `seq` (X x) > return a = a `seq` (X a) unless I am mistaken, this violates the first monad law (see Prelude documentation) return a >>= k == k a for k = const (return 3) and a = undefined, because return undefined >>= _ === _|_ but const (return 3) undefined === return 3 Generally speaking, the first monad law only holds for strict functions in your monad. > > [...] > Happy new year, Stephan -- Fr?her hie? es ja: Ich denke, also bin ich. Heute wei? man: Es geht auch so. - Dieter Nuhr From lrpalmer at gmail.com Thu Jan 1 15:06:39 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Jan 1 14:58:30 2009 Subject: [Haskell-cafe] Stupid question #852: Strict monad In-Reply-To: References: Message-ID: <7ca3f0160901011206s4a996683n7753087af2a52a9b@mail.gmail.com> On Thu, Jan 1, 2009 at 12:25 PM, Brian Hurt wrote: > > First off, let me apologize for this ongoing series of stupid newbie > questions. Haskell just recently went from that theoretically interesting > language I really need to learn some day to a language I actually kinda > understand and can write real code in (thanks to Real World Haskell). Of > course, this gives rise to a whole bunch of "wait- why is it this way?" sort > of questions. > > So today's question is: why isn't there a Strict monad? Something like: > > data Strict a = X a > > instance Monad Strict where > ( >>= ) (X m) f = let x = f m in x `seq` (X x) > return a = a `seq` (X a) First, the error is: f :: a -> Strict b, so you have to unpack the result first. X m >>= f = let X x = f m in x `seq` X x Now I would like to take a moment to point out something that is a cause of much fuzziness and confusion when talking about strictness. (1) "f is strict" means exactly f _|_ = _|_. (2) "x `seq` y" means _|_ when x is _|_, y otherwise. These are precise, mathematical definitions. Use them instead of your intuition to start with, until you fix your intuition. Now consider the right neutral monad law: m >>= return = m This fails when m = X _|_: X _|_ >>= return = let X x = return _|_ in x `seq` X x = let X x = _|_ `seq` X _|_ in x `seq` X x = let X x = _|_ in x `seq` X x = _|_ Because X _|_ is not _|_. The problem here was that return was too strict; i.e. return _|_ was _|_ instead of X _|_. So let's relax return to "return = X", and then see how it goes: X _|_ >>= return = let X x = return _|_ in x `seq` X x = let X x = X _|_ in x `seq` X x = _|_ `seq` X _|_ = _|_ Whoops! It happened again. So we're forced to relax the definition of bind also. And then the monad isn't strict as we were attempting. Maybe the problem is somewhere else: that X _|_ and _|_ are different; let's fix that by making Strict a newtype: newtype Strict a = X a instance Monad Strict where X m >>= f = let X x = f m in x `seq` X x return x = x `seq` X x Okay, first let's prove a little lemma to show the absurdity of this definition :-) : Let f x = x `seq` X x, then f = X. Let's consider two cases: (1) x is not _|_: then f x = x `seq` X x. But the definition of seq is that seq x y is _|_ when x is _|_, and y otherwise. So in this case f x = X x. (2) x is _|_: then f _|_ = _|_ `seq` X _|_ = _|_. But X _|_ = _|_ because of the semantics of newtypes, so f x = X x here also. Qed. So now we know we can replace x `seq` X x with simply X x without changing semantics: instance Monad Strict where X m >>= f = let X x = f m in X x return x = X x And performing some obvious rewrites: instance Monad Strict where X m >>= f = f m return = X And there you have your Strict monad. Oh, but it's the same as Identity. :-) So that's the answer: there already is a Strict monad. And an attempt to make a lazier one strict just results in breaking the monad laws. There's another answer though, regarding your question for why we don't just use StrictT State instead of a separate State.Strict. This message is already too long, and I suspect this will be the popular reply anyway, but the short answer is that Strict State is called that because it is strict in its state, not in its value. StrictT wouldn't be able to see that there even is a state, so it wouldn't be able to change semantics. And as we saw, an attempt to be overly strict in your value just results in law breaking. Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090101/df6cfc0d/attachment.htm From jonathanccast at fastmail.fm Thu Jan 1 15:06:41 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Jan 1 14:58:34 2009 Subject: [Haskell-cafe] Stupid question #852: Strict monad In-Reply-To: References: Message-ID: <1230840402.6019.40.camel@jonathans-macbook> On Thu, 2009-01-01 at 14:25 -0500, Brian Hurt wrote: > First off, let me apologize for this ongoing series of stupid newbie > questions. Haskell just recently went from that theoretically interesting > language I really need to learn some day to a language I actually kinda > understand and can write real code in (thanks to Real World Haskell). Of > course, this gives rise to a whole bunch of "wait- why is it this way?" > sort of questions. > > So today's question is: why isn't there a Strict monad? Something like: > > data Strict a = X a (Note that you can eliminate the `seq`s below by saying data Strict a = X !a instead, or, if X is going to be strict, newtype Strict a = X a). > instance Monad Strict where > ( >>= ) (X m) f = let x = f m in x `seq` (X x) > return a = a `seq` (X a) > > (although this code doesn't compile for reasons I'm not clear on- I keep > getting: > temp.hs:4:0: > Occurs check: cannot construct the infinite type: b = Strict b > When trying to generalise the type inferred for `>>=' > Signature type: forall a b1. > Strict a -> (a -> Strict b1) -> Strict b1 > Type to generalise: forall a b1. > Strict a -> (a -> Strict b1) -> Strict b1 > In the instance declaration for `Monad Strict' > as a type error. Feel free to jump in and tell me what I'm doing > wrong.) Since you asked, The simplest fix (that makes the code you posted compile) is to pattern match on the result of f (to do what you want): (>>=) (X m) f = let X x = f m in x `seq` X x (I would write X m >>= f = let X x = f m in X $! x) But unless you export the X constructor (and don't make it strict), then f should never return (X undefined), so the above is equivalent, for all f in practice, to X m >>= f = f m I think what you really want to say is newtype Strict alpha = X alpha instance Monad Strict where return = X X x >>= f = f $! x jcc From dave at zednenem.com Thu Jan 1 15:31:13 2009 From: dave at zednenem.com (David Menendez) Date: Thu Jan 1 15:23:03 2009 Subject: [Haskell-cafe] Stupid question #852: Strict monad In-Reply-To: <7ca3f0160901011206s4a996683n7753087af2a52a9b@mail.gmail.com> References: <7ca3f0160901011206s4a996683n7753087af2a52a9b@mail.gmail.com> Message-ID: <49a77b7a0901011231l265f445qf170610353d63551@mail.gmail.com> 2009/1/1 Luke Palmer : > > So that's the answer: there already is a Strict monad. And an attempt to > make a lazier one strict just results in breaking the monad laws. There is at least one transformer that will make a strict monad out of a non-strict monad. newtype CPS m a = CPS { unCPS :: forall b. (a -> m b) -> m b } instance Monad (CPS m) where return x = CPS (\k -> k x) m >>= f = CPS (\k -> unCPS m (\a -> unCPS (f a) k)) toCPS :: Monad m => m a -> CPS m a toCPS m = CPS (\k -> m >>= k) fromCPS :: Monad m => CPS m a -> m a fromCPS m = unCPS m return Contrast: > runIdentity $ undefined >>= \_ -> return () () > runIdentity . fromCPS $ undefined >>= \_ -> return () *** Exception: Prelude.undefined > There's another answer though, regarding your question for why we don't just > use StrictT State instead of a separate State.Strict. This message is > already too long, and I suspect this will be the popular reply anyway, but > the short answer is that Strict State is called that because it is strict in > its state, not in its value. No, Control.Monad.State.Strict and Control.Monad.State.Lazy never force evaluation of their states. Control.Monad.State.Strict> evalState (put undefined) '0' () The difference is in the strictness of (>>=). The same is true of the other Strict/Lazy pairs. -- Dave Menendez From lrpalmer at gmail.com Thu Jan 1 15:44:02 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Jan 1 15:35:53 2009 Subject: [Haskell-cafe] Stupid question #852: Strict monad In-Reply-To: <49a77b7a0901011231l265f445qf170610353d63551@mail.gmail.com> References: <7ca3f0160901011206s4a996683n7753087af2a52a9b@mail.gmail.com> <49a77b7a0901011231l265f445qf170610353d63551@mail.gmail.com> Message-ID: <7ca3f0160901011244ybd314fftd275fb86f91acaa6@mail.gmail.com> On Thu, Jan 1, 2009 at 1:31 PM, David Menendez wrote: > 2009/1/1 Luke Palmer : > > > > So that's the answer: there already is a Strict monad. And an attempt to > > make a lazier one strict just results in breaking the monad laws. > > There is at least one transformer that will make a strict monad out of > a non-strict monad. > > newtype CPS m a = CPS { unCPS :: forall b. (a -> m b) -> m b } I have heard this called the "codensity monad" (and it appears under that name in category-extras). Good observation. In my reply I missed the important consideration of the strictness of (>>=), irrsepective of the values. While you can not force values to be strict in a monad without breaking a law, (>>=) is "up for grabs", and that's what people are referring to when they refer to strict and lazy monads. So I guess "strict monad" means (>>= f) is strict for all f. Right? Luke > > There's another answer though, regarding your question for why we don't > just > > use StrictT State instead of a separate State.Strict. This message is > > already too long, and I suspect this will be the popular reply anyway, > but > > the short answer is that Strict State is called that because it is strict > in > > its state, not in its value. > > No, Control.Monad.State.Strict and Control.Monad.State.Lazy never > force evaluation of their states. > > Control.Monad.State.Strict> evalState (put undefined) '0' > () My mistake. Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090101/c603f48e/attachment.htm From judah.jacobson at gmail.com Thu Jan 1 16:10:48 2009 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Thu Jan 1 16:02:39 2009 Subject: [Haskell-cafe] [ANN] Haskell web server + wiki: salvia-0.0.4 + orchid-0.0.6 In-Reply-To: <4C8A43D6-2346-4B70-BB3E-CAEF2D57423B@cs.uu.nl> References: <6EE42792-F9CD-4028-AF4A-2880E5D322EE@cs.uu.nl> <4C8A43D6-2346-4B70-BB3E-CAEF2D57423B@cs.uu.nl> Message-ID: <6d74b0d20901011310i2912373er58624e87e2c9d59d@mail.gmail.com> On Thu, Jan 1, 2009 at 10:39 AM, Sebastiaan Visser wrote: > On Jan 1, 2009, at 7:15 PM, Gwern Branwen wrote: >> >> On Thu, Jan 1, 2009 at 9:04 AM, Sebastiaan Visser wrote: >>> >>> Happy new year, you all! >>> >>> I'm pleased to announce three new packages on Hackage: >>> ... >> >> Miscellaneous comments: >> 1) You're right about cabal-install versus runhaskell etc. There seems >> to be a(nother) Control.Exception issue with cabal-install using >> base-4: >> src/Network/Orchid/Backend/DarcsBackend.hs:91:29: >> Couldn't match expected type `IOException' >> against inferred type `Exception' >> Expected type: IO (Either IOException String) >> Inferred type: IO (Either Exception String) >> In the second argument of `()', namely >> `(try (U.readFile (repo /+ file)) :: >> IO (Either IOException String))' >> In the expression: >> eitherToMaybe >> >> (try (U.readFile (repo /+ file)) :: IO (Either IOException >> String)) > > I tried to enable building against both the old and the new Exception > libraries by using some preprocessor statements. It seems this attempt > failed. You may find the extensible-exceptions package from Hackage to be useful. It provides the new Exeptions API on all versions of ghc since 6.6 (and possibly earlier), so you don't have to deal with any preprocessing or cabal-install issues. -Judah From dave at zednenem.com Thu Jan 1 16:19:02 2009 From: dave at zednenem.com (David Menendez) Date: Thu Jan 1 16:10:53 2009 Subject: [Haskell-cafe] Stupid question #852: Strict monad In-Reply-To: <7ca3f0160901011244ybd314fftd275fb86f91acaa6@mail.gmail.com> References: <7ca3f0160901011206s4a996683n7753087af2a52a9b@mail.gmail.com> <49a77b7a0901011231l265f445qf170610353d63551@mail.gmail.com> <7ca3f0160901011244ybd314fftd275fb86f91acaa6@mail.gmail.com> Message-ID: <49a77b7a0901011319l48b87cd5k6280a4bafdfeecb6@mail.gmail.com> On Thu, Jan 1, 2009 at 3:44 PM, Luke Palmer wrote: > On Thu, Jan 1, 2009 at 1:31 PM, David Menendez wrote: >> >> newtype CPS m a = CPS { unCPS :: forall b. (a -> m b) -> m b } > > I have heard this called the "codensity monad" (and it appears under that > name in category-extras). Good observation. Interesting. I hadn't heard that name for it before. In my own monad library, I called it CPS, since it transforms a monad into continuation-passing style. It's handy for monads with an expensive (>>=), as discussed in Janis Voigtlander's "Asymptotic Improvement of Computations over Free Monads". > In my reply I missed the important consideration of the strictness of (>>=), > irrsepective of the values. While you can not force values to be strict in > a monad without breaking a law, (>>=) is "up for grabs", and that's what > people are referring to when they refer to strict and lazy monads. > > So I guess "strict monad" means (>>= f) is strict for all f. Right? That's my understanding. As a consequence, strict monads in Haskell also have the property that "return undefined" never equals "undefined". Otherwise, they wouldn't satisfy the monad laws. >> No, Control.Monad.State.Strict and Control.Monad.State.Lazy never >> force evaluation of their states. >> >> Control.Monad.State.Strict> evalState (put undefined) '0' >> () > > My mistake. I made that mistake myself, once. It doesn't help that the documentation just says "Lazy state monads" and "Strict state monads" without any further explanation. -- Dave Menendez From gwern0 at gmail.com Thu Jan 1 16:27:40 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Thu Jan 1 16:19:30 2009 Subject: [Haskell-cafe] [HUMOR] Haskell koans Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 In the spirit of my previous email on haikus (which turned out fairly well), I'd like to issue a RFK (Request For Koans) to everyone! You can find what I've accumulated already on http://haskell.org/haskellwiki/Koans . There are a few there, but half of them are mine. There is, however, a fairly complete external links section covering not just vaguely-Haskellish koans, but also FP and programming in general. So feel free to chip in with any koans or links to koans, if you know of any. I'm sure I must've missed a few just for #haskell alone. Example: gwern> a young novice spoke to #haskell, asking to be taught about the ways of the Maybe monad. 'What have you brought me to see?' asked the #haskeller. 'Nothing', replied the noob. 'Then take it away!'" - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkldNUkACgkQvpDo5Pfl1oJk4wCeMSsuFMI89oEHTdDCewkHQh5U CvYAn3xfgjbiwt9P9Z2+v8vnRbzztBKH =E7Pd -----END PGP SIGNATURE----- From jonathanccast at fastmail.fm Thu Jan 1 16:30:31 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Jan 1 16:22:23 2009 Subject: [Haskell-cafe] Stupid question #852: Strict monad In-Reply-To: <7ca3f0160901011244ybd314fftd275fb86f91acaa6@mail.gmail.com> References: <7ca3f0160901011206s4a996683n7753087af2a52a9b@mail.gmail.com> <49a77b7a0901011231l265f445qf170610353d63551@mail.gmail.com> <7ca3f0160901011244ybd314fftd275fb86f91acaa6@mail.gmail.com> Message-ID: <1230845431.6019.84.camel@jonathans-macbook> On Thu, 2009-01-01 at 13:44 -0700, Luke Palmer wrote: > On Thu, Jan 1, 2009 at 1:31 PM, David Menendez > wrote: > 2009/1/1 Luke Palmer : > > > > So that's the answer: there already is a Strict monad. And > an attempt to > > make a lazier one strict just results in breaking the monad > laws. > > > There is at least one transformer that will make a strict > monad out of > a non-strict monad. > > newtype CPS m a = CPS { unCPS :: forall b. (a -> m b) -> m b } > > I have heard this called the "codensity monad" (and it appears under > that name in category-extras). Good observation. > > In my reply I missed the important consideration of the strictness of > (>>=), irrsepective of the values. While you can not force values to > be strict in a monad without breaking a law, (>>=) is "up for grabs", Is it? By the second monad law, (>>= return) is required to be strict. return must not be strict, as observed above. Are there monads which satisfy both laws, but have undefined >>= f /= undefined, for some f? I suspect (although I don't seem to have the source on my computer atm) that Control.Monad.State.{Lazy,Strict} both cheat on the second monad law anyway, though... jcc From schlepptop at henning-thielemann.de Thu Jan 1 16:44:51 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 1 16:31:14 2009 Subject: [Haskell-cafe] unsafeInterleaveIO respecting order of actions In-Reply-To: References: <2f9b2d30812311301y1068b499u77fa12ef0cd44647@mail.gmail.com> Message-ID: <495D3953.6080609@henning-thielemann.de> I think I have a very similar problem to the currently discussed "WriterT [w] IO is not lazy in reading [w]". I want to defer IO actions, until they are needed, but they shall be executed in order. If I call unsafeInterleaveIO, they can be executed in any order. I understand that hGetContents does not defer the hGetChar operations but instead defers the call of the (:) constructors, thus preserving the order of the hGetChar calls. In the general case this is not so simple, since the result of a monadic block might not be a list and the result of particular actions might not be needed at all, e.g. (). If it is generally possible to use unsafeInterleaveIO such that it executes actions in the right order, wouldn't this allow the definition of a general lazy IO monad? From lrpalmer at gmail.com Thu Jan 1 16:40:34 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Jan 1 16:32:25 2009 Subject: [Haskell-cafe] [HUMOR] Haskell koans In-Reply-To: References: Message-ID: <7ca3f0160901011340m122b14b6iab79676b8f03e366@mail.gmail.com> Very nice! I'd love to see more of these. :-) On Thu, Jan 1, 2009 at 2:27 PM, Gwern Branwen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > In the spirit of my previous email on haikus (which turned out fairly > well), I'd like to issue a RFK (Request For Koans) to everyone! > > You can find what I've accumulated already on > http://haskell.org/haskellwiki/Koans . There are a few there, but half > of them are mine. There is, however, a fairly complete external links > section covering not just vaguely-Haskellish koans, but also FP and > programming in general. > > So feel free to chip in with any koans or links to koans, if you know > of any. I'm sure I must've missed a few just for #haskell alone. > > Example: > gwern> a young novice spoke to #haskell, asking to be taught about the > ways of the Maybe monad. > 'What have you brought me to see?' asked the #haskeller. > 'Nothing', replied the noob. > 'Then take it away!'" > > - -- > gwern > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEAREKAAYFAkldNUkACgkQvpDo5Pfl1oJk4wCeMSsuFMI89oEHTdDCewkHQh5U > CvYAn3xfgjbiwt9P9Z2+v8vnRbzztBKH > =E7Pd > -----END PGP SIGNATURE----- > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090101/c0666e90/attachment.htm From lrpalmer at gmail.com Thu Jan 1 16:44:11 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Jan 1 16:36:03 2009 Subject: [Haskell-cafe] Stupid question #852: Strict monad In-Reply-To: <1230845431.6019.84.camel@jonathans-macbook> References: <7ca3f0160901011206s4a996683n7753087af2a52a9b@mail.gmail.com> <49a77b7a0901011231l265f445qf170610353d63551@mail.gmail.com> <7ca3f0160901011244ybd314fftd275fb86f91acaa6@mail.gmail.com> <1230845431.6019.84.camel@jonathans-macbook> Message-ID: <7ca3f0160901011344l38982122wfcf7a52b0de0b5de@mail.gmail.com> On Thu, Jan 1, 2009 at 2:30 PM, Jonathan Cast wrote: > On Thu, 2009-01-01 at 13:44 -0700, Luke Palmer wrote: > > On Thu, Jan 1, 2009 at 1:31 PM, David Menendez > > wrote: > > 2009/1/1 Luke Palmer : > > > > > > So that's the answer: there already is a Strict monad. And > > an attempt to > > > make a lazier one strict just results in breaking the monad > > laws. > > > > > > There is at least one transformer that will make a strict > > monad out of > > a non-strict monad. > > > > newtype CPS m a = CPS { unCPS :: forall b. (a -> m b) -> m b } > > > > I have heard this called the "codensity monad" (and it appears under > > that name in category-extras). Good observation. > > > > In my reply I missed the important consideration of the strictness of > > (>>=), irrsepective of the values. While you can not force values to > > be strict in a monad without breaking a law, (>>=) is "up for grabs", > > Is it? By the second monad law, (>>= return) is required to be strict. > return must not be strict, as observed above. Are there monads which > satisfy both laws, but have undefined >>= f /= undefined, for some f? I > suspect (although I don't seem to have the source on my computer atm) > that Control.Monad.State.{Lazy,Strict} both cheat on the second monad > law anyway, though... ghci> import Control.Monad.Writer ghci> head . getDual . execWriter $ undefined >> tell (Dual [42]) 42 Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090101/e990837e/attachment.htm From dave at zednenem.com Thu Jan 1 17:03:29 2009 From: dave at zednenem.com (David Menendez) Date: Thu Jan 1 16:55:20 2009 Subject: [Haskell-cafe] Stupid question #852: Strict monad In-Reply-To: <1230845431.6019.84.camel@jonathans-macbook> References: <7ca3f0160901011206s4a996683n7753087af2a52a9b@mail.gmail.com> <49a77b7a0901011231l265f445qf170610353d63551@mail.gmail.com> <7ca3f0160901011244ybd314fftd275fb86f91acaa6@mail.gmail.com> <1230845431.6019.84.camel@jonathans-macbook> Message-ID: <49a77b7a0901011403i278ff5edn2ee2bcb0a1132ad5@mail.gmail.com> On Thu, Jan 1, 2009 at 4:30 PM, Jonathan Cast wrote: > On Thu, 2009-01-01 at 13:44 -0700, Luke Palmer wrote: >> >> In my reply I missed the important consideration of the strictness of >> (>>=), irrsepective of the values. While you can not force values to >> be strict in a monad without breaking a law, (>>=) is "up for grabs", > > Is it? By the second monad law, (>>= return) is required to be strict. > return must not be strict, as observed above. Are there monads which > satisfy both laws, but have undefined >>= f /= undefined, for some f? I > suspect (although I don't seem to have the source on my computer atm) > that Control.Monad.State.{Lazy,Strict} both cheat on the second monad > law anyway, though... How about the Identity monad? ghci> (return undefined :: Identity Char) `seq` () *** Exception: Prelude.undefined ghci> runIdentity $ undefined >>= \_ -> return () () "return" is strict and (>>=) is non-strict. -- Dave Menendez From jonathanccast at fastmail.fm Thu Jan 1 17:11:45 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Jan 1 17:03:36 2009 Subject: [Haskell-cafe] Stupid question #852: Strict monad In-Reply-To: <49a77b7a0901011403i278ff5edn2ee2bcb0a1132ad5@mail.gmail.com> References: <7ca3f0160901011206s4a996683n7753087af2a52a9b@mail.gmail.com> <49a77b7a0901011231l265f445qf170610353d63551@mail.gmail.com> <7ca3f0160901011244ybd314fftd275fb86f91acaa6@mail.gmail.com> <1230845431.6019.84.camel@jonathans-macbook> <49a77b7a0901011403i278ff5edn2ee2bcb0a1132ad5@mail.gmail.com> Message-ID: <1230847905.6019.87.camel@jonathans-macbook> On Thu, 2009-01-01 at 17:03 -0500, David Menendez wrote: > On Thu, Jan 1, 2009 at 4:30 PM, Jonathan Cast wrote: > > On Thu, 2009-01-01 at 13:44 -0700, Luke Palmer wrote: > >> > >> In my reply I missed the important consideration of the strictness of > >> (>>=), irrsepective of the values. While you can not force values to > >> be strict in a monad without breaking a law, (>>=) is "up for grabs", > > > > Is it? By the second monad law, (>>= return) is required to be strict. > > return must not be strict, as observed above. Are there monads which > > satisfy both laws, but have undefined >>= f /= undefined, for some f? I > > suspect (although I don't seem to have the source on my computer atm) > > that Control.Monad.State.{Lazy,Strict} both cheat on the second monad > > law anyway, though... > > How about the Identity monad? > > ghci> (return undefined :: Identity Char) `seq` () > *** Exception: Prelude.undefined > ghci> runIdentity $ undefined >>= \_ -> return () > () > > "return" is strict and (>>=) is non-strict. Sure, that works. jcc From schlepptop at henning-thielemann.de Thu Jan 1 17:43:23 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 1 17:29:30 2009 Subject: [Haskell-cafe] [ANN] Haskell web server + wiki: salvia-0.0.4 + orchid-0.0.6 In-Reply-To: <6d74b0d20901011310i2912373er58624e87e2c9d59d@mail.gmail.com> References: <6EE42792-F9CD-4028-AF4A-2880E5D322EE@cs.uu.nl> <4C8A43D6-2346-4B70-BB3E-CAEF2D57423B@cs.uu.nl> <6d74b0d20901011310i2912373er58624e87e2c9d59d@mail.gmail.com> Message-ID: <495D470B.2050007@henning-thielemann.de> Judah Jacobson schrieb: > On Thu, Jan 1, 2009 at 10:39 AM, Sebastiaan Visser wrote: >> On Jan 1, 2009, at 7:15 PM, Gwern Branwen wrote: >>> On Thu, Jan 1, 2009 at 9:04 AM, Sebastiaan Visser wrote: >>>> Happy new year, you all! >>>> >>>> I'm pleased to announce three new packages on Hackage: >>>> ... >>> Miscellaneous comments: >>> 1) You're right about cabal-install versus runhaskell etc. There seems >>> to be a(nother) Control.Exception issue with cabal-install using >>> base-4: >>> src/Network/Orchid/Backend/DarcsBackend.hs:91:29: >>> Couldn't match expected type `IOException' >>> against inferred type `Exception' >>> Expected type: IO (Either IOException String) >>> Inferred type: IO (Either Exception String) >>> In the second argument of `()', namely >>> `(try (U.readFile (repo /+ file)) :: >>> IO (Either IOException String))' >>> In the expression: >>> eitherToMaybe >>> >>> (try (U.readFile (repo /+ file)) :: IO (Either IOException String)) >> I tried to enable building against both the old and the new Exception >> libraries by using some preprocessor statements. It seems this attempt >> failed. > > You may find the extensible-exceptions package from Hackage to be > useful. It provides the new Exeptions API on all versions of ghc > since 6.6 (and possibly earlier), so you don't have to deal with any > preprocessing or cabal-install issues. Alternatively use the explicit-exception package, which works like IO (Either ...), but is more clean. Btw. although I have not looked into Pandoc, in general I find it more attracting to re-use existing software. If you think, that your document system is better than Pandoc, it would also be nice to have it as a separate package. From schlepptop at henning-thielemann.de Thu Jan 1 17:48:19 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 1 17:34:23 2009 Subject: [Haskell-cafe] [ANN] Haskell web server + wiki: salvia-0.0.4 + orchid-0.0.6 In-Reply-To: <6EE42792-F9CD-4028-AF4A-2880E5D322EE@cs.uu.nl> References: <6EE42792-F9CD-4028-AF4A-2880E5D322EE@cs.uu.nl> Message-ID: <495D4833.6000501@henning-thielemann.de> Sebastiaan Visser schrieb: > Happy new year, you all! > > I'm pleased to announce three new packages on Hackage: > > * salvia-0.0.4: A lightweight modular web server framework. Is it based on Simon Marlow's HWS, like mohws on Hackage? Does it support HTTPS? From barsoap at web.de Thu Jan 1 18:26:19 2009 From: barsoap at web.de (Achim Schneider) Date: Thu Jan 1 18:18:21 2009 Subject: [Haskell-cafe] The Psychology of Computer Programming Message-ID: <20090102002619.1b5f8b16@solaris> http://books.google.com/books?id=tiMPAAAACAAJ&hl=de (by Gerald M. Weinberg) I suggest you procure a copy and read it for a) the lulz (a lot of them) b) insight into your own hack mode c) insight into how to hack recruiting and team lead d) ways to make Haskell even more subversive -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From h8spawn at googlemail.com Thu Jan 1 18:48:50 2009 From: h8spawn at googlemail.com (=?UTF-8?Q?S._G=C3=BCnther?=) Date: Thu Jan 1 18:40:40 2009 Subject: [Haskell-cafe] Re: Updating doubly linked lists In-Reply-To: References: <495B6E91.8050809@van.steenbergen.nl> <2f9b2d30812311311k51d2a5adq48697976cb48af75@mail.gmail.com> Message-ID: > Whether circular or not, sharing values by using a "back pointer" is > problematic for any update. Why not use a zipper instead? I looked into zippers before and the problem I had was that they never really matched the structure which I needed and which led me to think about this whole knot tying thing again.[1] The things I read about them always assumed either a list like (i.e. linear) or a tree like (i.e. existence of a root) structure on the type to be plugged into the zipper. Now I know that this is not necessary and there are references to a generic zipper implementation but the thing is that I only found the source code and decided to first look into the knot tying thing before opening another can of worms with delimited continuations since I already spend too muchtime thinking about that stuff.[2] So if anyone has pointers to a good generic zipper explanation I would be thankful. Note that I don't need full blown error handling. I would first like to understand the basics. Now I think I came to the conclusion that locally updating a tied knot in a pure way really is hard and that it's not me just not seeing some obvious solution. So I just have to decide whether to use IORefs/Vars (clunky) or to implement zippers for the structure I need (probably toohard for me). Anyways thanks for all the answers from which I learned a few unexpected things and which assured me that my instincts aren't that far off. Cheers and warm regards (and a happy new year) Stephan [1]: "Again" means that I already looked into both tying the knot and zippers about a year ago out of curiosity. This time it was out of necessity although the original question I posed was more a necessity diverging into curiosity again. [2]: Note that "too much time" rather refers to the quantity I have at my disposal than to personal preferences. If I could I would like nothing more than to think about this "stuff" for the rest of my life. From allbery at ece.cmu.edu Thu Jan 1 19:07:55 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Jan 1 18:59:50 2009 Subject: [Haskell-cafe] unsafeInterleaveIO respecting order of actions In-Reply-To: <495D3953.6080609@henning-thielemann.de> References: <2f9b2d30812311301y1068b499u77fa12ef0cd44647@mail.gmail.com> <495D3953.6080609@henning-thielemann.de> Message-ID: <0F9EF08E-178E-4346-98E1-4BB7CE842F92@ece.cmu.edu> On 2009 Jan 1, at 16:44, Henning Thielemann wrote: > If it is generally possible to use unsafeInterleaveIO such that it > executes actions in the right order, wouldn't this allow the > definition > of a general lazy IO monad? I thought unsafeInterleaveIO and users of it (readFile, hGetContents) didn't guarantee the order of actions relative to independent IO actions (that is, those performed outside the unsafeInterleaveIO) and this was why it is generally disrecommended. For example the recurring situation where people try to readFile f >>= writeFile . someTransform and the writeFile fails with a "file locked" exception. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From derek.a.elkins at gmail.com Thu Jan 1 19:18:32 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Thu Jan 1 19:10:27 2009 Subject: [Haskell-cafe] Re: Updating doubly linked lists In-Reply-To: References: <495B6E91.8050809@van.steenbergen.nl> <2f9b2d30812311311k51d2a5adq48697976cb48af75@mail.gmail.com> Message-ID: <1230855512.31199.21.camel@derek-laptop> On Fri, 2009-01-02 at 10:48 +1100, S. G?nther wrote: > > Whether circular or not, sharing values by using a "back pointer" is > > problematic for any update. Why not use a zipper instead? > I looked into zippers before and the problem I had was that they never > really matched the structure which I needed and which led me to think > about this whole knot tying thing again.[1] The things I read about them > always assumed either a list like (i.e. linear) or a tree like (i.e. existence > of a root) structure on the type to be plugged into the zipper. Now I know > that this is not necessary and there are references to a generic zipper > implementation but the thing is that I only found the source code and > decided to first look into the knot tying thing before opening another > can of worms with delimited continuations since I already spend too > muchtime thinking about that stuff.[2] So if anyone has pointers to a > good generic zipper explanation I would be thankful. Note that I don't > need full blown error handling. I would first like to understand the basics. > Now I think I came to the conclusion that locally updating a tied knot in a > pure way really is hard and that it's not me just not seeing some obvious > solution. So I just have to decide whether to use IORefs/Vars (clunky) > or to implement zippers for the structure I need (probably toohard for me). > Anyways thanks for all the answers from which I learned a few unexpected > things and which assured me that my instincts aren't that far off. Read this http://strictlypositive.org/diff.pdf (again) From kevin at ksvanhorn.com Thu Jan 1 19:28:21 2009 From: kevin at ksvanhorn.com (Kevin Van Horn) Date: Thu Jan 1 19:20:14 2009 Subject: [Haskell-cafe] Thoughts on Haskell and OOP Message-ID: Haskell has been around in one form or another for nearly two decades now, yet has never been extended with explicit support for object- oriented programming. I've been thinking about why this is so. I've come to the conclusion that Haskell simply doesn't need any explicit OOP support -- algebraic datatypes, modules, lazy evaluation, and first-class functions give you everything you need to do the kinds of things you would use classes and inheritance for in OO languages. To see why this is so, let's think about what OOP is. At the most basic level we have what some call object-based programming. This amounts to support for data hiding and abstract data types. Haskell's module system handles this function quite well, without any need to introduce a special concept of "class" (in the OO sense) nor private vs. public class members. Object-oriented programming is then object-based programming plus class hierarchies and inheritance. Why are these useful? Properly used, OOP is all about interface inheritance, not implementation inheritance. (At least in C++, implementation inheritance -- inheriting the data members and method implementations of a base class -- usually leads to bad design, and is discouraged by the experts.) (For those more familiar with Python, "duck typing" is the analog of interface inheritance for a dynamically-typed language.) Interface inheritance allows you to write procedures that operate on the base-class interface, but can be applied to objects of any type derived from the base class. Can we do this in Haskell? Yes, we can. Let's consider the Haskell analog of an immutable C++ base class: struct Base { virtual ~Base(); virtual int foo() const; virtual int bar(int n) const; }; class derived :: public Base { ... data members ... public: derived(T_1 arg1, ..., T_k argk); ... implementations of the virtual functions ... }; Haskell has no direct analog of object classes and virtual methods, but you can use lazy evaluation and first-class functions to achieve the same result: data Base = Base { foo :: Int, bar :: Int -> Int } derived :: T_1 -> ... -> T_k -> Base derived a_1 ... a_k = Base { foo = ...; bar = bar } where bar n = ... The analog of a mutable C++ base class is a little bit more involved, but not much. Suppose that we change bar(int) to be a mutating method in the C++ Base class: virtual int bar(int n); The Haskell analog then changes to data Base = Base { foo :: Int, bar :: Int -> (Int, Base) } derived :: T_1 -> ... -> T_k -> Base derived a_1 ... a_k = Base { foo = ...; bar = bar } where bar n = (..., (derived a_1' ... a_k')) (Here a_1', ..., a_k' are k expressions involving n and a_1, ..., a_k.) What do the rest of you think? Is my analysis correct? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090101/59a3825b/attachment-0001.htm From barsoap at web.de Thu Jan 1 19:39:45 2009 From: barsoap at web.de (Achim Schneider) Date: Thu Jan 1 19:31:56 2009 Subject: [Haskell-cafe] Re: unsafeInterleaveIO respecting order of actions References: <2f9b2d30812311301y1068b499u77fa12ef0cd44647@mail.gmail.com> <495D3953.6080609@henning-thielemann.de> Message-ID: <20090102013945.221bca1f@solaris> Henning Thielemann wrote: > If it is generally possible to use unsafeInterleaveIO such that it > executes actions in the right order, wouldn't this allow the > definition of a general lazy IO monad? > The question is what "right order" means. Let B1..Bn be some arbitrary IO-Actions. Let A1..An be some arbitrary IO Actions passed to unsafeInterleaveIO You're guaranteed that a) Bk+1 is executed after Bk b) Ak+1 is executed after Ak , all by virtue of the IO Monad. However, usage of unsafeInterleaveIO means that you aren't guaranteed that A1..An happens _exactly_ between any pair of Bk and Bk+1: The total ordering of actions is circumvented. Semantically, this is equivalent to sparking a thread on a uniprocessor, and equivalent to sparking a thread on a multiprocessor for all but the rarest combinations of IO actions. There are no lazy monads. Monads imply explicit sequencing... writing kiss girl =><= speakTo girl , denoting "either (fist kiss the girl, then pass the result of that to speakTo girl) or (first speak to the girl, then pass the result of that to kiss girl) would, OTOH, certainly makes sense and certainly (well, depending on girl and setting) is undeterministic in both execution order and result. The question thus becomes: "Does arbitrary ordering of actions result in the same (in the id sense) result, and do I care more about the aggregate result than its ordering, or do I only care about ordering of actions for a certain definition of 'same result'?" Implementation of such a beast is left to the semantically inclined reader ;) In the meantime, I'm happy to just carelessly use unsafe*IO. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From lemming at henning-thielemann.de Thu Jan 1 19:56:16 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 1 19:48:08 2009 Subject: [Haskell-cafe] Re: unsafeInterleaveIO respecting order of actions In-Reply-To: <20090102013945.221bca1f@solaris> References: <2f9b2d30812311301y1068b499u77fa12ef0cd44647@mail.gmail.com> <495D3953.6080609@henning-thielemann.de> <20090102013945.221bca1f@solaris> Message-ID: On Fri, 2 Jan 2009, Achim Schneider wrote: > Henning Thielemann wrote: > >> If it is generally possible to use unsafeInterleaveIO such that it >> executes actions in the right order, wouldn't this allow the >> definition of a general lazy IO monad? >> > The question is what "right order" means. > > Let B1..Bn be some arbitrary IO-Actions. > Let A1..An be some arbitrary IO Actions passed to unsafeInterleaveIO > > You're guaranteed that > a) Bk+1 is executed after Bk > b) Ak+1 is executed after Ak > > , all by virtue of the IO Monad. If all Ak's are defered using individual unsafeInterleaveIO's then it is not guaranteed that A[k+1] is executed after A[k]. That's my problem. Check: Prelude> fmap snd $ Monad.liftM2 (,) (unsafeInterleaveIO getLine) (unsafeInterleaveIO getLine) If unsafely interleaved actions would be executed in order, then this would first ask you for the first pair member, then for the second one, then echo the second one. Actually it asks only for the second one and prints it. From dave at zednenem.com Thu Jan 1 20:08:12 2009 From: dave at zednenem.com (David Menendez) Date: Thu Jan 1 20:00:02 2009 Subject: [Haskell-cafe] Re: unsafeInterleaveIO respecting order of actions In-Reply-To: <20090102013945.221bca1f@solaris> References: <2f9b2d30812311301y1068b499u77fa12ef0cd44647@mail.gmail.com> <495D3953.6080609@henning-thielemann.de> <20090102013945.221bca1f@solaris> Message-ID: <49a77b7a0901011708sa425d0dw219b66bfcbce06a8@mail.gmail.com> On Thu, Jan 1, 2009 at 7:39 PM, Achim Schneider wrote: > > There are no lazy monads. Monads imply explicit sequencing... Huh? How are you defining "lazy monad"? -- Dave Menendez From roconnor at theorem.ca Thu Jan 1 20:22:26 2009 From: roconnor at theorem.ca (roconnor@theorem.ca) Date: Thu Jan 1 20:14:16 2009 Subject: [Haskell-cafe] Re: unsafeInterleaveIO respecting order of actions In-Reply-To: <20090102013945.221bca1f@solaris> References: <2f9b2d30812311301y1068b499u77fa12ef0cd44647@mail.gmail.com> <495D3953.6080609@henning-thielemann.de> <20090102013945.221bca1f@solaris> Message-ID: On Fri, 2 Jan 2009, Achim Schneider wrote: > There are no lazy monads. Monads imply explicit sequencing... writing I think this is an extremely bad thing to say and is a source of misunderstanding about monads and evaluation. Most monads _are_ lazy, and it is important to understand that when trying to understand the run-time properties of your monadic code. Monads sequence effects, but evaluation is an almost orthogonal issue. Here is a recent thread where I talk about laziness: http://www.reddit.com/r/haskell/comments/7itbi/mapm_mapm_and_monadic_statements/c06s6pm (for the short short story, simply try out > take 10 $ execWriter (sequence_ (repeat (tell "x"))) ) Furthermore, the code in my article on recursive do from The.Monad.Reader issue #6 requires the monads to be lazy in order to tie the knot. -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From barsoap at web.de Thu Jan 1 20:23:29 2009 From: barsoap at web.de (Achim Schneider) Date: Thu Jan 1 20:15:36 2009 Subject: [Haskell-cafe] Re: unsafeInterleaveIO respecting order of actions References: <2f9b2d30812311301y1068b499u77fa12ef0cd44647@mail.gmail.com> <495D3953.6080609@henning-thielemann.de> <20090102013945.221bca1f@solaris> Message-ID: <20090102022329.53997ef1@solaris> Henning Thielemann wrote: > > On Fri, 2 Jan 2009, Achim Schneider wrote: > > > Henning Thielemann wrote: > > > >> If it is generally possible to use unsafeInterleaveIO such that it > >> executes actions in the right order, wouldn't this allow the > >> definition of a general lazy IO monad? > >> > > The question is what "right order" means. > > > > Let B1..Bn be some arbitrary IO-Actions. > > Let A1..An be some arbitrary IO Actions passed to unsafeInterleaveIO > > > > You're guaranteed that > > a) Bk+1 is executed after Bk > > b) Ak+1 is executed after Ak > > > > , all by virtue of the IO Monad. > > If all Ak's are defered using individual unsafeInterleaveIO's then it > is not guaranteed that A[k+1] is executed after A[k]. That's my > problem. > > Check: > Prelude> fmap snd $ Monad.liftM2 (,) (unsafeInterleaveIO getLine) > Prelude> (unsafeInterleaveIO getLine) > > If unsafely interleaved actions would be executed in order, then this > would first ask you for the first pair member, then for the second > one, then echo the second one. Actually it asks only for the second > one and prints it. module Main where import System.IO.Unsafe chooseAct :: String -> IO (IO ()) chooseAct s = do putStrLn $ s ++ "?" l <- getLine if (l == s) then return $ putStrLn $ "w00t! a " ++ s else return $ putStrLn "bah" getActs :: IO [IO ()] getActs = mapM chooseAct ["foo", "bar", "baz"] main0 = unsafeInterleaveIO getActs >>= unsafeInterleaveIO . sequence_ main1 = unsafeInterleaveIO getActs >>= sequence_ main = main0 >> main1 There you've got the ordering. It's quite easy to write a haskell program that reduces itself to main = return (), though. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From allbery at ece.cmu.edu Thu Jan 1 20:26:42 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Jan 1 20:18:44 2009 Subject: [Haskell-cafe] Thoughts on Haskell and OOP In-Reply-To: References: Message-ID: <42F59663-0943-4E25-B9CE-C9C1A29B0700@ece.cmu.edu> On 2009 Jan 1, at 19:28, Kevin Van Horn wrote: > Haskell has been around in one form or another for nearly two > decades now, yet has never been extended with explicit support for > object-oriented programming. I've http://homepages.cwi.nl/~ralf/OOHaskell/ http://research.microsoft.com/en-us/um/people/simonpj/Papers/oo-haskell/index.htm http://www.cs.chalmers.se/~nordland/ohaskell/ http://www.timber-lang.org/ -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090101/c0057fd7/attachment.htm From allbery at ece.cmu.edu Thu Jan 1 20:29:54 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Jan 1 20:21:55 2009 Subject: [Haskell-cafe] Re: unsafeInterleaveIO respecting order of actions In-Reply-To: <49a77b7a0901011708sa425d0dw219b66bfcbce06a8@mail.gmail.com> References: <2f9b2d30812311301y1068b499u77fa12ef0cd44647@mail.gmail.com> <495D3953.6080609@henning-thielemann.de> <20090102013945.221bca1f@solaris> <49a77b7a0901011708sa425d0dw219b66bfcbce06a8@mail.gmail.com> Message-ID: <850BEDD8-F085-4609-8013-679BC7D1770A@ece.cmu.edu> On 2009 Jan 1, at 20:08, David Menendez wrote: > On Thu, Jan 1, 2009 at 7:39 PM, Achim Schneider > wrote: >> There are no lazy monads. Monads imply explicit sequencing... > > Huh? How are you defining "lazy monad"? We've had this discussion before; somewhere in the archives is an example of a State monad doing things in data-driven order instead of the apparently "explicit" monadic sequencing. Monads don't insure sequencing unless designed to do so (as, for example, IO). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From barsoap at web.de Thu Jan 1 20:30:43 2009 From: barsoap at web.de (Achim Schneider) Date: Thu Jan 1 20:22:48 2009 Subject: [Haskell-cafe] Re: unsafeInterleaveIO respecting order of actions References: <2f9b2d30812311301y1068b499u77fa12ef0cd44647@mail.gmail.com> <495D3953.6080609@henning-thielemann.de> <20090102013945.221bca1f@solaris> <20090102022329.53997ef1@solaris> Message-ID: <20090102023043.16075e38@solaris> Achim Schneider wrote: > [...] actually, even better: main = do acts <- unsafeInterleaveIO getActs putStrLn "dumdidum" sequence_ acts , which, at least on my machine, prints dumdidum before asking for foo. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From barsoap at web.de Thu Jan 1 20:39:43 2009 From: barsoap at web.de (Achim Schneider) Date: Thu Jan 1 20:31:40 2009 Subject: [Haskell-cafe] Re: unsafeInterleaveIO respecting order of actions References: <2f9b2d30812311301y1068b499u77fa12ef0cd44647@mail.gmail.com> <495D3953.6080609@henning-thielemann.de> <20090102013945.221bca1f@solaris> <49a77b7a0901011708sa425d0dw219b66bfcbce06a8@mail.gmail.com> <850BEDD8-F085-4609-8013-679BC7D1770A@ece.cmu.edu> Message-ID: <20090102023943.089cb029@solaris> "Brandon S. Allbery KF8NH" wrote: > On 2009 Jan 1, at 20:08, David Menendez wrote: > > On Thu, Jan 1, 2009 at 7:39 PM, Achim Schneider > > wrote: > >> There are no lazy monads. Monads imply explicit sequencing... > > > > Huh? How are you defining "lazy monad"? > > > We've had this discussion before; somewhere in the archives is an > example of a State monad doing things in data-driven order instead > of the apparently "explicit" monadic sequencing. Monads don't > insure sequencing unless designed to do so (as, for example, IO). > The more I try to put stuff into words, the more I part from lambda calculus into the regions of syntactical pitfalls. Therefore, I'm just going to shut up. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From derek.a.elkins at gmail.com Thu Jan 1 20:44:29 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Thu Jan 1 20:36:23 2009 Subject: [Haskell-cafe] Thoughts on Haskell and OOP In-Reply-To: References: Message-ID: <1230860669.31199.43.camel@derek-laptop> On Thu, 2009-01-01 at 17:28 -0700, Kevin Van Horn wrote: > Haskell has been around in one form or another for nearly two decades > now, yet has never been extended with explicit support for > object-oriented programming. Yes it has albeit in spun-off languages. See O'Haskell and Timber. > I've been thinking about why this is so. I've come to the conclusion > that Haskell simply doesn't need any explicit OOP support -- algebraic > datatypes, modules, lazy evaluation, and first-class functions give > you everything you need > to do the kinds of things you would use classes and inheritance for in > OO languages. Certainly not, though (particularly with existential types) it does cover a lot of what people -actually- do with OOP. It is possible to -encode- OOP into Haskell, but it is very rare to see code that uses/does these encodings (for good reason.) OOHaskell includes several: http://homepages.cwi.nl/~ralf/OOHaskell/ > To see why this is so, let's think about what OOP is. At the most > basic level we have what some call object-based programming. This > amounts to support for data hiding and abstract data types. Haskell's > module system handles this function quite well, without any need to > introduce a special concept of "class" (in the OO sense) nor private > vs. public class members. > > > Object-oriented programming is then object-based programming plus > class hierarchies and inheritance. Why are these useful? I don't think most OO programmers would agree with either of these two paragraphs. I don't. Also there are OO approaches that don't use classes or inheritance. > Properly used, OOP is all about interface inheritance, not > implementation inheritance. (At least in C++, implementation > inheritance -- inheriting the data members and method implementations > of a base class -- usually leads to bad design, and is discouraged by > the experts.) (For those more familiar with Python, "duck typing" is > the analog of interface inheritance for a dynamically-typed language.) > Interface inheritance allows you to write procedures that operate on > the base-class interface, but can be applied to objects of any type > derived from the base class. Can we do this in Haskell? While I agree that implementation inheritance does usually lead to poor design and should usually be avoided, I don't agree that it is "improper" and I do think many would consider it a crucial feature of OO. > > > Yes, we can. Let's consider the Haskell analog of an immutable C++ > base class: > > > struct Base { > virtual ~Base(); > virtual int foo() const; > virtual int bar(int n) const; > }; > > > class derived :: public Base { > ... data members ... > public: > derived(T_1 arg1, ..., T_k argk); > ... implementations of the virtual functions ... > }; > > > Haskell has no direct analog of object classes and virtual methods, > but you can use lazy evaluation and first-class functions to achieve > the same result: > > > data Base = Base { foo :: Int, bar :: Int -> Int } > > > derived :: T_1 -> ... -> T_k -> Base > derived a_1 ... a_k = Base { foo = ...; bar = bar } where bar n > = ... > > The analog of a mutable C++ base class is a little bit more involved, > but not much. Suppose that we change bar(int) to be a mutating method > in the C++ Base class: > > > virtual int bar(int n); > > > The Haskell analog then changes to > > > data Base = Base { foo :: Int, bar :: Int -> (Int, Base) } > > > derived :: T_1 -> ... -> T_k -> Base > derived a_1 ... a_k = Base { foo = ...; bar = bar } where > bar n = (..., (derived a_1' ... a_k')) > > > (Here a_1', ..., a_k' are k expressions involving n and a_1, ..., > a_k.) There are a lot more issues than your example illustrates. That said, encodings like this one can often suffice. Luca Cardelli and co. did a lot of work on this in the '90s. See http://lucacardelli.name/Papers/ObjectEncodings.ps for an overview of much of it, though there is later work that resolves some of the issues in the conclusion. Ultimately, I'd say most Haskell programmers simply don't "do the kinds of things you'd classes and inheritance for." Occasionally techniques that could be viewed as (simple) object encodings are used, though rarely is that perspective actually taken. Other times other techniques are used to achieve similar ends. Most of the time, though, Haskell code is written in a functional style that is simply not extensible in the ways that OO code is. From dave at zednenem.com Thu Jan 1 21:10:19 2009 From: dave at zednenem.com (David Menendez) Date: Thu Jan 1 21:02:09 2009 Subject: [Haskell-cafe] Re: unsafeInterleaveIO respecting order of actions In-Reply-To: <850BEDD8-F085-4609-8013-679BC7D1770A@ece.cmu.edu> References: <2f9b2d30812311301y1068b499u77fa12ef0cd44647@mail.gmail.com> <495D3953.6080609@henning-thielemann.de> <20090102013945.221bca1f@solaris> <49a77b7a0901011708sa425d0dw219b66bfcbce06a8@mail.gmail.com> <850BEDD8-F085-4609-8013-679BC7D1770A@ece.cmu.edu> Message-ID: <49a77b7a0901011810k61f9ec75v53c523fcc44ecc27@mail.gmail.com> On Thu, Jan 1, 2009 at 8:29 PM, Brandon S. Allbery KF8NH wrote: > On 2009 Jan 1, at 20:08, David Menendez wrote: >> >> On Thu, Jan 1, 2009 at 7:39 PM, Achim Schneider wrote: >>> >>> There are no lazy monads. Monads imply explicit sequencing... >> >> Huh? How are you defining "lazy monad"? > > > We've had this discussion before; somewhere in the archives is an example of > a State monad doing things in data-driven order instead of the apparently > "explicit" monadic sequencing. Monads don't insure sequencing unless > designed to do so (as, for example, IO). Certainly. I asked because Achim might have been making a point about about call-by-need versus call-by-value, or something. -- Dave Menendez From barsoap at web.de Thu Jan 1 21:19:42 2009 From: barsoap at web.de (Achim Schneider) Date: Thu Jan 1 21:11:40 2009 Subject: [Haskell-cafe] Re: unsafeInterleaveIO respecting order of actions References: <2f9b2d30812311301y1068b499u77fa12ef0cd44647@mail.gmail.com> <495D3953.6080609@henning-thielemann.de> <20090102013945.221bca1f@solaris> <49a77b7a0901011708sa425d0dw219b66bfcbce06a8@mail.gmail.com> <850BEDD8-F085-4609-8013-679BC7D1770A@ece.cmu.edu> <49a77b7a0901011810k61f9ec75v53c523fcc44ecc27@mail.gmail.com> Message-ID: <20090102031942.332e7735@solaris> "David Menendez" wrote: > On Thu, Jan 1, 2009 at 8:29 PM, Brandon S. Allbery KF8NH > wrote: > > On 2009 Jan 1, at 20:08, David Menendez wrote: > >> > >> On Thu, Jan 1, 2009 at 7:39 PM, Achim Schneider > >> wrote: > >>> > >>> There are no lazy monads. Monads imply explicit sequencing... > >> > >> Huh? How are you defining "lazy monad"? > > > > > > We've had this discussion before; somewhere in the archives is an > > example of a State monad doing things in data-driven order instead > > of the apparently "explicit" monadic sequencing. Monads don't > > insure sequencing unless designed to do so (as, for example, IO). > > Certainly. I asked because Achim might have been making a point about > about call-by-need versus call-by-value, or something. > Nah, I was speculating about (possibly better) ways to specify dependencies of side-effects. Ways, that is, that enable the computer to directly implement your perception of priorities like importance of ordering vs. importance of results. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From vigalchin at gmail.com Thu Jan 1 22:45:44 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Jan 1 22:37:34 2009 Subject: [Haskell-cafe] representation on persistent store question Message-ID: <5ae4f2ba0901011945t440739au51eb5e9c9b61d069@mail.gmail.com> Hello, Say I have several data structures that are marshalled(using Binary class) and written out linearly on persistence store. I want to calculate the offsets in bytes of these various data structures in a functional language way. What is the "suggested" (elegant) way .... ? Regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090101/abe5347a/attachment.htm From bos at serpentine.com Thu Jan 1 23:32:49 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu Jan 1 23:24:39 2009 Subject: [Haskell-cafe] Will GHC finally support epoll in 2009? In-Reply-To: <3e62d4360812311142hf32295kda105a971fb01807@mail.gmail.com> References: <3e62d4360812311142hf32295kda105a971fb01807@mail.gmail.com> Message-ID: On Wed, Dec 31, 2008 at 11:42 AM, Levi Greenspan wrote: > Hence my question - is it likely that GHC will support epoll in 2009? Yes. I'm working on a patch at the moment. From aslatter at gmail.com Thu Jan 1 23:51:50 2009 From: aslatter at gmail.com (Antoine Latter) Date: Thu Jan 1 23:43:41 2009 Subject: [Haskell-cafe] representation on persistent store question In-Reply-To: <5ae4f2ba0901011945t440739au51eb5e9c9b61d069@mail.gmail.com> References: <5ae4f2ba0901011945t440739au51eb5e9c9b61d069@mail.gmail.com> Message-ID: <694519c50901012051u5ef565d6g5ca033c243b55a19@mail.gmail.com> 2009/1/1 Galchin, Vasili : > > Say I have several data structures that are marshalled(using Binary > class) and written out linearly on persistence store. I want to calculate > the offsets in bytes of these various data structures in a functional > language way. What is the "suggested" (elegant) way .... ? > It doesn't look like the 'Put' monad in te binary package keeps track of position in the output stream. Is there a bigger-picture goal you're trying to achieve? Maybe we could suggest a better approach by stepping back a bit. -Antoine From vigalchin at gmail.com Fri Jan 2 00:25:10 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Fri Jan 2 00:16:59 2009 Subject: [Haskell-cafe] representation on persistent store question In-Reply-To: <694519c50901012051u5ef565d6g5ca033c243b55a19@mail.gmail.com> References: <5ae4f2ba0901011945t440739au51eb5e9c9b61d069@mail.gmail.com> <694519c50901012051u5ef565d6g5ca033c243b55a19@mail.gmail.com> Message-ID: <5ae4f2ba0901012125m77cacaa4k2afe4193202f5383@mail.gmail.com> The second data structure is an array of structure .. the third set of structure are a series of "bit" lists ... Each array element has an offset for its corresponding "bit list": [{........, offset: Int64}] [[bit]] when I marshall up all this "offset" should be the serialized/"marshalled" offset of its correponding [bit]!! Regards, Vasili On Thu, Jan 1, 2009 at 10:51 PM, Antoine Latter wrote: > 2009/1/1 Galchin, Vasili : > > > > Say I have several data structures that are marshalled(using Binary > > class) and written out linearly on persistence store. I want to calculate > > the offsets in bytes of these various data structures in a functional > > language way. What is the "suggested" (elegant) way .... ? > > > > It doesn't look like the 'Put' monad in te binary package keeps track > of position in the output stream. > > Is there a bigger-picture goal you're trying to achieve? Maybe we > could suggest a better approach by stepping back a bit. > > -Antoine > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090101/2b37b59a/attachment.htm From aslatter at gmail.com Fri Jan 2 01:24:54 2009 From: aslatter at gmail.com (Antoine Latter) Date: Fri Jan 2 01:16:46 2009 Subject: [Haskell-cafe] representation on persistent store question In-Reply-To: <5ae4f2ba0901012150w2d514763nbafa7d532fcd6485@mail.gmail.com> References: <5ae4f2ba0901011945t440739au51eb5e9c9b61d069@mail.gmail.com> <694519c50901012051u5ef565d6g5ca033c243b55a19@mail.gmail.com> <5ae4f2ba0901012125m77cacaa4k2afe4193202f5383@mail.gmail.com> <694519c50901012141p7b1c338alab7acafacc9b73a6@mail.gmail.com> <5ae4f2ba0901012150w2d514763nbafa7d532fcd6485@mail.gmail.com> Message-ID: <694519c50901012224u56efbaa1t34c8d6a6b559ecc@mail.gmail.com> On Jan 1, 2009 11:50pm, "Galchin, Vasili" wrote: > it is a bioinformatics standard .. . I am writing on this newsgroup in order to try to be objective to get a "correct" and elegant answer .. in any case I am helping on the bioinformatics code (you can see on Hackage). I am trying to finish the 2Bit file format code ... it seems to me that bioinformatics as an area is not clearly defined .... e.g. it is unclear to me whether "offset" is a marshalled/serialized concept or or unmarshalled/unserialized concept ..... this distinction is very important .... I will have to think about more myself! > > > Regards, Vasili > Here's some code using Data.Binary to store data as offsets into a byte array. I haven't tested it too much, so it may have bugs. Maybe there's some inspiration in there. -Antoine >>>> import Data.Binary import Data.Binary.Get import Data.Binary.Put import Data.ByteString.Lazy (ByteString) import qualified Data.ByteString.Lazy as B data TestStruct = TestStruct { property1 :: ByteString , property2 :: ByteString , property3 :: ByteString } deriving Show {- The serialized format looks like (all big-endian): * first offset into data block (Word32) * second offset into data block (Word32) * third offset into data block (Word32) * length of bnary data block (Word32) * binary data block (Arbitrary binary data) -} instance Binary TestStruct where put struct = let data1 = property1 struct data2 = property2 struct data3 = property3 struct dataBlock = data1 `B.append` data2 `B.append` data3 offset1 = 0 offset2 = offset1 + B.length data1 offset3 = offset2 + B.length data2 in do putWord32be $ fromIntegral offset1 putWord32be $ fromIntegral offset2 putWord32be $ fromIntegral offset3 putWord32be $ fromIntegral $ B.length dataBlock putLazyByteString dataBlock get = do offset1 <- getWord32be offset2 <- getWord32be offset3 <- getWord32be dataBlockLength <- getWord32be dataBlock <- B.drop (fromIntegral offset1) `fmap` getLazyByteString (fromIntegral dataBlockLength) let (data1, rest1) = B.splitAt (fromIntegral $ offset2 - offset1) dataBlock (data2, rest2) = B.splitAt (fromIntegral $ offset3 - offset2 - offset1) rest1 data3 = rest2 return $ TestStruct data1 data2 data3 <<<<< From colin at colina.demon.co.uk Fri Jan 2 01:39:02 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Fri Jan 2 01:30:53 2009 Subject: [Haskell-cafe] Thoughts on Haskell and OOP In-Reply-To: (Kevin Van Horn's message of "Thu\, 1 Jan 2009 17\:28\:21 -0700") References: Message-ID: >>>>> "Kevin" == Kevin Van Horn writes: Kevin> What do the rest of you think? Is my analysis correct? No, because ... Kevin> Properly used, OOP is all about interface inheritance, not Kevin> implementation inheritance. (At least in C++, Kevin> implementation inheritance -- inheriting the data members Kevin> and method implementations of a base class -- usually leads Kevin> to bad design, and is discouraged by the experts.) But C++ isn't OOP. It's a bodge where OO stuff is added on top of C. Naturally, this doesn't work out well. But that isn't necessarily why C++ doesn't vdo implementation inheritance well. Properly used, OOP is all about interface inheritance and implementation inheritance, with contracts used to ensure semantically correct behaviour. See Eiffel. -- Colin Adams Preston Lancashire From vigalchin at gmail.com Fri Jan 2 02:25:18 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Fri Jan 2 02:17:07 2009 Subject: [Haskell-cafe] representation on persistent store question In-Reply-To: <694519c50901012224u56efbaa1t34c8d6a6b559ecc@mail.gmail.com> References: <5ae4f2ba0901011945t440739au51eb5e9c9b61d069@mail.gmail.com> <694519c50901012051u5ef565d6g5ca033c243b55a19@mail.gmail.com> <5ae4f2ba0901012125m77cacaa4k2afe4193202f5383@mail.gmail.com> <694519c50901012141p7b1c338alab7acafacc9b73a6@mail.gmail.com> <5ae4f2ba0901012150w2d514763nbafa7d532fcd6485@mail.gmail.com> <694519c50901012224u56efbaa1t34c8d6a6b559ecc@mail.gmail.com> Message-ID: <5ae4f2ba0901012325s1ed37addwda276f5d665b86f1@mail.gmail.com> dude .. you rock ... let me check it out ;^) Vasili On Fri, Jan 2, 2009 at 12:24 AM, Antoine Latter wrote: > On Jan 1, 2009 11:50pm, "Galchin, Vasili" wrote: > > it is a bioinformatics standard .. . I am writing on this newsgroup in > order to try to be objective to get a "correct" and elegant answer .. in any > case I am helping on the bioinformatics code (you can see on Hackage). I am > trying to finish the 2Bit file format code ... it seems to me that > bioinformatics as an area is not clearly defined .... e.g. it is unclear to > me whether "offset" is a marshalled/serialized concept or or > unmarshalled/unserialized concept ..... this distinction is very important > .... I will have to think about more myself! > > > > > > Regards, Vasili > > > > > Here's some code using Data.Binary to store data as offsets into a > byte array. I haven't tested it too much, so it may have bugs. Maybe > there's some inspiration in there. > > -Antoine > > >>>> > import Data.Binary > import Data.Binary.Get > import Data.Binary.Put > > import Data.ByteString.Lazy (ByteString) > import qualified Data.ByteString.Lazy as B > > data TestStruct = TestStruct > { property1 :: ByteString > , property2 :: ByteString > , property3 :: ByteString > } > deriving Show > > {- > > The serialized format looks like (all big-endian): > > * first offset into data block (Word32) > * second offset into data block (Word32) > * third offset into data block (Word32) > * length of bnary data block (Word32) > * binary data block (Arbitrary binary data) > > -} > instance Binary TestStruct where > put struct = > let data1 = property1 struct > data2 = property2 struct > data3 = property3 struct > > dataBlock = data1 `B.append` data2 `B.append` data3 > > offset1 = 0 > offset2 = offset1 + B.length data1 > offset3 = offset2 + B.length data2 > > in do > putWord32be $ fromIntegral offset1 > putWord32be $ fromIntegral offset2 > putWord32be $ fromIntegral offset3 > > putWord32be $ fromIntegral $ B.length dataBlock > putLazyByteString dataBlock > > get = do > offset1 <- getWord32be > offset2 <- getWord32be > offset3 <- getWord32be > > dataBlockLength <- getWord32be > dataBlock <- B.drop (fromIntegral offset1) `fmap` > getLazyByteString (fromIntegral dataBlockLength) > > let (data1, rest1) = > B.splitAt (fromIntegral $ offset2 - offset1) dataBlock > (data2, rest2) = > B.splitAt (fromIntegral $ offset3 - offset2 - offset1) rest1 > data3 = rest2 > > return $ TestStruct data1 data2 data3 > <<<<< > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090102/7794cb71/attachment.htm From apfelmus at quantentunnel.de Fri Jan 2 05:50:26 2009 From: apfelmus at quantentunnel.de (Apfelmus, Heinrich) Date: Fri Jan 2 05:42:01 2009 Subject: [Haskell-cafe] Re: Updating doubly linked lists In-Reply-To: References: <495B6E91.8050809@van.steenbergen.nl> <2f9b2d30812311311k51d2a5adq48697976cb48af75@mail.gmail.com> Message-ID: S. G?nther wrote: >> >> Whether circular or not, sharing values by using a "back pointer" is >> problematic for any update. Why not use a zipper instead? > > I looked into zippers before and the problem I had was that they never > really matched the structure which I needed and which led me to think > about this whole knot tying thing again. What kind of structure do you need exactly? > The things I read about them > always assumed either a list like (i.e. linear) or a tree like (i.e. existence > of a root) structure on the type to be plugged into the zipper. Viewing the zipper as the derivative of a data type opens up more possibilities. That being said, every algebraic data types has a tree-like structure. The extra invariants like left . right = right . left that the programmer imposes are what make them different from trees. > So I just have to decide whether to use IORefs/Vars (clunky) > or to implement zippers for the structure I need (probably too hard for me). It's not too hard for you. You've got a whole haskell-cafe and #haskell at your fingertips, after all. ;) Regards, H. Apfelmus From frodo at theshire.org Fri Jan 2 05:52:29 2009 From: frodo at theshire.org (Cristiano Paris) Date: Fri Jan 2 05:44:17 2009 Subject: [Haskell-cafe] What are side effects in Haskell? In-Reply-To: References: <1230041789.3231.13.camel@dhcppc0> <1230393008.3045.33.camel@dhcppc0> Message-ID: On Tue, Dec 30, 2008 at 8:35 AM, Conal Elliott wrote: >> Everything in Haskell is a function [...] > > Where did this idea come from? > > I'd say every expression in Haskell denotes a pure value, only some of which > are functions (have type a->b for some types a & b). Maybe more formally correct, but my statement still holds true as any values can be tought as constant functions, even those representing functions themselves. Cristiano From redcom at fedoms.com Fri Jan 2 08:51:17 2009 From: redcom at fedoms.com (=?ISO-8859-15?Q?G=FCnther_Schmidt?=) Date: Fri Jan 2 08:43:23 2009 Subject: [Haskell-cafe] HDBC-ODBC - MS-Access backend problems with inserts Message-ID: Hi, I'm using HDBC extensively in my app and it works very well. Most of the time my app uses an Sqlite database with HDBC and no problems there. The only problem I have is when I use it against an Access database backend in which I want to do inserts. Creating a connection works fine, also running queries. It only budges when I want to do inserts. *RedcomBatch.Export> handleSqlError $ run dbc "insert into mytable values (?)" [toSql "dummytext"] *** Exception: user error (SQL error: SqlError {seState = "[\"HY104\"]", seNativ eError = -1, seErrorMsg = "bindparameter 1: [\"98: [Microsoft][ODBC Microsoft Ac cess Driver]Ung\\252ltiger Genauigkeitswert. \"]"}) *RedcomBatch.Export> Any ideas why? G?nther The German part of the error message reads "invalid precision value" From fmartini at gmail.com Fri Jan 2 09:20:07 2009 From: fmartini at gmail.com (Felix Martini) Date: Fri Jan 2 09:11:57 2009 Subject: [Haskell-cafe] Use of abbreviations in Haskell Message-ID: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> Hi all, There is currently a discussion on reddit/programming about Haskell. One complaint is that Haskell functions often use abbreviated names. I tend to agree with that. In my personal experience it generally takes more time to learn a third party Haskell library than libraries written in other languages. I am not sure why but it could be because of function names. It seems to me that Haskell's current record syntax enhances this. Take for example the new xml library, data Element = Element { elName :: QName elAttribs :: [Attr] elContent :: [Content] elLine :: Maybe Line } data Attr = Attr { attrKey :: QName attrVal :: String } data QName = QName { qName :: String qURI :: Maybe String qPrefix :: Maybe String } Personally i would prefer it to be something like data Element = Element { name :: QualifiedName attributes :: [Attribute] content :: [Content] line :: Maybe Line } data Attribute = Attribute { key :: QualifiedName value :: String } data QualifiedName = QualifiedName { name :: String uri :: Maybe String prefix :: Maybe String } but the global scope of the record field names doesn't allow that and therefore all kinds of abbreviations are inserted in front of the record field names which are hard to remember. So a better record syntax would be welcome. Perhaps the constructor could be used to limit the scope of the record field name e.g. QualifiedName.prefix? Regards, Felix From leimy2k at gmail.com Fri Jan 2 10:50:20 2009 From: leimy2k at gmail.com (David Leimbach) Date: Fri Jan 2 10:42:08 2009 Subject: [Haskell-cafe] What are side effects in Haskell? In-Reply-To: References: <1230041789.3231.13.camel@dhcppc0> <1230393008.3045.33.camel@dhcppc0> Message-ID: <3e1162e60901020750q26f8b746v13dbfe80561de803@mail.gmail.com> On Fri, Jan 2, 2009 at 2:52 AM, Cristiano Paris wrote: > On Tue, Dec 30, 2008 at 8:35 AM, Conal Elliott wrote: > >> Everything in Haskell is a function [...] > > > > Where did this idea come from? > > > > I'd say every expression in Haskell denotes a pure value, only some of > which > > are functions (have type a->b for some types a & b). > > Maybe more formally correct, but my statement still holds true as any > values can be tought as constant functions, even those representing > functions themselves. > > Cristiano I think most of the introductory material I've seen that made me go "aha now I get it" say pure functional programming is about values, and transformations of those values, and that functions are also values. Then they usually go into admitting that that's only really good for heating up the CPU and that I/O and side-effects have to be made possible, but they're not willing to give up what they won for us by having everything be a value... then monads enter the discussion or "actions", and then monads get introduced later. Dave > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090102/b85b87b9/attachment-0001.htm From martijn at van.steenbergen.nl Fri Jan 2 11:44:59 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Fri Jan 2 11:36:47 2009 Subject: [Haskell-cafe] Infinite grid In-Reply-To: <495969E7.8030405@henning-thielemann.de> References: <49595560.3040704@van.steenbergen.nl> <495969E7.8030405@henning-thielemann.de> Message-ID: <495E448B.6070202@van.steenbergen.nl> Henning Thielemann wrote: > A dungeon game? :-) Yes. :-) Thank you all for your answers! I especially like David's no-intermediate-structure solution because it allows for defining the area in terms of neighbours instead of needing an index on the rooms. Now that I have core functionality in my game I want to try and build some interesting areas, such as infinite ones: a infinite grid, or an N-dimensional Hilbert curve. Because rooms are mutable, I am building them inside a state monad and use ids: mkRoom :: M RoomId addExit :: RoomId -> Exit -> M () type Exit = (String, RoomId) I thought my original question would give me some ideas on how to construct infinite areas, but this monadic interface complicates things somewhat. If I create all rooms at once, runState never returns, so I will have to create them lazily, perhaps by changing: type Exit = M (String, RoomId) But I think in addition to that I will also needs refs, so that the monadic computation can check using a ref whether it's created its target room before. I will have to experiment and think on this some more. Martijn. From benjaoming at gmail.com Fri Jan 2 11:57:48 2009 From: benjaoming at gmail.com (Benjamin Bach) Date: Fri Jan 2 11:49:55 2009 Subject: [Haskell-cafe] Beginner question Message-ID: Supposing I have the following code: > module Main(main) where > main = putStr (show []) I will get these errors from GHC and Hugs respectively: > Main.hs:2:16: > Ambiguous type variable `a' in the constraint: > `Show a' arising from a use of `show' at Main.hs:2:16-22 > Probable fix: add a type signature that fixes these type variable(s) > ERROR "src/Main.hs":2 - Unresolved top-level overloading > *** Binding : main > *** Outstanding context : Show b But if I change my code to the following, it will compile. > module Main(main) where > main = putStr (show [1]) I have no problems typing in "putStr (show [])" in Hugs... runs fine. So what's wrong? I've really tried hard to think of an explanation, but with no luck.. Thanks, Benjamin From colin at colina.demon.co.uk Fri Jan 2 12:05:06 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Fri Jan 2 11:56:55 2009 Subject: [Haskell-cafe] Beginner question In-Reply-To: (Benjamin Bach's message of "Fri\, 2 Jan 2009 17\:57\:48 +0100") References: Message-ID: >>>>> "Benjamin" == Benjamin Bach writes: Benjamin> Supposing I have the following code: >> module Main(main) where main = putStr (show []) Benjamin> I will get these errors from GHC and Hugs respectively: >> Main.hs:2:16: Ambiguous type variable `a' in the constraint: >> `Show a' arising from a use of `show' at Main.hs:2:16-22 >> Probable fix: add a type signature that fixes these type >> variable(s) >> ERROR "src/Main.hs":2 - Unresolved top-level overloading *** >> Binding : main *** Outstanding context : Show b Benjamin> But if I change my code to the following, it will Benjamin> compile. >> module Main(main) where main = putStr (show [1]) Benjamin> I have no problems typing in "putStr (show [])" in Benjamin> Hugs... runs fine. So what's wrong? I've really tried Benjamin> hard to think of an explanation, but with no luck.. I would say that it is complaining that it doesn't know what type of empty list you want it to show. of course, they will all display the same at run time, but it's compile time that is the problem. -- Colin Adams Preston Lancashire From miguelimo38 at yandex.ru Fri Jan 2 12:05:50 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Fri Jan 2 11:57:52 2009 Subject: [Haskell-cafe] Beginner question In-Reply-To: References: Message-ID: On 2 Jan 2009, at 19:57, Benjamin Bach wrote: > Supposing I have the following code: > >> module Main(main) where >> main = putStr (show []) What type is your "[]" here? main :: IO () putStr :: String -> IO () show [] :: String show :: Show a => a -> String Now, how is Hugs or GHCi supposed to know the type of "[]"? The only information it has is that it's type belongs to the class "Show". You may think it's irrelevant, since empty lists are showed the same; but they are not: for example, ([] :: [Char]) would be shown as '""' (empty string). > I will get these errors from GHC and Hugs respectively: > >> Main.hs:2:16: >> Ambiguous type variable `a' in the constraint: >> `Show a' arising from a use of `show' at Main.hs:2:16-22 >> Probable fix: add a type signature that fixes these type >> variable(s) > >> ERROR "src/Main.hs":2 - Unresolved top-level overloading >> *** Binding : main >> *** Outstanding context : Show b > > But if I change my code to the following, it will compile. > >> module Main(main) where >> main = putStr (show [1]) > > I have no problems typing in "putStr (show [])" in Hugs... runs fine. > So what's wrong? I've really tried hard to think of an explanation, > but with no luck.. > > Thanks, > Benjamin > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From benjaoming at gmail.com Fri Jan 2 12:18:49 2009 From: benjaoming at gmail.com (Benjamin Bach) Date: Fri Jan 2 12:10:39 2009 Subject: [Haskell-cafe] Beginner question In-Reply-To: References: Message-ID: >>> module Main(main) where >>> main = putStr (show []) > > What type is your "[]" here? > (...) > You may think it's irrelevant, since empty lists are showed the same; but > they are not: for example, ([] :: [Char]) would be shown as '""' (empty > string). Of course you're right. Didn't know how to type an empty list. "main = putStr (show ([] :: [Char]))" seems so obvious now. Thanks, Benjamin From barsoap at web.de Fri Jan 2 14:03:01 2009 From: barsoap at web.de (Achim Schneider) Date: Fri Jan 2 13:55:02 2009 Subject: [Haskell-cafe] Re: What are side effects in Haskell? References: <1230041789.3231.13.camel@dhcppc0> <1230393008.3045.33.camel@dhcppc0> <3e1162e60901020750q26f8b746v13dbfe80561de803@mail.gmail.com> Message-ID: <20090102200301.5f3126db@solaris> "David Leimbach" wrote: > I think most of the introductory material I've seen that made me go > "aha now I get it" say pure functional programming is about values, > I dare to claim that functional programming is all about lambdas and reduction, and that functions and values are just two names for the same thing... in the same way that there are words for square and cube, but only one word to sum up all (n-dimensional) hypercubes. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From barsoap at web.de Fri Jan 2 14:16:33 2009 From: barsoap at web.de (Achim Schneider) Date: Fri Jan 2 14:08:31 2009 Subject: [Haskell-cafe] Re: Use of abbreviations in Haskell References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> Message-ID: <20090102201633.1fa066ca@solaris> "Felix Martini" wrote: > [..] > > data QualifiedName = QualifiedName { > name :: String > uri :: Maybe String > prefix :: Maybe String > } > > but the global scope of the record field names doesn't allow that and > therefore all kinds of abbreviations are inserted in front of the > record field names which are hard to remember. So a better record > syntax would be welcome. Perhaps the constructor could be used to > limit the scope of the record field name e.g. QualifiedName.prefix? > /me votes for introducing > data Attribute = Attribute { > Attribute.key :: QualifiedName > Attribute.value :: String > } It's surely gonna be used, and iff it becomes exceedingly wide-spread, it can be made default (in 10 years or so). OTOH, I don't like the idea of having to write "Attribute" all the time, and neither want to write pages of attrKey = Attribute.key for 1000-element records (or TH to tackle standard language problems, for that matter), so there has to be some way for library users to shorten code without being masochistic, somewhat like this: A = Attribute , that is, allow definition of data constructors in usual declarations, up to some limits. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From colin at colina.demon.co.uk Fri Jan 2 14:38:52 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Fri Jan 2 14:30:40 2009 Subject: [Haskell-cafe] Re: Use of abbreviations in Haskell In-Reply-To: <20090102201633.1fa066ca@solaris> (Achim Schneider's message of "Fri\, 2 Jan 2009 20\:16\:33 +0100") References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> <20090102201633.1fa066ca@solaris> Message-ID: >>>>> "Achim" == Achim Schneider writes: Achim> OTOH, I don't like the idea of having to write "Attribute" Achim> all the time, and neither want to write pages of Achim> attrKey = Attribute.key Achim> for 1000-element records (or TH to tackle standard language Achim> problems, for that matter), so there has to be some way for Achim> library users to shorten code without being masochistic, Achim> somewhat like this: Achim> A = Attribute Nay, there's no tax on keystrokes. Code is far more often read than written. -- Colin Adams Preston Lancashire From conal at conal.net Fri Jan 2 14:53:42 2009 From: conal at conal.net (Conal Elliott) Date: Fri Jan 2 14:45:28 2009 Subject: [Haskell-cafe] What are side effects in Haskell? In-Reply-To: References: <1230041789.3231.13.camel@dhcppc0> <1230393008.3045.33.camel@dhcppc0> Message-ID: Hi Cristiano, Similarly, any value can be thought of as a list (perhaps singleton), a Maybe (Just), a pair ((,) undefined or (,) mempty), an IO (return), ... (any Applicative). And yet I've heard "everything is a function" on several occasions, but not these others. Hence my (continuing) puzzlement about the source of that idea. I have some speculations: * In pure "OO" programming, everything is an object, so in pure "functional" programming, one might assume everything is a function. I find the term "value-oriented programming" a more accurate label than "functional programming". * C has definitions for functions but assignments for other types. Since pure functional languages eliminate assignment, one might assume that only functions remain. (I also hear people refer to top-level definitions in a Haskell module as "functions", whether they're of function type or not.) Are there other thoughts & insights about the source of the idea that "everything is a function"? Thanks, - Conal On Fri, Jan 2, 2009 at 2:52 AM, Cristiano Paris wrote: > On Tue, Dec 30, 2008 at 8:35 AM, Conal Elliott wrote: > >> Everything in Haskell is a function [...] > > > > Where did this idea come from? > > > > I'd say every expression in Haskell denotes a pure value, only some of > which > > are functions (have type a->b for some types a & b). > > Maybe more formally correct, but my statement still holds true as any > values can be tought as constant functions, even those representing > functions themselves. > > Cristiano > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090102/42f977e5/attachment.htm From barsoap at web.de Fri Jan 2 15:04:27 2009 From: barsoap at web.de (Achim Schneider) Date: Fri Jan 2 14:56:24 2009 Subject: [Haskell-cafe] Re: Use of abbreviations in Haskell References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> <20090102201633.1fa066ca@solaris> Message-ID: <20090102210427.7ec28d46@solaris> Colin Paul Adams wrote: > >>>>> "Achim" == Achim Schneider writes: > > Achim> OTOH, I don't like the idea of having to write "Attribute" > Achim> all the time, and neither want to write pages of > > Achim> attrKey = Attribute.key > > Achim> for 1000-element records (or TH to tackle standard language > Achim> problems, for that matter), so there has to be some way for > Achim> library users to shorten code without being masochistic, > Achim> somewhat like this: > > Achim> A = Attribute > > Nay, there's no tax on keystrokes. > > Code is far more often read than written. > Say, did you ever read Java and wondered why you have to continuously scroll to the right albeit using a 500-column terminal? Exceedingly long names are fine to organise a large library, but becomes burdensome when code only uses a subset of it... which is usually the case. _both_ in reading and writing. The longer identifiers are, the shorter information distance between two related ones tends to be, as in generateMapThatTakesAFooAndReturnsABarBydoingBaz vs. generateMapThatTakesAFuAndReturnsABarBydoingBaz compare this with locally-defined aliases mapOfFoo and mapOfFu Short notation isn't the problem, missing explanation of it is.[1] Currently, you can observe stuff like data Abst -- raction = Foo | Bar in my code. I don't mind making that a language feature for increased profit. Anyway, my code tends to get refactored more than being read or written. I want to finish typing _before_ the next idea kicks in. [1] This, as a side note, also tends to make me hate academics. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From frodo at theshire.org Fri Jan 2 15:16:17 2009 From: frodo at theshire.org (Cristiano Paris) Date: Fri Jan 2 15:08:04 2009 Subject: [Haskell-cafe] What are side effects in Haskell? In-Reply-To: References: <1230041789.3231.13.camel@dhcppc0> <1230393008.3045.33.camel@dhcppc0> Message-ID: On Fri, Jan 2, 2009 at 8:53 PM, Conal Elliott wrote: > > I have some speculations: > > * In pure "OO" programming, everything is an object, so in pure "functional" > programming, one might assume everything is a function. I find the term > "value-oriented programming" a more accurate label than "functional > programming". First, I've to say that I'm not a language theorist in any way. That said, I think yours is indeed a good point, yet programs in Haskell are *strictly* expressed in terms of function applications, in contrast to other languages where programs are made up *mostly* of function invocations and other effectful statements, like assignments and IO. The fact that functions are values like any others is, at the same time, the beauty and the power of the functional paradigm. Cristiano From miguelimo38 at yandex.ru Fri Jan 2 15:21:43 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Fri Jan 2 15:13:39 2009 Subject: [Haskell-cafe] Use of abbreviations in Haskell In-Reply-To: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> Message-ID: module Element where import QName import ... data Element = Element {name :: QName, attribs :: [Attr], content :: [Content], line :: Maybe Line} module Attr where import QName import ... data Attr = Attr {key :: QName, val :: String} module QName where import ... data QName = QName {name :: String, uri :: Maybe String, prefix :: Maybe String} module Main where import qualified QName as Q import qualified Element as E ... Q.name ... E.name ... On 2 Jan 2009, at 17:20, Felix Martini wrote: > Hi all, > > There is currently a discussion on reddit/programming about Haskell. > One complaint is that Haskell functions often use abbreviated names. I > tend to agree with that. In my personal experience it generally takes > more time to learn a third party Haskell library than libraries > written in other languages. I am not sure why but it could be because > of function names. It seems to me that Haskell's current record syntax > enhances this. Take for example the new xml library, > > data Element = Element { > elName :: QName > elAttribs :: [Attr] > elContent :: [Content] > elLine :: Maybe Line > } > > data Attr = Attr { > attrKey :: QName > attrVal :: String > } > > data QName = QName { > qName :: String > qURI :: Maybe String > qPrefix :: Maybe String > } > > Personally i would prefer it to be something like > > data Element = Element { > name :: QualifiedName > attributes :: [Attribute] > content :: [Content] > line :: Maybe Line > } > > data Attribute = Attribute { > key :: QualifiedName > value :: String > } > > data QualifiedName = QualifiedName { > name :: String > uri :: Maybe String > prefix :: Maybe String > } > > but the global scope of the record field names doesn't allow that and > therefore all kinds of abbreviations are inserted in front of the > record field names which are hard to remember. So a better record > syntax would be welcome. Perhaps the constructor could be used to > limit the scope of the record field name e.g. QualifiedName.prefix? > > > Regards, > Felix > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From dons at galois.com Fri Jan 2 15:27:24 2009 From: dons at galois.com (Don Stewart) Date: Fri Jan 2 15:18:57 2009 Subject: [Haskell-cafe] #haskell IRC channel reaches 600 users Message-ID: <20090102202724.GA3953@scytale.galois.com> A small announcement :) 7 years after its inception, under the guiding hand of Shae Erisson (aka shapr), the #haskell IRC channel[1] on freenode has reached 600 concurrent users! It's now in the top 3 language channels by size. To chart the growth, we can note that the channel was founded in late 2001, and had slow growth till 2006, reaching 200 users in January of that year. Since then growth in the user base has been far more rapid, reaching 300 users in Dec 2006, 400 users in August 2007, 500 users by July 2008, and 600 on January 2, 2009. This puts the channel at the 7th largest community of the 7000 freenode channels, and in the top 3 language communities. For comparision, a sample of the state of the other language communities, with comments comapred to their status a year ago: #php 612 #python 604 > #haskell 602 -- up 4 ##c++ 558 ##c 506 -- down 1 #perl 502 -- down 3 #ruby-lang 288 -- down #lisp 264 ##javascript 241 #erlang 146 -- unchanged #perl6 129 -- unchanged #scheme 123 -- down #lua 102 -- unchanged #clojure 78 #ocaml 70 -- unchanged You can see the growth of the channel over here: http://haskell.org/haskellwiki/IRC_channel If you've not dropped by the channel yet, feel free to come and chat, and toss around some lambdas! :) Cheers, Don From frodo at theshire.org Fri Jan 2 15:37:55 2009 From: frodo at theshire.org (Cristiano Paris) Date: Fri Jan 2 15:29:41 2009 Subject: [Haskell-cafe] Use of abbreviations in Haskell In-Reply-To: References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> Message-ID: On Fri, Jan 2, 2009 at 9:21 PM, Miguel Mitrofanov wrote: > module Element where > import QName > import ... > data Element = Element {name :: QName, attribs :: [Attr], content :: > [Content], line :: Maybe Line} > > module Attr where > import QName > import ... > data Attr = Attr {key :: QName, val :: String} > > module QName where > import ... > data QName = QName {name :: String, uri :: Maybe String, prefix :: Maybe > String} > > module Main where > import qualified QName as Q > import qualified Element as E > ... Q.name ... E.name ... I'm using this pattern of writing code and, so far, I find it very convenient. Yet, the code is likely to be spread across lots of files, which is not always a Good Thing. Cristiano From derek.a.elkins at gmail.com Fri Jan 2 15:41:06 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Fri Jan 2 15:32:55 2009 Subject: [Haskell-cafe] Use of abbreviations in Haskell In-Reply-To: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> Message-ID: <1230928866.31199.68.camel@derek-laptop> On Fri, 2009-01-02 at 15:20 +0100, Felix Martini wrote: > Hi all, > > There is currently a discussion on reddit/programming about Haskell. > One complaint is that Haskell functions often use abbreviated names. I > tend to agree with that. In my personal experience it generally takes > more time to learn a third party Haskell library than libraries > written in other languages. I am not sure why but it could be because > of function names. It seems to me that Haskell's current record syntax > enhances this. Take for example the new xml library, > > data Element = Element { > elName :: QName > elAttribs :: [Attr] > elContent :: [Content] > elLine :: Maybe Line > } > > data Attr = Attr { > attrKey :: QName > attrVal :: String > } > > data QName = QName { > qName :: String > qURI :: Maybe String > qPrefix :: Maybe String > } > > Personally i would prefer it to be something like > > data Element = Element { > name :: QualifiedName > attributes :: [Attribute] > content :: [Content] > line :: Maybe Line > } > > data Attribute = Attribute { > key :: QualifiedName > value :: String > } > > data QualifiedName = QualifiedName { > name :: String > uri :: Maybe String > prefix :: Maybe String > } > > but the global scope of the record field names doesn't allow that They are not global. They are scoped to the module just like any other function definition. So if you were to put each record in it's own module you can have Attribute.key today. No one does this though because that's rather heavy-weight. I've suggested in #haskell a few times an orthogonal language feature that will resolve this as well as providing other nice things and, being orthogonal, it keeps namespacing to namespacing mechanisms (namely modules.) The feature is simply local modules. You'd get what you want by simply writing, module Attribute where data Attribute = Attribute { key :: QualifiedName, value :: String } I haven't been able to find any semantic difficulties with this addition. There are some choices, namely what to import and export by default and some scoping issues. My choices would be to import everything in scope at the module declaration, the containing module tacitly imports everything the contained module exports, the same notation Module.name is used so a local module would shadow a top-level (hierarchical) module of the same name (though I don't expect that to be a common case.) With these conventions there would often be nominal mutual recursion between local modules at the same level. The implementation could either check to see if there is any actual mutual recursion and give an error, or, much more preferably, simply allow mutually recursive local modules as this should be much easier to handle than mutually recursive top-level modules. Some other benefits of this would be a nice way to make abstract data types, which are also underused due to the heaviness of the module system. You could write, for example, module Stack (Stack, empty, push, pop, isEmpty) where newtype Stack a = Stack [a] empty = Stack [] push x (Stack xs) = Stack (x:xs) pop (Stack (x:xs)) = Just (x, Stack xs) pop (Stack [] ) = Nothing isEmpty (Stack xs) = null xs It should be straightforward to implement this today as a pre-processor at the cost of not allowing local modules with the same qualified name as a top-level module and losing some encapsulation. The pre-processor would simply need to extract all the local module declarations and make the appropriate hierarchical modules and add the appropriate import statements. The easiest and most restrictive way to deal with mutual recursion in this case is simply have a local module only import it's ancestor modules and any modules explicitly imported. The benefit of this approach is that it doesn't require any kind of analysis, it could be done on an almost purely textual basis. > and > therefore all kinds of abbreviations are inserted in front of the > record field names which are hard to remember. So a better record > syntax would be welcome. Perhaps the constructor could be used to > limit the scope of the record field name e.g. QualifiedName.prefix? > > > Regards, > Felix > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From miguelimo38 at yandex.ru Fri Jan 2 15:48:15 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Fri Jan 2 15:40:03 2009 Subject: [Haskell-cafe] Use of abbreviations in Haskell In-Reply-To: References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> Message-ID: >> >> module Main where >> import qualified QName as Q >> import qualified Element as E >> ... Q.name ... E.name ... > > I'm using this pattern of writing code and, so far, I find it very > convenient. Yet, the code is likely to be spread across lots of files, > which is not always a Good Thing. That's a completely different matter. Personally, I think that holding each module in a separate file is not a great idea. From jonathanccast at fastmail.fm Fri Jan 2 15:54:45 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Fri Jan 2 15:46:35 2009 Subject: [Haskell-cafe] Use of abbreviations in Haskell In-Reply-To: References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> Message-ID: <1230929685.6299.0.camel@jonathans-macbook> On Fri, 2009-01-02 at 23:48 +0300, Miguel Mitrofanov wrote: > >> > >> module Main where > >> import qualified QName as Q > >> import qualified Element as E > >> ... Q.name ... E.name ... > > > > I'm using this pattern of writing code and, so far, I find it very > > convenient. Yet, the code is likely to be spread across lots of files, > > which is not always a Good Thing. > > That's a completely different matter. Personally, I think that holding > each module in a separate file is not a great idea. +1 jcc From ml at isaac.cedarswampstudios.org Fri Jan 2 15:59:07 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Fri Jan 2 15:51:18 2009 Subject: [Haskell-cafe] Use of abbreviations in Haskell In-Reply-To: <1230928866.31199.68.camel@derek-laptop> References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> <1230928866.31199.68.camel@derek-laptop> Message-ID: <495E801B.3090409@isaac.cedarswampstudios.org> Derek Elkins wrote: > I haven't been able to find any semantic difficulties with this > addition. I like it too... what I run into is that there's an implicit assumption that module of name Foo.Bar.Baz *must* be found in a file Foo/Bar/Baz.[l]hs . "module Main" seems to be the only one exempted from it. GHC uses this all the time when going looking for a module's source code. (it does help make sure that for any module name in a package, there's only one version of the source-code for that module...) So I think we need to accomplish working out the kinks we may get in trying to break this assumption. -Isaac From s.clover at gmail.com Fri Jan 2 16:12:50 2009 From: s.clover at gmail.com (Sterling Clover) Date: Fri Jan 2 16:03:45 2009 Subject: [Haskell-cafe] What are side effects in Haskell? In-Reply-To: References: <1230041789.3231.13.camel@dhcppc0> <1230393008.3045.33.camel@dhcppc0> Message-ID: <2A6FC0E4-7700-4CF1-A874-1FB93EE6602D@gmail.com> Granting the "everything is a function" idea the best intent, maybe what it's trying to express is the related but different notion that everything *can be* a function -- i.e. that any value can be replaced by a function which yields a value of the appropriate type. Alternately, it could be a confusion between the untyped lambda calculus, in which everything really is a function, and the typed lambda calculus, in which things are more complicated? --S. On Jan 2, 2009, at 2:53 PM, Conal Elliott wrote: > Hi Cristiano, > > Similarly, any value can be thought of as a list (perhaps > singleton), a Maybe (Just), a pair ((,) undefined or (,) mempty), > an IO (return), ... (any Applicative). > > And yet I've heard "everything is a function" on several occasions, > but not these others. Hence my (continuing) puzzlement about the > source of that idea. I have some speculations: > > * In pure "OO" programming, everything is an object, so in pure > "functional" programming, one might assume everything is a > function. I find the term "value-oriented programming" a more > accurate label than "functional programming". > > * C has definitions for functions but assignments for other types. > Since pure functional languages eliminate assignment, one might > assume that only functions remain. (I also hear people refer to > top-level definitions in a Haskell module as "functions", whether > they're of function type or not.) > > Are there other thoughts & insights about the source of the idea > that "everything is a function"? > > Thanks, > > - Conal > > On Fri, Jan 2, 2009 at 2:52 AM, Cristiano Paris > wrote: > On Tue, Dec 30, 2008 at 8:35 AM, Conal Elliott > wrote: > >> Everything in Haskell is a function [...] > > > > Where did this idea come from? > > > > I'd say every expression in Haskell denotes a pure value, only > some of which > > are functions (have type a->b for some types a & b). > > Maybe more formally correct, but my statement still holds true as any > values can be tought as constant functions, even those representing > functions themselves. > > Cristiano > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From wasserman.louis at gmail.com Fri Jan 2 17:05:48 2009 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Fri Jan 2 16:57:36 2009 Subject: [Haskell-cafe] Minor quibble Message-ID: Do CORE pragmas inhibit optimizations going between the code inside and outside of the pragma? This seems the case with certain code of mine, but it's not even alluded to in the GHC documentation. ;_; Louis Wasserman wasserman.louis@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090102/1337934c/attachment.htm From tphyahoo at gmail.com Fri Jan 2 17:52:14 2009 From: tphyahoo at gmail.com (Thomas Hartman) Date: Fri Jan 2 17:44:01 2009 Subject: [Haskell-cafe] Gitit - Encoding In-Reply-To: <87abadg6qg.fsf@oqube.oqube.com> References: <87abadg6qg.fsf@oqube.oqube.com> Message-ID: <910ddf450901021452x833ad2an17666ec1de8002d1@mail.gmail.com> Not positive this is relevant, but have you seen http://happstutorial.com/tutorial/foreignchars ? This was my writeup on the problems (and workarounds) I had when working with utf-8 and happs. Overall, it wasn't too bad, but there were some gotchas. Thomas. 2008/12/30 Arnaud Bailly : > Hello, > I have started using Gitit and I am very happy with it and eager to > start hacking. I am running into a practical problem: characters > encoding. When I edit pages using accented characters (I am french), > the accents get mangled when the page come back from server. > > The raw files are incorrectly encoded. Where Shall I look for fixing > this issue ? > > Thanks > > ps: the wiki is live at http://www.notre-ecole.org > > -- > Arnaud Bailly, PhD > OQube - Software Engineering > > web> http://www.oqube.com > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From fruehr at willamette.edu Fri Jan 2 17:54:25 2009 From: fruehr at willamette.edu (Fritz Ruehr) Date: Fri Jan 2 17:46:29 2009 Subject: [Haskell-cafe] How do we decide on the new logo? Message-ID: <9D116A8F-94A2-42CF-891F-E98C25082B0A@willamette.edu> Now that the new year is upon us, I suppose we must decide how to decide* on the new logo for the Haskell site. I'm not sure what the protocol and procedure for voting and tallying should be, but see below for a suggestion. (* a higher-order decision, very appropriate) If you haven't seen the page on the Wiki with proposed new logos, be sure to go there and take a look (but recall that submissions are now closed): I want to thank Don for proposing the contest and everyone who contributed logo designs or modifications. As the designer of the last "official" logo, I think this new crop is terrific, with many suggestions that are more professional-looking and sleeker than the old one: I will have a hard time deciding which one to vote for. Without starting a war on the theory of voting systems, perhaps we should use a system which allows for a certain amount of secondary (etc.) preference to be expressed? (Uh-oh, here come Control.Monad.Voting.HareSTV and Control.Monad.Voting.BordaCount and a hundred other variations, complete with back-tracking and trampolined continuations and ... .) Once we have a winning design, we could perhaps award the designer(s) with a T-shirt or some similar item. We have a small amount of "CafeBucks" (or whatever) accrued in the CafePress account, despite all efforts to avoid profit (rather like avoiding success at all costs). In the past, these funds have been used to purchase courtesy shirts for a few Haskell luminaries, at the discretion of the store proprietor. (Currently I think there are about $60 available.) -- Fritz (Ruehr) From barsoap at web.de Fri Jan 2 18:16:26 2009 From: barsoap at web.de (Achim Schneider) Date: Fri Jan 2 18:08:30 2009 Subject: [Haskell-cafe] Re: How do we decide on the new logo? References: <9D116A8F-94A2-42CF-891F-E98C25082B0A@willamette.edu> Message-ID: <20090103001626.07a77918@solaris> Fritz Ruehr wrote: > Now that the new year is upon us, I suppose we must decide how to > decide* on the new logo for the Haskell site. > I'm not sure what the protocol and procedure for voting and tallying > should be, but see below for a suggestion. > (* a higher-order decision, very appropriate) > > If you haven't seen the page on the Wiki with proposed new logos, be > sure to go there and take a look > (but recall that submissions are now closed): > > > > I want to thank Don for proposing the contest and everyone who > contributed logo designs or modifications. > As the designer of the last "official" logo, I think this new crop > is terrific, with many suggestions that are more > professional-looking and sleeker than the old one: I will have a > hard time deciding which one to vote for. > > Without starting a war on the theory of voting systems, perhaps we > should use a system which allows for > a certain amount of secondary (etc.) preference to be expressed? > > Step 1: Crunch down the size of proposals by factoring out common themes (eg. all the >\= logos count as one) Step 2: Determine the winner by polling preferences, same-level preference (ambivalence) allowed (eg. place 1 for logos C and D, place 2 for A and place 3 for B) Step 3: Re-open contest, accepting submissions _using_ the winning logo, in the categories a) colour schemes[1] b), official shapes[2] c), font[3] to go to b), d) layouts of b) + c) Step 4: Repeat step 2 for every category of step 3 Step 5: Announce the new buzzword-compliant branding and hand over a t-shirt to the one who wrote code to apply colour schemes to logos for displaying step 3. Obviously, we need to know the winner of step 2 to completely define step 3. Did I miss anything? [1] coloured, monochrome and b/w [2] shape details[4] vs. (coloured and monochrome vs. b/w) [3] not forgetting its licence [4] like whether or not to completely connect that > and \ to a lambda -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From reiner.pope at gmail.com Fri Jan 2 18:47:48 2009 From: reiner.pope at gmail.com (Reiner Pope) Date: Fri Jan 2 18:39:36 2009 Subject: [Haskell-cafe] What are side effects in Haskell? In-Reply-To: References: <1230041789.3231.13.camel@dhcppc0> <1230393008.3045.33.camel@dhcppc0> Message-ID: <4cf038ee0901021547r6a671218l1ba8cbafae44dfb0@mail.gmail.com> 2009/1/3 Conal Elliott : > Are there other thoughts & insights about the source of the idea that > "everything is a function"? > Lazy evaluation can make values seem like functions, given that laziness can be modeled in a strict imperative language by 0-argument functions. Also, in an uncurried language, decreasing the number of arguments to a function, still keeps it a function, eg foo(int a, int b); // 2 arguments foo(int a); // 1 argument foo(); // 0 arguments, but still a function In a strict language, there is a distinction between 0-argument functions and values; there isn't in Haskell, but it is still nice to maintain the idea of "0-argument functions" in Haskell -- which are just values. Cheers, Reiner From jamiiecb at googlemail.com Fri Jan 2 19:01:06 2009 From: jamiiecb at googlemail.com (Jamie Brandon) Date: Fri Jan 2 18:52:53 2009 Subject: [Haskell-cafe] #haskell IRC channel reaches 600 users In-Reply-To: <20090102202724.GA3953@scytale.galois.com> References: <20090102202724.GA3953@scytale.galois.com> Message-ID: <10ed1a750901021601k161ac032w1c4c3b91f7b43b8a@mail.gmail.com> The haskell community has a well deserved reputation for being one of the friendliest online communities. Perhaps this would be a good point to figure out what we're doing right? I'm convinced that part of it is that offtopic conversation is encouraged through on haskell-cafe, planet haskell and irc. It makes people seem more human and hence harder to flame. Jamie On Fri, Jan 2, 2009 at 8:27 PM, Don Stewart wrote: > > A small announcement :) > > 7 years after its inception, under the guiding hand of Shae Erisson (aka > shapr), the #haskell IRC channel[1] on freenode has reached 600 > concurrent users! It's now in the top 3 language channels by size. > > To chart the growth, we can note that the channel was founded in late > 2001, and had slow growth till 2006, reaching 200 users in January of > that year. Since then growth in the user base has been far more rapid, > reaching 300 users in Dec 2006, 400 users in August 2007, 500 users > by July 2008, and 600 on January 2, 2009. > > This puts the channel at the 7th largest community of the 7000 freenode > channels, and in the top 3 language communities. For comparision, a > sample of the state of the other language communities, with comments > comapred to their status a year ago: > > #php 612 > #python 604 > > > #haskell 602 -- up 4 > > ##c++ 558 > ##c 506 -- down 1 > #perl 502 -- down 3 > #ruby-lang 288 -- down > #lisp 264 > ##javascript 241 > #erlang 146 -- unchanged > #perl6 129 -- unchanged > #scheme 123 -- down > #lua 102 -- unchanged > #clojure 78 > #ocaml 70 -- unchanged > > You can see the growth of the channel over here: > > http://haskell.org/haskellwiki/IRC_channel > > If you've not dropped by the channel yet, feel free to come and chat, > and toss around some lambdas! :) > > Cheers, > Don > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From h8spawn at googlemail.com Fri Jan 2 19:39:18 2009 From: h8spawn at googlemail.com (=?UTF-8?Q?S._G=C3=BCnther?=) Date: Fri Jan 2 19:31:08 2009 Subject: [Haskell-cafe] Re: Updating doubly linked lists In-Reply-To: References: <495B6E91.8050809@van.steenbergen.nl> <2f9b2d30812311311k51d2a5adq48697976cb48af75@mail.gmail.com> Message-ID: There goes my promise like a new years resolution... ;) > What kind of structure do you need exactly? What I really need is a structure which represents a two dimensional grid, i.e. it consists of nodes having a value and a list of neighbours attached to it. Point is that if node 1 has node 2 as a neighbour then node 2 has to have node 1 as a neighbour and each node has the same number of neighbours (currently 4, but may vary). So it really is just an undirected planar graph with some restrictions. And it isn't even circular because nodes may have Leaves as neighbours signalling that they are boundary nodes. And since the algorithm I would like to implement is specified in a purely imperative way I need to be able to update the values stored at the nodes and insert new nodes at where there a Leaves. So I figured since the structure isn't even circular I could do it the inefficient way and just use a generalization of the update function for doubly linked lists I came up with before and thus always rebuild the whole structure. That's why I said that thinking about the circular case was just a divergence that rally got me wondering/interested which is why I posted the question in it's short form at the beginning. Anyways, back to the structure I need. One additional thing which will happen during the algorithm is that there will be updates to a certain local neighbourhood of a node. Now I understand, that that might very well be possible with zippers. Instead of lists of neighbouring nodes I might as well save the paths through the graphs separately from the nodes although I only have a very vague intuition about how that would look like. And instead of calculating a lists of nodes to update, I could calculate a path visting the nodes and update them (again beeing unable to escape from the prison of an imperative mindset) traversing the path. >> The things I read about them >> always assumed either a list like (i.e. linear) or a tree like (i.e. existence >> of a root) structure on the type to be plugged into the zipper. > > Viewing the zipper as the derivative of a data type opens up more > possibilities. > > That being said, every algebraic data types has a tree-like structure. > The extra invariants like > > left . right = right . left > > that the programmer imposes are what make them different from trees. That's right. After I wrote I that I realized that the distinction I made was a little bit of nonsense since a linear structure is a degenerated case of a tree like structure. But the point was that I just had a hard time generalizing what I read about zippers to structures where you can have embedded cycles, e.g. up . left . down . right = id. >> So I just have to decide whether to use IORefs/Vars (clunky) >> or to implement zippers for the structure I need (probably too hard for me). > > It's not too hard for you. You've got a whole haskell-cafe and #haskell > at your fingertips, after all. ;) Righty right, but there's still the possibility that given all the time in the world and the clearest explanations I'm just to dense to get a hold of it. That said I hope that's note the case but I might still be better off timewise to just go with MVars and a straightforward way first and then doing the reading and maybe refactoring to a different approach. cheers Stephan From schlepptop at henning-thielemann.de Fri Jan 2 20:03:35 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Fri Jan 2 19:49:36 2009 Subject: [Haskell-cafe] Use of abbreviations in Haskell In-Reply-To: References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> Message-ID: <495EB967.9020606@henning-thielemann.de> Miguel Mitrofanov schrieb: > module Element where > import QName > import ... > data Element = Element {name :: QName, attribs :: [Attr], content :: > [Content], line :: Maybe Line} > > module Attr where > import QName > import ... > data Attr = Attr {key :: QName, val :: String} > > module QName where > import ... > data QName = QName {name :: String, uri :: Maybe String, prefix :: Maybe > String} > > module Main where > import qualified QName as Q > import qualified Element as E > ... Q.name ... E.name ... +1 for this style http://www.haskell.org/haskellwiki/Qualified_names From schlepptop at henning-thielemann.de Fri Jan 2 20:25:36 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Fri Jan 2 20:11:32 2009 Subject: [Haskell-cafe] How do we decide on the new logo? In-Reply-To: <9D116A8F-94A2-42CF-891F-E98C25082B0A@willamette.edu> References: <9D116A8F-94A2-42CF-891F-E98C25082B0A@willamette.edu> Message-ID: <495EBE90.7010401@henning-thielemann.de> Fritz Ruehr schrieb: > Without starting a war on the theory of voting systems, perhaps we > should use a system which allows for > a certain amount of secondary (etc.) preference to be expressed? Give everyone 10 points and let every voter assign these points to his favorite logos, where it is possible to give more than one of his points to the same logo. (Or give every user one point and let him choose how to divide this into fractions which can be assigned to logos. Or give every voter any number of points he want and scale them to 1 afterwards.) Another question is how to handle logos with variations. I think all logos of one idea should be grouped and considered one object and the favorite variant can be voted on later. From benjovi at gmx.net Fri Jan 2 20:21:07 2009 From: benjovi at gmx.net (Benedikt Huber) Date: Fri Jan 2 20:12:58 2009 Subject: [Haskell-cafe] Re: Parsec : Problems with operator precedence (solution) In-Reply-To: <20081230040736.120be874.mle+cl@mega-nerd.com> References: <20081229202753.1246b9bb.mle+cl@mega-nerd.com> <20081230040736.120be874.mle+cl@mega-nerd.com> Message-ID: <495EBD83.4010504@gmx.net> Erik de Castro Lopo schrieb: > Erik de Castro Lopo wrote: > >> binaryOp :: String -> (SourcePos -> a -> a -> a) -> E.Assoc -> E.Operator Char st a >> binaryOp name con assoc = >> E.Infix (reservedOp name >> >> getPosition >>= >> return . con) assoc > > Replacing reservedOp above with: > > reservedOpNf :: String -> CharParser st () > reservedOpNf name = try (reservedOp name >> notFollowedBy (oneOf "|&=")) > > fixed the problem. > Hi Erik, There is an easy, better solution, modifying the lexer: > lexer = makeTokenParser $ emptyDef > { L.reservedOpNames = words "&& || & | ^" } > reservedOp = P.reservedOp lexer > identifier = P.identifier lexer > ... I'd try to avoid 'try', if possible. benedikt From schlepptop at henning-thielemann.de Fri Jan 2 20:33:52 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Fri Jan 2 20:19:48 2009 Subject: [Haskell-cafe] Re: How do we decide on the new logo? In-Reply-To: <20090103001626.07a77918@solaris> References: <9D116A8F-94A2-42CF-891F-E98C25082B0A@willamette.edu> <20090103001626.07a77918@solaris> Message-ID: <495EC080.704@henning-thielemann.de> Achim Schneider schrieb: > Step 2: Determine the winner by polling preferences, same-level > preference (ambivalence) allowed > (eg. place 1 for logos C and D, place 2 for A and place 3 for B) We recently had to vote for the new design of our university's website. This was done by asking every voter for an order of preference, with no equal preferences allowed. However, when the maintainer of the voting system was asked, how these answers are processed, he didn't know an answer. I think he finally converted positions to scores and added them. However, I suspect in chosing the scores for each position, he had an essential influence of the outcome of the election. From byorgey at seas.upenn.edu Fri Jan 2 22:06:45 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Fri Jan 2 21:58:32 2009 Subject: [Haskell-cafe] #haskell IRC channel reaches 600 users In-Reply-To: <10ed1a750901021601k161ac032w1c4c3b91f7b43b8a@mail.gmail.com> References: <20090102202724.GA3953@scytale.galois.com> <10ed1a750901021601k161ac032w1c4c3b91f7b43b8a@mail.gmail.com> Message-ID: <20090103030645.GA12866@seas.upenn.edu> On Sat, Jan 03, 2009 at 12:01:06AM +0000, Jamie Brandon wrote: > The haskell community has a well deserved reputation for being one of > the friendliest online communities. Perhaps this would be a good point > to figure out what we're doing right? I'm convinced that part of it is > that offtopic conversation is encouraged through on haskell-cafe, > planet haskell and irc. It makes people seem more human and hence > harder to flame. > > Jamie I have no hard data to back this up, but I suspect that another large part of the answer is simply the fact that culture tends to be self-reinforcing. So, as I understand it, we mostly have Shae to thank for very intentionally creating a friendly culture in the first place. Many online communities simply arise without anyone giving much thought to the sort of culture they want to create; empirically, emergent online culture is not so friendly. -Brent From mle+cl at mega-nerd.com Fri Jan 2 22:14:40 2009 From: mle+cl at mega-nerd.com (Erik de Castro Lopo) Date: Fri Jan 2 22:06:29 2009 Subject: [Haskell-cafe] Re: Parsec : Problems with operator precedence (solution) In-Reply-To: <495EBD83.4010504@gmx.net> References: <20081229202753.1246b9bb.mle+cl@mega-nerd.com> <20081230040736.120be874.mle+cl@mega-nerd.com> <495EBD83.4010504@gmx.net> Message-ID: <20090103141440.0ed3e1b6.mle+cl@mega-nerd.com> Benedikt Huber wrote: > There is an easy, better solution, modifying the lexer: > > > lexer = makeTokenParser $ emptyDef > > { L.reservedOpNames = words "&& || & | ^" } > > reservedOp = P.reservedOp lexer > > identifier = P.identifier lexer > > ... > > I'd try to avoid 'try', if possible. Hi Benedikt, I did try that (reservedOpNames as a list of operators as strings) but that interferred rather badly with another part of the parser which handles raw inline XML like this (yes, utterly horrid): var xdata = sucks ; Because I had the XML parsing working when I hit the operator precedence problem I worked towards a solution that didn't break the XML rather than do the right thing to fix the operator precedence and then have to fix the XML part. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "how am I expected to quit smoking if I have to deal with NT every day" -- Ben Raia From roconnor at theorem.ca Fri Jan 2 22:15:10 2009 From: roconnor at theorem.ca (roconnor@theorem.ca) Date: Fri Jan 2 22:06:57 2009 Subject: [Haskell-cafe] Re: How do we decide on the new logo? In-Reply-To: <20090103001626.07a77918@solaris> References: <9D116A8F-94A2-42CF-891F-E98C25082B0A@willamette.edu> <20090103001626.07a77918@solaris> Message-ID: On Sat, 3 Jan 2009, Achim Schneider wrote: > Step 2: Determine the winner by polling preferences, same-level > preference (ambivalence) allowed > (eg. place 1 for logos C and D, place 2 for A and place 3 for B) The only reasonable method of voting using this ranking data is one of the Condorcet methods. How you break ties doesnt matter much to me. Wikimedia, Debian, Gentoo, and Software in the Public Intrest all use Schulze method for what that is worth. However, I'm more concerned about who gets to vote and how many times do they get to vote. -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From wren at freegeek.org Fri Jan 2 23:20:19 2009 From: wren at freegeek.org (wren ng thornton) Date: Fri Jan 2 23:12:07 2009 Subject: [Haskell-cafe] Don't make 'show*' functions In-Reply-To: <495AB4BB.3040705@henning-thielemann.de> References: <20081226222329.26DA3276CDF@mail.avvanta.com> <4c44d90b0812261528m6ddc5ct9cf795d603bc8316@mail.gmail.com> <4959A68E.9090004@freegeek.org> <495AB4BB.3040705@henning-thielemann.de> Message-ID: <495EE783.5050109@freegeek.org> Henning Thielemann wrote: > I think, that a user who uses GHCi becomes a developer. For me a user is > someone who calls compiled Haskell programs. GHCi makes for a great calculator. I agree that, to a first approximation, "users" call compiled binaries and "developers" use GHCi. But there's a big gap between those two which is not devoid of life. I think there are many more people who use GHCi as an interactive shell session than most folks give credit for. More particularly, I posit that the prevalence of these people is part of what muddies the questions of who the audience of Show should be. Even if we chose to lump them in with "developers" there's still the very real problem of resolution. Many people develop by bricolage, which means that over time they transition from being "interactive users" or "casual developers" or "scripters" into being "'real' developers". Just as often 'real' developers transition into interaction when they want to do active debugging. We should be able to visualize data differently at each of these different stages, but it is just as important ---if not moreso--- to be able to transition between different resolutions easily. So far, the Show class is very much a one-size-fits-all solution which doesn't fit anyone very well. IMO, trying to refine or redefine the intended semantics of Show is wrongheaded, because the space between "users" and "developers" is far closer to being continuous than discrete. A single type-class that looks like Show cannot possibly resolve this mismatch, no matter what the intended semantics are. The continuous space between "users" and "developers" requires some solution which takes the variability of audiences/resolutions into consideration. Trying to shove everyone into the same bucket has been not working for some time already. We should acknowledge the real problem behind that. -- Live well, ~wren From barsoap at web.de Sat Jan 3 00:28:29 2009 From: barsoap at web.de (Achim Schneider) Date: Sat Jan 3 00:20:33 2009 Subject: [Haskell-cafe] Re: What are side effects in Haskell? References: <1230041789.3231.13.camel@dhcppc0> <1230393008.3045.33.camel@dhcppc0> <4cf038ee0901021547r6a671218l1ba8cbafae44dfb0@mail.gmail.com> Message-ID: <20090103062829.0e06d7c6@solaris> "Reiner Pope" wrote: > 2009/1/3 Conal Elliott : > > Are there other thoughts & insights about the source of the idea > > that "everything is a function"? > > > > Lazy evaluation can make values seem like functions, given that > laziness can be modeled in a strict imperative language by 0-argument > functions. > > Also, in an uncurried language, decreasing the number of arguments to > a function, still keeps it a function, eg > foo(int a, int b); // 2 arguments > foo(int a); // 1 argument > foo(); // 0 arguments, but still a function > In a strict language, there is a distinction between 0-argument > functions and values; there isn't in Haskell, but it is still nice to > maintain the idea of "0-argument functions" in Haskell -- which are > just values. > You can factor a cool intuitive understanding about IO actions not being the action itself, but just tokens that represent an action, out of this, by adding just one sentence. I guess the proper way to offset functions and values depends on what you want to explain, and multiple views on the same thing can't hurt. Conal, you aren't interrogating the list to figure out how to write a Haskell version of the wizard book, are you? We'd have to stop the pizza deliveries if you stop working on reactive... ;) -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From barsoap at web.de Sat Jan 3 00:46:05 2009 From: barsoap at web.de (Achim Schneider) Date: Sat Jan 3 00:38:31 2009 Subject: [Haskell-cafe] Re: Use of abbreviations in Haskell References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> <1230928866.31199.68.camel@derek-laptop> Message-ID: <20090103064605.37a7bed5@solaris> Derek Elkins wrote: > module Attribute where > data Attribute = Attribute { > key :: QualifiedName, > value :: String > } +1 Assuming that the above definition is inside a file called Foo/Bar.hs and, syntactically, inside a "module Foo where", I think a sane way to search for the module Foo.Bar.Attribute is a) Foo.Bar.Attribute.hs b) Foo/Bar.Attribute.hs c) Foo/Bar/Attribute.hs d) Foo.Bar.hs:Attribute e) Foo/Bar.hs:Attribute ...I guess you see a pattern emerging. It's not entirely unlike public inner java classes[1] The reason that the Main module is an exception to the naming/placement rules is that it's _always_ the root of the search tree, which is only confusing if you insist on being confused by it[2]. Furthermore, if you import Foo.Bar , you get Attribute.(..) imported by default, _except_ if you also do import [qualified] Foo.Bar.Attribute [as A] This fixes both the insanity of having thousands of three-line modules in thousands of files (which noone wants to manage) and source directories consisting of more directories than files. [1]uhmm... can inner classes be public? I think I never tried... [2]like javac chooses to be. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From barsoap at web.de Sat Jan 3 01:00:23 2009 From: barsoap at web.de (Achim Schneider) Date: Sat Jan 3 00:52:18 2009 Subject: [Haskell-cafe] Re: How do we decide on the new logo? References: <9D116A8F-94A2-42CF-891F-E98C25082B0A@willamette.edu> <20090103001626.07a77918@solaris> <495EC080.704@henning-thielemann.de> Message-ID: <20090103070023.6dd2afac@solaris> Henning Thielemann wrote: > Achim Schneider schrieb: > > > Step 2: Determine the winner by polling preferences, same-level > > preference (ambivalence) allowed > > (eg. place 1 for logos C and D, place 2 for A and place 3 for B) > > We recently had to vote for the new design of our university's > website. This was done by asking every voter for an order of > preference, with no equal preferences allowed. However, when the > maintainer of the voting system was asked, how these answers are > processed, he didn't know an answer. I think he finally converted > positions to scores and added them. However, I suspect in chosing the > scores for each position, he had an essential influence of the > outcome of the election. > I intended to sum up all scaled preferences for every logo, and take the smallest one as the winner. "Scaled" meaning that every voter, in the end, had the same total points to distribute... like in your system. I like mine because it shifts the calculation burden from the voter to the program doing the processing. A vote of all 10's would be equivalent to a vote of all ones, and a vote of just one one would be equivalent to a vote of one one and the rest two's. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From es at ertes.de Sat Jan 3 01:15:18 2009 From: es at ertes.de (Ertugrul Soeylemez) Date: Sat Jan 3 01:07:18 2009 Subject: [Haskell-cafe] Re: What are side effects in Haskell? References: <1230041789.3231.13.camel@dhcppc0> Message-ID: <20090103071518.04f6be25@tritium.xx> Adrian Neumann wrote: > Am 23.12.2008 um 15:16 schrieb Hans van Thiel: > > > I just saw somewhere that one of the purposes of monads is to > > capture side effects. I understand what a side effect is in C, for > > example. Say you want to switch the contents of two variables. Then > > you need a third temporary variable to store an intermediate > > result. If this is global, then it will be changed by the operation. > > [...] > > However when you *do* want state you can simulate it with a monad. > The IO Monad is a special case here, since its actions don't change > your program, they change the "world" the program is running in > (writing files etc.). getLine etc are functions when you think of them > as taking a hidden parameter, the state of the world. So getChar would > become > > getChar :: World -> (Char,World) > > but the world stays hidden inside the IO Monad. Yes, I like this view, but you shouldn't say that the world is hidden inside the IO monad, because you can easily use part of that state in computations. In my view, the IO monad is some notion of this: type IO = State World The main difference between this and the real IO is that there is no value for the (entire) world's state you could refer to, which eliminates the need for 'get', 'put', and by introducing a 'main' computation, also 'runState' becomes unnecessary. In fact, this makes the whole 'World' type unnecessary. So IO is really just a theoretical construct to make input/output consistent with referential transparency. This is a very short version of what I have written in section 7 [1] of my monads tutorial. [1] http://ertes.de/articles/monads.html#section-7 Greets, Ertugrul. -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/ From gour at mail.inet.hr Sat Jan 3 04:48:44 2009 From: gour at mail.inet.hr (Gour) Date: Sat Jan 3 04:40:29 2009 Subject: [Haskell-cafe] databases in Haskell & type-safety Message-ID: <87eizkra83.fsf@nitai.hr> Hi! I'd like to use sqlite3 as application storage in my haskell project... Browsing the available database options in Haskell it seems that: a) HSQL is dead (hackage reports build-failure with 6.8 & 6.10) b) haskelldb is also not in a good shape - build fails with 6.8 & 6.10 For Haskell-newbie as myself, it looks that haskelldb is the one which provide(ed)s the most secure API (I was reading draft paper about MetaHDBC but, apparently, the type inference support in open-source databases is poor and that's why, according to the author "This is unfortunately as it makes MetaHDBC a lot less valuable." What remains is: c) Takusen which is also not up-to-date (it fails with 6.10) and d) HDBC and sqlite bindings which are the only packages which build with 6.10. However options in d) do not offer, afaik, type-safety which is emblem of Haskell language, so I wonder how much this could be the problem for real-world usage? So, considering that HDBC nicely abstracts API enabling one to easily switch from e.g. Sqlite3 to Postgres, and it is used as in example for database programming, it seems as logical (and the only) choice for Haskell database programming in a real-world? I'm not familiar with Takusen which says: "Takusen's unique selling point is safety and efficiency..." and I would appreciate if someone could shed some more light to its 'safety' and the present status? Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090103/76af5221/attachment.bin From oleg at okmij.org Sat Jan 3 04:51:15 2009 From: oleg at okmij.org (oleg@okmij.org) Date: Sat Jan 3 04:44:03 2009 Subject: [Haskell-cafe] Re: Updating doubly linked lists Message-ID: <20090103095115.7B645AB11@Adric.metnet.fnmoc.navy.mil> Stephan Guenther wrote: > Is it possible to change a particular node of the doubly linked list? > That is to say, that would like to have a function: > update :: DList a -> a -> DList a > where > update node newValue > returns a list where only the value at the node which is passed in is > set to the new Value and all other values are the same. All this of > course in a pure way, that is without using (M/T/TM)Vars or IORefs. It is possible to do all of this, and more: - no rebuilding of the whole list on updates to the list - the update operation takes constant time (for lists longer than 32 elements on 32-bit platform) - both cyclic and terminated lists can be handled, uniformly - no monads used or mentioned - let alone no IORef, STRef, TVars, etc. The algorithm is essentially imperative (and so permits identity checking and in-place `updates') but implemented purely functionally. No destructive updates are ever used. Therefore, all the changes can be undone and re-done, and the code is MT-safe. The code is easily generalizable to 2D. Here are the tests > testl = fromList [1..5] > testl_s = takeDL 11 testl *FL> testl_s [5,1,2,3,4,5,1,2,3,4,5] > testl1 = update (-1) testl > testl1_s = takeDL 11 testl1 *FL> testl1_s [-1,1,2,3,4,-1,1,2,3,4,-1] > testl2 = update (-2) . move_right' . move_right' $ testl1 > testl2_s = takeDL 11 testl2 *FL> testl2_s [-2,3,4,-1,1,-2,3,4,-1,1,-2] > -- Old testl is still available > testl3 = update (-2) . move_right' . move_right' $ testl > testl3_s = takeDL 11 testl3 *FL> testl3_s [-2,3,4,5,1,-2,3,4,5,1,-2] It is not for nothing Haskell is called the best imperative language. One can implement imperative algorithms just as they are -- purely functionally, without any monads or other categorical notions. module FL where import qualified Data.IntMap as IM -- Representation of the double-linked list type Ref = Int -- positive, we shall treat 0 specially data Node a = Node{node_val :: a, node_left :: Ref, node_right :: Ref} data DList a = DList{dl_counter :: Ref, -- to generate new Refs dl_current :: Ref, -- current node dl_mem :: IM.IntMap (Node a)} -- main `memory' -- Operations on the DList a empty :: DList a empty = DList{dl_counter = 1, dl_current = 0, dl_mem = IM.empty} -- In a well-formed list, dl_current must point to a valid node -- All operations below preserve well-formedness well_formed :: DList a -> Bool well_formed dl | IM.null (dl_mem dl) = dl_current dl == 0 well_formed dl = IM.member (dl_current dl) (dl_mem dl) is_empty :: DList a -> Bool is_empty dl = IM.null (dl_mem dl) -- auxiliary function get_curr_node :: DList a -> Node a get_curr_node DList{dl_current=curr,dl_mem=mem} = maybe (error "not well-formed") id $ IM.lookup curr mem -- The insert operation below makes a cyclic list -- The other operations don't care -- Insert to the right of the current element, if any -- Return the DL where the inserted node is the current one insert_right :: a -> DList a -> DList a insert_right x dl | is_empty dl = let ref = dl_counter dl -- the following makes the list cyclic node = Node{node_val = x, node_left = ref, node_right = ref} in DList{dl_counter = succ ref, dl_current = ref, dl_mem = IM.insert ref node (dl_mem dl)} insert_right x dl@DList{dl_counter = ref, dl_current = curr, dl_mem = mem} = DList{dl_counter = succ ref, dl_current = ref, dl_mem = IM.insert ref new_node $ IM.insert curr curr_node' mem} where curr_node = get_curr_node dl curr_node'= curr_node{node_right = ref} new_node = Node{node_val = x, node_left = curr, node_right = node_right curr_node} get_curr :: DList a -> a get_curr = node_val . get_curr_node move_right :: DList a -> Maybe (DList a) move_right dl = if next == 0 then Nothing else Just (dl{dl_current=next}) where next = node_right $ get_curr_node dl -- If no right, just stay inplace move_right' :: DList a -> DList a move_right' dl = maybe dl id $ move_right dl fromList :: [a] -> DList a fromList = foldl (flip insert_right) FL.empty takeDL :: Int -> DList a -> [a] takeDL 0 _ = [] takeDL n dl | is_empty dl = [] takeDL n dl = get_curr dl : (maybe [] (takeDL (pred n)) $ move_right dl) -- Update the current node update :: a -> DList a -> DList a update x dl@(DList{dl_current = curr, dl_mem = mem}) = dl{dl_mem = IM.insert curr (curr_node{node_val = x}) mem} where curr_node = get_curr_node dl testl = fromList [1..5] testl_s = takeDL 11 testl testl1 = update (-1) testl testl1_s = takeDL 11 testl1 testl2 = update (-2) . move_right' . move_right' $ testl1 testl2_s = takeDL 11 testl2 -- Old testl is still available testl3 = update (-2) . move_right' . move_right' $ testl testl3_s = takeDL 11 testl3 From mad.one at gmail.com Sat Jan 3 05:25:12 2009 From: mad.one at gmail.com (Austin Seipp) Date: Sat Jan 3 05:17:00 2009 Subject: [Haskell-cafe] databases in Haskell & type-safety In-Reply-To: <87eizkra83.fsf@nitai.hr> References: <87eizkra83.fsf@nitai.hr> Message-ID: <1230977845-sup-6664@existential.local> Excerpts from Gour's message of Sat Jan 03 03:48:44 -0600 2009: > Hi! > > I'd like to use sqlite3 as application storage in my haskell project... > > Browsing the available database options in Haskell it seems that: > > a) HSQL is dead (hackage reports build-failure with 6.8 & 6.10) > > b) haskelldb is also not in a good shape - build fails with 6.8 & 6.10 > > For Haskell-newbie as myself, it looks that haskelldb is the one which > provide(ed)s the most secure API (I was reading draft paper about > MetaHDBC but, apparently, the type inference support in open-source > databases is poor and that's why, according to the author "This is > unfortunately as it makes MetaHDBC a lot less valuable." > > What remains is: > > c) Takusen which is also not up-to-date (it fails with 6.10) and > > d) HDBC and sqlite bindings which are the only packages which build with > 6.10. Have you tried the simple sqlite3 bindings available? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sqlite > I'm not familiar with Takusen which says: "Takusen's unique selling > point is safety and efficiency..." and I would appreciate if someone > could shed some more light to its 'safety' and the present status? Takusen is based on the (unique) concept of a left-fold enumerator. Having a left-fold interface guarantees timely (nearly perfect, really) deallocation of resources while still having the benefits of a 'lazy' stream. This interface has (as shown by Oleg and others) proven to be very efficient in a number of cases as well as favorable for many. The idea is very novel, and truly worth exploring if you ask me. For more information about left-fold enumerators and takusen, see here: http://okmij.org/ftp/papers/LL3-collections-enumerators.txt http://okmij.org/ftp/Haskell/fold-stream.lhs http://okmij.org/ftp/Haskell/misc.html#takusen NB: I have *just* (about 5 minutes ago) sent in a patch for takusen to get it to build on GHC 6.10.1 to Oleg. Hopefully an updated version will appear on hackage in the next few days. Austin From lemming at henning-thielemann.de Sat Jan 3 05:31:09 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Jan 3 05:22:55 2009 Subject: [Haskell-cafe] unsafeInterleaveIO respecting order of actions In-Reply-To: <0F9EF08E-178E-4346-98E1-4BB7CE842F92@ece.cmu.edu> References: <2f9b2d30812311301y1068b499u77fa12ef0cd44647@mail.gmail.com> <495D3953.6080609@henning-thielemann.de> <0F9EF08E-178E-4346-98E1-4BB7CE842F92@ece.cmu.edu> Message-ID: On Thu, 1 Jan 2009, Brandon S. Allbery KF8NH wrote: > On 2009 Jan 1, at 16:44, Henning Thielemann wrote: >> If it is generally possible to use unsafeInterleaveIO such that it >> executes actions in the right order, wouldn't this allow the definition >> of a general lazy IO monad? > > I thought unsafeInterleaveIO and users of it (readFile, hGetContents) didn't > guarantee the order of actions relative to independent IO actions (that is, > those performed outside the unsafeInterleaveIO) and this was why it is > generally disrecommended. For example the recurring situation where people > try to readFile f >>= writeFile . someTransform and the writeFile fails with > a "file locked" exception. Sure, it's dangerous. But for what I want to do, this situation cannot occur. I can come up with a simple example which might be generalized. It simulates what hGetContents does. liftLazy2 :: (a -> b -> c) -> IO a -> IO b -> IO c liftLazy2 f x y = fmap (\ ~(xr, ~(yr,())) -> f xr yr) $ unsafeInterleaveIO $ liftM2 (,) x $ unsafeInterleaveIO $ liftM2 (,) y $ return () test0, test1 :: IO String test0 = liftLazy2 (const) getLine getLine test1 = liftLazy2 (flip const) getLine getLine test0 only requests the first line, test1 expects two lines as user input. However, with liftLazy2 we have only Applicative functionality, not Monad, and it is not composable. For example: fmap (\((x,y),z) -> z) $ liftLazy2A (,) (liftLazy2A (,) getLine getLine) getLine This requests only one line, but should three ones. The reason is that the first two getLines are defered even until the last one. Thus, it is not enough that liftLazy2 returns (IO c). Instead it must return (IO (c,(a,(b,())))) and these pair emulated lists must somehow be combined in order to preserve the order of execution. This looks somehow like a writer monad transformer. From apfelmus at quantentunnel.de Sat Jan 3 06:37:28 2009 From: apfelmus at quantentunnel.de (Apfelmus, Heinrich) Date: Sat Jan 3 06:29:08 2009 Subject: [Haskell-cafe] Re: Updating doubly linked lists In-Reply-To: References: <495B6E91.8050809@van.steenbergen.nl> <2f9b2d30812311311k51d2a5adq48697976cb48af75@mail.gmail.com> Message-ID: S. G?nther wrote: > >> What kind of structure do you need exactly? > > What I really need is a structure which represents a two dimensional > grid, i.e. it consists of nodes having a value and a list of > neighbours attached to it. Point is that if node 1 has node 2 as a > neighbour then node 2 has to have node 1 as a > neighbour and each node has the same number of neighbours (currently > 4, but may vary). Ah, so you have a rectangular (or later hexagonal?) 2D grid? I suggest representing it as Data.Map (Integer, Integer) a as explained below. > That's why I said that thinking about the circular case was just a > divergence that really got me wondering/interested which is why I posted > the question in it's short form at the beginning. Exploring a related easier problem is always a good way to get some intuition for tackling the harder one. :) > Anyways, back to the structure I need. One additional thing which will > happen during the algorithm is that there will be updates to a certain > local neighboruhood of a node. Now I understand, that that might very > well be possible with zippers. > > Instead of lists of neighbouring nodes I might as well save the paths > through the graphs separately from the nodes although I only have a very > vague intuition about how that would look like. And instead of calculating > a lists of nodes to update, I could calculate a path visting the > nodes and update them (again beeing unable to escape from the prison > of an imperative mindset) traversing the path. A zipper indeed allows you to move to neighbors and update them. > But the point was that I just had a hard time generalizing what I read > about zippers to structures where you can have embedded cycles, e.g. > > up . left . down . right = id. If you interpret zippers as the original data structure with a hole, this is not so difficult. For instance, consider a rectangular grid +--+--+--+--+--+--+--+ | | | | | | | | +--+--+--+--+--+--+--+ | | | | | | | | +--+--+--+--+--+--+--+ | | | | | | | | +--+--+--+--+--+--+--+ where you store some data at every node. Now, a zipper is just the old data structure but one node is marked as "hole" +--+--+--+--+--+--+--+ | | | | | | | | +--+--+--O--+--+--+--+ | | | | | | | | +--+--+--+--+--+--+--+ | | | | | | | | +--+--+--+--+--+--+--+ If you represent the grid as a rectangular table type Position = (Integer, Integer) type Grid a = Data.Map Position a a zipper is simply the grid with an extra marker type Zipper a = (Grid a, Position) left,right,up,down :: Zipper a -> Zipper a left (g,(x,y)) = (g,(x-1,y)) right (g,(x,y)) = (g,(x+1,y)) up (g,(x,y)) = (g,(x,y-1)) down (g,(x,y)) = (g,(x,y+1)) update :: a -> Zipper a -> Zipper a update a (g,(x,y)) = (insert (x,y) a g, (x,y)) Note that the left, right etc. are not "baked into" the data type but implemented as normal functions. In principle, the same could be done for lists type ZipperL a = ([a], Int) left, right :: ZipperL a -> ZipperL a left (xs,i) = (xs,i-1) right (xs,i) = (xs,i+1) update :: a -> ZipperL a -> ZipperL a update a (xs,i) = (take i xs ++ [a] ++ drop (i+1) xs, i) This is a valid implementation of a zipper for lists, but of course is very inefficient, update is O(n) . The key thing about the original list zipper with back and front list is that all operations are O(1). For the 2D grid zipper above, moving around is O(1) but update is O(log n). This is acceptable; also because I'm quite confident that a zipper for a 2D grid with everything O(1) does not exist. I can prove that for a special case and should probably write it down at some point. In other words, I suggest representing your grid as a Data.Map (Integer,Integer) a and accept the minor inconvenience of a O(log n) update. Choosing a different finite map implementation may give a better constant factor. For instance you can nest two Data.IntMap etc. > Righty right, but there's still the possibility that given all the > time in the world and the clearest explanations I'm just to dense to > get a hold of it. That said I hope that's not the case but I might > still be better off timewise to just go with MVars and a > straightforward way first and then doing the reading and > maybe refactoring to a different approach. My personal experience is that not going with the obvious but messy solution but searching for a more elegant one is always faster in the long run. :) Regards, H. Apfelmus From schlepptop at henning-thielemann.de Sat Jan 3 08:45:43 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Sat Jan 3 08:31:42 2009 Subject: [Haskell-cafe] databases in Haskell & type-safety In-Reply-To: <87eizkra83.fsf@nitai.hr> References: <87eizkra83.fsf@nitai.hr> Message-ID: <495F6C07.5050006@henning-thielemann.de> Gour schrieb: > Hi! > > I'd like to use sqlite3 as application storage in my haskell project... > > Browsing the available database options in Haskell it seems that: > > a) HSQL is dead (hackage reports build-failure with 6.8 & 6.10) No, it is maintained by frederik@ofb.net . I have also contributed Oracle/OCI code a half year ago. From gour at mail.inet.hr Sat Jan 3 09:06:23 2009 From: gour at mail.inet.hr (Gour) Date: Sat Jan 3 08:58:05 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety References: <87eizkra83.fsf@nitai.hr> <495F6C07.5050006@henning-thielemann.de> Message-ID: <871vvkqyao.fsf@nitai.hr> >>>>> "Henning" == writes: Henning> No, it is maintained by frederik@ofb.net . I have also Henning> contributed Oracle/OCI code a half year ago. Oops, I stand corrected...nice to hear. Still, it would be nice to present some info 'cause web site still shows 1.7 from Dec '05 as the latest release :-( Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090103/6fa9f5a8/attachment.bin From gour at mail.inet.hr Sat Jan 3 09:09:51 2009 From: gour at mail.inet.hr (Gour) Date: Sat Jan 3 09:01:46 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety References: <87eizkra83.fsf@nitai.hr> <1230977845-sup-6664@existential.local> Message-ID: <87wsdcpjkg.fsf@nitai.hr> >>>>> "Austin" == Austin Seipp writes: Austin> Have you tried the simple sqlite3 bindings available? Austin> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sqlite Not (yet), but those are the one I mentioned (besides HDBC) under d) ;) Austin> Takusen is based on the (unique) concept of a left-fold Austin> enumerator. Having a left-fold interface guarantees timely Austin> (nearly perfect, really) deallocation of resources while still Austin> having the benefits of a 'lazy' stream. This interface has (as Austin> shown by Oleg and others) proven to be very efficient in a Austin> number of cases as well as favorable for many. The idea is very Austin> novel, and truly worth exploring if you ask me. Thank you very much. I went through the docs for which you provided some references - I cannot claim I understood everything, but it sounds/looks quite interesting and worth exploring. Is there any simple tutorial about using Takusen available somewhere? Austin> NB: I have *just* (about 5 minutes ago) sent in a patch for Austin> takusen to get it to build on GHC 6.10.1 to Oleg. Hopefully an Austin> updated version will appear on hackage in the next few days. Great news! Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090103/9dcc8746/attachment.bin From niklas.broberg at gmail.com Sat Jan 3 09:43:46 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sat Jan 3 09:35:33 2009 Subject: [Haskell-cafe] Updating doubly linked lists In-Reply-To: References: Message-ID: > Is it possible to change a particular node of the > doubly linked list? That is to say, that would like > to have a function: > update :: DList a -> a -> DList a > where > update node newValue > returns a list where only the value at the node > which is passed in is set to the new Value and > all other values are the same. What you need is for the nodes to keep track of the length of the list. Here's a different solution from that oleg posted, to me it's slightly more intuitive, since the updates work directly on the dlists instead of via (elegant) proxy functions. ---------------------------------------------------------------------- module DList where data DList a = DNode Int (DList a) a (DList a) | Empty mkDList :: [a] -> DList a mkDList [] = Empty mkDList xs = let len = length xs this = DNode len farLeft (head xs) nearRight (nearRight,farLeft) = mkRestDList len (tail xs) this this in this mkRestDList :: Int -> [a] -> DList a -> DList a -> (DList a, DList a) mkRestDList _ [] _ farRight = (farRight, farRight) -- will only happen if the initial list is singleton mkRestDList len [x] nearLeft farRight = let this = DNode len nearLeft x farRight in (this, this) mkRestDList len (x:xs) nearLeft farRight = let this = DNode len nearLeft x nearRight (nearRight,farLeft) = mkRestDList len xs this farRight in (this,farLeft) takeD :: Int -> DList a -> [a] takeD 0 _ = [] takeD _ Empty = [] takeD n (DNode _ _ x r) = x : takeD (n-1) r leftD, rightD :: DList a -> DList a leftD Empty = Empty leftD (DNode _ l _ _) = l rightD Empty = Empty rightD (DNode _ _ _ r) = r updateD :: a -> DList a -> DList a updateD _ Empty = Empty updateD x (DNode len _ _ r) = let this = DNode len farLeft x nearRight (nearRight,farLeft) = updateRestD (len-1) r this this in this updateRestD :: Int -> DList a -> DList a -> DList a -> (DList a, DList a) updateRestD 0 _ _ farRight = (farRight, farRight) -- will only happen if the initial list is singleton updateRestD 1 (DNode len _ x _) nearLeft farRight = let this = DNode len nearLeft x farRight in (this, this) updateRestD n (DNode len _ x r) nearLeft farRight = let this = DNode len nearLeft x nearRight (nearRight,farLeft) = updateRestD (n-1) r this farRight in (this,farLeft) updateRestD _ Empty _ _ = undefined -- can't happen ----------------------------------------------------- *DList> let dl = mkDList [1..5] *DList> takeD 11 dl [1,2,3,4,5,1,2,3,4,5,1] *DList> let dl' = updateD (-1) dl *DList> takeD 11 dl' [-1,2,3,4,5,-1,2,3,4,5,-1] Cheers, /Niklas From lemming at henning-thielemann.de Sat Jan 3 09:58:10 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Jan 3 09:49:55 2009 Subject: [Haskell-cafe] unsafeInterleaveIO respecting order of actions In-Reply-To: References: <2f9b2d30812311301y1068b499u77fa12ef0cd44647@mail.gmail.com> <495D3953.6080609@henning-thielemann.de> <0F9EF08E-178E-4346-98E1-4BB7CE842F92@ece.cmu.edu> Message-ID: On Sat, 3 Jan 2009, Henning Thielemann wrote: > On Thu, 1 Jan 2009, Brandon S. Allbery KF8NH wrote: > >> On 2009 Jan 1, at 16:44, Henning Thielemann wrote: >>> If it is generally possible to use unsafeInterleaveIO such that it >>> executes actions in the right order, wouldn't this allow the definition >>> of a general lazy IO monad? >> >> I thought unsafeInterleaveIO and users of it (readFile, hGetContents) >> didn't guarantee the order of actions relative to independent IO actions >> (that is, those performed outside the unsafeInterleaveIO) and this was why >> it is generally disrecommended. For example the recurring situation where >> people try to readFile f >>= writeFile . someTransform and the writeFile >> fails with a "file locked" exception. > > Sure, it's dangerous. But for what I want to do, this situation cannot occur. > I can come up with a simple example which might be generalized. It simulates > what hGetContents does. > > liftLazy2 :: (a -> b -> c) -> IO a -> IO b -> IO c > liftLazy2 f x y = > fmap (\ ~(xr, ~(yr,())) -> f xr yr) $ > unsafeInterleaveIO $ liftM2 (,) x $ > unsafeInterleaveIO $ liftM2 (,) y $ > return () I think I now have general Applicative functionality: apply :: (a -> b, ()) -> (a,()) -> (b,()) apply (f,fs) a = let (a0,as) = case fs of () -> a in (f a0, as) lazyIO :: IO a -> IO (a,()) lazyIO = unsafeInterleaveIO . fmap (\x -> (x,())) liftLazy2 :: (a -> b -> c) -> IO a -> IO b -> IO c liftLazy2 f x y = liftM2 (\xr yr -> fst $ (f,()) `apply` xr `apply` yr) (lazyIO x) (lazyIO y) The () is used to enforce the order of evaluation. From r.kelsall at millstream.com Sat Jan 3 10:07:41 2009 From: r.kelsall at millstream.com (Richard Kelsall) Date: Sat Jan 3 09:59:27 2009 Subject: [Haskell-cafe] Re: How do we decide on the new logo? In-Reply-To: <20090103001626.07a77918@solaris> References: <9D116A8F-94A2-42CF-891F-E98C25082B0A@willamette.edu> <20090103001626.07a77918@solaris> Message-ID: <495F7F3D.4090209@millstream.com> Achim Schneider wrote: ... > Step 3: Re-open contest, accepting submissions _using_ the winning > logo, in the categories a) colour schemes[1] b), official shapes[2] c), > font[3] to go to b), d) layouts of b) + c) ... This is a good suggestion. I would like small adjustments to the logo to be possible before it's frozen. Some kind of Step 3 will result in a much better logo. For example, I really like the pyramid from above / square containing three triangles that Lenny222 submitted, but I wouldn't choose this precise colour scheme and form. I didn't have time to enter an alternative. When the field has been significantly reduced I think people will be willing to expend effort improving the remaining entries. Richard. From thomas.dubuisson at gmail.com Sat Jan 3 10:22:47 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Sat Jan 3 10:14:32 2009 Subject: [Haskell-cafe] Type Family Relations Message-ID: <4c44d90b0901030722s7c0aefc2qe74986321f2e0e32@mail.gmail.com> Cafe, I am wondering if there is a way to enforce compile time checking of an axiom relating two separate type families. Mandatory contrived example: > type family AddressOf h > type family HeaderOf a > > -- I'm looking for something to the effect of: > type axiom HeaderOf (AddressOf x) ~ x > > -- Valid: > type instance AddressOf IPv4Header = IPv4 > type instance HeaderOf IPv4 = IPv4Header > > -- Invalid > type instance AddressOf AppHeader = AppAddress > type instance HeaderOf AppAddress = [AppHeader] So this is a universally enforced type equivalence. The stipulation could be arbitrarily complex, checked at compile time, and must hold for all instances of either type family. Am I making this too hard? Is there already a solution I'm missing? Cheers, Tom From jan.h.xie at gmail.com Sat Jan 3 10:28:30 2009 From: jan.h.xie at gmail.com (Xie Hanjian) Date: Sat Jan 3 10:20:30 2009 Subject: [Haskell-cafe] How to check object's identity? Message-ID: <20090103152830.GA22587@aiur> Hi, I tried this in ghci: >Prelude> 1:2:[] == 1:2:[] True Does this mean (:) return the same object on same input, or (==) is not for identity checking? If the later is true, how can I check two object is the *same* object? Thanks Jan -- jan=callcc{|jan|jan};jan.call(jan) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090103/dafa0f6d/attachment.bin From redcom at fedoms.com Sat Jan 3 10:34:59 2009 From: redcom at fedoms.com (=?iso-8859-15?Q?G=FCnther_Schmidt?=) Date: Sat Jan 3 10:27:05 2009 Subject: [Haskell-cafe] Re: How to check object's identity? References: <20090103152830.GA22587@aiur> Message-ID: Hi Jan, in functional programming there is no such thing as "identity" as we understand the idea from OO. There is only such as thing as "equality" though. G?nther Am 03.01.2009, 16:28 Uhr, schrieb Xie Hanjian : > Hi, > > I tried this in ghci: >> Prelude> 1:2:[] == 1:2:[] > True > > Does this mean (:) return the same object on same input, or > (==) is not for identity checking? If the later is true, how > can I check two object is the *same* object? > > Thanks > Jan > -- Erstellt mit Operas revolution?rem E-Mail-Modul: http://www.opera.com/mail/ From jan.h.xie at gmail.com Sat Jan 3 10:51:12 2009 From: jan.h.xie at gmail.com (Xie Hanjian) Date: Sat Jan 3 10:43:11 2009 Subject: [Haskell-cafe] How to check object's identity? In-Reply-To: <1230997198-sup-5373@ausone.local> References: <20090103152830.GA22587@aiur> <1230997198-sup-5373@ausone.local> Message-ID: <20090103155112.GB22587@aiur> Thanks guys :-) * Nicolas Pouillard [2009-01-03 16:39:59 +0100]: > Excerpts from Xie Hanjian's message of Sat Jan 03 16:28:30 +0100 2009: > > Hi, > > > > I tried this in ghci: > > >Prelude> 1:2:[] == 1:2:[] > > True > > > > Does this mean (:) return the same object on same input, or > > (==) is not for identity checking? If the later is true, how > > can I check two object is the *same* object? > > Here (==) is the structural equality. There is generally no exposed function > to check for identity of values. This would expose too much of the memory > model and the compilation process to give a specification to such a function. > > -- > Nicolas Pouillard -- jan=callcc{|jan|jan};jan.call(jan) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090103/2ddf3db7/attachment.bin From sylvan at student.chalmers.se Sat Jan 3 11:33:30 2009 From: sylvan at student.chalmers.se (Sebastian Sylvan) Date: Sat Jan 3 11:25:17 2009 Subject: [Haskell-cafe] Re: How do we decide on the new logo? In-Reply-To: References: <9D116A8F-94A2-42CF-891F-E98C25082B0A@willamette.edu> <20090103001626.07a77918@solaris> Message-ID: <3d96ac180901030833s7ecea057y774f820022a7f6ab@mail.gmail.com> On Sat, Jan 3, 2009 at 3:15 AM, wrote: > On Sat, 3 Jan 2009, Achim Schneider wrote: > > Step 2: Determine the winner by polling preferences, same-level >> preference (ambivalence) allowed >> (eg. place 1 for logos C and D, place 2 for A and place 3 for B) >> > > The only reasonable method of voting using this ranking data is one of the > Condorcet methods. How you break ties doesnt matter much to me. Wikimedia, > Debian, Gentoo, and Software in the Public Intrest all use Schulze method > for what that is worth. > Yes. Condorcet voting picks the best compromise and is IMO the way to do this - we won't all agree on the best logo, but at least we can pick the least disliked one. It doesn't need to be super sophisticated, just a box next to each logo where you can enter a rank in any range you like (1 being most preferred, empty boxing being equivalent to +Inf), allowing multiple entries to share the same rank. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090103/8543c127/attachment-0001.htm From brianchina60221 at gmail.com Sat Jan 3 12:35:35 2009 From: brianchina60221 at gmail.com (brian) Date: Sat Jan 3 12:27:19 2009 Subject: [Haskell-cafe] databases in Haskell & type-safety In-Reply-To: <1230977845-sup-6664@existential.local> References: <87eizkra83.fsf@nitai.hr> <1230977845-sup-6664@existential.local> Message-ID: <22f6a8f70901030935x663af248xc1bdac22baef02dd@mail.gmail.com> On Sat, Jan 3, 2009 at 4:25 AM, Austin Seipp wrote: > NB: I have *just* (about 5 minutes ago) sent in a patch for takusen > to get it to build on GHC 6.10.1 to Oleg. Hopefully an updated version > will appear on hackage in the next few days. Yay! Thanks. I've been waiting. From mad.one at gmail.com Sat Jan 3 12:45:57 2009 From: mad.one at gmail.com (Austin Seipp) Date: Sat Jan 3 12:37:46 2009 Subject: [Haskell-cafe] Type Family Relations In-Reply-To: <4c44d90b0901030722s7c0aefc2qe74986321f2e0e32@mail.gmail.com> References: <4c44d90b0901030722s7c0aefc2qe74986321f2e0e32@mail.gmail.com> Message-ID: <1231004159-sup-7361@existential.local> Excerpts from Thomas M. DuBuisson's message of Sat Jan 03 09:22:47 -0600 2009: > Mandatory contrived example: > > > type family AddressOf h > > type family HeaderOf a > > > > -- I'm looking for something to the effect of: > > type axiom HeaderOf (AddressOf x) ~ x > > > > -- Valid: > > type instance AddressOf IPv4Header = IPv4 > > type instance HeaderOf IPv4 = IPv4Header > > > > -- Invalid > > type instance AddressOf AppHeader = AppAddress > > type instance HeaderOf AppAddress = [AppHeader] > > So this is a universally enforced type equivalence. The stipulation > could be arbitrarily complex, checked at compile time, and must hold > for all instances of either type family. > > Am I making this too hard? Is there already a solution I'm missing? > The problem is that type classes are open - anybody can extend this family i.e. > type instance AddressOf IPv4Header = IPv4 > type instance HeaderOf IPv4 = IPv4Header > type instance AddressOf IPv6Header = IPv4 > > ipv4func :: (AddressOf x ~ IPv4) => x -> ... And it will perfectly accept arguments with a type of IPv6Header. There is a proposal for extending GHC to support type invariants of this nature, but it is not implemented: http://tomschrijvers.blogspot.com/2008/11/type-invariants-for-haskell.html Austin From byorgey at seas.upenn.edu Sat Jan 3 13:20:48 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Jan 3 13:12:32 2009 Subject: [Haskell-cafe] Haskell Weekly News: Issue 99 - January 3, 2009 Message-ID: <20090103182048.GA9948@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20090103 Issue 99 - January 03, 2009 --------------------------------------------------------------------------- Welcome to issue 99 of HWN, a newsletter covering developments in the [1]Haskell community. Happy new year to all! May 2009 be a year full of joy, family, friends, professional success, much Haskell hacking, and a minimal number of rabid weasels. Just in case. Announcements #haskell IRC channel reaches 600 users. Don Stewart [2]announced that 7 years after its inception, under the guiding hand of Shae Erisson (aka shapr), the [3]#haskell IRC channel on freenode has reached 600 concurrent users! citeproc-hs-0.2. andrea rossato [4]announced the release of [5]citeproc-hs-0.2, a Haskell implementation of the Citation Style Language, which adds a Bibtex like citation and bibliographic formatting and generation facility to [6]pandoc. This version adds support for citation collapsing, a wrapper around [7]hs-bibutils, and some [8]API documentation. hs-bibutils-0.1. andrea rossato [9]announced the first release of [10]hs-bibutils, Haskell bindings to Chris Putnam's [11]bibutils. Bibutils is a library and a set of bibliographic utilities to interconvert between various bibliography database formats using a common MODS-format XML intermediate. Haskell koans. Gwern Branwen [12]issued an RFK (Request for [13]Koans), following the success of his CFH (Call for [14]Haiku). [ANN] Haskell web server + wiki: salvia-0.0.4 + orchid-0.0.6. Sebastiaan Visser [15]announced the release of three new packages: [16]salvia, a lightweight modular web server framework; [17]orchid, a(nother) wiki written in Haskell, using Darcs as a versioning back-end and Salvia as the application server; and [18]orchid-demo, a simple demo application using Salvia and Orchid to serve an example darcs repository. You can play around with an [19]online demo. gitit-0.4.1, recaptcha-0.1. John MacFarlane [20]announced the release of [21]gitit-0.4.1, a wiki program that stores pages in a git repository. This release adds support for (optional) captchas, using the reCAPTCHA service. The reCAPTCHA code has been packaged as a separate library on Hackage, [22]recaptcha. monte-carlo-0.2, gsl-random-0.2.3. Patrick Perry [23]announced the release of a new version of the [24]monte-carlo package. The new version includes a more general type class, MonadMC, which allows all the functions to work in both MC and MCT monads; functions to sample from discrete distributions, and functions to sample subsets. There is also a [25]quick tutorial. Reading group for Programming Collective Intelligence. Creighton Hogg [26]announced that he would like to start a small group for the O'Reilly book [27]Programming Collective Intelligence, to work through translating some of the examples to Haskell. Email Creighton if you are interested in participating. Maintaining laziness. Henning Thielemann [28]announced that he has written a [29]tutorial on how to make functions lazy and how to test whether they are actually lazy. Request for feedback: Understanding Haskell Monads. Ertugrul Soeylemez [30]requested feedback on a new [31]monad tutorial. Discussion How do we decide on the new logo?. Fritz Ruehr began a [32]discussion of how to go about choosing a winner of the [33]Great 2009 Haskell Logo Contest. Weigh in if you care! Jobs Two Positions as Associate Professor in Software Engineering at Chalmers University. Koen Claessen [34]announced the availability of [35]two positions as Associate Professor at Chalmers University in Gothenburg, Sweden, within the division of Software Engineering and Technology at the department of Computer Science and Engineering. The application deadline is January 12, 2009. Blog noise [36]Haskell news from the [37]blogosphere. * GHC / OpenSPARC Project: [38]Bootstrapping. * Dan Piponi (sigfpe): [39]Rewriting Monadic Expressions with Template Haskell. * GHC / OpenSPARC Project: [40]Fighting dependencies. * GHC / OpenSPARC Project: [41]A new year and a new project. * Alson Kemp: [42]2009: The Year Of Hackage. * Patrick Perry: [43]Monte Carlo Poker Odds. * Joachim Breitner: [44]Handling explicit and implicit recursion in Haskell data. * Luke Palmer: [45]Domain Convergence. * Eric Kow (kowey): [46]riot is almost a Haskell mail client. * John Goerzen (CosmicRay): [47]Real World Haskell update. * Alson Kemp: [48]A Plea For "cabal install". * Alson Kemp: [49]Cyptol on Slashdot. Quotes of the Week * lilac: how do I see the number of reductions required to calculate something? bohdan: the usual method is to ask Cale to reduce it by hand :) * conal: If it's purely functional, how do you *do* anything? You don't ;-) * ddarius: The opposite ends of CS meet in the Haskell world. * EvilTerran: forcedYet :: a -> Bool; forcedYet x = x `seq` True -- :P * bmh: I dream in folds. One day I'll dream in monads. * sclv: dreaming is a monad. About the Haskell Weekly News New editions are posted to [50]the Haskell mailing list as well as to [51]the Haskell Sequence and [52]Planet Haskell. [53]RSS is also available, and headlines appear on [54]haskell.org. To help create new editions of this newsletter, please see the information on [55]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [56]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://article.gmane.org/gmane.comp.lang.haskell.cafe/49824 3. http://haskell.org/haskellwiki/IRC_channel 4. http://article.gmane.org/gmane.comp.lang.haskell.general/16709 5. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/citeproc-hs 6. http://johnmacfarlane.net/pandoc/ 7. http://code.haskell.org/hs-bibutils/ 8. http://code.haskell.org/citeproc-hs/docs/ 9. http://article.gmane.org/gmane.comp.lang.haskell.general/16708 10. http://code.haskell.org/hs-bibutils/ 11. http://www.scripps.edu/~cdputnam/software/bibutils/ 12. http://article.gmane.org/gmane.comp.lang.haskell.cafe/49774 13. http://haskell.org/haskellwiki/Koans 14. http://haskell.org/haskellwiki/Haiku 15. http://article.gmane.org/gmane.comp.lang.haskell.cafe/49759 16. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/salvia 17. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/orchid 18. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/orchid-demo 19. http://funct.org/wiki/] 20. http://article.gmane.org/gmane.comp.lang.haskell.cafe/49747 21. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/gitit 22. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/recaptcha 23. http://article.gmane.org/gmane.comp.lang.haskell.cafe/49739 24. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/monte-carlo 25. http://quantile95.com/2008/12/31/monte-carlo-poker-odds/ 26. http://article.gmane.org/gmane.comp.lang.haskell.cafe/49716 27. http://tinyurl.com/7x4rga 28. http://article.gmane.org/gmane.comp.lang.haskell.cafe/49655 29. http://www.haskell.org/haskellwiki/Maintaining_laziness 30. http://article.gmane.org/gmane.comp.lang.haskell.cafe/49546 31. http://ertes.de/articles/monads.html 32. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/49833 33. http://haskell.org/haskellwiki/Haskell_logos/New_logo_ideas 34. http://article.gmane.org/gmane.comp.lang.haskell.general/16712 35. http://www.chalmers.se/cse/EN/news/vacancies/positions/two-positions-as 36. http://planet.haskell.org/ 37. http://haskell.org/haskellwiki/Blog_articles 38. http://ghcsparc.blogspot.com/2009/01/building.html 39. http://sigfpe.blogspot.com/2009/01/rewriting-monadic-expressions-with.html 40. http://ghcsparc.blogspot.com/2009/01/in-in-morning.html 41. http://ghcsparc.blogspot.com/2008/12/alright.html 42. http://www.alsonkemp.com/haskell/2009-the-year-of-hackage/ 43. http://quantile95.com/2008/12/31/monte-carlo-poker-odds/ 44. https://www.joachim-breitner.de/blog/archives/316-Handling-explicit-and-implicit-recusion-in-Haskell-data.html 45. http://lukepalmer.wordpress.com/2008/12/31/domain-convergence/ 46. http://koweycode.blogspot.com/2008/12/riot-is-almost-haskell-mail-client.html 47. http://changelog.complete.org/archives/861-real-world-haskell-update-2 48. http://www.alsonkemp.com/haskell/a-plea-for-cabal-install/ 49. http://www.alsonkemp.com/haskell/cyptol-on-slashdot/ 50. http://www.haskell.org/mailman/listinfo/haskell 51. http://sequence.complete.org/ 52. http://planet.haskell.org/ 53. http://sequence.complete.org/node/feed 54. http://haskell.org/ 55. http://haskell.org/haskellwiki/HWN 56. http://code.haskell.org/~byorgey/code/hwn/ From gwern0 at gmail.com Sat Jan 3 13:32:09 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Sat Jan 3 13:23:54 2009 Subject: [Haskell-cafe] [ANN] Haskell web server + wiki: salvia-0.0.4 + orchid-0.0.6 In-Reply-To: <6EE42792-F9CD-4028-AF4A-2880E5D322EE@cs.uu.nl> References: <6EE42792-F9CD-4028-AF4A-2880E5D322EE@cs.uu.nl> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, Jan 1, 2009 at 9:04 AM, Sebastiaan Visser wrote: > Happy new year, you all! > > I'm pleased to announce three new packages on Hackage: .... > I had some trouble getting all dependencies right on systems other than my > own. Using `cabal install' seems to behave differently from `./Setup > install' in the package directory, but this may vary from system to system. > It is known to work at least on Macosx and Linux with GHC 6.8, 6.10 or even > 6.11. Pdflatex is needed for PDF generation, dvipng for inline formulas. > > Have fun and best wishes for this new year! > > > [1] http://funct.org/wiki/ > [2] http://funct.org/wiki/data/Index.html > [3] http://www.cs.uu.nl/wiki/HUT/AttributeGrammarSystem Sebastiaan: are there any public repos for these packages? - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAklfryAACgkQvpDo5Pfl1oJuIACdHtzspXuAt3Bp4UXAubvT0UvD RtkAn1PlqWYbAxLRG4WOqAmZw6Dd6f/1 =wwLT -----END PGP SIGNATURE----- From ketil at malde.org Sat Jan 3 15:26:18 2009 From: ketil at malde.org (Ketil Malde) Date: Sat Jan 3 15:17:45 2009 Subject: [Haskell-cafe] Use of abbreviations in Haskell In-Reply-To: <495E801B.3090409@isaac.cedarswampstudios.org> (Isaac Dupree's message of "Fri\, 02 Jan 2009 15\:59\:07 -0500") References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> <1230928866.31199.68.camel@derek-laptop> <495E801B.3090409@isaac.cedarswampstudios.org> Message-ID: <87k59c2l1x.fsf@malde.org> Isaac Dupree writes: > Derek Elkins wrote: >> I haven't been able to find any semantic difficulties with this >> addition. > I like it too... what I run into is that there's an implicit > assumption that module of name Foo.Bar.Baz *must* be found in a file > Foo/Bar/Baz.[l]hs . Ah, surely mere practicalities will not stand in the way of improving the usability of the language? > GHC uses this all the time ..unless you want a compiler, I guess. How about this: A module may be defined in a file with a name corresponding to the module name, or any dot-separated prefix of it? I.e. the file Foo/Bar.hs will define module Foo.Bar and optionally Foo.Bar.Baz as well? GHC should then be able to find it, and I believe it already has a prioritized search mechanism (presumably, the file could be named Foo.Bar.hs, too). -k -- If I haven't seen further, it is by standing in the footprints of giants From eelco at lempsink.nl Sat Jan 3 15:27:58 2009 From: eelco at lempsink.nl (Eelco Lempsink) Date: Sat Jan 3 15:19:45 2009 Subject: [Haskell-cafe] Re: How do we decide on the new logo? In-Reply-To: <3d96ac180901030833s7ecea057y774f820022a7f6ab@mail.gmail.com> References: <9D116A8F-94A2-42CF-891F-E98C25082B0A@willamette.edu> <20090103001626.07a77918@solaris> <3d96ac180901030833s7ecea057y774f820022a7f6ab@mail.gmail.com> Message-ID: <8A639993-8309-48D1-B9C8-70F85F0E85A7@lempsink.nl> On 3 jan 2009, at 17:33, Sebastian Sylvan wrote: > On Sat, Jan 3, 2009 at 3:15 AM, wrote: >> On Sat, 3 Jan 2009, Achim Schneider wrote: >> >>> Step 2: Determine the winner by polling preferences, same-level >>> preference (ambivalence) allowed >>> (eg. place 1 for logos C and D, place 2 for A and place 3 for B) >> >> The only reasonable method of voting using this ranking data is one >> of the Condorcet methods. How you break ties doesnt matter much to >> me. Wikimedia, Debian, Gentoo, and Software in the Public Intrest >> all use Schulze method for what that is worth. > > Yes. Condorcet voting picks the best compromise and is IMO the way > to do this - we won't all agree on the best logo, but at least we > can pick the least disliked one. > It doesn't need to be super sophisticated, just a box next to each > logo where you can enter a rank in any range you like (1 being most > preferred, empty boxing being equivalent to +Inf), allowing multiple > entries to share the same rank. Since there already is a condorcet voting package on Hackage, I made a simple (HAppS powered) web app where you can drag-n-drop your preferences. See http://github.com/eelco/voting/tree/master for the code (contributions more than welcome! Note, there's also a jQuery branch which has a bit different drag-n-drop behaviour) and http://code.tupil.com/voting/ for a live demo. It needs a bit more work but mainly a whole bulk of decisions, like * Limit voting, if so how? Email confirmation, IP based, vote once, once per day? * Maybe don't show the results until the contest is over? I, for one, very much welcome any benevolent dictator to make these decisions, because we can probably argue about pros and cons for months. Since Don started the contest (http://www.haskell.org/pipermail/haskell-cafe/2008-December/051836.html ) and also seems to have some ideas about the voting process (http://www.haskell.org/pipermail/haskell-cafe/2008-December/052257.html ), I hereby officially appoint him to lead to masses. (Does it work like that? ;) -- Regards, Eelco Lempsink -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090103/437ceb88/PGP.bin From m.gubinelli at gmail.com Sat Jan 3 16:06:26 2009 From: m.gubinelli at gmail.com (Massimiliano Gubinelli) Date: Sat Jan 3 16:01:50 2009 Subject: [Haskell-cafe] Re: Pattern combinators References: <494DAB4A.5080509@mcmaster.ca> <49a77b7a0812202137j23ff10edw1853f5a24eb6aae9@mail.gmail.com> <49a77b7a0812221320r28b35e3ak179e7275c34e3bd1@mail.gmail.com> Message-ID: David Menendez zednenem.com> writes: > > On Sun, Dec 21, 2008 at 10:14 PM, Andrew Wagner > gmail.com> wrote: > > I'd love to see a copy of this go up on hackage for experimentation. >> Would > > you care to upload your code, or send it to me so I can upload it? > > I've uploaded my latest version to . It > explicitly makes patterns polymorphic over the answer type of the case > statement by making Pattern a newtype and universally quantifying the > (un)currying and matching functions. > > For example, > > (->>) :: Pattern a () vec -> Curry vec ans -> Case a ans > > I'm not sure it makes sense to create a package just yet. At the very > least, you should ask Morten Rhiger first. The type signatures are > mine, but the code is mostly straight transcriptions from his paper. > Hi, I've tried to undestand the paper, in particular the relation between the combinators written in cps style and combinators written using a Maybe type (i.e pattern matching functions returning Maybe to signal success or failure). The code below gives an implementation of the basic pattern matching functions on top of two possible implementation of an abstract interface for building and using bindings. In particular using type families it seems to be possible to automatically construct a function inj to convert between a function in the form a->b->c->d to a function in the form (a,(b,c,())) -> d, thereby removing the need of building such coverter via the pattern matching functions like suggested in the paper. Since I'm an Haskell begineer I would appreciate very much comments or suggestions for improvements. Best, Massimiliano Gubinelli Here the code: ----------------------------------- {-# LANGUAGE TypeFamilies, MultiParamTypeClasses, FlexibleInstances, RankNTypes #-} module PM where -- inj converts a function of the form a -> b -> c -> d to the -- uniform representation (a,(b,(c,()))) -> d class Fn a c where type Fnq a c inj :: Fnq a c -> a -> c instance Fn () c where type Fnq () c = c inj f () = f instance Fn b c => Fn (a,b) c where type Fnq (a,b) c = a -> Fnq b c inj f (a,b) = inj (f a) b -- pattern matching, cps style -- a binding function has three inputs: ks kf v. v is a list of -- current bindings. newtype PatA a b = PatA { unPatA :: forall ans. (b -> ans) -> ans -> a -> ans } applyA :: PatA a b -> (b -> c) -> c -> a -> c applyA (PatA p) ks kf v = p ks kf v meetA :: PatA a b -> PatA b c -> PatA a c meetA (PatA a) (PatA b) = PatA $ \ ks kf -> a (b ks kf) kf joinA :: PatA a b -> PatA a b -> PatA a b joinA (PatA a) (PatA b) = PatA $ \ ks kf v -> a ks (b ks kf v) v anyA :: PatA a a anyA = PatA $ \ ks kf -> ks noneA :: PatA a a noneA = PatA $ \ ks kf v -> kf varA :: x -> PatA a (x,a) varA x = PatA $ \ ks kf v -> ks (x,v) pairA a b (x,y) = meetA (a x) (b y) conA a x = if a == x then anyA else noneA andA a b x = meetA (a x) (b x) orA p n x = joinA (p x) (n x) matchA val pat = pat val () caseA a fa fb x v = applyA (a x) (inj fa) (fb x v) v otherwiseA kf = \x v -> kf isA p x = matchA x $ caseA p (\_ -> True) $ otherwiseA False testA1 z = matchA z $ caseA (conA (1,2)) ("first match") $ caseA (pairA (conA 1) varA) (\x -> "second match " ++ show x) $ caseA (pairA varA varA) (\x y -> "third match " ++ show x) $ otherwiseA "mismatch" -- pattern matching, Maybe style -- a binding function receives a list of current bindings and returns -- a Maybe type containing the list of updated bindings in case of -- success newtype PatB a b = PatB { unPatB :: a -> Maybe b } applyB :: PatB a b -> (b -> c) -> c -> a -> c applyB (PatB p) ks kf v = maybe kf ks (p v) meetB :: PatB a b -> PatB c a -> PatB c b meetB (PatB a) (PatB b) = PatB $ \v -> (b v) >>= a joinB :: PatB a b -> PatB a b -> PatB a b joinB (PatB a) (PatB b) = PatB $ \v -> maybe (b v) Just (a v) anyB :: PatB a a anyB = PatB $ \v -> Just v noneB :: PatB a a noneB = PatB $ \v -> Nothing varB :: x -> PatB a (x,a) varB x = PatB $ \v -> Just (x,v) pairB a b (x,y) = meetB (a x) (b y) conB a x = if a == x then anyB else noneB orB a b x = joinB (a x) (b x) andB a b x = meetB (a x) (b x) matchB val pat = pat val () --caseB a fa fb x v = maybe (fb x v) (inj fa) ((unPatB $ a x) v) caseB a fa fb x v = applyB (a x) (inj fa) (fb x v) v otherwiseB f = \x v -> f isB p x = matchB x $ caseB p (\_ -> True) $ otherwiseB False testB1 z = matchB z $ caseB (pairB (conB 1) (conB 2)) ("first match") $ caseB (pairB (conB 1) varB) (\x -> "second match " ++ show x) $ caseB (pairB varB varB) (\x y -> "third match " ++ show x) $ otherwiseB "mismatch" From hjgtuyl at chello.nl Sat Jan 3 16:46:29 2009 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sat Jan 3 16:38:10 2009 Subject: [Haskell-cafe] Re: [Haskell] #haskell IRC channel reaches 600 users In-Reply-To: <20090102202724.GA3953@scytale.galois.com> References: <20090102202724.GA3953@scytale.galois.com> Message-ID: On Fri, 02 Jan 2009 21:27:24 +0100, Don Stewart wrote: > > A small announcement :) > > 7 years after its inception, under the guiding hand of Shae Erisson (aka > shapr), the #haskell IRC channel[1] on freenode has reached 600 > concurrent users! It's now in the top 3 language channels by size. > Some more statistics can be found at http://www.langpop.com/ An interesting quote from this site: It's interesting to note how languages like Haskell and Erlang are talked about a lot, despite scoring fairly low on the normalized popularity chart above. People are interested in them, but haven't begun to use them on a large scale yet. We have to create more webpages about Haskell (containing the words "programming" and "Haskell") to score better! :) And there should be more Haskell jobs :) Other sites with statistics: http://www.tiobe.com/content/paperinfo/tpci/index.html http://www.complang.tuwien.ac.at/anton/comp.lang-statistics/ An article about what makes a language popular: http://www.paulgraham.com/popular.html -- Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- From ryani.spam at gmail.com Sat Jan 3 16:58:11 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Sat Jan 3 16:49:55 2009 Subject: [Haskell-cafe] Type Family Relations In-Reply-To: <4c44d90b0901030722s7c0aefc2qe74986321f2e0e32@mail.gmail.com> References: <4c44d90b0901030722s7c0aefc2qe74986321f2e0e32@mail.gmail.com> Message-ID: <2f9b2d30901031358o26724eb8r33c6f3973ce06e99@mail.gmail.com> I've been fighting this same problem for a while. The solution I've come up with is to encode the axioms into a typeclass which gives you a proof of the axioms. Here's an excerpt from some code I've been playing around with; HaskTy and Lift are type families. -- Theorem: for all t instance of Lift, (forall env. HaskTy (Lift t) env == t) data HaskTy_Lift_Id t env = (t ~ HaskTy (Lift t) env) => HaskTy_Lift_Id class Thm_HaskTy_Lift_Id t where thm_haskty_lift_id :: forall env. HaskTy_Lift_Id t env instance Thm_HaskTy_Lift_Id Int where thm_haskty_lift_id = HaskTy_Lift_Id instance Thm_HaskTy_Lift_Id Bool where thm_haskty_lift_id = HaskTy_Lift_Id lemma_haskty_lift_id_app :: HaskTy_Lift_Id a env -> HaskTy_Lift_Id b env -> HaskTy_Lift_Id (a -> b) env lemma_haskty_lift_id_app HaskTy_Lift_Id HaskTy_Lift_Id = HaskTy_Lift_Id instance (Thm_HaskTy_Lift_Id a, Thm_HaskTy_Lift_Id b) => Thm_HaskTy_Lift_Id (a -> b) where thm_haskty_lift_id = lemma_haskty_lift_id_app thm_haskty_lift_id thm_haskty_lift_id As you can see, I encode a witness of the type equality into a concrete data type. You then direct the typechecker as to how to prove the type equality using the typeclass mechanism; the class instances closely mirror the type family instances. You then add this typeclass as a context on functions that require the equality. Control.Coroutine[1] uses a similar restriction: class Connect s where connect :: (s ~ Dual c, c ~ Dual s) => InSession s a -> InSession c b -> (a,b) A cleaner solution, that sadly doesn't work in GHC6.10 [2], would be something like: class (s ~ Dual (Dual s)) => Connect s where connect :: InSession s a -> InSession (Dual s) b -> (a,b) The difference is mainly one of efficiency; even though there is only one constructor for Thm_HaskTy_Lift_Id t env, at runtime the code still has to prove that evaluation terminates (to avoid _|_ giving an unsound proof of type equality). This means that deeply nested instances of the (a -> b) instance require calling dictionary constructors to match the tree, until eventually we see that each leaf is a valid constructor. If the type equality could be brought into scope by just bringing the typeclass into scope, the dictionaries themselves could remain unevaluated at runtime. -- ryan [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Coroutine [2] http://hackage.haskell.org/trac/ghc/ticket/2102 On Sat, Jan 3, 2009 at 7:22 AM, Thomas DuBuisson wrote: > Cafe, > I am wondering if there is a way to enforce compile time checking of > an axiom relating two separate type families. > > Mandatory contrived example: > >> type family AddressOf h >> type family HeaderOf a >> >> -- I'm looking for something to the effect of: >> type axiom HeaderOf (AddressOf x) ~ x >> >> -- Valid: >> type instance AddressOf IPv4Header = IPv4 >> type instance HeaderOf IPv4 = IPv4Header >> >> -- Invalid >> type instance AddressOf AppHeader = AppAddress >> type instance HeaderOf AppAddress = [AppHeader] > > So this is a universally enforced type equivalence. The stipulation > could be arbitrarily complex, checked at compile time, and must hold > for all instances of either type family. > > Am I making this too hard? Is there already a solution I'm missing? > > Cheers, > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From iavor.diatchki at gmail.com Sat Jan 3 20:18:59 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sat Jan 3 20:10:43 2009 Subject: [Haskell-cafe] Type Family Relations In-Reply-To: <4c44d90b0901030722s7c0aefc2qe74986321f2e0e32@mail.gmail.com> References: <4c44d90b0901030722s7c0aefc2qe74986321f2e0e32@mail.gmail.com> Message-ID: <5ab17e790901031718q2c3f3030y8cb7d3b4e7bc01ba@mail.gmail.com> Hello, Usually, you can program such things by using super-classes. Here is how you could encode your example: {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances #-} class HeaderOf addr hdr | addr -> hdr class HeaderOf addr hdr => AddressOf hdr addr | addr -> hdr data IPv4Header = C1 data IPv4 = C2 data AppAddress = C3 data AppHeader = C4 instance AddressOf IPv4Header IPv4 instance HeaderOf IPv4 IPv4Header {- results in error: instance AddressOf AppHeader AppAddress instance HeaderOf AppAddress [AppHeader] -} Hope that this helps, Iavor On Sat, Jan 3, 2009 at 7:22 AM, Thomas DuBuisson wrote: > Cafe, > I am wondering if there is a way to enforce compile time checking of > an axiom relating two separate type families. > > Mandatory contrived example: > >> type family AddressOf h >> type family HeaderOf a >> >> -- I'm looking for something to the effect of: >> type axiom HeaderOf (AddressOf x) ~ x >> >> -- Valid: >> type instance AddressOf IPv4Header = IPv4 >> type instance HeaderOf IPv4 = IPv4Header >> >> -- Invalid >> type instance AddressOf AppHeader = AppAddress >> type instance HeaderOf AppAddress = [AppHeader] > > So this is a universally enforced type equivalence. The stipulation > could be arbitrarily complex, checked at compile time, and must hold > for all instances of either type family. > > Am I making this too hard? Is there already a solution I'm missing? > > Cheers, > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From warrensomebody at gmail.com Sat Jan 3 20:28:20 2009 From: warrensomebody at gmail.com (Warren Harris) Date: Sat Jan 3 20:20:37 2009 Subject: [Haskell-cafe] teaching functional programming at work Message-ID: I am seeking suggestions from the haskell cafe for teaching functional programming concepts to colleagues at work. I'm currently working on a project using ocaml and functional programming techniques, and am a lone ranger at my workplace when it comes to this sort of thing (we are primarily a python shop). However there seems to be a growing curiosity in functional programming, and I think there's a lot to be learned from from it whether one chooses a functional language for their next big project or not. But I'm a practitioner, not an academic or lecturer, and although I find the idea of helping my colleagues understand these concepts to be an exciting prospect, I'm not really sure where to start in terms of materials or overall direction. My sense is to form a study group (perhaps going through Real World Haskell together), but I'm a little afraid of assembling people together for a "now what?" experience. So my first question is whether this is even a good idea? Some things I think would be useful to get across are: - fp is more than just an exercise in avoiding assignment statements -- why a smart programmer should care? - reading knowledge of ocaml and/or haskell (even syntax, precedence and infix operators can be an initial stumbling block) - core concepts: type classes, proper tail recursion, higher-order functions, folds, combinators, monads, monad transformers, arrows - evidence that concise expression can lead to less bugs / better maintainability (hard to prove, but perhaps a sense can be conveyed) - relationship between types / theorems / programs / proofs and why this is important for the future of software Regarding this last point, my own sense has been that by leveraging a powerful type system such as found in ocaml or haskell has allowed me to achieve things I never would have been able to without it (or at least would have ended up with a much less elegant implementation and much more debugging) but many seem to find types to be either an impedance to getting things done quickly, or at best irrelevant. I know this is for the most part a religious war, but I would like my colleagues to arrive at their opinion from an informed perspective, which means learning that there's more to typeful programming than what is presented by java or c++. Finally, any comments on how to make the learning experience fun, engaging, and a positive experience would be greatly appreciated. Warren From lrpalmer at gmail.com Sat Jan 3 20:46:50 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Sat Jan 3 20:38:34 2009 Subject: [Haskell-cafe] How to check object's identity? In-Reply-To: <20090103152830.GA22587@aiur> References: <20090103152830.GA22587@aiur> Message-ID: <7ca3f0160901031746l45bd9455x7f5da575cb1c50f1@mail.gmail.com> 2009/1/3 Xie Hanjian > Hi, > > I tried this in ghci: > >Prelude> 1:2:[] == 1:2:[] > True > > Does this mean (:) return the same object on same input, Also, in functional programming, *every* function returns the same output for the same input. That's part of the definition of function. :-) Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090103/794510eb/attachment.htm From ml at isaac.cedarswampstudios.org Sat Jan 3 22:08:55 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sat Jan 3 22:00:52 2009 Subject: [Haskell-cafe] Use of abbreviations in Haskell In-Reply-To: <87k59c2l1x.fsf@malde.org> References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> <495E801B.3090409@isaac.cedarswampstudios.org> <87k59c2l1x.fsf@malde.org> Message-ID: <200901032208.55633.ml@isaac.cedarswampstudios.org> Ketil Malde wrote: > A module may be defined in a file with a name corresponding to the > module name, or any dot-separated prefix of it? I.e. the file > Foo/Bar.hs will define module Foo.Bar and optionally Foo.Bar.Baz as > well? > > GHC should then be able to find it, and I believe it already has a > prioritized search mechanism (presumably, the file could be named > Foo.Bar.hs, too). I don't think GHC actually allows that (Foo.Bar.hs, ever). But your suggestion could work. 1. Try Foo/Bar/Baz.hs ; if it exists, end search (and error if it does not contain Foo.Bar.Baz, obviously as the file's top-level module). 2. Try Foo.Bar.hs ; if it exists, end search (and error if it does not contain Foo.Bar.Baz, obviously as a sub-module). 3. Try Foo.hs ; if it exists, end search (and error if it does not contain Foo.Bar.Baz, obviously as a sub-module... or possibly as a sub-sub-module?). 4. give up :-) Note though, that local modules tempt us to a couple other things too, even though they're not necessary to the proposal and would complicate it: - access-controlled modules (e.g. if other code can't import Foo.Bar.Baz) - relative-path imports / module names (e.g. if in Foo/Bar.hs we make Baz and try to import it some way with "import Baz") and as we already mentioned, it would likely involve some implicit importing of the sub-module. translating into ordinary haskell: I think my module-search mechanism makes a well-defined, deterministic way to find the right module, no complex translation necessary (except layout rule madness maybe?). Implicit importing: submodule syntax implies adding an "import The.Module.Name" line at that point in the containing file. This would suggest that submodules must be at the top, among the imports, because all imports must syntactically be at the beginning of the file -- and there's a reason for this. Bother! Even if the reason is dependency chasing, one would think same-file dependencies aren't important, but the submodules themselves can import things from other files, so those lines should need to be near the beginning anyway. so an example could be module MyData ( module MyData.Sub, -- or equivalently, D(..) transform ) where module MyData.Sub --or "module Sub" ?? that seems a bit too ad-hoc though where data D = E | F transform :: D -> D transform F = E transform E = F ~Isaac From wren at freegeek.org Sat Jan 3 22:42:54 2009 From: wren at freegeek.org (wren ng thornton) Date: Sat Jan 3 22:34:38 2009 Subject: [Haskell-cafe] ANN: bytestring-trie 0.1.1 (bugfix) In-Reply-To: <494C8B52.2040209@freegeek.org> References: <494C8B52.2040209@freegeek.org> Message-ID: <4960303E.8010102@freegeek.org> -------------------------------------------- -- bytestring-trie 0.1.1 (bugfix) -------------------------------------------- An efficient finite map from (byte)strings to values. The implementation is based on big-endian patricia trees, like Data.IntMap. We first trie on the Word8 elements of a Data.ByteString, sharing string prefixes where possible, and then trie on the big-endian bit representation of those elements. Patricia trees have efficient algorithms for union and other merging operations, but they're also quick for lookups and insertions. -------------------------------------------- -- Changes -------------------------------------------- * Fixed a bug in lookupBy_ pointed out by Maxime Henrion. The bug affects all "lookup-like" functions when a prefix of the query matches only part of a shared prefix in the trie (e.g. looking for "fi" in a trie containing ["foo","bar","baz"], but not when looking up "fo", "food", or "bag"). * By popular demand Trie now has a Binary instance. This adds a new dependency on the binary package. The dependency shouldn't be onerous to anyone, but let me know if it is. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-trie Darcs: http://code.haskell.org/~wren/bytestring-trie/ Haddock (Darcs version): http://code.haskell.org/~wren/bytestring-trie/dist/doc/html/bytestring-trie/ -- Live well, ~wren From jan.h.xie at gmail.com Sat Jan 3 23:11:05 2009 From: jan.h.xie at gmail.com (Xie Hanjian) Date: Sat Jan 3 23:02:57 2009 Subject: [Haskell-cafe] How to check object's identity? In-Reply-To: <7ca3f0160901031746l45bd9455x7f5da575cb1c50f1@mail.gmail.com> References: <20090103152830.GA22587@aiur> <7ca3f0160901031746l45bd9455x7f5da575cb1c50f1@mail.gmail.com> Message-ID: <20090104041105.GA31082@aiur> * Luke Palmer [2009-01-03 18:46:50 -0700]: > 2009/1/3 Xie Hanjian > > > Hi, > > > > I tried this in ghci: > > >Prelude> 1:2:[] == 1:2:[] > > True > > > > Does this mean (:) return the same object on same input, > > > Also, in functional programming, *every* function returns the same output > for the same input. That's part of the definition of function. :-) This is true in Haskell, but may not true in Scheme (I guess also false in Lisp). In DrScheme: >(eq? (cons 1 2) (cons 1 2)) #f >(equal? (cons 1 2) (cons 1 2)) #t Although equal? treats the two as the *same*, they're different lists because if we modify one (e.g by set-car!) the other won't be affected. So here comes another question: when we say a function always give the same output for the same input, what the *same* means here? ?dentity or equality? Thanks Jan > > Luke > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- jan=callcc{|jan|jan};jan.call(jan) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090104/7d6583a2/attachment.bin From thomas.dubuisson at gmail.com Sat Jan 3 23:11:37 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Sat Jan 3 23:03:20 2009 Subject: [Haskell-cafe] Use of abbreviations in Haskell In-Reply-To: <200901032208.55633.ml@isaac.cedarswampstudios.org> References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> <495E801B.3090409@isaac.cedarswampstudios.org> <87k59c2l1x.fsf@malde.org> <200901032208.55633.ml@isaac.cedarswampstudios.org> Message-ID: <4c44d90b0901032011k7ed6b541we3cc4aaa114b10bd@mail.gmail.com> Cafe, I was going to write about this earlier, but I'm so ill read on the record selector papers that I deleted the draft. My proposal would be for each selector name to be a special type of "phantom" type class (existing in the intermediate language only). This type class would not be accessible by the programmer and thus s/he couldn't make a polymorphic function for which specialization would be needed. In other words - in normal circumstances there is no need for dictionaries and thus no run-time difference between this method and using different record names. Example: > data IPv4Hdr = Hdr4 { src, dst :: IPv4 } > data IPv6Hdr = Hdr6 { src, dst :: IPv6 } > > func4 :: IPv4Hdr -> IO () > func4 hdr = do > let s = src hdr > ... > > func6 :: IPv6Hdr -> IO () > func6 hdr = do > let s = src hdr > ... At some intermediate stage you'd see: > class Src h s where > src :: h -> s > class Dst h d where > dst :: h -> d > > instance Src IPv4Hdr IPv4 where > src (IPv4 s _) = s > instance Dst IPv4Hdr IPv4 where > dst (IPv4 _ d) = d > -- repeat for IPv6 The only point of frustration I see is if the programmer manually makes both data types an instance of a programmer-visible type class, thus making a polymorphic function. > class IPHdr a > instance IPHdr IPv4Hdr > instance IPHdr IPv6Hdr > > sendPing :: (IPHdr a) => a -> IO () > sendPing p = networkSend (dst p) pingPayload In this case I'd vote for specializing the function so there still aren't any extra dictionaries, but I know that is not always optimal. Tom On Sat, Jan 3, 2009 at 10:08 PM, Isaac Dupree wrote: > Ketil Malde wrote: >> A module may be defined in a file with a name corresponding to the >> module name, or any dot-separated prefix of it? I.e. the file >> Foo/Bar.hs will define module Foo.Bar and optionally Foo.Bar.Baz as >> well? >> >> GHC should then be able to find it, and I believe it already has a >> prioritized search mechanism (presumably, the file could be named >> Foo.Bar.hs, too). > > I don't think GHC actually allows that (Foo.Bar.hs, ever). But your suggestion > could work. > > 1. Try Foo/Bar/Baz.hs ; if it exists, end search (and error if it does not > contain Foo.Bar.Baz, obviously as the file's top-level module). > 2. Try Foo.Bar.hs ; if it exists, end search (and error if it does not contain > Foo.Bar.Baz, obviously as a sub-module). > 3. Try Foo.hs ; if it exists, end search (and error if it does not contain > Foo.Bar.Baz, obviously as a sub-module... or possibly as a sub-sub-module?). > 4. give up :-) > > Note though, that local modules tempt us to a couple other things too, even > though they're not necessary to the proposal and would complicate it: > - access-controlled modules (e.g. if other code can't import Foo.Bar.Baz) > - relative-path imports / module names (e.g. if in Foo/Bar.hs we make Baz and > try to import it some way with "import Baz") > > and as we already mentioned, it would likely involve some implicit importing > of the sub-module. > > translating into ordinary haskell: > I think my module-search mechanism makes a well-defined, deterministic way to > find the right module, no complex translation necessary (except layout rule > madness maybe?). > Implicit importing: submodule syntax implies adding an "import > The.Module.Name" line at that point in the containing file. This would suggest > that submodules must be at the top, among the imports, because all imports > must syntactically be at the beginning of the file -- and there's a reason for > this. Bother! Even if the reason is dependency chasing, one would think > same-file dependencies aren't important, but the submodules themselves can > import things from other files, so those lines should need to be near the > beginning anyway. > > so an example could be > > module MyData > ( > module MyData.Sub, -- or equivalently, D(..) > transform > ) > where > > module MyData.Sub --or "module Sub" ?? that seems a bit too ad-hoc though > where > data D = E | F > > transform :: D -> D > transform F = E > transform E = F > > > ~Isaac > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From lrpalmer at gmail.com Sat Jan 3 23:17:09 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Sat Jan 3 23:08:51 2009 Subject: [Haskell-cafe] How to check object's identity? In-Reply-To: <20090104041105.GA31082@aiur> References: <20090103152830.GA22587@aiur> <7ca3f0160901031746l45bd9455x7f5da575cb1c50f1@mail.gmail.com> <20090104041105.GA31082@aiur> Message-ID: <7ca3f0160901032017g39b16fe3paf170fce3ce3da90@mail.gmail.com> 2009/1/3 Xie Hanjian > * Luke Palmer [2009-01-03 18:46:50 -0700]: > > > 2009/1/3 Xie Hanjian > > > > > Hi, > > > > > > I tried this in ghci: > > > >Prelude> 1:2:[] == 1:2:[] > > > True > > > > > > Does this mean (:) return the same object on same input, > > > > > > Also, in functional programming, *every* function returns the same output > > for the same input. That's part of the definition of function. :-) > > This is true in Haskell, but may not true in Scheme (I guess also false > in Lisp). I, like many arrogant Haskellers, reject Scheme and other such impure languages as "functional". At least until I turn on my brain. So, revise the beginning of my statement to "Also, in *pure* functional programming, ..." Luke > > In DrScheme: > > >(eq? (cons 1 2) (cons 1 2)) > #f > >(equal? (cons 1 2) (cons 1 2)) > #t > > Although equal? treats the two as the *same*, they're different lists > because if we modify one (e.g by set-car!) the other won't be affected. > > So here comes another question: when we say a function always give the > same output for the same input, what the *same* means here? ?dentity > or equality? > > Thanks > Jan > > > > > Luke > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -- > jan=callcc{|jan|jan};jan.call(jan) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090103/13fcd1e4/attachment.htm From thomas.dubuisson at gmail.com Sat Jan 3 23:35:35 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Sat Jan 3 23:27:19 2009 Subject: [Haskell-cafe] Type Family Relations In-Reply-To: <5ab17e790901031718q2c3f3030y8cb7d3b4e7bc01ba@mail.gmail.com> References: <4c44d90b0901030722s7c0aefc2qe74986321f2e0e32@mail.gmail.com> <5ab17e790901031718q2c3f3030y8cb7d3b4e7bc01ba@mail.gmail.com> Message-ID: <4c44d90b0901032035q1001bfaau4deec962ca0f6cf9@mail.gmail.com> Thank you all for the responses. I find the solution that omits type families [Diatchki] to be too limiting while the solution 'class (Dual (Dual s) ~ s) =>' [Ingram] isn't globally enforced. I've yet to closely study your first solution, Ryan, but it appears to be what I was looking for - I'll give it a try in the coming week. Tom On Sat, Jan 3, 2009 at 8:18 PM, Iavor Diatchki wrote: > Hello, > Usually, you can program such things by using super-classes. Here is > how you could encode your example: > > {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, > FlexibleInstances #-} > > class HeaderOf addr hdr | addr -> hdr > class HeaderOf addr hdr => AddressOf hdr addr | addr -> hdr > > data IPv4Header = C1 > data IPv4 = C2 > data AppAddress = C3 > data AppHeader = C4 > > instance AddressOf IPv4Header IPv4 > instance HeaderOf IPv4 IPv4Header > > {- results in error: > instance AddressOf AppHeader AppAddress > instance HeaderOf AppAddress [AppHeader] > -} > > Hope that this helps, > Iavor > > > > On Sat, Jan 3, 2009 at 7:22 AM, Thomas DuBuisson > wrote: >> Cafe, >> I am wondering if there is a way to enforce compile time checking of >> an axiom relating two separate type families. >> >> Mandatory contrived example: >> >>> type family AddressOf h >>> type family HeaderOf a >>> >>> -- I'm looking for something to the effect of: >>> type axiom HeaderOf (AddressOf x) ~ x >>> >>> -- Valid: >>> type instance AddressOf IPv4Header = IPv4 >>> type instance HeaderOf IPv4 = IPv4Header >>> >>> -- Invalid >>> type instance AddressOf AppHeader = AppAddress >>> type instance HeaderOf AppAddress = [AppHeader] >> >> So this is a universally enforced type equivalence. The stipulation >> could be arbitrarily complex, checked at compile time, and must hold >> for all instances of either type family. >> >> Am I making this too hard? Is there already a solution I'm missing? >> >> Cheers, >> Tom >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > From h8spawn at googlemail.com Sun Jan 4 01:13:30 2009 From: h8spawn at googlemail.com (=?UTF-8?Q?S._G=C3=BCnther?=) Date: Sun Jan 4 01:05:12 2009 Subject: [Haskell-cafe] Updating doubly linked lists In-Reply-To: References: Message-ID: G'Day, and phew... quite a lot of code to grok. Thanks for the answers, they're much appreciated. On Sun, Jan 4, 2009 at 1:43 AM, Niklas Broberg wrote: > > What you need is for the nodes to keep track of the length of the > list. Here's a different solution from that oleg posted, to me it's > slightly more intuitive, since the updates work directly on the dlists > instead of via (elegant) proxy functions. > I had exactly the same thoughts after I realized that, if one wants to update only the non cyclic part of the list one has to know where the non cyclic part ends. But the only way to know that, is by keeping track of the length of the list and using this to find out when to tie the knot. So your solution is also more intuitive to me but if I'm not mistaken it has update complexity linear in the number of elements in the list whereas Oleg's solution is logarithmic. > mkRestDList :: Int -> [a] -> DList a -> DList a -> (DList a, DList a) > mkRestDList _ [] _ farRight = > (farRight, farRight) -- will only happen if the initial list is singleton > mkRestDList len [x] nearLeft farRight = > let this = DNode len nearLeft x farRight > in (this, this) > mkRestDList len (x:xs) nearLeft farRight = > let this = DNode len nearLeft x nearRight > (nearRight,farLeft) = mkRestDList len xs this farRight > in (this,farLeft) > > updateRestD :: Int -> DList a -> DList a -> DList a -> (DList a, DList a) > updateRestD 0 _ _ farRight = > (farRight, farRight) -- will only happen if the initial list is singleton > updateRestD 1 (DNode len _ x _) nearLeft farRight = > let this = DNode len nearLeft x farRight in (this, this) > updateRestD n (DNode len _ x r) nearLeft farRight = > let this = DNode len nearLeft x nearRight > (nearRight,farLeft) = updateRestD (n-1) r this farRight > in (this,farLeft) > updateRestD _ Empty _ _ = undefined -- can't happen > I think you can drop the second case in those two functions if you rewrite the first case like this: mkRestDList _ [] nearLeft farRight = (farRight, nearLeft) resp. updateRestD 0 _ nearLeft farRight = (farRight, nearLeft) On Sat, Jan 3, 2009 at 8:51 PM, wrote: > > Stephan Guenther wrote: > > The algorithm is essentially imperative (and so permits identity > checking and in-place `updates') but implemented purely > functionally. No destructive updates are ever used. Therefore, all the > changes can be undone and re-done, and the code is MT-safe. The code > is easily generalizable to 2D. Thanks for your answer. As I'll explain below I also thought about using a Map for the 2D case, but wouldn't have thought of it in the one dimensional case as my intuition would have been to use Niklas' solution there. Thanks for putting my thoughts in a different direction. Yet the thing that really puzzled me in the list case was, that I was searching for a solution without using auxiliary data like the length or delegating the update to a data structure which already supported it. I'm pretty sure by now that its impossible without using zippers or something else. > It is not for nothing Haskell is called the best imperative > language. One can implement imperative algorithms just as they are -- > purely functionally, without any monads or other categorical notions. Amen to that. > -- The insert operation below makes a cyclic list > -- The other operations don't care > -- Insert to the right of the current element, if any > -- Return the DL where the inserted node is the current one > insert_right :: a -> DList a -> DList a > insert_right x dl | is_empty dl = > let ref = dl_counter dl > -- the following makes the list cyclic > node = Node{node_val = x, node_left = ref, node_right = ref} > in DList{dl_counter = succ ref, > dl_current = ref, > dl_mem = IM.insert ref node (dl_mem dl)} > > insert_right x dl@DList{dl_counter = ref, dl_current = curr, dl_mem = mem} = > DList{dl_counter = succ ref, dl_current = ref, > dl_mem = IM.insert ref new_node $ IM.insert curr curr_node' mem} > where > curr_node = get_curr_node dl > curr_node'= curr_node{node_right = ref} > new_node = Node{node_val = x, node_left = curr, > node_right = node_right curr_node} Could it be that there's a small inconsistency in the fact that if you don't update the left_node ref of curr_node? This is nearly never a problem except when you do insert_right on a DList with only one element. In that case node_left of curr_node references itself and should be updated to reference it's new right (and therefore also left wraparound) neighbour. If I'm right this leads to the fact that DList is only right cyclic while the left end always wraps around to itself. I know that this is easily corrected (if wanted), I just want to know if I'm understanding the code correctly. On Sat, Jan 3, 2009 at 10:37 PM, Apfelmus, Heinrich wrote: > Ah, so you have a rectangular (or later hexagonal?) 2D grid? I suggest > representing it as > > Data.Map (Integer, Integer) a > > as explained below. Right on the button. This is exactly what I need. And I also contemplated doing it with indexing into Data.Map but decided against it because of the lookup complexity. It might very well be the case that this is a non issue but I'd rather not loose the O(1) neighbour lookup and O(1) update. OTOH hand I'm aware of the fact that using TVars very well might hurt performance if I'm not careful with my transactions since the way TVars are managed would give me worse complexity again. So for now I'm going with TVars while still keeping in mind to maybe try the Data.Map approach later to see how it pans out. > For the 2D grid zipper above, moving around is O(1) but update is O(log > n). This is acceptable; also because I'm quite confident that a zipper > for a 2D grid with everything O(1) does not exist. I can prove that for > a special case and should probably write it down at some point. I would be pretty interested in the proof, since when I was trying to generalize zippers I wanted to keep the nice O(1) on everything. And that was exactly what I couldn't bring together with non trivial cycles. I should point out that this is the point where my thoughts diverged. With the doubly linked list example I wasn't concerned with performance I just wanted to figure out a way to do updates in on circular DLists with proper sharing and no additional data or data structures. With my real world needs i.e. the 2D example I wanted to find a way to keep the performance while remaining pure. > My personal experience is that not going with the obvious but messy > solution but searching for a more elegant one is always faster in the > long run. :) Not only that but I also have the slight feeling that haskell would reward me for choosing the Data.Map approach. But I need a little bit of training on TVars and STM anyways so I'm going for this. For now that is. ;) Big thanks. I already learned a lot from this thread. Cheers Stephan From anton at appsolutions.com Sun Jan 4 02:08:13 2009 From: anton at appsolutions.com (Anton van Straaten) Date: Sun Jan 4 02:00:00 2009 Subject: [Haskell-cafe] How to check object's identity? In-Reply-To: <7ca3f0160901032017g39b16fe3paf170fce3ce3da90@mail.gmail.com> References: <20090103152830.GA22587@aiur> <7ca3f0160901031746l45bd9455x7f5da575cb1c50f1@mail.gmail.com> <20090104041105.GA31082@aiur> <7ca3f0160901032017g39b16fe3paf170fce3ce3da90@mail.gmail.com> Message-ID: <4960605D.4010201@appsolutions.com> Luke Palmer wrote: > I, like many arrogant Haskellers, reject Scheme and other such impure > languages as "functional". At least until I turn on my brain. If Haskell is functional, then so is Scheme - it's just that Scheme lets you use IORefs and the IO monad without going to nearly as much trouble. Anton From barsoap at web.de Sun Jan 4 03:19:04 2009 From: barsoap at web.de (Achim Schneider) Date: Sun Jan 4 03:11:02 2009 Subject: [Haskell-cafe] Re: about the concatenation on a tree References: <902ff3e80812310659j2ee7949du7a54bcf5de7c0139@mail.gmail.com> Message-ID: <20090104091904.297b9d2b@solaris> "Max cs" wrote: > hi all, not sure if there is someone still working during holiday > like me : ) > > I got a little problem in implementing some operations on tree. > > suppose we have a tree date type defined: > > data Tree a = Leaf a | Branch (Tree a) (Tree a) > > I want to do a concatenation on these tree just like the concat on > list. Anyone has idea on it? or there are some existing > implementation? > The semantics of tree concat vary, depending on what type of tree you want to have. In the simplest case, it's unbalanced, so you can just do concat :: Tree a -> Tree a -> Tree a concat x y = Branch x y if, on the other hand, you want to keep the tree balanced, or sorted, or whatever, things get more involved. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From qdunkan at gmail.com Sun Jan 4 03:19:38 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Sun Jan 4 03:11:22 2009 Subject: [Haskell-cafe] How to check object's identity? In-Reply-To: <20090104041105.GA31082@aiur> References: <20090103152830.GA22587@aiur> <7ca3f0160901031746l45bd9455x7f5da575cb1c50f1@mail.gmail.com> <20090104041105.GA31082@aiur> Message-ID: <2518b95d0901040019s78d963c5gea2a13e200955d40@mail.gmail.com> > Although equal? treats the two as the *same*, they're different lists > because if we modify one (e.g by set-car!) the other won't be affected. > > So here comes another question: when we say a function always give the > same output for the same input, what the *same* means here? ?dentity > or equality? If you don't have set-car!, then identity and equality are impossible to differentiate. And haskell doesn't have set-car!. However, as was noted, it does have something like mutable pointers via IORef, and sure enough, you can do pointer comparisons with them: h <- newIORef 12 h' <- newIORef 12 print $ h == h --> True print $ h == h' --> False Since they're pointers, to compare by value you have to explicitly derefence them: print =<< liftM2 (==) (readIORef h) (readIORef h') --> True If you're wondering about the implementation of "(1:[], 1:[])", ghc might be smart enough to do CSE in this case and hence use the same memory for both lists, but in general CSE doesn't happen to avoid accidental recomputation. There's some stuff in the ghc manual about lambda and let lifting that describes when CSE will and won't happen. I wouldn't count on it in general, but I don't read core well enough to tell. Maybe someone who knows more about core can help me here: a = \ (eta_azv :: State# RealWorld) -> case a24 stdout lvl7 eta_azv of wild_aFu { (# new_s_aFw, a103_aFx #) -> $wa13 stdout '\n' new_s_aFw } There are lots of apparently undefined variables, like the function 'a24'. But it looks like the pair should come from 'lvl7', which is chained all the way down to 'lvl' like so: lvl :: Integer lvl = S# 1 lvl1 :: [Integer] lvl1 = : @ Integer lvl ([] @ Integer) lvl2 :: ShowS lvl2 = showList lvl1 lvl3 :: [ShowS] lvl3 = : @ ShowS lvl2 ([] @ ShowS) lvl4 :: [ShowS] lvl4 = : @ ShowS lvl2 lvl3 lvl5 :: [Char] lvl5 = : @ Char a2 ([] @ Char) lvl6 :: String lvl6 = foldr1 @ (String -> String) lvl16 lvl4 lvl5 lvl7 :: [Char] lvl7 = : @ Char a lvl6 So it *looks* like there's only one list created in 'lvl1', but I can't see where it's turning into a tuple, and I don't understand the ' = : ' stuff, as in 'lvl5 = : @ Char a2 ([] @ Char)'. 'lvl5' is a Char resulting from the application of 'a2' to ""? The code, btw, was 'main = print (1:[], 1:[])'. From derek.a.elkins at gmail.com Sun Jan 4 03:48:31 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sun Jan 4 03:40:19 2009 Subject: [Haskell-cafe] How to check object's identity? In-Reply-To: <2518b95d0901040019s78d963c5gea2a13e200955d40@mail.gmail.com> References: <20090103152830.GA22587@aiur> <7ca3f0160901031746l45bd9455x7f5da575cb1c50f1@mail.gmail.com> <20090104041105.GA31082@aiur> <2518b95d0901040019s78d963c5gea2a13e200955d40@mail.gmail.com> Message-ID: <1231058912.5973.2.camel@derek-laptop> On Sun, 2009-01-04 at 16:19 +0800, Evan Laforge wrote: > > Although equal? treats the two as the *same*, they're different lists > > because if we modify one (e.g by set-car!) the other won't be affected. > > > > So here comes another question: when we say a function always give the > > same output for the same input, what the *same* means here? ?dentity > > or equality? > > If you don't have set-car!, then identity and equality are impossible > to differentiate. And haskell doesn't have set-car!. > > However, as was noted, it does have something like mutable pointers > via IORef, and sure enough, you can do pointer comparisons with them: > > h <- newIORef 12 > h' <- newIORef 12 > print $ h == h --> True > print $ h == h' --> False > > Since they're pointers, to compare by value you have to explicitly > derefence them: > > print =<< liftM2 (==) (readIORef h) (readIORef h') --> True > > > If you're wondering about the implementation of "(1:[], 1:[])", ghc > might be smart enough to do CSE in this case and hence use the same > memory for both lists, but in general CSE doesn't happen to avoid > accidental recomputation. There's some stuff in the ghc manual about > lambda and let lifting that describes when CSE will and won't happen. > I wouldn't count on it in general, but I don't read core well enough > to tell. Maybe someone who knows more about core can help me here: > > a = > \ (eta_azv :: State# RealWorld) -> > case a24 stdout lvl7 eta_azv > of wild_aFu { (# new_s_aFw, a103_aFx #) -> > $wa13 stdout '\n' new_s_aFw > } > > There are lots of apparently undefined variables, like the function > 'a24'. But it looks like the pair should come from 'lvl7', which is > chained all the way down to 'lvl' like so: > > lvl :: Integer > lvl = S# 1 > > lvl1 :: [Integer] > lvl1 = > : @ Integer lvl ([] @ Integer) > > lvl2 :: ShowS > lvl2 = showList lvl1 > > lvl3 :: [ShowS] > lvl3 = : @ ShowS lvl2 ([] @ ShowS) > > lvl4 :: [ShowS] > lvl4 = : @ ShowS lvl2 lvl3 > > lvl5 :: [Char] > lvl5 = : @ Char a2 ([] @ Char) > > lvl6 :: String > lvl6 = > foldr1 > @ (String -> String) lvl16 lvl4 lvl5 > > lvl7 :: [Char] > lvl7 = : @ Char a lvl6 > > So it *looks* like there's only one list created in 'lvl1', but I > can't see where it's turning into a tuple, and I don't understand the > ' = : ' stuff, You're reading it wrong. : is a name. It's lvl5 = (:) @ Char a2 ([] @ Char) where @ is type application (instantiation). Triming that, it's lvl5 = (:) a2 [] or just lvl5 = a2:[] From jan.h.xie at gmail.com Sun Jan 4 03:49:33 2009 From: jan.h.xie at gmail.com (jan.h.xie@gmail.com) Date: Sun Jan 4 03:41:28 2009 Subject: [Haskell-cafe] How to check object's identity? In-Reply-To: <2518b95d0901040019s78d963c5gea2a13e200955d40@mail.gmail.com> References: <20090103152830.GA22587@aiur> <7ca3f0160901031746l45bd9455x7f5da575cb1c50f1@mail.gmail.com> <20090104041105.GA31082@aiur> <2518b95d0901040019s78d963c5gea2a13e200955d40@mail.gmail.com> Message-ID: <20090104084933.GC31082@aiur> * Evan Laforge [2009-01-04 16:19:38 +0800]: > > Although equal? treats the two as the *same*, they're different lists > > because if we modify one (e.g by set-car!) the other won't be affected. > > > > So here comes another question: when we say a function always give the > > same output for the same input, what the *same* means here? ?dentity > > or equality? > > If you don't have set-car!, then identity and equality are impossible > to differentiate. And haskell doesn't have set-car!. > > However, as was noted, it does have something like mutable pointers > via IORef, and sure enough, you can do pointer comparisons with them: > > h <- newIORef 12 > h' <- newIORef 12 > print $ h == h --> True > print $ h == h' --> False > > Since they're pointers, to compare by value you have to explicitly > derefence them: > > print =<< liftM2 (==) (readIORef h) (readIORef h') --> True > > > If you're wondering about the implementation of "(1:[], 1:[])", ghc > might be smart enough to do CSE in this case and hence use the same > memory for both lists, but in general CSE doesn't happen to avoid > accidental recomputation. There's some stuff in the ghc manual about > lambda and let lifting that describes when CSE will and won't happen. > I wouldn't count on it in general, but I don't read core well enough > to tell. Maybe someone who knows more about core can help me here: Very clear explanation, thanks Evan :-) -- jan=callcc{|jan|jan};jan.call(jan) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090104/73867adf/attachment.bin From qdunkan at gmail.com Sun Jan 4 03:55:19 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Sun Jan 4 03:47:02 2009 Subject: [Haskell-cafe] How to check object's identity? In-Reply-To: <1231058912.5973.2.camel@derek-laptop> References: <20090103152830.GA22587@aiur> <7ca3f0160901031746l45bd9455x7f5da575cb1c50f1@mail.gmail.com> <20090104041105.GA31082@aiur> <2518b95d0901040019s78d963c5gea2a13e200955d40@mail.gmail.com> <1231058912.5973.2.camel@derek-laptop> Message-ID: <2518b95d0901040055r2fa2d8c0i80fcd837f4564094@mail.gmail.com> >> So it *looks* like there's only one list created in 'lvl1', but I >> can't see where it's turning into a tuple, and I don't understand the >> ' = : ' stuff, > > You're reading it wrong. : is a name. > It's lvl5 = (:) @ Char a2 ([] @ Char) where @ is type application > (instantiation). Triming that, it's > lvl5 = (:) a2 [] or just lvl5 = a2:[] Ooohhhh, much clearer, thanks! The lack of ()s threw me. I'm still confused about the apparently undefined 'a2' though. However, it looks like there's only one [1], defined in lvl1, so I guess this means ghc has merged the two conses into one variable, and hence they really do have the same identity? From miguelimo38 at yandex.ru Sun Jan 4 04:15:50 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Sun Jan 4 04:07:35 2009 Subject: [Haskell-cafe] Use of abbreviations in Haskell In-Reply-To: <4c44d90b0901032011k7ed6b541we3cc4aaa114b10bd@mail.gmail.com> References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> <495E801B.3090409@isaac.cedarswampstudios.org> <87k59c2l1x.fsf@malde.org> <200901032208.55633.ml@isaac.cedarswampstudios.org> <4c44d90b0901032011k7ed6b541we3cc4aaa114b10bd@mail.gmail.com> Message-ID: <7F616EE3-74D7-48F2-925B-6E436943E26B@yandex.ru> On 4 Jan 2009, at 07:11, Thomas DuBuisson wrote: > My proposal would be for each selector name to be a special type of > "phantom" type class (existing in the intermediate language only). > This type class would not be accessible by the programmer and thus > s/he couldn't make a polymorphic function for which specialization > would be needed. In other words - in normal circumstances there is > no need for dictionaries and thus no run-time difference between this > method and using different record names. > > Example: > >> data IPv4Hdr = Hdr4 { src, dst :: IPv4 } >> data IPv6Hdr = Hdr6 { src, dst :: IPv6 } > At some intermediate stage you'd see: > >> class Src h s where >> src :: h -> s >> class Dst h d where >> dst :: h -> d class Src h s | h -> s From iavor.diatchki at gmail.com Sun Jan 4 04:45:58 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun Jan 4 04:37:40 2009 Subject: [Haskell-cafe] Type Family Relations In-Reply-To: <4c44d90b0901032035q1001bfaau4deec962ca0f6cf9@mail.gmail.com> References: <4c44d90b0901030722s7c0aefc2qe74986321f2e0e32@mail.gmail.com> <5ab17e790901031718q2c3f3030y8cb7d3b4e7bc01ba@mail.gmail.com> <4c44d90b0901032035q1001bfaau4deec962ca0f6cf9@mail.gmail.com> Message-ID: <5ab17e790901040145p327e6655tcefe964713e21103@mail.gmail.com> Hi, I like collecting examples of different type system related issues, and I am curious in what way is the solution that I posted limited. Do you happen to have an example? Thanks, Iavor On Sat, Jan 3, 2009 at 8:35 PM, Thomas DuBuisson wrote: > Thank you all for the responses. I find the solution that omits type > families [Diatchki] to be too limiting while the solution 'class (Dual > (Dual s) ~ s) =>' [Ingram] isn't globally enforced. I've yet to > closely study your first solution, Ryan, but it appears to be what I > was looking for - I'll give it a try in the coming week. > > Tom > > On Sat, Jan 3, 2009 at 8:18 PM, Iavor Diatchki wrote: >> Hello, >> Usually, you can program such things by using super-classes. Here is >> how you could encode your example: >> >> {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, >> FlexibleInstances #-} >> >> class HeaderOf addr hdr | addr -> hdr >> class HeaderOf addr hdr => AddressOf hdr addr | addr -> hdr >> >> data IPv4Header = C1 >> data IPv4 = C2 >> data AppAddress = C3 >> data AppHeader = C4 >> >> instance AddressOf IPv4Header IPv4 >> instance HeaderOf IPv4 IPv4Header >> >> {- results in error: >> instance AddressOf AppHeader AppAddress >> instance HeaderOf AppAddress [AppHeader] >> -} >> >> Hope that this helps, >> Iavor >> >> >> >> On Sat, Jan 3, 2009 at 7:22 AM, Thomas DuBuisson >> wrote: >>> Cafe, >>> I am wondering if there is a way to enforce compile time checking of >>> an axiom relating two separate type families. >>> >>> Mandatory contrived example: >>> >>>> type family AddressOf h >>>> type family HeaderOf a >>>> >>>> -- I'm looking for something to the effect of: >>>> type axiom HeaderOf (AddressOf x) ~ x >>>> >>>> -- Valid: >>>> type instance AddressOf IPv4Header = IPv4 >>>> type instance HeaderOf IPv4 = IPv4Header >>>> >>>> -- Invalid >>>> type instance AddressOf AppHeader = AppAddress >>>> type instance HeaderOf AppAddress = [AppHeader] >>> >>> So this is a universally enforced type equivalence. The stipulation >>> could be arbitrarily complex, checked at compile time, and must hold >>> for all instances of either type family. >>> >>> Am I making this too hard? Is there already a solution I'm missing? >>> >>> Cheers, >>> Tom >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From la at iki.fi Sun Jan 4 05:12:11 2009 From: la at iki.fi (Lauri Alanko) Date: Sun Jan 4 05:03:53 2009 Subject: [Haskell-cafe] How to check object's identity? In-Reply-To: <2518b95d0901040019s78d963c5gea2a13e200955d40@mail.gmail.com> References: <20090103152830.GA22587@aiur> <7ca3f0160901031746l45bd9455x7f5da575cb1c50f1@mail.gmail.com> <20090104041105.GA31082@aiur> <2518b95d0901040019s78d963c5gea2a13e200955d40@mail.gmail.com> Message-ID: <20090104101211.GA9294@cs.helsinki.fi> On Sun, Jan 04, 2009 at 04:19:38PM +0800, Evan Laforge wrote: > If you don't have set-car!, then identity and equality are impossible > to differentiate. There's still eqv?. (I wish people wouldn't use eq? as an example of an identity-comparison operation. It's as underdefined as unsafePtrEq.) So although state implies identity, the converse is not true. You can also have immutable objects with distinct identities. Some dialects of Scheme have recently started leaning towards making pairs immutable, but whether they should also make them indistinguishable is a separate question: http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/7eccba9fb4eebb44 And having a limited form of observable identity has even been proposed for Haskell: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.4053 Personally, I find the idea appealing (and have implemented the Refs in the paper with IORefs and unsafePerformIO), because really, even currently a programmer has to care about sharing since it can have radical implications for performance and memory usage. Making it observable in the program would just mean acknowledging the fact that in real-world programming, you can't _really_ replace a variable with its definition without changing its behavior in important ways. Lauri From lambda-belka at yandex.ru Sun Jan 4 07:18:51 2009 From: lambda-belka at yandex.ru (Belka) Date: Sun Jan 4 07:10:37 2009 Subject: [Haskell-cafe] Connect to DBMS - what's the cost Message-ID: <21275600.post@talk.nabble.com> Hello, community people! Is anybody aware, what aproximately is the cost for the acquiring connection to DB (and also disconnecting from it)? I guess that may differ from DBMS to DBMS, so I mostly am interested in PostgreSQL case, but for other DBMS it's also good to know. Actually, since all Haskell libraries, that provide interfaces to DBMS, use foreign functions, - the question should be focused on commonly used C libraries. Thanks in advance! -- View this message in context: http://www.nabble.com/Connect-to-DBMS---what%27s-the-cost-tp21275600p21275600.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From Tom.Schrijvers at cs.kuleuven.be Sun Jan 4 07:58:47 2009 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Sun Jan 4 07:50:51 2009 Subject: [Haskell-cafe] Type Family Relations In-Reply-To: <5ab17e790901040145p327e6655tcefe964713e21103@mail.gmail.com> References: <4c44d90b0901030722s7c0aefc2qe74986321f2e0e32@mail.gmail.com> <5ab17e790901031718q2c3f3030y8cb7d3b4e7bc01ba@mail.gmail.com> <4c44d90b0901032035q1001bfaau4deec962ca0f6cf9@mail.gmail.com> <5ab17e790901040145p327e6655tcefe964713e21103@mail.gmail.com> Message-ID: > Hi, > I like collecting examples of different type system related issues, > and I am curious in what way is the solution that I posted limited. Do > you happen to have an example? Hi Iavor, I think that >>> class HeaderOf addr hdr | addr -> hdr does not enforce that there must be a corresponding instance AddressOf hdr addr. Hence, the type checker cannot use that information either. Do you have a way to remedy that? Cheers, Tom > On Sat, Jan 3, 2009 at 8:35 PM, Thomas DuBuisson > wrote: >> Thank you all for the responses. I find the solution that omits type >> families [Diatchki] to be too limiting while the solution 'class (Dual >> (Dual s) ~ s) =>' [Ingram] isn't globally enforced. I've yet to >> closely study your first solution, Ryan, but it appears to be what I >> was looking for - I'll give it a try in the coming week. >> >> Tom >> >> On Sat, Jan 3, 2009 at 8:18 PM, Iavor Diatchki wrote: >>> Hello, >>> Usually, you can program such things by using super-classes. Here is >>> how you could encode your example: >>> >>> {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, >>> FlexibleInstances #-} >>> >>> class HeaderOf addr hdr | addr -> hdr >>> class HeaderOf addr hdr => AddressOf hdr addr | addr -> hdr >>> >>> data IPv4Header = C1 >>> data IPv4 = C2 >>> data AppAddress = C3 >>> data AppHeader = C4 >>> >>> instance AddressOf IPv4Header IPv4 >>> instance HeaderOf IPv4 IPv4Header >>> >>> {- results in error: >>> instance AddressOf AppHeader AppAddress >>> instance HeaderOf AppAddress [AppHeader] >>> -} >>> >>> Hope that this helps, >>> Iavor >>> >>> >>> >>> On Sat, Jan 3, 2009 at 7:22 AM, Thomas DuBuisson >>> wrote: >>>> Cafe, >>>> I am wondering if there is a way to enforce compile time checking of >>>> an axiom relating two separate type families. >>>> >>>> Mandatory contrived example: >>>> >>>>> type family AddressOf h >>>>> type family HeaderOf a >>>>> >>>>> -- I'm looking for something to the effect of: >>>>> type axiom HeaderOf (AddressOf x) ~ x >>>>> >>>>> -- Valid: >>>>> type instance AddressOf IPv4Header = IPv4 >>>>> type instance HeaderOf IPv4 = IPv4Header >>>>> >>>>> -- Invalid >>>>> type instance AddressOf AppHeader = AppAddress >>>>> type instance HeaderOf AppAddress = [AppHeader] >>>> >>>> So this is a universally enforced type equivalence. The stipulation >>>> could be arbitrarily complex, checked at compile time, and must hold >>>> for all instances of either type family. >>>> >>>> Am I making this too hard? Is there already a solution I'm missing? >>>> >>>> Cheers, >>>> Tom >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe@haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From ndmitchell at gmail.com Sun Jan 4 09:16:21 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Jan 4 09:08:03 2009 Subject: [Haskell-cafe] teaching functional programming at work In-Reply-To: References: Message-ID: <404396ef0901040616x7619a413y679bddb25ff67427@mail.gmail.com> Hi Warren, I'd recommend getting them to read Why FP Matters (http://www.cs.chalmers.se/~rjmh/Papers/whyfp.html) to tempt them, followed by Programming in Haskell (http://www.cs.nott.ac.uk/~gmh/book.html) to teach them the concepts/syntax etc, possibly with Learn You a Haskell (http://learnyouahaskell.com/) to get them familiar with GHCi and how/where to type things. That's how I've been doing it at work, and it seems to be working well. Real World Haskell might be a nice follow on after they've learnt functional programming and want to do real stuff with it. Thanks Neil On Sun, Jan 4, 2009 at 1:28 AM, Warren Harris wrote: > I am seeking suggestions from the haskell cafe for teaching functional > programming concepts to colleagues at work. I'm currently working on a > project using ocaml and functional programming techniques, and am a lone > ranger at my workplace when it comes to this sort of thing (we are primarily > a python shop). However there seems to be a growing curiosity in functional > programming, and I think there's a lot to be learned from from it whether > one chooses a functional language for their next big project or not. > > But I'm a practitioner, not an academic or lecturer, and although I find the > idea of helping my colleagues understand these concepts to be an exciting > prospect, I'm not really sure where to start in terms of materials or > overall direction. My sense is to form a study group (perhaps going through > Real World Haskell together), but I'm a little afraid of assembling people > together for a "now what?" experience. So my first question is whether this > is even a good idea? > > Some things I think would be useful to get across are: > > - fp is more than just an exercise in avoiding assignment statements -- why > a smart programmer should care? > - reading knowledge of ocaml and/or haskell (even syntax, precedence and > infix operators can be an initial stumbling block) > - core concepts: type classes, proper tail recursion, higher-order > functions, folds, combinators, monads, monad transformers, arrows > - evidence that concise expression can lead to less bugs / better > maintainability (hard to prove, but perhaps a sense can be conveyed) > - relationship between types / theorems / programs / proofs and why this is > important for the future of software > > Regarding this last point, my own sense has been that by leveraging a > powerful type system such as found in ocaml or haskell has allowed me to > achieve things I never would have been able to without it (or at least would > have ended up with a much less elegant implementation and much more > debugging) but many seem to find types to be either an impedance to getting > things done quickly, or at best irrelevant. I know this is for the most part > a religious war, but I would like my colleagues to arrive at their opinion > from an informed perspective, which means learning that there's more to > typeful programming than what is presented by java or c++. > > Finally, any comments on how to make the learning experience fun, engaging, > and a positive experience would be greatly appreciated. > > Warren > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jeremy.odonoghue at gmail.com Sun Jan 4 10:19:19 2009 From: jeremy.odonoghue at gmail.com (Jeremy O'Donoghue) Date: Sun Jan 4 10:11:01 2009 Subject: [Haskell-cafe] ANN: wxHaskell 0.11.1 Message-ID: <1231082359.21749.1292906397@webmail.messagingengine.com> The wxHaskell development team is pleased to announce the release of wxHaskell 0.11.1, a Haskell binding for the wxWidgets GUI library. The Haskell support is built on a reasonably complete C language binding, which could be used as the basis for wxWidgets support on other languages/platforms which do not have easy mechanisms for linking with C++ code. The main highlights of wxHaskell 0.11.1 are: - Support for XRC resource files, allowing GUI design using a visual tool. Note that this is currently not type safe, and programs will crash if a widget is not cast to the correct type on loading. - Support for wxWidgets 2.8.x. Support for wxWidgets 2.4.2 is now dropped and wxHaskell will not compile against versions of wxWidgets prior to 2.6. This means that exploratory development using GHCi is no longer possible. Workaround is to continue to use older wxHaskell versions. - Support for GHC 6.10 - Preliminary support for Cabal / Hackage The full list of changes is provided at the end of this mail. Binary packages are available from the wxHaskell download site at http://sourceforge.net/project/showfiles.php?group_id=73133, for the following platforms: - Windows - OS X (Intel platform only) - Source code .tar.gz and .zip - Documentation (cross-platform) The wxHaskell libraries (wxcore and wx) are also available from Hackage (http://hackage.haskell.org). About wxHaskell --------------- wxHaskell is a Haskell binding to the wxWidgets GUI library for recent versions of the Glasgow Haskell Compiler. It provides a native look and feel on Windows, OS X and Linux, and a medium level programming interface. The main project page for wxHaskell is at http://wxhaskell.sourceforge.net. The latest source code for wxHaskell can always be obtained from http://darcs.haskell.org/wxhaskell. There are developer (wxhaskell-devel@lists.sourceforge.net and user (wxhaskell-users@lists.sourceforge.net) mailing lists, and a wiki page at http://haskell.org/haskellwiki/WxHaskell which can provide more information to those interested. The C language binding for wxHaskell was derived from an original C language binding created for the Eiffel programming language by the ELJ project (http://elj.sourceforge.net). Non backward compatible changes: - Preliminary Cabal / Hackage support - Added "--global" argument to configure script - Added "--user" argument to configure script - Changed wxhaskell official web page to Haskell wiki at http://haskell.org/haskellwiki/WxHaskell - Changed official darcs repository to code.haskell.org - Adapted the wxHaskell C-layer to work with wxWidgets 2.8 - Adapted some part of wxcore API to be able to refer to wxWidgets 2.8 documentation for wxcore functions - Added "TopLevelWindow", which mainly removes some functionality from "Frame" - Changed "--with-stc" argument to "--with-contrib" - Removed "Wave" type synonym Backward compatible additions: - Added support for using XRC resource files to load most controls and menus attached to frames. - Added sample file showing how to use XRC support to attach command handlers to menu items - Added sample file showing how to use properties with many controls. - Added "--enable-optimization" argument to configure script - Added "--O*" argument to configure script - Added "--enable-library-profiling" argument to configure script - Added "--p" argument to configure script - Added "-fvia-C" argument to configure script. And moved this compilation flag to configure script - Added Image / ByteString conversion functions - Adapted the configuration to work with GHC 6.10. - Changed "Var" type synonym from "IORef" to stm's "TVar" for thread safety - Changed "imageGetPixelArray" and "imageCreateFromPixelArray" to be more flexible. - Changed "Point", "Size", "Vector" and "Rect" to be type synonym. - Added "wxcMilliSleep". Now, "wxcAppUSleep" is deprecated. Use "wxcMilliSleep" instead - Added very experimental wxGraphicsContext support - Added wxSVGFileDC functions Bugfixes: - Applied DEPRECATED pragma to old deprecated functions. Just documented in Haddock before. - Fixed "processExecAsync" hangs Windows GUI-only program - Fixed Windows binary install problem when path with spaces (bug 1400488) - Probably fixed the applicattion failed to initialize properly when using Windows binary. -- Jeremy O'Donoghue jeremy.odonoghue@gmail.com -- Jeremy O'Donoghue jeremy.odonoghue@gmail.com From atomb at galois.com Sun Jan 4 12:08:41 2009 From: atomb at galois.com (Aaron Tomb) Date: Sun Jan 4 12:00:31 2009 Subject: [Haskell-cafe] How to check object's identity? In-Reply-To: <20090103152830.GA22587@aiur> References: <20090103152830.GA22587@aiur> Message-ID: <808E6D62-9231-48AB-9763-4B5A4BAF6E23@galois.com> On Jan 3, 2009, at 7:28 AM, Xie Hanjian wrote: > Hi, > > I tried this in ghci: >> Prelude> 1:2:[] == 1:2:[] > True > > Does this mean (:) return the same object on same input, or > (==) is not for identity checking? If the later is true, how > can I check two object is the *same* object? As others have explained, the == operator doesn't tell you whether two values are actually stored at the same location in memory. If you really need to do this, however, GHC does provide a primitive for comparing the addresses of two arbitrary values: reallyUnsafePtrEquality# :: a -> a -> Int# http://haskell.org/ghc/docs/latest/html/libraries/ghc-prim/GHC-Prim.html#22 Take note of the "reallyUnsafe" prefix, though. :-) It's not something most programs should ever need to deal with. Aaron From tom.davie at gmail.com Sun Jan 4 12:33:03 2009 From: tom.davie at gmail.com (Thomas Davie) Date: Sun Jan 4 12:24:47 2009 Subject: [Haskell-cafe] How to check object's identity? In-Reply-To: <808E6D62-9231-48AB-9763-4B5A4BAF6E23@galois.com> References: <20090103152830.GA22587@aiur> <808E6D62-9231-48AB-9763-4B5A4BAF6E23@galois.com> Message-ID: <7375BBA9-4552-40FA-A1E5-00F00BB5ED97@gmail.com> On 4 Jan 2009, at 18:08, Aaron Tomb wrote: > > On Jan 3, 2009, at 7:28 AM, Xie Hanjian wrote: > >> Hi, >> >> I tried this in ghci: >>> Prelude> 1:2:[] == 1:2:[] >> True >> >> Does this mean (:) return the same object on same input, or >> (==) is not for identity checking? If the later is true, how >> can I check two object is the *same* object? > > As others have explained, the == operator doesn't tell you whether > two values are actually stored at the same location in memory. If > you really need to do this, however, GHC does provide a primitive > for comparing the addresses of two arbitrary values: > > reallyUnsafePtrEquality# :: a -> a -> Int# > > http://haskell.org/ghc/docs/latest/html/libraries/ghc-prim/GHC-Prim.html#22 > > Take note of the "reallyUnsafe" prefix, though. :-) It's not > something most programs should ever need to deal with. Of note, you probably don't need to do this. It's usually safer to associate data with a key, using Data.Map, or just pairing objects with a unique id. Bob From mpj at cs.pdx.edu Sun Jan 4 12:40:48 2009 From: mpj at cs.pdx.edu (Mark P. Jones) Date: Sun Jan 4 12:32:32 2009 Subject: [Haskell-cafe] Type Family Relations In-Reply-To: <4c44d90b0901030722s7c0aefc2qe74986321f2e0e32@mail.gmail.com> References: <4c44d90b0901030722s7c0aefc2qe74986321f2e0e32@mail.gmail.com> Message-ID: <4960F4A0.5050704@cs.pdx.edu> Hi Thomas, The specific problem you describe has a simple solution using multiple parameter classes with syntactic sugar for functional notation instead of type families [1]: > class AddressOf h a | h -> a, a -> h -- bijections > class HeaderOf a h | a -> h, h -> a > instance HeaderOf (AddressOf h) h -- "your axiom" By the way, without the syntactic sugar, the instance declaration shown here is just: > instance AddressOf h a => HeaderOf a h -- also "your axiom" Individual (address,header) pairs are documented with a single instance, as in: > instance AddressOf IPv4Header IPv4 And now the type system can derive "HeaderOf IPv4 IPv4Header" automatically using "your axiom". But you won't be able to add the invalid AppHeader example because it will conflict (either with overlapping instances or with covering, depending on how you approach it). I like this approach because we only have to give a single instance instead of writing a pair of declarations that have to be checked for mutual consistency. I conclude that perhaps your example doesn't illustrate the kind of "arbitrarily complex" constraints you had in mind. Maybe you could elaborate? All the best, Mark [1] http://web.cecs.pdx.edu/~mpj/pubs/fundeps-design.html Thomas DuBuisson wrote: > Cafe, > I am wondering if there is a way to enforce compile time checking of > an axiom relating two separate type families. > > Mandatory contrived example: > >> type family AddressOf h >> type family HeaderOf a >> >> -- I'm looking for something to the effect of: >> type axiom HeaderOf (AddressOf x) ~ x >> >> -- Valid: >> type instance AddressOf IPv4Header = IPv4 >> type instance HeaderOf IPv4 = IPv4Header >> >> -- Invalid >> type instance AddressOf AppHeader = AppAddress >> type instance HeaderOf AppAddress = [AppHeader] > > So this is a universally enforced type equivalence. The stipulation > could be arbitrarily complex, checked at compile time, and must hold > for all instances of either type family. > > Am I making this too hard? Is there already a solution I'm missing? > > Cheers, > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From paul at cogito.org.uk Sun Jan 4 12:46:35 2009 From: paul at cogito.org.uk (Paul Johnson) Date: Sun Jan 4 12:38:22 2009 Subject: [Haskell-cafe] teaching functional programming at work In-Reply-To: References: Message-ID: <4960F5FB.5090705@cogito.org.uk> Warren Harris wrote: > I am seeking suggestions from the haskell cafe for teaching functional > programming concepts to colleagues at work. I'd suggest starting with a couple of hours of "Why Haskell" talk to sell them on the concepts, followed by something like the the study group you mentioned for anyone who wants to pursue it. If you can get them to spare the time then the video of the SPJ talk from last year might be a good starting point. Failing that, try presenting them with some case studies of "here is where Haskell (saves effort) / (improves modularity)" in the kind of environment where you work. Explain how monads are a "reprogrammable semicolon" and show an application of that. No need to go into "bind" operators, just show what the code looks like before and after monads. Paul. From eyal.lotem at gmail.com Sun Jan 4 12:50:20 2009 From: eyal.lotem at gmail.com (eyal.lotem@gmail.com) Date: Sun Jan 4 12:42:00 2009 Subject: [Haskell-cafe] Auto-deriving Control.Exception.Exception Message-ID: <7fd61dfa-da14-40fb-86a9-86a23a642eb5@s9g2000prg.googlegroups.com> If this is valid: import qualified Control.Exception as Exc genericFromException :: Typeable a => Exc.SomeException -> Maybe a genericFromException (Exc.SomeException e) = cast e instance Exc.Exception SomeType where fromException = genericFromException then why not have an auto-deriving rule for Exception (fromException = cast . unSomeException)? From haskell at list.mightyreason.com Sun Jan 4 13:19:18 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Sun Jan 4 13:11:11 2009 Subject: [Haskell-cafe] Re: ANN: bytestring-trie 0.1.1 (bugfix) In-Reply-To: <4960303E.8010102@freegeek.org> References: <494C8B52.2040209@freegeek.org> <4960303E.8010102@freegeek.org> Message-ID: <4960FDA6.3020708@list.mightyreason.com> Question and suggestion: looking at http://hackage.haskell.org/packages/archive/bytestring-trie/0.1.1/doc/html/src/Data-Trie.html#Trie I am questioning your choice of foldr in fromList: > -- | Convert association list into a trie. On key conflict, values > -- earlier in the list shadow later ones. > fromList :: [(KeyString,a)] -> Trie a > fromList = foldr (uncurry insert) empty > -- | /O(1)/, The empty trie. > {-# INLINE empty #-} > empty :: Trie a > empty = Empty > -- | Insert a new key. If the key is already present, overrides the > -- old value > {-# INLINE insert #-} > insert :: KeyString -> a -> Trie a -> Trie a > insert = alterBy (\_ x _ -> Just x) > -- | Generic function to alter a trie by one element with a function > -- to resolve conflicts (or non-conflicts). > alterBy :: (KeyString -> a -> Maybe a -> Maybe a) > -> KeyString -> a -> Trie a -> Trie a > alterBy f_ q_ x_ > | S.null q_ = mergeBy (\x y -> f_ q_ x (Just y)) (singleton q_ x_) > | otherwise = go q_ > where > -- | /O(1)/, Is the trie empty? > {-# INLINE null #-} > null :: Trie a -> Bool > null Empty = True > null _ = False So it looks like the reduction is fromList - uncurry insert - alterBy - null. Let me use insert in place of uncurry insert: fromList ( (a,1) : ( (b,2) : ( (c,3) : [] ) ) ) (a,1) `insert` ( (b,2) `insert` ( (c,3) `insert` Empty ) ) ) So fromList forces the whole call chain above to be traversed until it hits the Empty. For a large input list this will force the whole list to be allocated before proceeding AND the call chain might overflow the allowed stack size in ghc. For a large trie (which is a likely use case) this is a poor situation. If you use foldl' then the input list is only forced one element at a time. A small change to the lambda that insert passes to adjustBy will retain the same semantics of earlier key wins (which are an especially good idea in the foldl' case). Cheers, Chris From lemming at henning-thielemann.de Sun Jan 4 14:50:53 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Jan 4 14:42:36 2009 Subject: [Haskell-cafe] unsafeInterleaveIO respecting order of actions In-Reply-To: References: <2f9b2d30812311301y1068b499u77fa12ef0cd44647@mail.gmail.com> <495D3953.6080609@henning-thielemann.de> <0F9EF08E-178E-4346-98E1-4BB7CE842F92@ece.cmu.edu> Message-ID: On Sat, 3 Jan 2009, Henning Thielemann wrote: > I think I now have general Applicative functionality ... I hope the following is a proper Monad implementation. In contrast to Applicative a Writer for sequencing actions does no longer work, instead I need a State monad. newtype LazyIO a = LazyIO {runLazyIO :: StateT RunAll IO a} data RunAll = RunAll deriving Show instance Monad LazyIO where return x = LazyIO $ return x x >>= f = LazyIO $ mapStateT unsafeInterleaveIO . runLazyIO . f =<< mapStateT unsafeInterleaveIO (runLazyIO x) instance MonadIO LazyIO where liftIO m = LazyIO $ StateT $ \RunAll -> fmap (\x->(x,RunAll)) m evalLazyIO :: LazyIO a -> IO a evalLazyIO = flip evalStateT RunAll . runLazyIO I'll write some tests and upload it to Hackage. Thank you for being a patient audience. ;-) From lambda-belka at yandex.ru Sun Jan 4 14:59:38 2009 From: lambda-belka at yandex.ru (Belka) Date: Sun Jan 4 14:51:19 2009 Subject: [Haskell-cafe] Haskell, successing crossplatform API standart: first feedback In-Reply-To: <5CDE013B-1F09-48A9-8946-93959E911E52@gmail.com> References: <20742743.post@talk.nabble.com> <5CDE013B-1F09-48A9-8946-93959E911E52@gmail.com> Message-ID: <21280480.post@talk.nabble.com> Thanks everybody for your responses, they helped a lot. And sorry for my misconcept on JSON. ;] Sterling Clover, Nov 30, 2008: >These days, however, web services seem to be moving towards a RESTful >model with a JSON layer and there are plenty of JSON libraries on >hackage, which you could just throw over the fastCGI bindings. >Alternately you could try JSON over one of the really lightweight >haskell web servers, such as shed [2] or lucu [3]. If you go the >atter route, I'd love to hear how it went. So here is my first feedback. I hope that's something like an introduction to my futher feedbacks. 1. I started with HAppS. But found it lacking some good definitions. Moreover, I'm still a newbie and not yet confident with monads, so when I accidently saw this: "Author's Note: Due to my inexperience with Monads, these explanations are probably lacking. Feel free to improve them." (HAppS tutorial2, sect. 1.1), I felt myself standing on a risky ground, where the risk is to get Monads wronger than wrong. So I decided to check Lucu and return to HAppS later (when I'm "invincible"). 2. I loved Lucu, and feel respect to it's developer. The code is nice and tidy, one can feel good style in it. Looks like Lucu author achieved great technique in Haskell, knew, how to use Monads and laziness in full power. However I still didn't understand some aspects (simply becase of lacking experience). I sucessfully managed to write a helloworld which connected to DB and provided simple WEB interface. 3. I also tried shed httpd, which is the most minimalistic WEB server. This looks like the best start for a newbie, who isn't confident with monads yet. I manager a small comparison of Lucu and Shed responce times - Lucu was 2 times faster for 1 simple query, which returned 5 rows from small DB. Now I'm planning 1. To try some modification of Lucu, so it has a DB connection in it's environment and some basic triggering (providing conditioned actions after WEB interaction process). 2. Implement one simple project on it. Regards, Belka -- View this message in context: http://www.nabble.com/Haskell%2C-successing-crossplatform-API-standart-tp20742743p21280480.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From aslatter at gmail.com Sun Jan 4 15:13:50 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sun Jan 4 15:05:31 2009 Subject: Fwd: [Haskell-cafe] Auto-deriving Control.Exception.Exception In-Reply-To: <694519c50901041213w7dddef92m9553262d34f46b36@mail.gmail.com> References: <7fd61dfa-da14-40fb-86a9-86a23a642eb5@s9g2000prg.googlegroups.com> <694519c50901041213w7dddef92m9553262d34f46b36@mail.gmail.com> Message-ID: <694519c50901041213m7cd61956h93d8628b551e858e@mail.gmail.com> Forwarding response to cafe ---------- Forwarded message ---------- From: Antoine Latter Date: Sun, Jan 4, 2009 at 2:13 PM Subject: Re: [Haskell-cafe] Auto-deriving Control.Exception.Exception To: "eyal.lotem@gmail.com" On Sun, Jan 4, 2009 at 11:50 AM, eyal.lotem@gmail.com wrote: > If this is valid: > > import qualified Control.Exception as Exc > > genericFromException :: Typeable a => Exc.SomeException -> Maybe a > genericFromException (Exc.SomeException e) = cast e > instance Exc.Exception SomeType where fromException = > genericFromException > > then why not have an auto-deriving rule for Exception (fromException = > cast . unSomeException)? If you just say: > instance Exception YourType where and leave the instance body empty, it will use the default definitions of 'fromException' and 'toException', which do the right thing by default. At least, I'm pretty sure that's what happens. The Haddock docs have lost their links to the source code. -Antoine From ketil at malde.org Sun Jan 4 18:31:14 2009 From: ketil at malde.org (Ketil Malde) Date: Sun Jan 4 18:22:34 2009 Subject: [Haskell-cafe] How to check object's identity? In-Reply-To: <808E6D62-9231-48AB-9763-4B5A4BAF6E23@galois.com> (Aaron Tomb's message of "Sun\, 4 Jan 2009 09\:08\:41 -0800") References: <20090103152830.GA22587@aiur> <808E6D62-9231-48AB-9763-4B5A4BAF6E23@galois.com> Message-ID: <87y6xq1we5.fsf@malde.org> Aaron Tomb writes: > As others have explained, the == operator doesn't tell you whether two > values are actually stored at the same location in memory. Nobody yet mentioned that (==) doesn't guarantee *anything* - it's a user defined function. So while it may and should give structural equality, it also may not. -k -- If I haven't seen further, it is by standing in the footprints of giants From bugfact at gmail.com Sun Jan 4 18:37:49 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Sun Jan 4 18:29:30 2009 Subject: [Haskell-cafe] How to check object's identity? In-Reply-To: <20090103152830.GA22587@aiur> References: <20090103152830.GA22587@aiur> Message-ID: Maybe you could use stable names for this: http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-StableName.html "Stable names are a way of performing fast (O(1)), not-quite-exact comparison between objects. Stable names solve the following problem: suppose you want to build a hash table with Haskell objects as keys, but you want to use pointer equality for comparison; maybe because the keys are large and hashing would be slow, or perhaps because the keys are infinite in size. We can't build a hash table using the address of the object as the key, because objects get moved around by the garbage collector, meaning a re-hash would be necessary after every garbage collection." 2009/1/3 Xie Hanjian : > Hi, > > I tried this in ghci: >>Prelude> 1:2:[] == 1:2:[] > True > > Does this mean (:) return the same object on same input, or > (==) is not for identity checking? If the later is true, how > can I check two object is the *same* object? > > Thanks > Jan > > -- > jan=callcc{|jan|jan};jan.call(jan) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From dvogel at intercarve.net Sun Jan 4 20:47:53 2009 From: dvogel at intercarve.net (Drew Vogel) Date: Sun Jan 4 20:39:34 2009 Subject: [Haskell-cafe] Thoughts on Haskell and OOP In-Reply-To: References: Message-ID: <496166C9.9010609@intercarve.net> I saw a blog entry once (sorry, google can't seem to find it now) proposing the idea that OOP really is just language support for CPS (continuation-passing-style). Does anyone have a link to this? Drew Kevin Van Horn wrote: > Haskell has been around in one form or another for nearly two decades > now, yet has never been extended with explicit support for > object-oriented programming. I've been thinking about why this is > so. I've come to the conclusion that Haskell simply doesn't need any > explicit OOP support -- algebraic datatypes, modules, lazy evaluation, > and first-class functions give you everything you need > to do the kinds of things you would use classes and inheritance for in > OO languages. > > To see why this is so, let's think about what OOP is. At the most > basic level we have what some call object-based programming. This > amounts to support for data hiding and abstract data types. Haskell's > module system handles this function quite well, without any need to > introduce a special concept of "class" (in the OO sense) nor private > vs. public class members. > > Object-oriented programming is then object-based programming plus > class hierarchies and inheritance. Why are these useful? > > Properly used, OOP is all about interface inheritance, not > implementation inheritance. (At least in C++, implementation > inheritance -- inheriting the data members and method implementations > of a base class -- usually leads to bad design, and is discouraged by > the experts.) (For those more familiar with Python, "duck typing" is > the analog of interface inheritance for a dynamically-typed > language.) Interface inheritance allows you to write procedures that > operate on the base-class interface, but can be applied to objects of > any type derived from the base class. Can we do this in Haskell? > > Yes, we can. Let's consider the Haskell analog of an immutable C++ > base class: > > struct Base { > virtual ~Base(); > virtual int foo() const; > virtual int bar(int n) const; > }; > > class derived :: public Base { > ... data members ... > public: > derived(T_1 arg1, ..., T_k argk); > ... implementations of the virtual functions ... > }; > > Haskell has no direct analog of object classes and virtual methods, > but you can use lazy evaluation and first-class functions to achieve > the same result: > > data Base = Base { foo :: Int, bar :: Int -> Int } > > derived :: T_1 -> ... -> T_k -> Base > derived a_1 ... a_k = Base { foo = ...; bar = bar } where bar n = ... > > The analog of a mutable C++ base class is a little bit more involved, > but not much. Suppose that we change bar(int) to be a mutating method > in the C++ Base class: > > virtual int bar(int n); > > The Haskell analog then changes to > > data Base = Base { foo :: Int, bar :: Int -> (Int, Base) } > > derived :: T_1 -> ... -> T_k -> Base > derived a_1 ... a_k = Base { foo = ...; bar = bar } where > bar n = (..., (derived a_1' ... a_k')) > > (Here a_1', ..., a_k' are k expressions involving n and a_1, ..., a_k.) > > > What do the rest of you think? Is my analysis correct? > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090104/92599c20/signature.bin From kyagrd at gmail.com Sun Jan 4 22:03:16 2009 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Sun Jan 4 21:55:15 2009 Subject: [Haskell-cafe] Haskell good for parallelism/concurrency on manycore? Message-ID: Dear Haskellers, I just got an inquiry from a research department head of a Korean company seriously considering to adopt functional languages because they heard that functional languages can do good at parallel programming on manycore platforms. They want to know what technologies out there implemented in functional languages, such as Erlang or Haskell, that can help them write more maintainable programs that are better at utilizing parallelism and avoiding bugs related to synchronization. They are also very interested in Cilk, as well as Haskell or Erlang. My first thought is that maybe Cilk would work better for them just because it would not be easy to recruit Erlang or Haskell programmers experienced in network, security, or concurrent/parallel programming. I myself can answer basic inquiries such as what libraries to look for to implenent such and so, but not able to give advice on large scale projects such as unified security solution package. So, it wouldn't be practical form them to launch a project without inviting an Erlang or Haskell expert in their domain as a project manager from overseas, which I don't think they are very willing to do. Are there Haskell consultants or Haskell experts on this subject, who believes that Haskell based approach might work better for them, or Haskell can be useful along with other approaches (e.g. DSL, prototyping, formal modeling of policies)? If so, I would like to recommend them trying contact you, and try my best to help communicating with them, if needed. They know English, of course, but may not be familiar with functional programming orlanguage-oriented programming jargons such as DSLs, oops, I mean language middleware :-) For your information: The company is a network security company whose main products are VPN and firewall appliances and their management software. Their research department is in search of better technologies to implement their future UTM (unified threat management) solutions utilizing the manycore platforms. In Korea, there are some research groups and few companies using OCaml, but almost no Erlang or Haskell communities. This company is preferring local researchers or consultants for advice or consulting, but there's no local group using Haskell seriously, as far as I know, even in research yet. That's why this person contacted me, just because I wrote a small tutorial on Haskell Server Programming while ago. P.S. If you happen to be a local Korean expert on this matter, sorry for my ignorance, and I'd be happy to forward their inquiry to you! -- Ahn, Ki Yung From wren at freegeek.org Sun Jan 4 22:14:21 2009 From: wren at freegeek.org (wren ng thornton) Date: Sun Jan 4 22:06:05 2009 Subject: [Haskell-cafe] [Fwd: Re: ANN: bytestring-trie 0.1.1 (bugfix)] Message-ID: <49617B0D.8010307@freegeek.org> -------- Original Message -------- Message-ID: <496176CF.3090708@freegeek.org> Date: Sun, 04 Jan 2009 21:56:15 -0500 From: wren ng thornton User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: ChrisK Subject: Re: ANN: bytestring-trie 0.1.1 (bugfix) References: <494C8B52.2040209@freegeek.org> <4960303E.8010102@freegeek.org> <4960FDA6.3020708@list.mightyreason.com> In-Reply-To: <4960FDA6.3020708@list.mightyreason.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ChrisK wrote: > Question and suggestion: > > looking at > http://hackage.haskell.org/packages/archive/bytestring-trie/0.1.1/doc/html/src/Data-Trie.html#Trie > > I am questioning your choice of foldr in fromList: > > So fromList forces the whole call chain above to be traversed until it > hits the Empty. For a large input list this will force the whole list > to be allocated before proceeding AND the call chain might overflow the > allowed stack size in ghc. For a large trie (which is a likely use > case) this is a poor situation. > > If you use foldl' then the input list is only forced one element at a > time. A small change to the lambda that insert passes to adjustBy will > retain the same semantics of earlier key wins (which are an especially > good idea in the foldl' case). The reason for foldr is to play nice with build/foldr list fusion. Though you're right that foldl' is often nicer when fusion isn't used. As noted (in the code) both toList and fromList are just quick mockups for now. Have you noticed issues with stack overflows or bad performance? My quick tests don't see any problems: $> cat FromListTest.hs ---------------------------------------------------------------- module Main (main) where import qualified Data.Trie as T import Data.Trie.Convenience (insertIfAbsent) import Data.List (foldl') import qualified Data.ByteString as S import Data.ByteString.Internal (c2w) import Microbench import Control.Exception (evaluate) getList, getList' :: T.KeyString -> Int -> [(T.KeyString, Int)] getList xs n = map (\k -> (k,0)) . S.inits . S.take n $ xs getList' xs n = map (\k -> (k,0)) . S.tails . S.take n $ xs main :: IO () main = do -- 100000 is large enough to trigger Microbench's stop condition, -- and small enough to not lock up the system in trying to create it. xs <- evaluate $ S.replicate 100000 (c2w 'a') microbench "fromListR obverse" (T.null . fromListR . getList xs) microbench "fromListL obverse" (T.null . fromListL . getList xs) microbench "fromListR reverse" (T.null . fromListR . getList' xs) microbench "fromListL reverse" (T.null . fromListL . getList' xs) ---------------------------------------------------------------- $> ghc --make -O2 FromListTest.hs [1 of 5] Compiling Data.Trie.ByteStringInternal ( Data/Trie/ByteStringInternal.hs, Data/Trie/ByteStringInternal.o ) [2 of 5] Compiling Data.Trie.BitTwiddle ( Data/Trie/BitTwiddle.hs, Data/Trie/BitTwiddle.o ) [3 of 5] Compiling Data.Trie ( Data/Trie.hs, Data/Trie.o ) [4 of 5] Compiling Data.Trie.Convenience ( Data/Trie/Convenience.hs, Data/Trie/Convenience.o ) [5 of 5] Compiling Main ( FromListTest.hs, FromListTest.o ) Linking FromListTest ... $> ./FromListTest * fromListR obverse: ............... 75.664ns per iteration / 13216.30 per second. * fromListL obverse: ............. 283.380ns per iteration / 3528.84 per second. * fromListR reverse: ............. 630.597ns per iteration / 1585.80 per second. * fromListL reverse: ............... 74.894ns per iteration / 13352.28 per second. Don't mind the 4x speed difference, it's an artifact of the order of the keys being inserted (the cost of splitting an arc vs appending to it). *Main> let run f l n = T.null . f . l (S.replicate n (c2w 'a')) $ n *Main> *Main> run fromListR getList 10 (0.00 secs, 0 bytes) *Main> run fromListR getList 100 (0.00 secs, 0 bytes) *Main> run fromListR getList 1000 (0.01 secs, 599116 bytes) *Main> run fromListR getList 10000 (0.47 secs, 5198576 bytes) *Main> run fromListR getList 100000 (45.36 secs, 51067440 bytes) *Main> *Main> run fromListL getList 10 (0.00 secs, 0 bytes) *Main> run fromListL getList 100 (0.00 secs, 1063168 bytes) *Main> run fromListL getList 1000 (0.06 secs, 74587280 bytes) *Main> run fromListL getList 10000 (10.62 secs, 7438453480 bytes) *Main> run fromListL getList 100000 Interrupted. *Main> *Main> run fromListR getList' 10 (0.00 secs, 0 bytes) *Main> run fromListR getList' 100 (0.00 secs, 1063196 bytes) *Main> run fromListR getList' 1000 (0.09 secs, 74587208 bytes) *Main> run fromListR getList' 10000 (18.19 secs, 7438854556 bytes) *Main> run fromListR getList' 100000 Interrupted. *Main> *Main> run fromListL getList' 10 (0.00 secs, 0 bytes) *Main> run fromListL getList' 100 (0.00 secs, 0 bytes) *Main> run fromListL getList' 1000 (0.01 secs, 533072 bytes) *Main> run fromListL getList' 10000 (0.46 secs, 3791240 bytes) *Main> run fromListL getList' 100000 (44.71 secs, 38515056 bytes) Both options seem about the same to me. The foldl' version is somewhat better in the worst case key ordering (though it changes which ordering that is). I could offer both as alternatives, but I think it'd be better to work on a version that is less succeptable to variation for the order of keys. -- Live well, ~wren -- Live well, ~wren From derek.a.elkins at gmail.com Sun Jan 4 22:25:57 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sun Jan 4 22:17:42 2009 Subject: [Haskell-cafe] Thoughts on Haskell and OOP In-Reply-To: <496166C9.9010609@intercarve.net> References: <496166C9.9010609@intercarve.net> Message-ID: <1231125957.5973.13.camel@derek-laptop> On Sun, 2009-01-04 at 19:47 -0600, Drew Vogel wrote: > I saw a blog entry once (sorry, google can't seem to find it now) > proposing the idea that OOP really is just language support for CPS > (continuation-passing-style). Does anyone have a link to this? 'don't think I've heard of it, but it sounds like it should be given as much shrift as most blog articles, which is to say none at all. I can imagine something about using the duality between FP and OOP and using type negation (which is related to CPS) to witness this, but from that perspective FP is just as much "just language support for CPS," a non-sensical phrase. "Language support for continuations" does of course make sense but doesn't describe many languages, OO or otherwise. From barsoap at web.de Sun Jan 4 23:39:28 2009 From: barsoap at web.de (Achim Schneider) Date: Sun Jan 4 23:31:24 2009 Subject: [Haskell-cafe] Re: How to check object's identity? References: <20090103152830.GA22587@aiur> <7ca3f0160901031746l45bd9455x7f5da575cb1c50f1@mail.gmail.com> <20090104041105.GA31082@aiur> <2518b95d0901040019s78d963c5gea2a13e200955d40@mail.gmail.com> <20090104101211.GA9294@cs.helsinki.fi> Message-ID: <20090105053928.6f02f262@solaris> Lauri Alanko wrote: > Personally, I find the idea appealing (and have implemented the Refs > in the paper with IORefs and unsafePerformIO), because really, even > currently a programmer has to care about sharing since it can have > radical implications for performance and memory usage. Making it > observable in the program would just mean acknowledging the fact that > in real-world programming, you can't _really_ replace a variable with > its definition without changing its behavior in important ways. > +1 realism. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From barsoap at web.de Mon Jan 5 00:57:15 2009 From: barsoap at web.de (Achim Schneider) Date: Mon Jan 5 00:49:08 2009 Subject: [Haskell-cafe] Re: #haskell IRC channel reaches 600 users References: <20090102202724.GA3953@scytale.galois.com> <10ed1a750901021601k161ac032w1c4c3b91f7b43b8a@mail.gmail.com> Message-ID: <20090105065715.027daca0@solaris> "Jamie Brandon" wrote: > The haskell community has a well deserved reputation for being one of > the friendliest online communities. Perhaps this would be a good point > to figure out what we're doing right? I'm convinced that part of it is > that offtopic conversation is encouraged through on haskell-cafe, > planet haskell and irc. It makes people seem more human and hence > harder to flame. > Well... if you believe what's written in the Cathedral and the Bazaar (which I tend to in this case), which is that the main difference between academic culture and hacker culture lies in the tabooisation/encouragement of personal critique (aka flame, cf. rant), then stuff might be easy to explain. The flame-taboo in hacker culture doesn't actually prevent flames to appear, albeit they are partly hidden and much less prone to escalation than in say alt.politics. The valve tends go get opened only iff you really, really know that you're right and the flamed one doesn't have a chance to fight back with equal force without appearing even more like a fool. Such flames aren't addressed exactly because of the taboo and the respect peers have for the flamer _as a hacker_, not necessarily as a flamer. In academics, OTOH, were asbestos and flame throwers are compulsory, people with highly sophisticated skills in both technical topics and mental warfare are bred. The Haskell community, as I observe it, is a melting pot of both cultures. If now Joe Random Hacker is confronted with a question like "XYZ complains about missing sources, but I have the XYZ package installed", the response won't be "Install a sufficiently leet distro like gentoo or, that failing, install XYZ-dev" (at least without a smiley) because J.R.H. fears to be ripped apart by talk of "co-dependent isomorphic congruency vectors" or something of that ilk... the worst thing being, all that stuff might actually make sense, if you could only understood it. OTOH, academics tend to know that even if you have published n award-winning papers in n+k papers and given n^k talks about them (and have no critics whatsoever, for noone understands what you're talking about), no hacker will even consider to start to respect you if you can't follow up on every one of them with honest-to-model-m, applicable working code. That is, both cultures have their own, diametrically opposite, definitions of bogosity. Nobody wants to appear as bogosity's reincarnation, so everybody shuts up and is nice to each other (except in jest, or, of course, for the hell of it). Does that make sense? /me wonders whether this post is a rant or academics-flame -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From barsoap at web.de Mon Jan 5 01:27:13 2009 From: barsoap at web.de (Achim Schneider) Date: Mon Jan 5 01:19:00 2009 Subject: [Haskell-cafe] Re: #haskell IRC channel reaches 600 users References: <20090102202724.GA3953@scytale.galois.com> <10ed1a750901021601k161ac032w1c4c3b91f7b43b8a@mail.gmail.com> <20090105065715.027daca0@solaris> Message-ID: <20090105072713.0ba09b0c@solaris> Achim Schneider wrote: > [...] > Hmmm... I seem to have left out the academics definition of bogosity. I bet that others are much more qualified to elaborate on this, but my working assumption has been (and still is) that it does include a wide range of working code, and excludes a lot of abstract nonsense. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From mjm2002 at gmail.com Mon Jan 5 02:23:10 2009 From: mjm2002 at gmail.com (Matt Morrow) Date: Mon Jan 5 02:14:49 2009 Subject: [Haskell-cafe] Type Family Relations Message-ID: <1638d5210901042323p31866fd5h869ddbc9a398d496@mail.gmail.com> Hi, > I think that > >>> class HeaderOf addr hdr | addr -> hdr > does not enforce that there must be a corresponding instance > AddressOf hdr addr. Hence, the type checker cannot use that information > either. Do you have a way to remedy that? I've often wanted something similar, and experimenting with this the following two options seem to be equivalent and work as desired: ----------------------------------------------------------------------------- -- both options share this code: -- | The crucial assertion ipv4 :: AddrHdrPair IPv4 IPv4Header ipv4 = AddrHdrPair data IPv4Header = C1 data IPv4 = C2 data AppAddress = C3 data AppHeader = C4 ----------------------------------------------------------------------------- -- OPTION(1): -- type families + GADT with equality constraints type family HeaderOf addr type family AddressOf hdr data AddrHdrPair hdr addr where AddrHdrPair :: (hdr ~ HeaderOf addr ,addr ~ AddressOf hdr) => AddrHdrPair addr hdr type instance HeaderOf IPv4 = IPv4Header type instance AddressOf IPv4Header = IPv4 ----------------------------------------------------------------------------- -- OPTION(2): -- classes + GADT with instance constraints class HeaderOf addr hdr | addr -> hdr class AddressOf hdr addr | addr -> hdr data AddrHdrPair hdr addr where AddrHdrPair :: (HeaderOf addr hdr ,AddressOf hdr addr) => AddrHdrPair addr hdr instance AddressOf IPv4Header IPv4 instance HeaderOf IPv4 IPv4Header ----------------------------------------------------------------------------- -- And commenting out the above instances in turn -- to verify that everything indeed works, and to -- compare error message content: {- -- type instance HeaderOf IPv4 = IPv4Header Cafe0.hs:9:0: Couldn't match expected type `HeaderOf IPv4' against inferred type `IPv4Header' When generalising the type(s) for `ipv4' Failed, modules loaded: none. -- type instance AddressOf IPv4Header = IPv4 Cafe0.hs:9:0: Couldn't match expected type `AddressOf IPv4Header' against inferred type `IPv4' When generalising the type(s) for `ipv4' Failed, modules loaded: none. -} {- -- instance AddressOf IPv4Header IPv4 Cafe0.hs:9:7: No instance for (AddressOf IPv4Header IPv4) arising from a use of `AddrHdrPair' at Cafe0.hs:9:7-17 Possible fix: add an instance declaration for (AddressOf IPv4Header IPv4) In the expression: AddrHdrPair In the definition of `ipv4': ipv4 = AddrHdrPair Failed, modules loaded: none. -- instance HeaderOf IPv4 IPv4Header Cafe0.hs:9:7: No instance for (HeaderOf IPv4 IPv4Header) arising from a use of `AddrHdrPair' at Cafe0.hs:9:7-17 Possible fix: add an instance declaration for (HeaderOf IPv4 IPv4Header) In the expression: AddrHdrPair In the definition of `ipv4': ipv4 = AddrHdrPair Failed, modules loaded: none. -} -- endcode ----------------------------------------------------------------------------- I'm not sure if there are any circumstances under which these two don't behave equivalently. All the best, Matt From greenrd at greenrd.org Sat Jan 3 16:39:40 2009 From: greenrd at greenrd.org (Robin Green) Date: Mon Jan 5 02:42:23 2009 Subject: [Haskell-cafe] Re: #haskell IRC channel reaches 600 users In-Reply-To: <20090105072713.0ba09b0c@solaris> References: <20090102202724.GA3953@scytale.galois.com> <10ed1a750901021601k161ac032w1c4c3b91f7b43b8a@mail.gmail.com> <20090105065715.027daca0@solaris> <20090105072713.0ba09b0c@solaris> Message-ID: <20090103213940.0e9316a5@greenrd.org> On Mon, 5 Jan 2009 07:27:13 +0100 Achim Schneider wrote: > Achim Schneider wrote: > > > [...] > > > Hmmm... I seem to have left out the academics definition of bogosity. > I bet that others are much more qualified to elaborate on this, but my > working assumption has been (and still is) that it does include a wide > range of working code, and excludes a lot of abstract nonsense. Well, as someone who has done research in at least 4 different subfields of computer science, I'd say it depends on which subfield you are in. Academics in Human Computer Interaction might criticise a project for having a badly-designed user interface that is hard to use; academics in formal methods might criticise code for not having a specification anywhere of what it does or how it is supposed to handle erroneous inputs; academics working on aspect-oriented software development might criticise code for "tangling" too many concerns unnecessarily in one function. Whereas, each of these academics might be oblivious (or almost oblivious) to the other two critiques. -- Robin From barsoap at web.de Mon Jan 5 04:27:22 2009 From: barsoap at web.de (Achim Schneider) Date: Mon Jan 5 04:19:10 2009 Subject: [Haskell-cafe] Re: #haskell IRC channel reaches 600 users References: <20090102202724.GA3953@scytale.galois.com> <10ed1a750901021601k161ac032w1c4c3b91f7b43b8a@mail.gmail.com> <20090105065715.027daca0@solaris> <20090105072713.0ba09b0c@solaris> <20090103213940.0e9316a5@greenrd.org> Message-ID: <20090105102722.42d94051@solaris> Robin Green wrote: > Whereas, each of these academics might be oblivious (or almost > oblivious) to the other two critiques. > And a load full of arguments why those other critiques are irrelevant? ;) -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From gour at mail.inet.hr Mon Jan 5 04:34:02 2009 From: gour at mail.inet.hr (Gour) Date: Mon Jan 5 04:25:40 2009 Subject: [Haskell-cafe] Re: Haskell good for parallelism/concurrency on manycore? References: Message-ID: <871vvigkqd.fsf@nitai.hr> >>>>> "Ahn" == Ahn, Ki Yung writes: Ahn> P.S. If you happen to be a local Korean expert on this matter, Ahn> sorry for my ignorance, and I'd be happy to forward their inquiry Ahn> to you! Probably not Korea-based, but 1st class Haskell hackers: http://www.well-typed.com/ Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090105/4750c442/attachment.bin From mjm2002 at gmail.com Mon Jan 5 05:09:18 2009 From: mjm2002 at gmail.com (Matt Morrow) Date: Mon Jan 5 05:00:57 2009 Subject: [Haskell-cafe] Type Family Relations In-Reply-To: <1638d5210901042323p31866fd5h869ddbc9a398d496@mail.gmail.com> References: <1638d5210901042323p31866fd5h869ddbc9a398d496@mail.gmail.com> Message-ID: <1638d5210901050209n5acdce6fl33eba297871ab14e@mail.gmail.com> Generalizing the previous post, with: ----------------------------------------------------------------------------- {-# LANGUAGE GADTs #-} module Equ where data a:==:b where Equ :: (a ~ b) => a:==:b symm :: (a:==:a) symm = Equ refl :: (a:==:b) -> (b:==:a) refl Equ = Equ trans :: (a:==:b) -> (b:==:c) -> (a:==:c) trans Equ Equ = Equ cast :: (a:==:b) -> (a -> b) cast Equ = id ----------------------------------------------------------------------------- We can do (e.g.): > data IPv4Header = C1 > data IPv4 = C2 > type instance HeaderOf IPv4 = IPv4Header > type instance AddressOf IPv4Header = IPv4 t0 :: IPv4 :==: AddressOf IPv4Header t0 = Equ t1 :: IPv4Header :==: HeaderOf IPv4 t1 = Equ t2 :: IPv4 :==: AddressOf (HeaderOf IPv4) t2 = Equ t3 :: IPv4Header :==: HeaderOf (AddressOf IPv4Header) t3 = Equ -- And interestingly `t6' shows that the type family option -- in the previous case is slightly stronger that the funcdeps -- option, ie the type fams one corresponds to the funcdeps -- addr -> hdr, hdr -> addr (instead of the weaker addr -> hdr). -- If this isn't desired I'd bet there's a way to modify the type -- instances to get the desired behavior. t5 :: AddrHdrPair a b -> a :==: AddressOf (HeaderOf a) t5 AddrHdrPair = Equ t6 :: AddrHdrPair a b -> b :==: HeaderOf (AddressOf b) t6 AddrHdrPair = Equ Matt From ketil at malde.org Mon Jan 5 06:23:21 2009 From: ketil at malde.org (Ketil Malde) Date: Mon Jan 5 06:14:42 2009 Subject: [Haskell-cafe] Use of abbreviations in Haskell In-Reply-To: <200901032208.55633.ml@isaac.cedarswampstudios.org> (Isaac Dupree's message of "Sat\, 3 Jan 2009 22\:08\:55 -0500") References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> <495E801B.3090409@isaac.cedarswampstudios.org> <87k59c2l1x.fsf@malde.org> <200901032208.55633.ml@isaac.cedarswampstudios.org> Message-ID: <873afy0zfa.fsf@malde.org> Isaac Dupree writes: My proposal: >> A module may be defined in a file with a name corresponding to the >> module name, or any dot-separated prefix of it. I.e. the file >> Foo/Bar.hs will define module Foo.Bar and optionally Foo.Bar.Baz as >> well. > Note though, that local modules tempt us to a couple other things too, even > though they're not necessary to the proposal and would complicate it: > - access-controlled modules (e.g. if other code can't import Foo.Bar.Baz) This has been requested on and off, typically exposing internals for testing purposes. > - relative-path imports / module names (e.g. if in Foo/Bar.hs we make Baz and > try to import it some way with "import Baz") My choice would be to be cavalier about it, and sweep these under the orthogonality carpet :-) I'm not convinced they would complicate things - not a lot, at any rate. If possible the system should be designed so that sub-modules should behave just as if they were defined in files in the appropriate subdirectory. Is it possible? OTOH, a bonus would be that you might avoid the need to bootstrap recursive modules if you put them in the same file? > and as we already mentioned, it would likely involve some implicit importing > of the sub-module. I must have missed this, could you help me with a pointer? > I think my module-search mechanism makes a well-defined, deterministic way to > find the right module Yes. > Implicit importing: submodule syntax implies adding an "import > The.Module.Name" line at that point in the containing file. I'm not sure I agree with that, I don't see why we shouldn't treat these modules as ordinary modules. One of the motivations for doing this is to qualify record labels - not being able to specify "import .. qualified" or "as ..." seems like rather a loss. > This would suggest that submodules must be at the top, among the > imports, because all imports must syntactically be at the beginning > of the file -- and there's a reason for this. Which is? Do we avoid one pass, or what? > so an example could be > > module MyData > ( > module MyData.Sub, -- or equivalently, D(..) > transform > ) > where -- so I would require this as well, import MyData.Sub (transform, D(..)) > module MyData.Sub --or "module Sub" ?? that seems a bit too ad-hoc though > where > data D = E | F > > transform :: D -> D > transform F = E > transform E = F Another example: ------------------------------ module Foo where import qualified Foo.Bar as Bar import Foo.Zot f z = x z -- z = Zot.z, f :: Z -> Float g b = Bar.x b + Bar.y b ... module Foo.Bar where data B = B { x, y :: Int } ... module Foo.Zot where data Z = Z { x :: Float } ... ------------------------------ I'd make an exception for Main, which would count as no top-level module, and thus allow module Main where import ... import Sub ... module Sub where -- not Main.Sub, but possibly FileName.Sub? import ... ... -k -- If I haven't seen further, it is by standing in the footprints of giants From barsoap at web.de Mon Jan 5 06:30:02 2009 From: barsoap at web.de (Achim Schneider) Date: Mon Jan 5 06:21:55 2009 Subject: [Haskell-cafe] Re: Use of abbreviations in Haskell References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> <495E801B.3090409@isaac.cedarswampstudios.org> <87k59c2l1x.fsf@malde.org> <200901032208.55633.ml@isaac.cedarswampstudios.org> <873afy0zfa.fsf@malde.org> Message-ID: <20090105123002.30c0141e@solaris> Ketil Malde wrote: > > Implicit importing: submodule syntax implies adding an "import > > The.Module.Name" line at that point in the containing file. > > I'm not sure I agree with that, I don't see why we shouldn't treat > these modules as ordinary modules. One of the motivations for doing > this is to qualify record labels - not being able to specify "import > .. qualified" or "as ..." seems like rather a loss. import [qualified] module Foo [as F] [hiding(baz)] where bar = undefined baz = bar OTOH, the Ocaml folks are going to ridicule us even more. "Now they redid the module system, and it's still second-class" -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From ketil at malde.org Mon Jan 5 07:02:57 2009 From: ketil at malde.org (Ketil Malde) Date: Mon Jan 5 06:54:22 2009 Subject: [Haskell-cafe] Re: Use of abbreviations in Haskell In-Reply-To: <20090105123002.30c0141e@solaris> (Achim Schneider's message of "Mon\, 5 Jan 2009 12\:30\:02 +0100") References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> <495E801B.3090409@isaac.cedarswampstudios.org> <87k59c2l1x.fsf@malde.org> <200901032208.55633.ml@isaac.cedarswampstudios.org> <873afy0zfa.fsf@malde.org> <20090105123002.30c0141e@solaris> Message-ID: <87y6xqyn7y.fsf@malde.org> Achim Schneider writes: >>> Implicit importing: submodule syntax implies adding an "import >>> The.Module.Name" line at that point in the containing file. >> I'm not sure I agree with that, I don't see why we shouldn't treat >> these modules as ordinary modules. > import [qualified] module Foo [as F] [hiding(baz)] where > bar = undefined > baz = bar Why do you want the 'where' there? Why not simply treat a file Foo.Bar as a concatenation of module Foo.Bar and optionally modules Foo.Bar.*? > OTOH, the Ocaml folks are going to ridicule us even more. "Now they > redid the module system, and it's still second-class" Well, they would be wrong, wouldn't they? I don't want to "redo" the module system, and in fact, I think my proposal wouldn't change the language at all, merely how the compiler searches for modules. (Which it would be nice if the compilers agreed upon, of course.) -k -- If I haven't seen further, it is by standing in the footprints of giants From barsoap at web.de Mon Jan 5 07:10:06 2009 From: barsoap at web.de (Achim Schneider) Date: Mon Jan 5 07:01:52 2009 Subject: [Haskell-cafe] Re: Use of abbreviations in Haskell References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> <495E801B.3090409@isaac.cedarswampstudios.org> <87k59c2l1x.fsf@malde.org> <200901032208.55633.ml@isaac.cedarswampstudios.org> <873afy0zfa.fsf@malde.org> <20090105123002.30c0141e@solaris> <87y6xqyn7y.fsf@malde.org> Message-ID: <20090105131006.5137db1b@solaris> Ketil Malde wrote: > Achim Schneider writes: > > import [qualified] module Foo [as F] [hiding(baz)] where > > bar = undefined > > baz = bar > > Why do you want the 'where' there? Why not simply treat a file > Foo.Bar as a concatenation of module Foo.Bar and optionally modules > Foo.Bar.*? > Because the module definition syntax is "module Foo[(exports] where"... technically, it's not necessary, but it's nice. > > OTOH, the Ocaml folks are going to ridicule us even more. "Now they > > redid the module system, and it's still second-class" > > Well, they would be wrong, wouldn't they? I don't want to "redo" the > module system, and in fact, I think my proposal wouldn't change the > language at all, merely how the compiler searches for modules. (Which > it would be nice if the compilers agreed upon, of course.) > It's just that inline modules, especially that syntax above, reminded me of Ocaml. It's not far from there to foo = module Foo where bar = undefined import foo -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From barsoap at web.de Mon Jan 5 07:40:34 2009 From: barsoap at web.de (Achim Schneider) Date: Mon Jan 5 07:32:23 2009 Subject: [Haskell-cafe] Re: Use of abbreviations in Haskell References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> <495E801B.3090409@isaac.cedarswampstudios.org> <87k59c2l1x.fsf@malde.org> <200901032208.55633.ml@isaac.cedarswampstudios.org> <873afy0zfa.fsf@malde.org> <20090105123002.30c0141e@solaris> <87y6xqyn7y.fsf@malde.org> <20090105131006.5137db1b@solaris> Message-ID: <20090105134034.77f262ad@solaris> Achim Schneider wrote: > Ketil Malde wrote: > > > Achim Schneider writes: > > > import [qualified] module Foo [as F] [hiding(baz)] where > > > bar = undefined > > > baz = bar > > > > Why do you want the 'where' there? Why not simply treat a file > > Foo.Bar as a concatenation of module Foo.Bar and optionally modules > > Foo.Bar.*? > > > Because the module definition syntax is "module Foo[(exports] > where"... technically, it's not necessary, but it's nice. > Additionally, I don't think concatenation works well here, n-ary trees work better. module Foo where import module Bar where import module Baz where quux = undefined quux' = quux . quux quux'' = quux' . quux' quux''' = quux'' . quux'' would be nice. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From ketil at malde.org Mon Jan 5 07:44:14 2009 From: ketil at malde.org (Ketil Malde) Date: Mon Jan 5 07:36:13 2009 Subject: [Haskell-cafe] Re: Use of abbreviations in Haskell In-Reply-To: <20090105131006.5137db1b@solaris> (Achim Schneider's message of "Mon\, 5 Jan 2009 13\:10\:06 +0100") References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> <495E801B.3090409@isaac.cedarswampstudios.org> <87k59c2l1x.fsf@malde.org> <200901032208.55633.ml@isaac.cedarswampstudios.org> <873afy0zfa.fsf@malde.org> <20090105123002.30c0141e@solaris> <87y6xqyn7y.fsf@malde.org> <20090105131006.5137db1b@solaris> Message-ID: <877i59ylb5.fsf@malde.org> >> Achim Schneider writes: >> > import [qualified] module Foo [as F] [hiding(baz)] where >> > bar = undefined >> > baz = bar >> Why do you want the 'where' there? > Because the module definition syntax is "module Foo[(exports] where"... > technically, it's not necessary, but it's nice. Right - I missed the 'module' and just read it as an import statement. Clearly your proposal here goes beyond mine, what are the advantages? I.e, what's the rationale for syntactical changes instead of >> simply treat[ing] a file Foo.Bar as a concatenation of module >> Foo.Bar and optionally modules Foo.Bar.*? -k -- If I haven't seen further, it is by standing in the footprints of giants From barsoap at web.de Mon Jan 5 07:51:29 2009 From: barsoap at web.de (Achim Schneider) Date: Mon Jan 5 07:43:17 2009 Subject: [Haskell-cafe] Re: Use of abbreviations in Haskell References: <6c0416190901020620i33de0031hc8a8e568f70b97cd@mail.gmail.com> <495E801B.3090409@isaac.cedarswampstudios.org> <87k59c2l1x.fsf@malde.org> <200901032208.55633.ml@isaac.cedarswampstudios.org> <873afy0zfa.fsf@malde.org> <20090105123002.30c0141e@solaris> <87y6xqyn7y.fsf@malde.org> <20090105131006.5137db1b@solaris> <877i59ylb5.fsf@malde.org> Message-ID: <20090105135129.2e896ccd@solaris> Ketil Malde wrote: > > >> Achim Schneider writes: > > >> > import [qualified] module Foo [as F] [hiding(baz)] where > >> > bar = undefined > >> > baz = bar > > >> Why do you want the 'where' there? > > > Because the module definition syntax is "module Foo[(exports] > > where"... technically, it's not necessary, but it's nice. > > Right - I missed the 'module' and just read it as an import > statement. Clearly your proposal here goes beyond mine, what are the > advantages? I.e, what's the rationale for syntactical changes instead > of > module Foo where [...] import Foo just doesn't look elegant to my eyes so I'd like to have it in one statement, that's all. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From bit at mutantlemon.com Mon Jan 5 09:59:02 2009 From: bit at mutantlemon.com (Bit Connor) Date: Mon Jan 5 09:50:40 2009 Subject: [Haskell-cafe] Will GHC finally support epoll in 2009? In-Reply-To: References: <3e62d4360812311142hf32295kda105a971fb01807@mail.gmail.com> Message-ID: <6205bd290901050659h1d4432d0pdf086159746eab52@mail.gmail.com> On Thu, Jan 1, 2009 at 8:32 PM, Bryan O'Sullivan wrote: > On Wed, Dec 31, 2008 at 11:42 AM, Levi Greenspan > wrote: > >> Hence my question - is it likely that GHC will support epoll in 2009? > > Yes. I'm working on a patch at the moment. Awesome! Please post to this list when you have any news or updates. Thanks, Bit From briqueabraque at yahoo.com Mon Jan 5 12:01:47 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Mon Jan 5 11:53:59 2009 Subject: [Haskell-cafe] Inferno and Haskell? Message-ID: Hi, Do you guys know the Inferno platform? en.wikipedia.org/wiki/Inferno_(operating_system) Wouldn't it be a nice place to run GHC? All written in a type safe language (what kind of safety I'm not smart enough to say), seems to have a much simpler design than regular unix, virtual machine runs everywhere and, from my non-expert point of view, probably good for embedded software. This is, however, one of those I-have-no-idea-on- how-much-effort-is-needed-and-have-no-knowledge-to- help questions... Sorry for that. Best, Maur?cio From bugfact at gmail.com Mon Jan 5 12:09:40 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Mon Jan 5 12:01:19 2009 Subject: [Haskell-cafe] Is Arrow based FRP a subset of Classic FRP, at least conceptually/semantically? Message-ID: Classic FRP ("CFRP", like Fran, FAL, Reactive, Grapefruit?...) exposes signals as first class values. Arrow based FRP ("AFRP", like Fruit, Yampa...) hides signals as first class values; instead the signal transformers are the first class values. Can I conclude that it would theoretically be possible to translate an AFRP function into a CFRP function? I.e. is AFRP a subset of CFRP? Thanks, Peter From vigalchin at gmail.com Mon Jan 5 13:11:02 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Mon Jan 5 13:02:41 2009 Subject: [Haskell-cafe] nested function application question Message-ID: <5ae4f2ba0901051011j3cafe980u93045364fd01987f@mail.gmail.com> Hello, I have the following: B.intercalate $ B.intercalate ByteString [ByteString] [ByteString] I get a type error with this. If I comment out the 2nd B.intercalate and the third parameter I get no type errors. Regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090105/6b329628/attachment.htm From max.rabkin at gmail.com Mon Jan 5 13:13:41 2009 From: max.rabkin at gmail.com (Max Rabkin) Date: Mon Jan 5 13:05:40 2009 Subject: [Haskell-cafe] nested function application question In-Reply-To: <5ae4f2ba0901051011j3cafe980u93045364fd01987f@mail.gmail.com> References: <5ae4f2ba0901051011j3cafe980u93045364fd01987f@mail.gmail.com> Message-ID: 2009/1/5 Galchin, Vasili : > Hello, > > I have the following: > > B.intercalate $ B.intercalate > ByteString > [ByteString] > [ByteString] > > I get a type error with this. If I comment out the 2nd B.intercalate > and the third parameter I get no type errors. B.intercalate needs a ByteString and a list of ByteStrings. Two B.intercalates need two ByteStrings and two lists of ByteStrings. --Max From vigalchin at gmail.com Mon Jan 5 13:17:18 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Mon Jan 5 13:08:57 2009 Subject: [Haskell-cafe] nested function application question In-Reply-To: References: <5ae4f2ba0901051011j3cafe980u93045364fd01987f@mail.gmail.com> Message-ID: <5ae4f2ba0901051017l44505fa1ga9f31d0d3c1e6a0a@mail.gmail.com> Hi Max, That is what should happen .... The inner B.intercalate will produce the ByteString to be used by the B.intercalate. ?? Vasili On Mon, Jan 5, 2009 at 12:13 PM, Max Rabkin wrote: > 2009/1/5 Galchin, Vasili : > > Hello, > > > > I have the following: > > > > B.intercalate $ B.intercalate > > ByteString > > [ByteString] > > [ByteString] > > > > I get a type error with this. If I comment out the 2nd > B.intercalate > > and the third parameter I get no type errors. > > B.intercalate needs a ByteString and a list of ByteStrings. Two > B.intercalates need two ByteStrings and two lists of ByteStrings. > > --Max > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090105/61a6c498/attachment.htm From rmm-haskell at z.odi.ac Mon Jan 5 13:18:03 2009 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Mon Jan 5 13:09:45 2009 Subject: [Haskell-cafe] nested function application question In-Reply-To: <5ae4f2ba0901051017l44505fa1ga9f31d0d3c1e6a0a@mail.gmail.com> References: <5ae4f2ba0901051011j3cafe980u93045364fd01987f@mail.gmail.com> <5ae4f2ba0901051017l44505fa1ga9f31d0d3c1e6a0a@mail.gmail.com> Message-ID: <6012ECCA-910E-43AB-90C5-D46EAD020E72@z.odi.ac> Did you mean: B.intercalate (B.intercalate ByteString [ByteString]) [ByteString] ($) applies all the way to the right, so you were giving the inner intercalate two lists of ByteString. -Ross On Jan 5, 2009, at 1:17 PM, Galchin, Vasili wrote: > Hi Max, > > That is what should happen .... The inner B.intercalate will > produce the ByteString to be used by the B.intercalate. ?? > > Vasili > > On Mon, Jan 5, 2009 at 12:13 PM, Max Rabkin > wrote: > 2009/1/5 Galchin, Vasili : > > Hello, > > > > I have the following: > > > > B.intercalate $ B.intercalate > > ByteString > > [ByteString] > > [ByteString] > > > > I get a type error with this. If I comment out the 2nd > B.intercalate > > and the third parameter I get no type errors. > > B.intercalate needs a ByteString and a list of ByteStrings. Two > B.intercalates need two ByteStrings and two lists of ByteStrings. > > --Max > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090105/ae6d2385/attachment.htm From max.rabkin at gmail.com Mon Jan 5 13:19:34 2009 From: max.rabkin at gmail.com (Max Rabkin) Date: Mon Jan 5 13:11:39 2009 Subject: [Haskell-cafe] nested function application question In-Reply-To: <5ae4f2ba0901051017l44505fa1ga9f31d0d3c1e6a0a@mail.gmail.com> References: <5ae4f2ba0901051011j3cafe980u93045364fd01987f@mail.gmail.com> <5ae4f2ba0901051017l44505fa1ga9f31d0d3c1e6a0a@mail.gmail.com> Message-ID: On Mon, Jan 5, 2009 at 10:17 AM, Galchin, Vasili wrote: > Hi Max, > > That is what should happen .... The inner B.intercalate will produce > the ByteString to be used by the B.intercalate. ?? > > Vasili > Of course. My mistake. Ross Mellgren seems to be on the money though. --Max From vigalchin at gmail.com Mon Jan 5 13:23:52 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Mon Jan 5 13:15:31 2009 Subject: [Haskell-cafe] nested function application question In-Reply-To: <6012ECCA-910E-43AB-90C5-D46EAD020E72@z.odi.ac> References: <5ae4f2ba0901051011j3cafe980u93045364fd01987f@mail.gmail.com> <5ae4f2ba0901051017l44505fa1ga9f31d0d3c1e6a0a@mail.gmail.com> <6012ECCA-910E-43AB-90C5-D46EAD020E72@z.odi.ac> Message-ID: <5ae4f2ba0901051023m5de26cc7hf9a86719e2449456@mail.gmail.com> yep ... that is exactly what I meant!! so can I use more $'s or must I use parens (as you did) to disambiguate? Vasili On Mon, Jan 5, 2009 at 12:18 PM, Ross Mellgren wrote: > Did you mean: > B.intercalate (B.intercalate ByteString [ByteString]) [ByteString] > > ($) applies all the way to the right, so you were giving the inner > intercalate two lists of ByteString. > > -Ross > > > On Jan 5, 2009, at 1:17 PM, Galchin, Vasili wrote: > > Hi Max, > > That is what should happen .... The inner B.intercalate will produce > the ByteString to be used by the B.intercalate. ?? > > Vasili > > On Mon, Jan 5, 2009 at 12:13 PM, Max Rabkin wrote: > >> 2009/1/5 Galchin, Vasili : >> > Hello, >> > >> > I have the following: >> > >> > B.intercalate $ B.intercalate >> > ByteString >> > [ByteString] >> > [ByteString] >> > >> > I get a type error with this. If I comment out the 2nd >> B.intercalate >> > and the third parameter I get no type errors. >> >> B.intercalate needs a ByteString and a list of ByteStrings. Two >> B.intercalates need two ByteStrings and two lists of ByteStrings. >> >> --Max >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090105/d844b87b/attachment.htm From rmm-haskell at z.odi.ac Mon Jan 5 13:29:10 2009 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Mon Jan 5 13:20:51 2009 Subject: [Haskell-cafe] nested function application question In-Reply-To: <5ae4f2ba0901051023m5de26cc7hf9a86719e2449456@mail.gmail.com> References: <5ae4f2ba0901051011j3cafe980u93045364fd01987f@mail.gmail.com> <5ae4f2ba0901051017l44505fa1ga9f31d0d3c1e6a0a@mail.gmail.com> <6012ECCA-910E-43AB-90C5-D46EAD020E72@z.odi.ac> <5ae4f2ba0901051023m5de26cc7hf9a86719e2449456@mail.gmail.com> Message-ID: <4E93EE18-C687-4BA8-B094-893F8E21A395@z.odi.ac> In this case you have to use parens -- two dollar signs, like this B.intercalate $ B.intercalate ByteString [ByteString] $ [ByteString] would also not type check -- it is exactly equivalent to your first example: B.intercalate (B.intercalate ByteString [ByteString] ([ByteString])) just with one level of extra parentheses. If for some reason you absolutely need to avoid parentheses (mostly as a thought exercise, I guess), you'd have to have a flipped version of intercalate: flippedIntercalate :: [ByteString] -> ByteString -> ByteString flippedIntercalate = flip B.intercalate flippedIntercalate [ByteString] $ B.intercalate ByteString [ByteString] of course, this is pretty contrived. -Ross On Jan 5, 2009, at 1:23 PM, Galchin, Vasili wrote: > yep ... that is exactly what I meant!! so can I use more $'s or must > I use parens (as you did) to disambiguate? > > Vasili > > On Mon, Jan 5, 2009 at 12:18 PM, Ross Mellgren haskell@z.odi.ac> wrote: > Did you mean: > > B.intercalate (B.intercalate ByteString [ByteString]) [ByteString] > > ($) applies all the way to the right, so you were giving the inner > intercalate two lists of ByteString. > > -Ross > > > On Jan 5, 2009, at 1:17 PM, Galchin, Vasili wrote: > >> Hi Max, >> >> That is what should happen .... The inner B.intercalate will >> produce the ByteString to be used by the B.intercalate. ?? >> >> Vasili >> >> On Mon, Jan 5, 2009 at 12:13 PM, Max Rabkin >> wrote: >> 2009/1/5 Galchin, Vasili : >> > Hello, >> > >> > I have the following: >> > >> > B.intercalate $ B.intercalate >> > ByteString >> > [ByteString] >> > [ByteString] >> > >> > I get a type error with this. If I comment out the 2nd >> B.intercalate >> > and the third parameter I get no type errors. >> >> B.intercalate needs a ByteString and a list of ByteStrings. Two >> B.intercalates need two ByteStrings and two lists of ByteStrings. >> >> --Max >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090105/585d8af9/attachment-0001.htm From dave at zednenem.com Mon Jan 5 13:57:45 2009 From: dave at zednenem.com (David Menendez) Date: Mon Jan 5 13:49:24 2009 Subject: [Haskell-cafe] nested function application question In-Reply-To: <4E93EE18-C687-4BA8-B094-893F8E21A395@z.odi.ac> References: <5ae4f2ba0901051011j3cafe980u93045364fd01987f@mail.gmail.com> <5ae4f2ba0901051017l44505fa1ga9f31d0d3c1e6a0a@mail.gmail.com> <6012ECCA-910E-43AB-90C5-D46EAD020E72@z.odi.ac> <5ae4f2ba0901051023m5de26cc7hf9a86719e2449456@mail.gmail.com> <4E93EE18-C687-4BA8-B094-893F8E21A395@z.odi.ac> Message-ID: <49a77b7a0901051057v7e261ac1l1aa3923d149aad95@mail.gmail.com> 2009/1/5 Ross Mellgren : > If for some reason you absolutely need to avoid parentheses (mostly as a > thought exercise, I guess), you'd have to have a flipped version of > intercalate: Or a version of ($) that associates differently. infixl 0 $$ f $$ x = f x *Main Data.ByteString> :t \x y z -> intercalate $$ intercalate x y $$ z \x y z -> intercalate $$ intercalate x y $$ z :: ByteString -> [ByteString] -> [ByteString] -> ByteString -- Dave Menendez From vigalchin at gmail.com Mon Jan 5 13:59:29 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Mon Jan 5 13:51:06 2009 Subject: [Haskell-cafe] nested function application question In-Reply-To: <49a77b7a0901051057v7e261ac1l1aa3923d149aad95@mail.gmail.com> References: <5ae4f2ba0901051011j3cafe980u93045364fd01987f@mail.gmail.com> <5ae4f2ba0901051017l44505fa1ga9f31d0d3c1e6a0a@mail.gmail.com> <6012ECCA-910E-43AB-90C5-D46EAD020E72@z.odi.ac> <5ae4f2ba0901051023m5de26cc7hf9a86719e2449456@mail.gmail.com> <4E93EE18-C687-4BA8-B094-893F8E21A395@z.odi.ac> <49a77b7a0901051057v7e261ac1l1aa3923d149aad95@mail.gmail.com> Message-ID: <5ae4f2ba0901051059h71ea048cge207a438915bd625@mail.gmail.com> Thank you everybody! Vasili On Mon, Jan 5, 2009 at 12:57 PM, David Menendez wrote: > 2009/1/5 Ross Mellgren : > > If for some reason you absolutely need to avoid parentheses (mostly as a > > thought exercise, I guess), you'd have to have a flipped version of > > intercalate: > > Or a version of ($) that associates differently. > > infixl 0 $$ > > f $$ x = f x > > *Main Data.ByteString> :t \x y z -> intercalate $$ intercalate x y $$ z > \x y z -> intercalate $$ intercalate x y $$ z :: ByteString > -> [ByteString] > -> [ByteString] > -> ByteString > > > -- > Dave Menendez > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090105/79a25913/attachment.htm From lrpalmer at gmail.com Mon Jan 5 14:14:46 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Jan 5 14:06:25 2009 Subject: [Haskell-cafe] Is Arrow based FRP a subset of Classic FRP, at least conceptually/semantically? In-Reply-To: References: Message-ID: <7ca3f0160901051114r6eb4f42j67ce6892e5c881bb@mail.gmail.com> On Mon, Jan 5, 2009 at 10:09 AM, Peter Verswyvelen wrote: > Classic FRP ("CFRP", like Fran, FAL, Reactive, Grapefruit?...) > exposes signals as first class values. > > Arrow based FRP ("AFRP", like Fruit, Yampa...) hides signals as first > class values; instead the signal transformers are the first class > values. > > Can I conclude that it would theoretically be possible to translate an > AFRP function into a CFRP function? I.e. is AFRP a subset of CFRP? Why don't you check yourself? AFRP, if I recall correctly, has Arrow and ArrowLoop. So the combinators we need follow: Using a ~> b as shorthand for Behavior a -> Behavior b. -- From Arrow arr :: (a -> b) -> (a ~> b) first :: (a ~> b) -> ((a,c) ~> (b,c)) (>>>) :: (a ~> b) -> (b ~> c) -> (a ~> c) arr = fmap first f ac = liftA2 (,) (f (fst <$> ac)) (snd <$> ac) (>>>) = (>>>) -- From ArrowLoop loop :: ((a,c) ~> (b,c)) -> (a ~> b) loop f a = let bc = f (liftA2 (,) a (snd <$> bc)) in fst <$> bc So that's a positive on all the arrow combinators. You have to check the supplied primitives, too, such as integral and pswitch. Once you do that, you could even implement a ClassicFRP arrow and use that instead of the Yampa arrow, so the client code wouldn't need to be changed at all. What I have just described is the ideal situation. Here are some of the practicalities you might run into: * AFRP models events as signals of Maybe. Semantically speaking, signals of Maybe don't have nice eventy properties, such as discrete occurrences, so you might have some difficulty translating between the two. I'm currently exploring an arrow model that accounts for events properly, but that probably doesn't help you. * The above "loop" combinator is key to eliminating quadratic behavior in certain classic FRP situations, and I believe the reason arrows were explored to begin with. See "Plugging a Space Leak with an Arrow" by Hudak and Liu[1] for more. In Fran-like systems, there is another fix for this leak, in exchange for loss of perfect reactivity (making a "discrete memo table" of sorts). [1] www.cs.yale.edu/~hl293/download/*leak*.pdf > > Thanks, > Peter > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090105/0ae93f9e/attachment.htm From allbery at ece.cmu.edu Mon Jan 5 15:16:02 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Jan 5 15:07:57 2009 Subject: [Haskell-cafe] nested function application question In-Reply-To: <49a77b7a0901051057v7e261ac1l1aa3923d149aad95@mail.gmail.com> References: <5ae4f2ba0901051011j3cafe980u93045364fd01987f@mail.gmail.com> <5ae4f2ba0901051017l44505fa1ga9f31d0d3c1e6a0a@mail.gmail.com> <6012ECCA-910E-43AB-90C5-D46EAD020E72@z.odi.ac> <5ae4f2ba0901051023m5de26cc7hf9a86719e2449456@mail.gmail.com> <4E93EE18-C687-4BA8-B094-893F8E21A395@z.odi.ac> <49a77b7a0901051057v7e261ac1l1aa3923d149aad95@mail.gmail.com> Message-ID: <3C91D6C3-BC01-4D00-B499-E72093F9563E@ece.cmu.edu> On 2009 Jan 5, at 13:57, David Menendez wrote: > 2009/1/5 Ross Mellgren : >> If for some reason you absolutely need to avoid parentheses (mostly >> as a >> thought exercise, I guess), you'd have to have a flipped version of >> intercalate: > > Or a version of ($) that associates differently. > > infixl 0 $$ > > f $$ x = f x > > *Main Data.ByteString> :t \x y z -> intercalate $$ intercalate x y $ > $ z > \x y z -> intercalate $$ intercalate x y $$ z :: ByteString > -> [ByteString] > -> [ByteString] > -> ByteString ...at which point we're reinventing Applicative, no? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From dave at zednenem.com Mon Jan 5 15:33:02 2009 From: dave at zednenem.com (David Menendez) Date: Mon Jan 5 15:24:39 2009 Subject: [Haskell-cafe] nested function application question In-Reply-To: <3C91D6C3-BC01-4D00-B499-E72093F9563E@ece.cmu.edu> References: <5ae4f2ba0901051011j3cafe980u93045364fd01987f@mail.gmail.com> <5ae4f2ba0901051017l44505fa1ga9f31d0d3c1e6a0a@mail.gmail.com> <6012ECCA-910E-43AB-90C5-D46EAD020E72@z.odi.ac> <5ae4f2ba0901051023m5de26cc7hf9a86719e2449456@mail.gmail.com> <4E93EE18-C687-4BA8-B094-893F8E21A395@z.odi.ac> <49a77b7a0901051057v7e261ac1l1aa3923d149aad95@mail.gmail.com> <3C91D6C3-BC01-4D00-B499-E72093F9563E@ece.cmu.edu> Message-ID: <49a77b7a0901051233qff9df7cib8be6ab270c7b1cd@mail.gmail.com> On Mon, Jan 5, 2009 at 3:16 PM, Brandon S. Allbery KF8NH wrote: > On 2009 Jan 5, at 13:57, David Menendez wrote: >> >> 2009/1/5 Ross Mellgren : >>> >>> If for some reason you absolutely need to avoid parentheses (mostly as a >>> thought exercise, I guess), you'd have to have a flipped version of >>> intercalate: >> >> Or a version of ($) that associates differently. >> >> infixl 0 $$ >> >> f $$ x = f x >> >> *Main Data.ByteString> :t \x y z -> intercalate $$ intercalate x y $$ z >> \x y z -> intercalate $$ intercalate x y $$ z :: ByteString >> -> [ByteString] >> -> [ByteString] >> -> ByteString > > > ...at which point we're reinventing Applicative, no? Is "const" a reinvention of "return"? You could write the above code with (<*>), but you'd need to convert back and forth from Identity in order to get the proper Applicative instance. runIdentity $ Identity B.intercalate <*> Identity (B.intercalate x y) <*> Identity z At that point, you might as well save the noise and write, B.intercalate (B.intercalate x y) z -- Dave Menendez From thaldyron at gmail.com Mon Jan 5 15:48:10 2009 From: thaldyron at gmail.com (Peter Robinson) Date: Mon Jan 5 15:39:48 2009 Subject: [Haskell-cafe] Portability of MonadError Message-ID: Hello, One thing that's been bothering me about MonadError monads is the non-portability of code that uses a custom Error type. Meaning, if I have libraries A and B that use different error types, I won't be able to write a function func: func = (funcA >> funcB) `catchError` (\e -> ...) funcA :: ErrorT MyErrorA m () funcB :: ErrorT MyErrorB m () So I'm wondering whether there's a reason not to introduce a type class hierarchy instead of custom error types to make the code more portable. Something like this: -------------------- import Control.Exception(IOException) import Control.Monad.Error class (Eq e,Show e,Error e) => MyExc e where myExc1 :: e myExc1 = strMsg "myExc1" -- Now we can simply extend MyExc and catch all errors defined in MyExc and -- MyExc2 in the same error-handler (see handler2 below): class MyExc e => MyExc2 e where myExc2 :: e myExc2 = strMsg "myExc2" -- Uses the error class MyExc test1:: (MonadError e m, Monad m, MonadIO m, MyExc e) => m () test1 = do liftIO $ putStrLn "############ Throwing myExc1: " throwError myExc1 `catchError` handler1 -- Uses the error class MyExc2 that extends MyExc test2 :: (MonadError e m,MonadIO m, MyExc2 e) => m () test2 = do liftIO $ putStrLn "\n############ Throwing myExc2: " throwError myExc2 `catchError` handler2 -- Uses the error type class MyExc2 but throws an error -- already defined in MyExc test3 :: (MonadError e m,MonadIO m,MyExc2 e) => m () test3 = do liftIO $ putStrLn "\n############ Throwing myExc1 within context MyExc2: " throwError myExc1 `catchError` handler2 -- Error handler for class MyExc handler1 :: (MonadError e m, MonadIO m,Monad m,MyExc e) => e -> m () handler1 e = do when (e == myExc1) $ liftIO $ putStrLn $ "Caught a MyExc1 " ++ show e -- Error handler for class MyExc2 (catches errors in MyExc1) handler2 :: (MonadError e m, MonadIO m,Monad m,MyExc2 e) => e -> m () handler2 e = do when (e == myExc1) $ do liftIO $ putStrLn $ "Caught a MyExc1 " ++ show e throwError e when (e == myExc2) $ liftIO $ putStrLn $ "Caught a MyExc2 " ++ show e -- To run the code in the IO monad we need: instance MyExc IOException where myExc1 = userError "myExc1 has occurred" instance MyExc2 IOException where myExc2 = userError "myExc2 has occurred" -- Run test1 and test2 in the IO monad mymain :: IO () mymain = (test1 >> test2 >> test3) `catchError` (\e -> putStrLn $ "Something went wrong...\n" ++ show e) -- Now let's try a custom monad: newtype MyMonad e a = MyMonad { runMM :: ErrorT e IO a } deriving(Monad,MonadError e,MonadIO) runMyMonad :: Error e => MyMonad e a -> IO (Either e a) runMyMonad = runErrorT . runMM mymainT :: IO () mymainT = do res <- runMyMonad (test1 >> test2 >> test3 :: MyMonad IOException ()) case res of Left e -> putStrLn $ "Something went wrong...\n" ++ show e _ -> return () ---------------------- Maybe I'm missing something but is there any advantage of using custom data types rather than the typeclass approach? Cheers, Peter PS: Please be frank if I'm reinventing the wheel here... :-) From igloo at earth.li Mon Jan 5 16:09:12 2009 From: igloo at earth.li (Ian Lynagh) Date: Mon Jan 5 16:00:51 2009 Subject: [Haskell-cafe] Trouble with interact in ghci In-Reply-To: <7B724789-0B67-4A49-9BC9-3E0049C2B946@inf.fu-berlin.de> References: <7B724789-0B67-4A49-9BC9-3E0049C2B946@inf.fu-berlin.de> Message-ID: <20090105210912.GA9900@matrix.chaos.earth.li> Hi Adrian On Wed, Dec 17, 2008 at 11:44:14AM +0100, Adrian Neumann wrote: > > I have a strange problem with "interact" on OS X (ghc 6.10.1). It > seems to garble stdin. See the "After using getContents" section of http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci-faq.html Thanks Ian From lrpalmer at gmail.com Mon Jan 5 16:13:32 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Jan 5 16:05:11 2009 Subject: [Haskell-cafe] Portability of MonadError In-Reply-To: References: Message-ID: <7ca3f0160901051313u683b66axd553709dc6cada21@mail.gmail.com> On Mon, Jan 5, 2009 at 1:48 PM, Peter Robinson wrote: > Hello, > > One thing that's been bothering me about MonadError monads is > the non-portability of code that uses a custom Error type. Meaning, if I > have libraries A and B that use different error types, I won't be able to > write a function func: > > func = (funcA >> funcB) `catchError` (\e -> ...) > > funcA :: ErrorT MyErrorA m () > > funcB :: ErrorT MyErrorB m () > > So I'm wondering whether there's a reason not to introduce a type class > hierarchy instead of custom error types to make the code more portable. I think this worry is related to a world view of "large monads", which also proliferates claims like "monads are not appropriate for large programs", and is related to fat interfaces in OOP. I claim that, like objects, monads are appropriate for little pieces of computations, and monadic computations in different monads deserve to be composed just as much so as those in the same monad. The complex type-directed approach gives the feel of exceptions from mainstream languages, but will run into problems when eg. two computations both use ErrorT String, but you want to differentiate the errors. All that is necessary is a simple function: mapError :: (e -> e') -> ErrorT e a -> ErrorT e' a mapError f = ErrorT . liftM (left f) . runErrorT (Where "left" is from Control.Arrow, and is a "semantic editor") Then your example can become:: func = (mapError Left funcA >> mapError Right funcB) `catchError` (\e -> ...) Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090105/4b10a6eb/attachment.htm From lrpalmer at gmail.com Mon Jan 5 16:15:32 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Jan 5 16:07:10 2009 Subject: [Haskell-cafe] Portability of MonadError In-Reply-To: <7ca3f0160901051313u683b66axd553709dc6cada21@mail.gmail.com> References: <7ca3f0160901051313u683b66axd553709dc6cada21@mail.gmail.com> Message-ID: <7ca3f0160901051315s538c9682nd2e707d7833ced6e@mail.gmail.com> On Mon, Jan 5, 2009 at 2:13 PM, Luke Palmer wrote: > On Mon, Jan 5, 2009 at 1:48 PM, Peter Robinson wrote: > >> Hello, >> >> One thing that's been bothering me about MonadError monads is >> the non-portability of code that uses a custom Error type. Meaning, if I >> have libraries A and B that use different error types, I won't be able to >> write a function func: >> >> func = (funcA >> funcB) `catchError` (\e -> ...) >> >> funcA :: ErrorT MyErrorA m () >> >> funcB :: ErrorT MyErrorB m () >> >> So I'm wondering whether there's a reason not to introduce a type class >> hierarchy instead of custom error types to make the code more portable. > > > I think this worry is related to a world view of "large monads", which also > proliferates claims like "monads are not appropriate for large programs", > and is related to fat interfaces in OOP. I claim that, like objects, monads > are appropriate for little pieces of computations, and monadic computations in > different monads deserve to be composed just as much so as those in the > same monad. > > The complex type-directed approach gives the feel of exceptions from > mainstream languages, but will run into problems when eg. two computations > both use ErrorT String, but you want to differentiate the errors. All that > is necessary is a simple function: > > mapError :: (e -> e') -> ErrorT e a -> ErrorT e' a > mapError f = ErrorT . liftM (left f) . runErrorT > Modulo obvious errors, as usual. Haskell type inference knows better than I do: mapError :: Monad m => (e -> e') -> ErrorT e m a -> ErrorT e' m a Luke > (Where "left" is from Control.Arrow, and is a "semantic editor") > > Then your example can become:: > > func = (mapError Left funcA >> mapError Right funcB) `catchError` (\e -> > ...) > > Luke > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090105/1f51a8ab/attachment.htm From westondan at imageworks.com Mon Jan 5 16:34:44 2009 From: westondan at imageworks.com (Dan Weston) Date: Mon Jan 5 16:26:27 2009 Subject: [Haskell-cafe] Infinite grid In-Reply-To: <49595560.3040704@van.steenbergen.nl> References: <49595560.3040704@van.steenbergen.nl> Message-ID: <49627CF4.9010607@imageworks.com> I think I found a solution to this, if you're still looking for one. See attached code. It uses a rose tree zipper where tree depth is manhattan distance from origin and forest width is nodes around concentric diamonds. The code is straightforward. Polar coords (RK) are stored in node label, with conversion to/from cartesian calculated on the fly (but may also be stored in label if speed is more important than time). Cyclic closed loop tests like your f below run in constant space for me. Dan Weston Martijn van Steenbergen wrote: > Hello, > > I would like to construct an infinite two-dimensional grid of nodes, > where a node looks like this: > >> data Node = Node >> { north :: Node >> , east :: Node >> , south :: Node >> , west :: Node >> } > > in such a way that for every node n in the grid it doesn't matter how I > travel to n, I always end up in the same memory location for that node. > > I suspect another way of saying that is that > >> let f = f . north . east . south . west in f origin > > should run in constant space. I hope this makes the problem clear. :-) > > How do I do this? > > Thanks in advance, > > Martijn. -------------- next part -------------- A non-text attachment was scrubbed... Name: GridZipper.hs Type: text/x-haskell Size: 10244 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090105/01fe7b59/GridZipper.bin From thaldyron at gmail.com Mon Jan 5 16:44:29 2009 From: thaldyron at gmail.com (Peter Robinson) Date: Mon Jan 5 16:36:07 2009 Subject: [Haskell-cafe] Portability of MonadError In-Reply-To: <7ca3f0160901051315s538c9682nd2e707d7833ced6e@mail.gmail.com> References: <7ca3f0160901051313u683b66axd553709dc6cada21@mail.gmail.com> <7ca3f0160901051315s538c9682nd2e707d7833ced6e@mail.gmail.com> Message-ID: > On Mon, Jan 5, 2009 at 2:13 PM, Luke Palmer wrote: >> >> On Mon, Jan 5, 2009 at 1:48 PM, Peter Robinson >> wrote: >>> >>> Hello, >>> >>> One thing that's been bothering me about MonadError monads is >>> the non-portability of code that uses a custom Error type. Meaning, if I >>> have libraries A and B that use different error types, I won't be able to >>> write a function func: >>> >>> func = (funcA >> funcB) `catchError` (\e -> ...) >>> >>> funcA :: ErrorT MyErrorA m () >>> >>> funcB :: ErrorT MyErrorB m () >>> >>> So I'm wondering whether there's a reason not to introduce a type class >>> hierarchy instead of custom error types to make the code more portable. >> >> I think this worry is related to a world view of "large monads", which >> also proliferates claims like "monads are not appropriate for large >> programs", and is related to fat interfaces in OOP. I claim that, like >> objects, monads are appropriate for little pieces of computations, and >> monadic computations in different monads deserve to be composed just as much >> so as those in the same monad. Well my main concern was that composability issue of "similar" (modulo error type) monads. >> The complex type-directed approach gives the feel of exceptions from >> mainstream languages, but will run into problems when eg. two computations >> both use ErrorT String, but you want to differentiate the errors. Not sure I got this: When using the type class approach you would not use an instantiation like ErrorT String in code intended to be portable, but rather something like "ErrorT MyClass". Either two computations have the same error type class or they don't, so there shouldn't be any problem differentiating errors, right? >> All that >> is necessary is a simple function: >> mapError :: (e -> e') -> ErrorT e a -> ErrorT e' a >> mapError f = ErrorT . liftM (left f) . runErrorT > > Modulo obvious errors, as usual. Haskell type inference knows better than I > do: > mapError :: Monad m => (e -> e') -> ErrorT e m a -> ErrorT e' m a > Luke >> >> (Where "left" is from Control.Arrow, and is a "semantic editor") >> Then your example can become:: >> func = (mapError Left funcA >> mapError Right funcB) `catchError` (\e -> >> ...) Yes that does look interesting. Thanks for the hint! Peter From lrpalmer at gmail.com Mon Jan 5 16:51:02 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Jan 5 16:42:39 2009 Subject: [Haskell-cafe] Portability of MonadError In-Reply-To: <7ca3f0160901051313u683b66axd553709dc6cada21@mail.gmail.com> References: <7ca3f0160901051313u683b66axd553709dc6cada21@mail.gmail.com> Message-ID: <7ca3f0160901051351w6b3345d7p8602d3b092b94c69@mail.gmail.com> On Mon, Jan 5, 2009 at 2:13 PM, Luke Palmer wrote: > Then your example can become:: > > func = (mapError Left funcA >> mapError Right funcB) `catchError` (\e -> > ...) > > Luke > Oh bother! My new year's resolution: think before I speak. While I do think this is the right answer, it is not the right answer in the status quo. This is because ErrorT e m is only a monad when e is an Error, which Either (and most types) are not. It will be the right answer when fail is factored out of Monad into MonadFail (which will happen someday hopefully), because then the typechecker will verify that the above composition cannot fail. But now I can't think of a good answer. Darn. Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090105/f51842b6/attachment.htm From lemming at henning-thielemann.de Mon Jan 5 16:55:11 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jan 5 16:46:49 2009 Subject: [Haskell-cafe] Portability of MonadError In-Reply-To: <7ca3f0160901051351w6b3345d7p8602d3b092b94c69@mail.gmail.com> References: <7ca3f0160901051313u683b66axd553709dc6cada21@mail.gmail.com> <7ca3f0160901051351w6b3345d7p8602d3b092b94c69@mail.gmail.com> Message-ID: On Mon, 5 Jan 2009, Luke Palmer wrote: > Oh bother! ?My new year's resolution: think before I speak. > > While I do think this is the right answer, it is not the right answer in the status quo. ?This is > because ErrorT e m is only a monad when e is an Error, which Either (and most types) are not. ?It > will be the right answer when fail is factored out of Monad into MonadFail (which will happen > someday hopefully), because then the typechecker will verify that the above composition cannot > fail. > > But now I can't think of a good answer. ?Darn. In the explicit-exception package I omit 'fail' and allow an exception type without constraints. From igloo at earth.li Mon Jan 5 17:18:02 2009 From: igloo at earth.li (Ian Lynagh) Date: Mon Jan 5 17:09:42 2009 Subject: [Haskell-cafe] Re: GHC 6.10.1 for Solaris i86 In-Reply-To: <4947C829.1000408@dfki.de> References: <21bdabea0812111811h6735d02bk1f57986f403723da@mail.gmail.com> <4947C829.1000408@dfki.de> Message-ID: <20090105221802.GA11228@matrix.chaos.earth.li> On Tue, Dec 16, 2008 at 04:24:25PM +0100, Christian Maeder wrote: > Donald Halomoan wrote: > > I am waiting for GHC 6.10. 1 binary for Solaris i86. Thanks. > > You could try mine: > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/ghcs/ghc-6.10.1-i386-unknown-solaris2.tar.bz2 > it needs libedit.so.0 and libncurses.so.5 Thanks Christian - I've added this to the 6.10.1 download page. Thanks Ian From mgross21 at verizon.net Mon Jan 5 18:34:33 2009 From: mgross21 at verizon.net (Murray Gross) Date: Mon Jan 5 18:00:16 2009 Subject: [Haskell-cafe] Maybe a compiler bug? In-Reply-To: References: Message-ID: When using any of -O, -O1, -O2 with the Debian binary build of GHC 6.6, trace shows that the expression if (lr > ll) then False else True is (at least partially) evaluated, but the value returned is always True, even though trace reports that (lr > ll) is True. When I use only the native code generator (without optimization), the correct value (False) is returned. Further detail and complete code on request. Best, Murray Gross From lrpalmer at gmail.com Mon Jan 5 18:56:26 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Jan 5 18:48:04 2009 Subject: [Haskell-cafe] Maybe a compiler bug? In-Reply-To: References: Message-ID: <7ca3f0160901051556j51d21edat457c7fa80beb4640@mail.gmail.com> On Mon, Jan 5, 2009 at 4:34 PM, Murray Gross wrote: > > When using any of -O, -O1, -O2 with the Debian binary build of GHC 6.6, > trace shows that the expression > > if (lr > ll) then False else True > > is (at least partially) evaluated, but the value returned is always True, > even though trace reports that (lr > ll) is True. When I use only the native > code generator (without optimization), the correct value (False) is > returned. > > Further detail and complete code on request. Of course! This is obviously incorrect behavior. Are you doing any unsafePerformIO? Please, complete code (minimal test case if possible, but don't let that stop you). Luke > > > Best, > > Murray Gross > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090105/b2dfba41/attachment.htm From westondan at imageworks.com Mon Jan 5 18:59:12 2009 From: westondan at imageworks.com (Dan Weston) Date: Mon Jan 5 18:50:54 2009 Subject: [Haskell-cafe] Re: Updating doubly linked lists In-Reply-To: References: <495B6E91.8050809@van.steenbergen.nl> <2f9b2d30812311311k51d2a5adq48697976cb48af75@mail.gmail.com> Message-ID: <49629ED0.8080102@imageworks.com> > For the 2D grid zipper above, moving around is O(1) but update is O(log > n). This is acceptable; also because I'm quite confident that a zipper > for a 2D grid with everything O(1) does not exist. I can prove that for > a special case and should probably write it down at some point. Really? My solution (rose tree zipper where tree depth is manhattan distance from origin and forest width is nodes around concentric diamonds, see http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/49948) was designed specifically to be amortized constant for everything for paths that do not specifically move helically around the origin. The complexity of lookup is O(d) where d is the number of defined nodes at a given radius. Until the grid gets pretty dense, d grows very slowly for most sane paths. Have I missed something? Dan Apfelmus, Heinrich wrote: > S. G?nther wrote: >>> What kind of structure do you need exactly? >> What I really need is a structure which represents a two dimensional >> grid, i.e. it consists of nodes having a value and a list of >> neighbours attached to it. Point is that if node 1 has node 2 as a >> neighbour then node 2 has to have node 1 as a >> neighbour and each node has the same number of neighbours (currently >> 4, but may vary). > > Ah, so you have a rectangular (or later hexagonal?) 2D grid? I suggest > representing it as > > Data.Map (Integer, Integer) a > > as explained below. > >> That's why I said that thinking about the circular case was just a >> divergence that really got me wondering/interested which is why I posted >> the question in it's short form at the beginning. > > Exploring a related easier problem is always a good way to get some > intuition for tackling the harder one. :) > >> Anyways, back to the structure I need. One additional thing which will >> happen during the algorithm is that there will be updates to a certain >> local neighboruhood of a node. Now I understand, that that might very >> well be possible with zippers. >> >> Instead of lists of neighbouring nodes I might as well save the paths >> through the graphs separately from the nodes although I only have a very >> vague intuition about how that would look like. And instead of calculating >> a lists of nodes to update, I could calculate a path visting the >> nodes and update them (again beeing unable to escape from the prison >> of an imperative mindset) traversing the path. > > A zipper indeed allows you to move to neighbors and update them. > >> But the point was that I just had a hard time generalizing what I read >> about zippers to structures where you can have embedded cycles, e.g. >> >> up . left . down . right = id. > > If you interpret zippers as the original data structure with a hole, > this is not so difficult. For instance, consider a rectangular grid > > +--+--+--+--+--+--+--+ > | | | | | | | | > +--+--+--+--+--+--+--+ > | | | | | | | | > +--+--+--+--+--+--+--+ > | | | | | | | | > +--+--+--+--+--+--+--+ > > where you store some data at every node. Now, a zipper is just the old > data structure but one node is marked as "hole" > > +--+--+--+--+--+--+--+ > | | | | | | | | > +--+--+--O--+--+--+--+ > | | | | | | | | > +--+--+--+--+--+--+--+ > | | | | | | | | > +--+--+--+--+--+--+--+ > > If you represent the grid as a rectangular table > > type Position = (Integer, Integer) > type Grid a = Data.Map Position a > > a zipper is simply the grid with an extra marker > > type Zipper a = (Grid a, Position) > > left,right,up,down :: Zipper a -> Zipper a > left (g,(x,y)) = (g,(x-1,y)) > right (g,(x,y)) = (g,(x+1,y)) > up (g,(x,y)) = (g,(x,y-1)) > down (g,(x,y)) = (g,(x,y+1)) > > update :: a -> Zipper a -> Zipper a > update a (g,(x,y)) = (insert (x,y) a g, (x,y)) > > Note that the left, right etc. are not "baked into" the data type but > implemented as normal functions. > > In principle, the same could be done for lists > > type ZipperL a = ([a], Int) > > left, right :: ZipperL a -> ZipperL a > left (xs,i) = (xs,i-1) > right (xs,i) = (xs,i+1) > > update :: a -> ZipperL a -> ZipperL a > update a (xs,i) = (take i xs ++ [a] ++ drop (i+1) xs, i) > > This is a valid implementation of a zipper for lists, but of course is > very inefficient, update is O(n) . The key thing about the original > list zipper with back and front list is that all operations are O(1). > > For the 2D grid zipper above, moving around is O(1) but update is O(log > n). This is acceptable; also because I'm quite confident that a zipper > for a 2D grid with everything O(1) does not exist. I can prove that for > a special case and should probably write it down at some point. > > In other words, I suggest representing your grid as a > > Data.Map (Integer,Integer) a > > and accept the minor inconvenience of a O(log n) update. Choosing a > different finite map implementation may give a better constant factor. > For instance you can nest two Data.IntMap etc. > > >> Righty right, but there's still the possibility that given all the >> time in the world and the clearest explanations I'm just to dense to >> get a hold of it. That said I hope that's not the case but I might >> still be better off timewise to just go with MVars and a >> straightforward way first and then doing the reading and >> maybe refactoring to a different approach. > > My personal experience is that not going with the obvious but messy > solution but searching for a more elegant one is always faster in the > long run. :) > > > Regards, > H. Apfelmus > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From wren at freegeek.org Mon Jan 5 20:07:46 2009 From: wren at freegeek.org (wren ng thornton) Date: Mon Jan 5 19:59:29 2009 Subject: [Haskell-cafe] ANN bytestring-trie 0.1.2 (bugfix) Message-ID: <4962AEE2.4030403@freegeek.org> -------------------------------------------- -- bytestring-trie 0.1.2 (bugfix) -------------------------------------------- Another bugfix release for efficient finite maps from (byte)strings to values. Release early, release often. -------------------------------------------- -- Changes -------------------------------------------- * Fixed a bug in alterBy pointed out by Mark Wotton. Same bug as the previous one pointed out by Maxime Henrion (a missing case). * Added an Eq instance, in case anyone cares. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-trie Darcs: http://code.haskell.org/~wren/bytestring-trie/ Haddock (Darcs version): http://code.haskell.org/~wren/bytestring-trie/dist/doc/html/bytestring-trie/ -- Live well, ~wren From mgross21 at verizon.net Mon Jan 5 20:51:04 2009 From: mgross21 at verizon.net (Murray Gross) Date: Mon Jan 5 20:16:52 2009 Subject: [Haskell-cafe] Maybe a compiler bug? In-Reply-To: <7ca3f0160901051556j51d21edat457c7fa80beb4640@mail.gmail.com> References: <7ca3f0160901051556j51d21edat457c7fa80beb4640@mail.gmail.com> Message-ID: No unsafe perform (except what may be hidden in trace), nothing, fancy, no gimmicks (very pedestrian, even heavy-handed) code. Complete code is attached (I don't have smaller snippets, because I just discovered the problem). Best, Murray Gross On Mon, 5 Jan 2009, Luke Palmer wrote: > On Mon, Jan 5, 2009 at 4:34 PM, Murray Gross wrote: > >> >> When using any of -O, -O1, -O2 with the Debian binary build of GHC 6.6, >> trace shows that the expression >> >> if (lr > ll) then False else True >> >> is (at least partially) evaluated, but the value returned is always True, >> even though trace reports that (lr > ll) is True. When I use only the native >> code generator (without optimization), the correct value (False) is >> returned. >> >> Further detail and complete code on request. > > > Of course! This is obviously incorrect behavior. Are you doing any > unsafePerformIO? Please, complete code (minimal test case if possible, but > don't let that stop you). > > Luke > > > > >> >> >> Best, >> >> Murray Gross >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > -------------- next part -------------- -- ********************************************************************* -- * * -- * Eternity II puzzle. Each puzzle piece is represented by a * -- * 5-tuple, in which the first 4 entries represent the four * -- * edge colors in the order left, top, right, bottom, and the * -- * fifth member is the (numerical) identifier for the piece. * -- * * -- ********************************************************************* -- module Solve where import Data.Array.IArray import Control.Parallel import Control.Parallel.Strategies import List import Debug.Trace main = putStrLn (show corns) >> putStrLn (corpic) >> putStrLn "Left sides\n">> putStrLn (pArrayPic (pArray pSides)) >> putStrLn "Right sides\n">> putStrLn (pArrayPic (rightArray ))>> putStrLn (show (length (perims (pArray pSides) corTemp))) >> putStrLn (show (perims (pArray pSides) corTemp))>> putStrLn "done" -- ********************************************************************* -- * * -- * Make a list of all possible perimeters. Run the operation in * -- * parallel over the list of possible corner configurations. * -- * * -- ********************************************************************* perims:: Array (Int) [Int]-> [(Int,Int,Int,Int)]->[[Int]] perims pArray corTemp = concat $ parMap rwhnf (\oneCor->makPerim oneCor pArray ) corTemp -- ********************************************************************* -- * * -- * We build a list of perimeters by constructing each backward * -- * from position 59. However, position 59 needs special handling * -- * because it must match position 0 as well as 58. Each of the * -- * other corners will also need special handling, which is done * -- * by a case statement. * -- * * -- * Note that pArray is organized by the left sides of the pieces, * -- * while in makePerim we need to check the right side of a * -- * against the bottom of the first corner. This results in the * -- * need for rightArray, and some tricky indexing. * -- * * -- ********************************************************************* makPerim :: (Int,Int,Int,Int) -> Array (Int) [Int] -> [[Int]] makPerim oneCor pArray = [a:b | a <- ((rightArray) ! startCol), b <- (restPerim a (pArray // [(left(refPerim!a), (pArray!(left(refPerim!a)))\\[a])]) (rightArray //[(startCol, (rightArray ! startCol) \\ [a])]) oneCor 58), trace (show b) b /=[] ] where startCol = bot (corns !! (fst4 oneCor)) -- ********************************************************************* -- * * -- * Once past the first piece in a perimeter, move to next. * -- * Check for a corner piece, which needs special handling. * -- * If there are no candidates left to match last, terminate * -- * the recursion, indicating there is no way to continue. * -- * Otherwise, construct the list of possible continuations of * -- * the perimeter. * -- * * -- ********************************************************************* -- restPerim last leftRay rightRay oneCor iAm | -- trace ((show iAm)++" "++ (show last)) elem iAm [0,15,30,45] = corner last leftRay rightRay oneCor iAm | useRow /= [] = extend | otherwise = [] where useRow = rightRay ! (left (refPerim ! last)) extend = [b:c | b <- (rightRay ! (left (refPerim ! last))), c <- restPerim b (newLeft b) (newRight b) oneCor (iAm - 1), --trace (show c) c/=[]] newLeft b = leftRay // [((left (refPerim ! b)), (leftRay ! (left (refPerim ! b))) \\ [b])] newRight b = rightRay // [((right (refPerim ! b)), (rightRay ! (right (refPerim ! b))) \\ [b])] -- ********************************************************************* -- * * -- * Corners get special handling. The corner in the upper left is * -- * always piece 1, because of rotational symmetry. * -- * * -- ********************************************************************* -- corner last leftRay rightRay oneCor iAm | -- trace ((show last)++" "++(show iAm)) iAm == 15 = if (gTst3 leftRay rightRay) then goOn (snd4 oneCor) else trace "fail" [] | -- trace "goo" iAm == 30 = goOn (thd4 oneCor) | -- trace "gah" iAm == 45 = goOn (fth4 oneCor) | -- trace "gii" iAm == 0 = if (lastLeft == rightCor 1) then [[1]] else [] | otherwise = error ("\n\n *** You can't get here"++ " *** \n\n") where lastLeft = left (refPerim ! last) rightCor b = right (refPerim ! b) botCor b = bot (refPerim ! b) nLeft b = left (refPerim ! b) goOn q = if (lastLeft /= rightCor q) then [] else [q:c:d | c <- (leftRay ! (botCor q)), d <- -- trace ((show q)++" "++ -- (show c)++"xx ") restPerim c (newleft c) (newright c) oneCor (iAm - 2) ] newleft c = leftRay // [((nLeft c), leftRay!(nLeft c)\\[c])] newright c = rightRay // [((rightCor c), rightRay!(rightCor c)\\ [c])] -- ********************************************************************* -- * * -- * agTst is a simple heuristic test to determine whether it is * -- * possible for a perimeter to be built with the remaining * -- * pieces: it tests to find out whether there are an equal no. of * -- * pieces whose right side matches the left sides of available * -- * pieces, except, perhaps for 1, which will fit a corner piece. * -- * * -- * And it doesn't work, at least at the beginning of the solution.* -- * In the first 10,000,000 passages through corner 15, there is * -- * only 1 fail. * -- * * -- ********************************************************************* gTst :: Array Int [Int] -> Array Int [Int] -> Bool gTst right left = and $ map tryme (indices right) where iList = indices right tryme x | (length (right ! x)) == (length (left ! x)) = True | abs ((length (right ! x))- (length (left ! x))) == 1 = True | otherwise = False gTst1:: Array Int [Int] -> Array Int [Int] -> Bool gTst1 right left = if (sum $ map tryme (indices right)) > 2 then False else True where tryme x = abs ((length (right ! x)) - (length (left ! x))) gTst2 right left = if (length (left ! 2)) > 0 then True else False gTst3 right left = if (lr > ll) then False else True where lr = length (right ! 2) ll = length (left ! 2) -- ********************************************************************* -- * * -- * Here we make up a list of the 6 possible corner configurations * -- * There are only 6 such because the remaining permutations of * -- * corner pieces are merely rotations of the six used here. * -- * * -- ********************************************************************* corTemp :: [(Int,Int,Int,Int)] corTemp = [(1,2,3,4),(1,2,4,3),(1,3,2,4),(1,3,4,2),(1,4,2,3),(1,4,3,2)] corns = [(0,0,0,0,0), (0,0,2,1,1),(0,0,2,3,2),(0,0,4,1,3),(0,0,1,4,4)] -- ********************************************************************* -- * * -- * Construct an array in which each entry is a list of pieces * -- * that have the same color on the left side. This array will be * -- * used to construct the perimeters of the puzzle. * -- * * -- * We use pArray as an array of available pieces, and refPerim * -- * in order to find the matching colors; since it changes a lot, * -- * the reduced item count will reduce overhead from building new * -- * pArray's. * -- * * -- ********************************************************************* pSides:: [(Int,Int,Int,Int,Int)] pSides = [(2,0,2,5,5),(4,0,2,6,6),(2,0,2,7,7),(8,0,2,7,8),(1,0,2,9,9), (3,0,2,10,10),(4,0,2,11,11),(3,0,2,12,12),(8,0,2,12,13), (3,0,2,13,14),(2,0,4,6,15),(1,0,4,14,16),(8,0,4,15,17), (8,0,4,16,18),(4,0,4,10,19),(4,0,4,11,20),(3,0,4,17,21), (2,0,4,18,22),(8,0,4,18,23),(2,0,4,19,24),(2,0,4,13,25), (4,0,1,5,26),(1,0,1,5,27),(1,0,1,6,28),(1,0,1,14,29), (8,0,1,10,30),(4,0,1,11,31),(1,0,1,19,32),(4,0,1,12,33), (3,0,1,12,34),(8,0,1,20,35),(3,0,1,21,36),(2,0,3,14,37), (8,0,3,22,38),(8,0,3,9,39),(4,0,3,16,40),(1,0,3,16,41), (2,0,3,11,42),(4,0,3,11,43),(1,0,3,11,44),(2,0,3,17,45), (3,0,3,19,46),(3,0,3,12,47),(3,0,3,20,48),(8,0,8,5,49), (2,0,8,6,50),(4,0,8,6,51),(2,0,8,7,52),(3,0,8,10,53), (3,0,8,17,54),(8,0,8,17,55),(1,0,8,12,56),(2,0,8,20,57), (8,0,8,20,58),(4,0,8,13,59),(1,0,8,21,60)] pArray:: [(Int,Int,Int,Int,Int)] -> Array (Int) [Int] pArray pSides = accumArray (++) [] (1,8) accumPlist rightArray:: Array (Int) [Int] rightArray = accumArray (++) [] (1,8) rightAccum rightAccum = map (\item ->((right item),[piece item])) pSides accumPlist = map (\item ->((left item),[piece item])) pSides refPerim:: Array (Int) (Int,Int,Int,Int,Int) refPerim = listArray (1,60) (trace "don't get here"(drop 1 corns)++pSides) -- ********************************************************************* -- * * -- * Pretty-printer for corner configurations. * -- * * -- * * -- ********************************************************************* corpic = concat $ map oneSq corTemp oneSq (a,b,c,d) = show (corns !! a) ++ " " ++ show (corns !! b) ++ "\n\n" ++ show (corns !! c)++" "++show (corns !! d) ++ "\n\n\n" -- ********************************************************************* -- * * -- * Ugly-printer for pArray, the array of pieces for the * -- * perimeter. * -- * * -- * * -- ********************************************************************* pArrayPic myray = concatMap (\x-> (show x)++"\n\n") (elems myray) -- ********************************************************************* -- * * -- * Convenience functions. * -- * * -- ********************************************************************* left:: (Int,Int,Int,Int,Int) -> Int left (a,b,c,d,e) = a fst4 (a,b,c,d) = a top (a,b,c,d,e) = b snd4 (a,b,c,d) =b right (a,b,c,d,e) = c thd4 (a,b,c,d) = c bot (a,b,c,d,e) = d fth4 (a,b,c,d) = d piece (a,b,c,d,e) = e From chunye.wang at nsn.com Tue Jan 6 02:33:00 2009 From: chunye.wang at nsn.com (Wang, Chunye (NSN - CN/Beijing)) Date: Tue Jan 6 02:24:40 2009 Subject: [Haskell-cafe] Can I destructive rebind a local variable in haskell? Message-ID: <2667F74761A946468605DA9E63434A0870CEA2@CNBEEXC006.nsn-intra.net> Dear haskeller, Can I destructive rebind a local variable like this import System.Directory test filename = do is_dir <- doesDirectoryExist filename let filename = if not is_dir then filename else filename putStrLn $ " filename " ++ filename main = test "." in GHCi 6.10.1 on WinXP, the ghci aborts silencely when I executes "main" after compile it into a executable file. c:\USERS\home\learning_haskell\>testDirectory testDirectory C stack overflow in generated code I have some code in scheme which works very well (define (func x) (let ((x x)) x)) By rebinding a formal variable, we can save naming some varaibles. I am not good at naming a variable. Thank you in advance Best Regards Chunye Wang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090106/6eb670eb/attachment.htm From lrpalmer at gmail.com Tue Jan 6 02:44:25 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Jan 6 02:36:02 2009 Subject: [Haskell-cafe] Can I destructive rebind a local variable in haskell? In-Reply-To: <2667F74761A946468605DA9E63434A0870CEA2@CNBEEXC006.nsn-intra.net> References: <2667F74761A946468605DA9E63434A0870CEA2@CNBEEXC006.nsn-intra.net> Message-ID: <7ca3f0160901052344i10a996a2t62f9b59f4111e378@mail.gmail.com> 2009/1/6 Wang, Chunye (NSN - CN/Beijing) Dear haskeller, > > > Can I destructive rebind a local variable like this > > import System.Directory > test filename = do > is_dir <- doesDirectoryExist filename > let filename = if not is_dir then filename else filename > Nope. The "filename" on the right side of the = is the same as the "filename" on the left, so you're making an infinite loop, the same way: let x = x in x is an infinite loop. However you can make a new name as you are trying, you just can't reference the old one. e.g.: let filename = 42 Here would be just fine. However, for cases like this, it is useful that single quote is a valid identifier, so you can say: let filename' = if not is_dir then filename else filename (read "filename prime") Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090106/f8219629/attachment.htm From chunye.wang at nsn.com Tue Jan 6 02:47:53 2009 From: chunye.wang at nsn.com (Wang, Chunye (NSN - CN/Beijing)) Date: Tue Jan 6 02:39:38 2009 Subject: [Haskell-cafe] Can I destructive rebind a local variable in haskell? In-Reply-To: <7ca3f0160901052344i10a996a2t62f9b59f4111e378@mail.gmail.com> References: <2667F74761A946468605DA9E63434A0870CEA2@CNBEEXC006.nsn-intra.net> <7ca3f0160901052344i10a996a2t62f9b59f4111e378@mail.gmail.com> Message-ID: <2667F74761A946468605DA9E63434A0870CEC6@CNBEEXC006.nsn-intra.net> Hi Luke Thank you ! I got it :) Best Regards Chunye Wang ________________________________ From: ext Luke Palmer [mailto:lrpalmer@gmail.com] Sent: Tuesday, January 06, 2009 3:44 PM To: Wang, Chunye (NSN - CN/Beijing) Cc: Haskell-Cafe@haskell.org Subject: Re: [Haskell-cafe] Can I destructive rebind a local variable in haskell? 2009/1/6 Wang, Chunye (NSN - CN/Beijing) Dear haskeller, Can I destructive rebind a local variable like this import System.Directory test filename = do is_dir <- doesDirectoryExist filename let filename = if not is_dir then filename else filename Nope. The "filename" on the right side of the = is the same as the "filename" on the left, so you're making an infinite loop, the same way: let x = x in x is an infinite loop. However you can make a new name as you are trying, you just can't reference the old one. e.g.: let filename = 42 Here would be just fine. However, for cases like this, it is useful that single quote is a valid identifier, so you can say: let filename' = if not is_dir then filename else filename (read "filename prime") Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090106/bfbe57b8/attachment.htm From qdunkan at gmail.com Tue Jan 6 03:00:52 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Tue Jan 6 02:52:29 2009 Subject: [Haskell-cafe] Can I destructive rebind a local variable in haskell? In-Reply-To: <7ca3f0160901052344i10a996a2t62f9b59f4111e378@mail.gmail.com> References: <2667F74761A946468605DA9E63434A0870CEA2@CNBEEXC006.nsn-intra.net> <7ca3f0160901052344i10a996a2t62f9b59f4111e378@mail.gmail.com> Message-ID: <2518b95d0901060000p198403c5jd13c34ac76a8cda8@mail.gmail.com> 2009/1/6 Luke Palmer : > 2009/1/6 Wang, Chunye (NSN - CN/Beijing) > Dear haskeller, >> >> >> Can I destructive rebind a local variable like this >> >> import System.Directory >> test filename = do >> is_dir <- doesDirectoryExist filename >> let filename = if not is_dir then filename else filename > > Nope. The "filename" on the right side of the = is the same as the > "filename" on the left, so you're making an infinite loop, the same way: > let x = x in x > is an infinite loop. However you can make a new name as you are trying, you > just can't reference the old one. e.g.: > let filename = 42 You can also reuse the name exactly by using bind+return instead of let: test filename = do is_dir <- doesDirectoryExist filename filename <- return $ if not is_dir then filename else filename I'm not a huge fan of the prime thing because it's tiny and easy to miss and if you forget it you probably won't get a type error, you'll just get a bug, possibly a subtle one. Besides, what's the next step? filename''? filename'''? From chunye.wang at nsn.com Tue Jan 6 03:20:16 2009 From: chunye.wang at nsn.com (Wang, Chunye (NSN - CN/Beijing)) Date: Tue Jan 6 03:12:04 2009 Subject: [Haskell-cafe] Can I destructive rebind a local variable in haskell? In-Reply-To: <2518b95d0901060000p198403c5jd13c34ac76a8cda8@mail.gmail.com> References: <2667F74761A946468605DA9E63434A0870CEA2@CNBEEXC006.nsn-intra.net> <7ca3f0160901052344i10a996a2t62f9b59f4111e378@mail.gmail.com> <2518b95d0901060000p198403c5jd13c34ac76a8cda8@mail.gmail.com> Message-ID: <2667F74761A946468605DA9E63434A0870CF25@CNBEEXC006.nsn-intra.net> Hi Evan, > You can also reuse the name exactly by using bind+return instead of let: > test filename = do > is_dir <- doesDirectoryExist filename > filename <- return $ if not is_dir then filename else filename > I'm not a huge fan of the prime thing because it's tiny and easy to miss and if you forget it you probably won't get a type error, you'll just get a bug, possibly a subtle one. Besides, what's the next step? > filename''? filename'''? Nice. Good solution. ``imperative style'' is not a bad idea when I'm not used to the ``pure functional style'' E.g. filename <- return $ combine filename "Makefile" Similar to the other imperative language filename = joinPath(filename,"Makefile") and I often write similar code in EmacsLisp also. It is not so buggy, because we live in "imperitive programming" for long time Best Regards Chunye Wang From qdunkan at gmail.com Tue Jan 6 03:33:15 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Tue Jan 6 03:24:50 2009 Subject: [Haskell-cafe] Can I destructive rebind a local variable in haskell? In-Reply-To: <2667F74761A946468605DA9E63434A0870CF25@CNBEEXC006.nsn-intra.net> References: <2667F74761A946468605DA9E63434A0870CEA2@CNBEEXC006.nsn-intra.net> <7ca3f0160901052344i10a996a2t62f9b59f4111e378@mail.gmail.com> <2518b95d0901060000p198403c5jd13c34ac76a8cda8@mail.gmail.com> <2667F74761A946468605DA9E63434A0870CF25@CNBEEXC006.nsn-intra.net> Message-ID: <2518b95d0901060033g402515fct2d0e4a6333f3c659@mail.gmail.com> > Nice. Good solution. ``imperative style'' is not a bad idea when I'm > not used to the ``pure functional style'' > > E.g. > > filename <- return $ combine filename "Makefile" > > Similar to the other imperative language > > filename = joinPath(filename,"Makefile") I wouldn't consider it particularly imperative, it's just variable shadowing. It desugars to calling a function with a parameter that shadows the old variable. Of course, you could say a more functional way would be to use pointfree style or just nested calls to avoid naming the intermediate values. Then you can't intersperse IO actions... but it's good to avoid doing that anyway. From apfelmus at quantentunnel.de Tue Jan 6 04:05:46 2009 From: apfelmus at quantentunnel.de (Apfelmus, Heinrich) Date: Tue Jan 6 03:57:14 2009 Subject: [Haskell-cafe] Re: Updating doubly linked lists In-Reply-To: <49629ED0.8080102@imageworks.com> References: <495B6E91.8050809@van.steenbergen.nl> <2f9b2d30812311311k51d2a5adq48697976cb48af75@mail.gmail.com> <49629ED0.8080102@imageworks.com> Message-ID: Dan Weston wrote: >> For the 2D grid zipper above, moving around is O(1) but update is O(log >> n). This is acceptable; also because I'm quite confident that a zipper >> for a 2D grid with everything O(1) does not exist. I can prove that for >> a special case and should probably write it down at some point. > > Really? My solution (rose tree zipper where tree depth is manhattan > distance from origin and forest width is nodes around concentric > diamonds, see > http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/49948) was > designed specifically to be amortized constant for everything for paths > that do not specifically move helically around the origin. The > complexity of lookup is O(d) where d is the number of defined nodes at a > given radius. Until the grid gets pretty dense, d grows very slowly for > most sane paths. > > Have I missed something? >From your description (without reading the code ;)), I gather that your tree looks something like this? -+- / \ -+ -+- +- / / \ \ -+ -+ -+- +- +- / / / \ \ \ -+ -+ -+ -+- +- +- +- / / / / \ \ \ \ + B A + +--+--C--+--+-- ... \ \ \ \ / / / / -+ -+ -+ -+- +- +- +- \ \ \ / / / -+ -+ -+- +- +- \ \ / / -+ -+- +- \ / -+- The root of the tree is the center and you can descend on the right. But with this structure, walking from A to B is O(d) = O(n) (where d is the distance from the origin, n the side length of the grid) instead of O(1). Put differently, using Data.Tree.Zipper.parent on B will move you to C, not to A. I mean, O(d) may be fine for you, but it's not O(1) for everything as advertised. :) Regards, H. Apfelmus From RafaelGCPP.Linux at gmail.com Tue Jan 6 05:08:29 2009 From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto) Date: Tue Jan 6 05:00:06 2009 Subject: [Haskell-cafe] Maybe a compiler bug? In-Reply-To: References: <7ca3f0160901051556j51d21edat457c7fa80beb4640@mail.gmail.com> Message-ID: <351ff25e0901060208u30480fcdxa4a731ec1bc965b8@mail.gmail.com> Specifically for this code: gTst3 right left = if (lr > ll) then False else True where lr = length (right ! 2) ll = length (left ! 2) why don't you just negate the condition, like: gTst3 right left = (lr <= ll) where lr = length (right ! 2) ll = length (left ! 2) 2009/1/5 Murray Gross > > > No unsafe perform (except what may be hidden in trace), nothing, fancy, no > gimmicks (very pedestrian, even heavy-handed) code. Complete code is > attached (I don't have smaller snippets, because I just discovered the > problem). > > > > Best, > > Murray Gross > > > > > On Mon, 5 Jan 2009, Luke Palmer wrote: > > On Mon, Jan 5, 2009 at 4:34 PM, Murray Gross >> wrote: >> >> >>> When using any of -O, -O1, -O2 with the Debian binary build of GHC 6.6, >>> trace shows that the expression >>> >>> if (lr > ll) then False else True >>> >>> is (at least partially) evaluated, but the value returned is always True, >>> even though trace reports that (lr > ll) is True. When I use only the >>> native >>> code generator (without optimization), the correct value (False) is >>> returned. >>> >>> Further detail and complete code on request. >>> >> >> >> Of course! This is obviously incorrect behavior. Are you doing any >> unsafePerformIO? Please, complete code (minimal test case if possible, >> but >> don't let that stop you). >> >> Luke >> >> >> >> >> >>> >>> Best, >>> >>> Murray Gross >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090106/0d68d124/attachment.htm From ndmitchell at gmail.com Tue Jan 6 05:20:17 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jan 6 05:11:53 2009 Subject: [Haskell-cafe] Maybe a compiler bug? In-Reply-To: <351ff25e0901060208u30480fcdxa4a731ec1bc965b8@mail.gmail.com> References: <7ca3f0160901051556j51d21edat457c7fa80beb4640@mail.gmail.com> <351ff25e0901060208u30480fcdxa4a731ec1bc965b8@mail.gmail.com> Message-ID: <404396ef0901060220l196213d8hf446492281042794@mail.gmail.com> Hi > gTst3 right left = if (lr > ll) then False else True > where lr = length (right ! 2) > ll = length (left ! 2) Running this code over HLint (http://www.cs.york.ac.uk/~ndm/hlint) says: Example.hs:8:1: Error: Redundant if Found: if (lr > ll) then False else True Why not: not (lr > ll) Making that change and running it again gives: Example.hs:8:1: Error: Use <= Found: not (lr > ll) Why not: lr <= ll Which ends up with something similar to what you came up with. However, if we take your final answer: > gTst3 right left = (lr <= ll) > where lr = length (right ! 2) > ll = length (left ! 2) We get: Example.hs:8:1: Warning: Redundant brackets Found: (lr <= ll) Why not: lr <= ll Leaving us with the HLint 1.0 compliant (TM) : gTst3 right left = lr <= ll where lr = length (right ! 2) ll = length (left ! 2) Thanks Neil From marlowsd at gmail.com Tue Jan 6 08:28:47 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jan 6 08:20:32 2009 Subject: [Haskell-cafe] Re: building HSQL MySQL on windows (Was: FFI imported function names) In-Reply-To: References: Message-ID: <49635C8F.7090006@gmail.com> Daniil Elovkov wrote: > Ok, enough talking to myself :) > > If anybody ever wants to build hsql-mysql on windows and has the same > problems as I had, here's how it should be done. > > The problem I had seemed to be that libmysql.dll uses stdcall, but > names its functions without @ decoration. Thus, when linking a > Haskell program against it, names with @ cannot be resolved. > > The solution is pretty much a hack. Somebody from the Ruby community > used to run into the same problem, from the same situation -- namely > building ruby mysql bindings. > > Here is the procedure one person suggests > http://rubydotnetproxy.rubyforge.org/mysql_win.html > > It worked perfectly for me. Of course, with some cabal specifics, > which is obviously not described in the above page. > > The solution was to create a def file listing the names which could > not be resolved and creating a .a file based on the dll and this def > file. GHC adds the @N suffix to any foreign function declared with the stdcall calling convention, which I think matches what gcc does. I wonder how it works for C. Cheers, Simon > > 2008/12/24 Daniil Elovkov : >> Mm, actually I didn't change the calling convention ffi imports when I >> thought I did. I tried to do it through defines... >> >> Well, by explicitly saying ccall I get the names without @ >> decoration. And it all links well. But I get segault when I run the >> code, which should mean that calling conventions didn't match. >> >> Actually I found some ramblings on the internet that there's something >> wrong with libmysql.dll and libmysql.lib in this respect, but they >> were from 2004. >> >> Thus the question: how do I link against a lib file in ghc? When I say >> -lmysql on command line it strictly searches for dll and complains if >> it's not found. Adding lib exlpicitly on the cmd line doesn't seem to >> have any effect. >> >> Thanks >> >> >> 2008/12/24 Daniil Elovkov : >>> Hello >>> >>> How is decided whether the name of imported function gets the ending >>> of the form @4 in ghc? >>> >>> I'm having this problem on Windows trying to use HSQL MySQL on windows. >>> >>> I compile HSQL Oracle backend and I get names without that. It's ok. >>> With HSQL MySQL I get names with that stuff. It prevents me from >>> further linking to dll. Supplying in the ghc command-line the "lib" >>> file where names have those marks doesn't have any effect. >>> >>> The linker says that fname@NN cannot be resolved. >>> >>> Can I control that? >>> >>> The ffi calling convention doesn't (and shouldn't as I understand) >>> affect this. The only difference is that in the case of mysql the >>> header file itself where functions are described marks it STDCALL. Is >>> that the reason? >>> >>> Also I changed ffi import line from "hsmysql.h func" to just "func", >>> to no avail. >>> >>> ghc 6.8.2 >>> >>> I'm lost. Please help. >>> >>> -- >>> Daniil Elovkov >>> >> >> >> -- >> Daniil Elovkov >> > > > From mgross21 at verizon.net Tue Jan 6 10:52:50 2009 From: mgross21 at verizon.net (Murray Gross) Date: Tue Jan 6 10:18:31 2009 Subject: [Haskell-cafe] Maybe a compiler bug? In-Reply-To: <404396ef0901060220l196213d8hf446492281042794@mail.gmail.com> References: <7ca3f0160901051556j51d21edat457c7fa80beb4640@mail.gmail.com> <351ff25e0901060208u30480fcdxa4a731ec1bc965b8@mail.gmail.com> <404396ef0901060220l196213d8hf446492281042794@mail.gmail.com> Message-ID: The issue here is not whether or not the code is pretty or elegant, but whether or not I get correct execution of what I have, which is a correct statement of what I want (even if not the prettiest or most lint free), and I don't. There are lots of ways to work around the problem, but that doesn't, unfortunately, make the problem go away, and it is sure to appear elsewhere as the program is extended, which it will be. It would appear that the real issue here is that someone with resources I don't have needs to dig into the compilers--it should not be necessary to use trial and error to find an alternate writing of code that is legal and correct (regardless of the aesthetics) but is incorrectly compiled. For the time being, I will use native compilation and hope that someone can find and fix the error so that I can use the speed advantage of optimization. Best, Murray Gross On Tue, 6 Jan 2009, Neil Mitchell wrote: > Hi > >> gTst3 right left = if (lr > ll) then False else True >> where lr = length (right ! 2) >> ll = length (left ! 2) > > Running this code over HLint (http://www.cs.york.ac.uk/~ndm/hlint) says: > > Example.hs:8:1: Error: Redundant if > Found: > if (lr > ll) then False else True > Why not: > not (lr > ll) > > Making that change and running it again gives: > > Example.hs:8:1: Error: Use <= > Found: > not (lr > ll) > Why not: > lr <= ll > > Which ends up with something similar to what you came up with. > However, if we take your final answer: > >> gTst3 right left = (lr <= ll) >> where lr = length (right ! 2) >> ll = length (left ! 2) > > We get: > > Example.hs:8:1: Warning: Redundant brackets > Found: > (lr <= ll) > Why not: > lr <= ll > > Leaving us with the HLint 1.0 compliant (TM) : > > gTst3 right left = lr <= ll > where lr = length (right ! 2) > ll = length (left ! 2) > > Thanks > > Neil > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From bugfact at gmail.com Tue Jan 6 10:33:20 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Tue Jan 6 10:24:56 2009 Subject: [Haskell-cafe] Maybe a compiler bug? In-Reply-To: References: <7ca3f0160901051556j51d21edat457c7fa80beb4640@mail.gmail.com> <351ff25e0901060208u30480fcdxa4a731ec1bc965b8@mail.gmail.com> <404396ef0901060220l196213d8hf446492281042794@mail.gmail.com> Message-ID: Exactly. The best you can do is try to reduce your code to a tiny fragment that still exposes the problem, and report it as a bug. On Tue, Jan 6, 2009 at 4:52 PM, Murray Gross wrote: > > The issue here is not whether or not the code is pretty or elegant, but > whether or not I get correct execution of what I have, which is a correct > statement of what I want (even if not the prettiest or most lint free), and > I don't. There are lots of ways to work around the problem, but that > doesn't, unfortunately, make the problem go away, and it is sure to appear > elsewhere as the program is extended, which it will be. > > It would appear that the real issue here is that someone with resources I > don't have needs to dig into the compilers--it should not be necessary to > use trial and error to find an alternate writing of code that is legal and > correct (regardless of the aesthetics) but is incorrectly compiled. For the > time being, I will use native compilation and hope that someone can find and > fix the error so that I can use the speed advantage of optimization. > > Best, > > Murray Gross > > > > On Tue, 6 Jan 2009, Neil Mitchell wrote: > >> Hi >> >>> gTst3 right left = if (lr > ll) then False else True >>> where lr = length (right ! 2) >>> ll = length (left ! 2) >> >> Running this code over HLint (http://www.cs.york.ac.uk/~ndm/hlint) says: >> >> Example.hs:8:1: Error: Redundant if >> Found: >> if (lr > ll) then False else True >> Why not: >> not (lr > ll) >> >> Making that change and running it again gives: >> >> Example.hs:8:1: Error: Use <= >> Found: >> not (lr > ll) >> Why not: >> lr <= ll >> >> Which ends up with something similar to what you came up with. >> However, if we take your final answer: >> >>> gTst3 right left = (lr <= ll) >>> where lr = length (right ! 2) >>> ll = length (left ! 2) >> >> We get: >> >> Example.hs:8:1: Warning: Redundant brackets >> Found: >> (lr <= ll) >> Why not: >> lr <= ll >> >> Leaving us with the HLint 1.0 compliant (TM) : >> >> gTst3 right left = lr <= ll >> where lr = length (right ! 2) >> ll = length (left ! 2) >> >> Thanks >> >> Neil >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ndmitchell at gmail.com Tue Jan 6 10:35:57 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jan 6 10:27:34 2009 Subject: [Haskell-cafe] Maybe a compiler bug? In-Reply-To: References: <7ca3f0160901051556j51d21edat457c7fa80beb4640@mail.gmail.com> <351ff25e0901060208u30480fcdxa4a731ec1bc965b8@mail.gmail.com> <404396ef0901060220l196213d8hf446492281042794@mail.gmail.com> Message-ID: <404396ef0901060735w4d1dc4c4w6559d6c26bddef9c@mail.gmail.com> Hi Murray, > The issue here is not whether or not the code is pretty or elegant, but > whether or not I get correct execution of what I have, which is a correct > statement of what I want (even if not the prettiest or most lint free), and > I don't. Sorry, I was merely responding to someone else suggesting ways to improve your code. Of course you are right - if the code goes wrong when written in an inelegant way that is the fault of the compiler, not the fault or the author! Trying your code I get 69 of output on stdout, then the message "fail" repeatedly on stderr. This happens whether I compile the code with -fasm or -fvia-c, using GHC 6.10. What are you expecting the code to output in each case, what command lines do you use, and which do you believe is correct? Please make sure you clean all the .hi and .o files between each build, so they don't have any confusing effects. As soon as someone else can reproduce the problem, they will probably be able to snip it down to a more manageable example. Thanks Neil From marlowsd at gmail.com Tue Jan 6 11:03:04 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jan 6 10:54:45 2009 Subject: [Haskell-cafe] Re: Threads with high CPU usage In-Reply-To: <995056501.20081222125622@gmail.com> References: <1229897782.4495.7.camel@localhost.localdomain> <1229899191.4495.13.camel@localhost.localdomain> <995056501.20081222125622@gmail.com> Message-ID: <496380B8.7040600@gmail.com> Bulat Ziganshin wrote: > Hello G?nther, > > Monday, December 22, 2008, 1:57:22 AM, you wrote: > > try -threaded, +RTS -N2, and forkOS simultaneously. it may work - i > don't see reasons why other threads should be freezd why one does > unsafe call Please don't suggest using forkOS - it will probably harm performance and do nothing else, unless you actually need it (i.e. you're using OpenGL). Cheers, Simon From marlowsd at gmail.com Tue Jan 6 11:07:35 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jan 6 10:59:15 2009 Subject: [Haskell-cafe] Re: Threads with high CPU usage In-Reply-To: <494FA112.60904@complete.org> References: <1229897782.4495.7.camel@localhost.localdomain> <1229899191.4495.13.camel@localhost.localdomain> <20081221230712.GE25249@scytale.galois.com> <20081222103051.4fa2f917.Malcolm.Wallace@cs.york.ac.uk> <1229946142.5704.57.camel@localhost> <494FA112.60904@complete.org> Message-ID: <496381C7.50904@gmail.com> John Goerzen wrote: > Duncan Coutts wrote: >> On Mon, 2008-12-22 at 10:30 +0000, Malcolm Wallace wrote: >> >>> The terminology seems counter-intuitive, but in other other words, a >>> "safe" call is slower but more flexible, an "unsafe" call is fast and >>> dangerous. Therefore it is always OK to convert an "unsafe" declaration >>> into a "safe" one, but never OK to convert from "safe" to "unsafe" >>> without looking at what the foreign side actually does. >> And in general we would not even bother with considering using "unsafe" >> for calls that are already expensive. It's only worth considering when >> the length of the call is always very short. >> >> For example in a database library it might make sense to use 'unsafe' on >> the data-access functions that extract data from a local query result >> but we should always use 'safe' on any DB function that might want to >> talk to the network (eg to get more query results). > > It's difficult to anticipate the needs here. For instance, some people > may be using a few very-long-running queries measured in minutes, such > as the original poster. Other people, such as web app developers, may > be issuing literally millions of queries, right after another, where the > difference matters. I'd be really interested to know whether you can actually measure a difference between safe and unsafe foreign calls for something complicated like a database query. Do you have any figures? If it turns out that "safe" calls are a bottleneck, then there might be room for optimisation there. > I had initially used "unsafe" because of the documented performance > benefit, plus I certainly am not expecting Sqlite to call back into the > Haskell runtime. > > It seems to me strange that using "unsafe" instead of "safe" would have > negative implications for threading. After all, as Malcolm said above, > "it is always OK to convert an unsafe declaration into a safe one". So > could the compiler be made to be smart enough to do so when it is > advantageous for threading purposes? It's not possible to make the choice at runtime without compromising the efficiency of "unsafe" calls. An "unsafe" call is just an inline call to the C function, whereas a "safe" call is wrapped in a couple of calls into the RTS to save/restore the Haskell state. Cheers, Simon From marlowsd at gmail.com Tue Jan 6 11:10:38 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jan 6 11:02:20 2009 Subject: [Haskell-cafe] Re: Threads with high CPU usage In-Reply-To: <1230040962.11245.18.camel@localhost> References: <494FA112.60904@complete.org> <125EACD0CAE4D24ABDB4D148C4593DA911025D72@GBLONXMB02.corp.amvescap.net> <20081222205916.GA17953@hustlerturf.com> <2f9b2d30812221714m139f5f0n217e15e030253d6e@mail.gmail.com> <1230040962.11245.18.camel@localhost> Message-ID: <4963827E.7020302@gmail.com> Duncan Coutts wrote: > On Tue, 2008-12-23 at 03:56 +0100, wman wrote: >> Thanks to you all for inspiration. >> >> My web app (which otherwise ran ok) was getting stuck while getting >> harassed by ab (apache-benchmark) after receiving some 800+ requests >> in short succession (not less, never gotten to 900, what was weird >> that running like 500 reqs - pause - 500 reqs ... went ok). >> >> After compiling with -threaded and running with +RTS -N2 it handles >> 10k+ requests (with 10 concurrent request running at once) without >> missing a beat. > > How about compiled with -threaded and running with just +RTS -N1 ? > > I would expect the crucial thing is the -threaded not the number of cpus > running Haskell code concurrently (-threaded uses a pool of OS threads > to make blocking foreign calls effectively non-blocking). Exactly - adding another virtual CPU with +RTS -N2 should never turn a deadlocked program into a responsive one (unless there are threads busy not allocating anything, that is). Cheers, Simon From mgross21 at verizon.net Tue Jan 6 12:32:01 2009 From: mgross21 at verizon.net (Murray Gross) Date: Tue Jan 6 11:57:47 2009 Subject: [Haskell-cafe] Maybe a compiler bug? In-Reply-To: <404396ef0901060735w4d1dc4c4w6559d6c26bddef9c@mail.gmail.com> References: <7ca3f0160901051556j51d21edat457c7fa80beb4640@mail.gmail.com> <351ff25e0901060208u30480fcdxa4a731ec1bc965b8@mail.gmail.com> <404396ef0901060220l196213d8hf446492281042794@mail.gmail.com> <404396ef0901060735w4d1dc4c4w6559d6c26bddef9c@mail.gmail.com> Message-ID: My last note had an error in it, and the code originally sent to the list should be ignored. I have attached the current version of the code, and here is some further information (the behavior is different, by the way, but still apparently wrong). I have attached the current version of the program, which behaves slightly differently from the version originally sent. I am running ghc 6.6, gcc 4.1.2, g++ 4.1.1, on Debian Linux. The compile lines are ghc -threaded solve.hs or ghc -threaded -O2 solve.hs. The execution line is ./a.out, which should give me single-threaded execution. Ignore the output on stdout; it is the same for both versions. On stderr, the unoptimized version of the attached code gives me both "fail" and "goOn" (see lines #150 and #153). The optimized version gives me only "goOn." I think that both should give me both "fail" and "goOn." Were circumstances different, I might suspect that laziness and optimization had something to do with this. However, earlier tests showed inconsistency between the result of the test in gTst3 and the code where the value of gTst3 is used. A copy of the current version of solve.hs is attached. Best, Murray Gross P.S.: For anyone who has actually looked at the logic, I am aware that the test in gTst3 can be sharpened. That will come later. The current version is adequate for the time being. -------------- next part -------------- -- ********************************************************************* -- * * -- * Eternity II puzzle. Each puzzle piece is represented by a * -- * 5-tuple, in which the first 4 entries represent the four * -- * edge colors in the order left, top, right, bottom, and the * -- * fifth member is the (numerical) identifier for the piece. * -- * * -- ********************************************************************* -- module Solve where import Data.Array.IArray import Control.Parallel import Control.Parallel.Strategies import List import Debug.Trace main = putStrLn (show corns) >> putStrLn (corpic) >> putStrLn "Left sides\n">> putStrLn (pArrayPic (pArray pSides)) >> putStrLn "Right sides\n">> putStrLn (pArrayPic (rightArray ))>> putStrLn (show (length (perims (pArray pSides) corTemp))) >> putStrLn (show (perims (pArray pSides) corTemp))>> putStrLn "done" -- ********************************************************************* -- * * -- * Make a list of all possible perimeters. Run the operation in * -- * parallel over the list of possible corner configurations. * -- * * -- ********************************************************************* perims:: Array (Int) [Int]-> [(Int,Int,Int,Int)]->[[Int]] perims pArray corTemp = concat $ parMap rwhnf (\oneCor->makPerim oneCor pArray ) corTemp -- ********************************************************************* -- * * -- * We build a list of perimeters by constructing each backward * -- * from position 59. However, position 59 needs special handling * -- * because it must match position 0 as well as 58. Each of the * -- * other corners will also need special handling, which is done * -- * by a case statement. * -- * * -- * Note that pArray is organized by the left sides of the pieces, * -- * while in makePerim we need to check the right side of a * -- * against the bottom of the first corner. This results in the * -- * need for rightArray, and some tricky indexing. * -- * * -- ********************************************************************* makPerim :: (Int,Int,Int,Int) -> Array (Int) [Int] -> [[Int]] makPerim oneCor pArray = [a:b | a <- ((rightArray) ! startCol), b <- (restPerim a (pArray // [(left(refPerim!a), (pArray!(left(refPerim!a)))\\[a])]) (rightArray //[(startCol, (rightArray ! startCol) \\ [a])]) oneCor 58), trace (show b) b /=[] ] where startCol = bot (corns !! (fst4 oneCor)) -- ********************************************************************* -- * * -- * Once past the first piece in a perimeter, move to next. * -- * Check for a corner piece, which needs special handling. * -- * If there are no candidates left to match last, terminate * -- * the recursion, indicating there is no way to continue. * -- * Otherwise, construct the list of possible continuations of * -- * the perimeter. * -- * * -- ********************************************************************* -- restPerim last leftRay rightRay oneCor iAm | -- trace ((show iAm)++" "++ (show last)) elem iAm [0,15,30,45] = corner last leftRay rightRay oneCor iAm | useRow /= [] = extend | otherwise = [] where useRow = rightRay ! (left (refPerim ! last)) extend = [b:c | b <- (rightRay ! (left (refPerim ! last))), c <- restPerim b (newLeft b) (newRight b) oneCor (iAm - 1), --trace (show c) c/=[]] newLeft b = leftRay // [((left (refPerim ! b)), (leftRay ! (left (refPerim ! b))) \\ [b])] newRight b = rightRay // [((right (refPerim ! b)), (rightRay ! (right (refPerim ! b))) \\ [b])] -- ********************************************************************* -- * * -- * Corners get special handling. The corner in the upper left is * -- * always piece 1, because of rotational symmetry. * -- * * -- ********************************************************************* -- corner last leftRay rightRay oneCor iAm | -- trace ((show last)++" "++(show iAm)) iAm == 15 = if (gTst3 leftRay rightRay) then (trace "goOn") goOn (snd4 oneCor) else trace "fail" [] | -- trace "goo" iAm == 30 = goOn (thd4 oneCor) | -- trace "gah" iAm == 45 = goOn (fth4 oneCor) | -- trace "gii" iAm == 0 = if (lastLeft == rightCor 1) then [[1]] else [] | otherwise = error ("\n\n *** You can't get here"++ " *** \n\n") where lastLeft = left (refPerim ! last) rightCor b = right (refPerim ! b) botCor b = bot (refPerim ! b) nLeft b = left (refPerim ! b) goOn q = if (lastLeft /= rightCor q) then [] else [q:c:d | c <- (leftRay ! (botCor q)), d <- -- trace ((show q)++" "++ -- (show c)++"xx ") restPerim c (newleft c) (newright c) oneCor (iAm - 2) ] newleft c = leftRay // [((nLeft c), leftRay!(nLeft c)\\[c])] newright c = rightRay // [((rightCor c), rightRay!(rightCor c)\\ [c])] -- ********************************************************************* -- * * -- * agTst is a simple heuristic test to determine whether it is * -- * possible for a perimeter to be built with the remaining * -- * pieces: it tests to find out whether there are an equal no. of * -- * pieces whose right side matches the left sides of available * -- * pieces, except, perhaps for 1, which will fit a corner piece. * -- * * -- * And it doesn't work, at least at the beginning of the solution.* -- * In the first 10,000,000 passages through corner 15, there is * -- * only 1 fail. * -- * * -- ********************************************************************* gTst :: Array Int [Int] -> Array Int [Int] -> Bool gTst right left = and $ map tryme (indices right) where iList = indices right tryme x | (length (right ! x)) == (length (left ! x)) = True | abs ((length (right ! x))- (length (left ! x))) == 1 = True | otherwise = False gTst1:: Array Int [Int] -> Array Int [Int] -> Bool gTst1 right left = if (sum $ map tryme (indices right)) > 2 then False else True where tryme x = abs ((length (right ! x)) - (length (left ! x))) gTst2 right left = if (length (left ! 2)) > 0 then True else False gTst3 right left = if ((lr > ll+2)||(lr < ll-2)) then False else True where lr = length (right ! 2) ll = length (left ! 2) -- ********************************************************************* -- * * -- * Here we make up a list of the 6 possible corner configurations * -- * There are only 6 such because the remaining permutations of * -- * corner pieces are merely rotations of the six used here. * -- * * -- ********************************************************************* corTemp :: [(Int,Int,Int,Int)] corTemp = [(1,2,3,4),(1,2,4,3),(1,3,2,4),(1,3,4,2),(1,4,2,3),(1,4,3,2)] corns = [(0,0,0,0,0), (0,0,2,1,1),(0,0,2,3,2),(0,0,4,1,3),(0,0,1,4,4)] -- ********************************************************************* -- * * -- * Construct an array in which each entry is a list of pieces * -- * that have the same color on the left side. This array will be * -- * used to construct the perimeters of the puzzle. * -- * * -- * We use pArray as an array of available pieces, and refPerim * -- * in order to find the matching colors; since it changes a lot, * -- * the reduced item count will reduce overhead from building new * -- * pArray's. * -- * * -- ********************************************************************* pSides:: [(Int,Int,Int,Int,Int)] pSides = [(2,0,2,5,5),(4,0,2,6,6),(2,0,2,7,7),(8,0,2,7,8),(1,0,2,9,9), (3,0,2,10,10),(4,0,2,11,11),(3,0,2,12,12),(8,0,2,12,13), (3,0,2,13,14),(2,0,4,6,15),(1,0,4,14,16),(8,0,4,15,17), (8,0,4,16,18),(4,0,4,10,19),(4,0,4,11,20),(3,0,4,17,21), (2,0,4,18,22),(8,0,4,18,23),(2,0,4,19,24),(2,0,4,13,25), (4,0,1,5,26),(1,0,1,5,27),(1,0,1,6,28),(1,0,1,14,29), (8,0,1,10,30),(4,0,1,11,31),(1,0,1,19,32),(4,0,1,12,33), (3,0,1,12,34),(8,0,1,20,35),(3,0,1,21,36),(2,0,3,14,37), (8,0,3,22,38),(8,0,3,9,39),(4,0,3,16,40),(1,0,3,16,41), (2,0,3,11,42),(4,0,3,11,43),(1,0,3,11,44),(2,0,3,17,45), (3,0,3,19,46),(3,0,3,12,47),(3,0,3,20,48),(8,0,8,5,49), (2,0,8,6,50),(4,0,8,6,51),(2,0,8,7,52),(3,0,8,10,53), (3,0,8,17,54),(8,0,8,17,55),(1,0,8,12,56),(2,0,8,20,57), (8,0,8,20,58),(4,0,8,13,59),(1,0,8,21,60)] pArray:: [(Int,Int,Int,Int,Int)] -> Array (Int) [Int] pArray pSides = accumArray (++) [] (1,8) accumPlist rightArray:: Array (Int) [Int] rightArray = accumArray (++) [] (1,8) rightAccum rightAccum = map (\item ->((right item),[piece item])) pSides accumPlist = map (\item ->((left item),[piece item])) pSides refPerim:: Array (Int) (Int,Int,Int,Int,Int) refPerim = listArray (1,60) (trace "don't get here"(drop 1 corns)++pSides) -- ********************************************************************* -- * * -- * Pretty-printer for corner configurations. * -- * * -- * * -- ********************************************************************* corpic = concat $ map oneSq corTemp oneSq (a,b,c,d) = show (corns !! a) ++ " " ++ show (corns !! b) ++ "\n\n" ++ show (corns !! c)++" "++show (corns !! d) ++ "\n\n\n" -- ********************************************************************* -- * * -- * Ugly-printer for pArray, the array of pieces for the * -- * perimeter. * -- * * -- * * -- ********************************************************************* pArrayPic myray = concatMap (\x-> (show x)++"\n\n") (elems myray) -- ********************************************************************* -- * * -- * Convenience functions. * -- * * -- ********************************************************************* left:: (Int,Int,Int,Int,Int) -> Int left (a,b,c,d,e) = a fst4 (a,b,c,d) = a top (a,b,c,d,e) = b snd4 (a,b,c,d) =b right (a,b,c,d,e) = c thd4 (a,b,c,d) = c bot (a,b,c,d,e) = d fth4 (a,b,c,d) = d piece (a,b,c,d,e) = e From jefferson.r.heard at gmail.com Tue Jan 6 12:08:47 2009 From: jefferson.r.heard at gmail.com (Jeff Heard) Date: Tue Jan 6 12:00:22 2009 Subject: [Haskell-cafe] Template Haskell question Message-ID: <4165d3a70901060908y1c47665atb6b204bbce07a852@mail.gmail.com> Alright... I *think* I'm nearly there, but I can't figure out how to derive a class instance using record accessors and updaters... Can anyone help? There are [| XXXf |] instances at the end of the module and they all need replaced, but I can't figure out what to replace them with. The basic idea of the module is that you define your record type, Q, and that record type contains all the state you're interested in. The Hieroglyph system has other basic state, and the idea is that you use $(additions "QWithState" ''Q) $(deriveUIState ''QWithState) to create your final UIState instance. -- - {-# LANGUAGE TemplateHaskell #-} module Graphics.Rendering.Hieroglyph.TH where import Language.Haskell.TH import Language.Haskell.TH.Syntax import Graphics.Rendering.Hieroglyph.UIState import Graphics.Rendering.Hieroglyph.Primitives import Graphics.UI.Gtk.Types (Widget) import Control.Monad {- output of $( fmap (LitE . StringL . show) [| reify ''BasicUIState |] ) TyConI (DataD [] Graphics.Rendering.Hieroglyph.BasicUIState.BasicUIState [] [RecC Graphics.Rendering.Hieroglyph.BasicUIState.BasicUIState [(Graphics.Rendering.Hieroglyph.BasicUIState.mousePosition,NotStrict,ConT Graphics.Rendering.Hieroglyph.Primitives.Point) ,(Graphics.Rendering.Hieroglyph.BasicUIState.mouseLeftButtonDown,NotStrict,ConT GHC.Base.Bool) ,(Graphics.Rendering.Hieroglyph.BasicUIState.mouseRightButtonDown,NotStrict,ConT GHC.Base.Bool) ,(Graphics.Rendering.Hieroglyph.BasicUIState.mouseMiddleButtonDown,NotStrict,ConT GHC.Base.Bool) ,(Graphics.Rendering.Hieroglyph.BasicUIState.mouseWheel,NotStrict,ConT GHC.Base.Int) ,(Graphics.Rendering.Hieroglyph.BasicUIState.keyCtrl,NotStrict,ConT GHC.Base.Bool) ,(Graphics.Rendering.Hieroglyph.BasicUIState.keyShift,NotStrict,ConT GHC.Base.Bool) ,(Graphics.Rendering.Hieroglyph.BasicUIState.keyAlt,NotStrict,ConT GHC.Base.Bool) ,(Graphics.Rendering.Hieroglyph.BasicUIState.key,NotStrict,ConT Graphics.Rendering.Hieroglyph.UIState.Key) ,(Graphics.Rendering.Hieroglyph.BasicUIState.drawing,NotStrict,AppT (ConT Data.Maybe.Maybe) (ConT Graphics.UI.Gtk.Types.Widget)) ,(Graphics.Rendering.Hieroglyph.BasicUIState.sizeX,NotStrict,ConT GHC.Float.Double) ,(Graphics.Rendering.Hieroglyph.BasicUIState.sizeY,NotStrict,ConT GHC.Float.Double) ,(Graphics.Rendering.Hieroglyph.BasicUIState.imageCache,NotStrict,AppT (ConT Data.Maybe.Maybe) (ConT Graphics.Rendering.Hieroglyph.UIState.ImageCache))]] []) -} -- usage: $(additions "MyTypeName" OldTypeName) {- - Add fields to a record type for handling basic UI state for Hieroglyph. Gives you mouse buttons, etcetera -} additions newtypenamestr nm = do TyConI (DataD _ _ _ [RecC _ fielddefs]) <- reify nm let newtypename = mkName newtypenamestr return $ (DataD [] newtypename [] [RecC newtypename [(mkName "mousePositionf",NotStrict,ConT ''Point) ,(mkName "mouseLeftButtonDownf",NotStrict,ConT ''Bool) ,(mkName "mouseRightButtonDownf",NotStrict,ConT ''Bool) ,(mkName "mouseMiddleButtonDownf",NotStrict,ConT ''Bool) ,(mkName "mouseWheelf",NotStrict,ConT ''Int) ,(mkName "keyCtrlf",NotStrict,ConT ''Bool) ,(mkName "keyShiftf",NotStrict,ConT ''Bool) ,(mkName "keyAltf",NotStrict,ConT ''Bool) ,(mkName "keyf",NotStrict,ConT ''Key) ,(mkName "drawingf",NotStrict,AppT (ConT ''Maybe) (ConT ''Widget)) ,(mkName "sizeXf",NotStrict,ConT ''Double) ,(mkName "sizeYf",NotStrict,ConT ''Double) ,(mkName "imageCachef",NotStrict,AppT (ConT ''Maybe) (ConT ''ImageCache))] ++ fielddefs] []) -- | Apply a Binary type constructor to given type: "t" -> "Binary t" appUIState :: Type -> Type appUIState t = AppT (ConT ''UIState) t -- | Generate from list of type names result of types application: -- appType T [a,b] -> "T a b" appType :: Name -> [Name] -> Type --appType t [] = ConT t -- T --appType t [t1] = AppT (ConT t) (VarT t1) -- T a --appType t [t1,t2] = AppT (AppT (ConT t) (VarT t1)) (VarT t2) -- T a b == (T a) b appType t ts = foldl (\a e -> AppT a (VarT e)) (ConT t) ts -- general definition -- | Generate `n` unique variables and return them in form of patterns and expressions genNames :: Int -> Q ([PatQ],[ExpQ]) genNames n = do ids <- replicateM n (newName "x") return (map varP ids, map varE ids) -- usage: $(deriveUIState ''MyTypeWithUIState) {- - Derive an instance of UIState from some type that has had UIState fields added to it. -} deriveUIState tp = do return [InstanceD [] (appUIState $ appType tp []) [FunD 'mousePosition [| mousePositionf |] ,FunD 'mouseLeftButtonDown [| mouseLeftButtonDownf |] ,FunD 'mouseRightButtonDown [| mouseRightButtonDownf |] ,FunD 'mouseMiddleButtonDown [| mouseMiddleButtonDownf |] ,FunD 'mouseWheel [| mouseWheelf |] ,FunD 'keyCtrl [| keyCtrlf |] ,FunD 'keyShift [| keyShiftf |] ,FunD 'keyAlt [| keyAltf |] ,FunD 'key [| keyf |] ,FunD 'drawing [| drawingf |] ,FunD 'sizeX [| sizeXf |] ,FunD 'sizeY [| sizeYf |] ,FunD 'imageCache [| imageCachef |] ,FunD 'setMousePosition [| \b a -> a{ mousePositionf=b } |] ,FunD 'setMouseLeftButtonDown [| \b a -> a{ mouseLeftButtonDownf=b } |] ,FunD 'setMouseRightButtonDown [| \b a -> a{ mouseRightButtonDownf=b } |] ,FunD 'setMouseMiddleButtonDown [| \b a -> a{ mouseMiddleButtonDownf=b } |] ,FunD 'setMouseWheel [| \b a -> a{ mouseWheelf=b } |] ,FunD 'setKeyCtrl [| \b a -> a{ keyCtrlf=b } |] ,FunD 'setKeyShift [| \b a -> a{ keyShiftf=b } |] ,FunD 'setKeyAlt [| \b a -> a{ keyAltf=b } |] ,FunD 'setKey [| \b a -> a{ keyf=b } |] ,FunD 'setDrawing [| \b a -> a{ drawingf=b } |] ,FunD 'setSizeX [| \b a -> a{ sizeXf=b } |] ,FunD 'setSizeY [| \b a -> a{ sizeYf=b } |] ,FunD 'setImageCache] [| \b a -> a{ imageCachef=b } |] ] From redcom at fedoms.com Tue Jan 6 13:06:38 2009 From: redcom at fedoms.com (=?iso-8859-15?Q?G=FCnther_Schmidt?=) Date: Tue Jan 6 12:58:23 2009 Subject: [Haskell-cafe] HDBC-Sqlite3 "attaching databases" Message-ID: Hi, has anybody here successfully tried to "attach" another database to an Sqlite database with HDBC-Sqlite3? I keep failing, so I'd be grateful for a hint how to do it. G?nther From roma at ro-che.info Tue Jan 6 13:24:05 2009 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue Jan 6 13:15:46 2009 Subject: [Haskell-cafe] bug in HPDF? Message-ID: <20090106182404.GA11316@flit> Here is a program which illustrates an unexpected behaviour: import Graphics.PDF main = runPdf "bug.pdf" standardDocInfo (PDFRect 0 0 100 100) pdf where pdf = do p <- addPage Nothing drawWithPage p $ drawText $ sequence $ replicate 10 $ text (PDFFont Helvetica 10) 10 10 (toPDFString "ABC") What I expect here is "ABC" printed 10 times on the same place (starting at (10,10)). What I see (in Okular) is ABC printed each time in the new place like this: ABC ABC ABC ABC What's happening here? I'm using HPDF-1.4.1 from Hackage. -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain From misc at alpheccar.org Tue Jan 6 13:37:31 2009 From: misc at alpheccar.org (alpheccar) Date: Tue Jan 6 13:29:12 2009 Subject: [Haskell-cafe] Re: bug in HPDF? In-Reply-To: <20090106182404.GA11316@flit> References: <20090106182404.GA11316@flit> Message-ID: <52017652-7C7E-4DA9-94B1-E2289ABC85BD@alpheccar.org> Roman, The text monad is very low level and its functions are mapping directly to the PDF text environment commands. "text" function is generating two PDF commands : Td and Tj. In Adobe PDF spec : Td : Move to the start of the next line, offset from the start of the current line by (tx , ty ). tx and ty are numbers expressed in unscaled text space units. Tj : Show a text string. So, the behavior is correct and HPDF really needs a documentation :-) and some cleaning of the API. Thanks, Christophe. > Here is a program which illustrates an unexpected behaviour: > > import Graphics.PDF > > main = runPdf "bug.pdf" standardDocInfo (PDFRect 0 0 100 100) pdf > where > pdf = do > p <- addPage Nothing > drawWithPage p $ drawText $ > sequence $ replicate 10 $ > text (PDFFont Helvetica 10) 10 10 (toPDFString "ABC") > > What I expect here is "ABC" printed 10 times on the same place > (starting > at (10,10)). What I see (in Okular) is ABC printed each time in the > new > place like this: > > ABC > ABC > ABC > ABC > > What's happening here? I'm using HPDF-1.4.1 from Hackage. > > -- > Roman I. Cheplyaka :: http://ro-che.info/ > "Don't let school get in the way of your education." - Mark Twain -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090106/a68f5d7c/attachment.htm From dons at galois.com Tue Jan 6 13:49:09 2009 From: dons at galois.com (Don Stewart) Date: Tue Jan 6 13:40:32 2009 Subject: [Haskell-cafe] Maybe a compiler bug? In-Reply-To: References: <7ca3f0160901051556j51d21edat457c7fa80beb4640@mail.gmail.com> <351ff25e0901060208u30480fcdxa4a731ec1bc965b8@mail.gmail.com> <404396ef0901060220l196213d8hf446492281042794@mail.gmail.com> <404396ef0901060735w4d1dc4c4w6559d6c26bddef9c@mail.gmail.com> Message-ID: <20090106184909.GB15794@scytale.galois.com> If you believe this is a compiler bug, please report it: http://hackage.haskell.org/trac/ghc/newticket?type=bug mgross21: > > > My last note had an error in it, and the code originally sent to the list > should be ignored. I have attached the current version of the code, and > here is some further information (the behavior is different, by the way, > but still apparently wrong). > > I have attached the current version of the program, which behaves > slightly differently from the version originally sent. > > I am running ghc 6.6, gcc 4.1.2, g++ 4.1.1, on Debian Linux. The compile > lines are ghc -threaded solve.hs or ghc -threaded -O2 solve.hs. The > execution line is ./a.out, which should give me single-threaded execution. > > Ignore the output on stdout; it is the same for both versions. > > On stderr, the unoptimized version of the attached code gives me both > "fail" and "goOn" (see lines #150 and #153). The optimized version gives > me only "goOn." I think that both should give me both "fail" and "goOn." > > Were circumstances different, I might suspect that laziness and > optimization had something to do with this. However, earlier tests showed > inconsistency between the result of the test in gTst3 and the code where > the value of gTst3 is used. > > A copy of the current version of solve.hs is attached. > > Best, > > Murray Gross > > P.S.: For anyone who has actually looked at the logic, I am aware that the > test in gTst3 can be sharpened. That will come later. The current version > is adequate for the time being. Content-Description: Current version of solve.hs > -- ********************************************************************* > -- * * > -- * Eternity II puzzle. Each puzzle piece is represented by a * > -- * 5-tuple, in which the first 4 entries represent the four * > -- * edge colors in the order left, top, right, bottom, and the * > -- * fifth member is the (numerical) identifier for the piece. * > -- * * > -- ********************************************************************* > > -- module Solve where > > > import Data.Array.IArray > import Control.Parallel > import Control.Parallel.Strategies > import List > import Debug.Trace > > > > main = putStrLn (show corns) >> > putStrLn (corpic) >> > putStrLn "Left sides\n">> > > putStrLn (pArrayPic (pArray pSides)) >> > putStrLn "Right sides\n">> > putStrLn (pArrayPic (rightArray ))>> > putStrLn (show (length (perims (pArray pSides) corTemp))) >> > putStrLn (show (perims (pArray pSides) corTemp))>> > putStrLn "done" > > > > > -- ********************************************************************* > -- * * > -- * Make a list of all possible perimeters. Run the operation in * > -- * parallel over the list of possible corner configurations. * > -- * * > -- ********************************************************************* > > > perims:: Array (Int) [Int]-> > [(Int,Int,Int,Int)]->[[Int]] > perims pArray corTemp = concat $ parMap rwhnf (\oneCor->makPerim > oneCor pArray > ) > corTemp > > > -- ********************************************************************* > -- * * > -- * We build a list of perimeters by constructing each backward * > -- * from position 59. However, position 59 needs special handling * > -- * because it must match position 0 as well as 58. Each of the * > -- * other corners will also need special handling, which is done * > -- * by a case statement. * > -- * * > -- * Note that pArray is organized by the left sides of the pieces, * > -- * while in makePerim we need to check the right side of a * > -- * against the bottom of the first corner. This results in the * > -- * need for rightArray, and some tricky indexing. * > -- * * > -- ********************************************************************* > > makPerim :: (Int,Int,Int,Int) -> Array (Int) [Int] -> [[Int]] > makPerim oneCor > pArray = [a:b | a <- ((rightArray) ! startCol), b <- > (restPerim a > (pArray // [(left(refPerim!a), > (pArray!(left(refPerim!a)))\\[a])]) > > (rightArray //[(startCol, > (rightArray ! startCol) \\ [a])]) > oneCor > 58), > trace (show b) > b /=[] > ] > where startCol = bot (corns !! (fst4 oneCor)) > > > -- ********************************************************************* > -- * * > -- * Once past the first piece in a perimeter, move to next. * > -- * Check for a corner piece, which needs special handling. * > -- * If there are no candidates left to match last, terminate * > -- * the recursion, indicating there is no way to continue. * > -- * Otherwise, construct the list of possible continuations of * > -- * the perimeter. * > -- * * > -- ********************************************************************* > -- > > > restPerim last > leftRay > rightRay > oneCor > iAm | -- trace ((show iAm)++" "++ (show last)) > elem iAm [0,15,30,45] = corner last > leftRay > rightRay > oneCor > iAm > > | useRow /= [] = extend > > | otherwise = [] > > > where useRow = rightRay ! (left (refPerim ! last)) > extend = [b:c | b <- (rightRay ! (left > (refPerim ! last))), > c <- restPerim > b > (newLeft b) > (newRight b) > oneCor > (iAm - 1), > --trace (show c) > c/=[]] > newLeft b = leftRay // > [((left (refPerim ! b)), > (leftRay ! (left (refPerim ! b))) > \\ [b])] > newRight b = rightRay // > [((right (refPerim ! b)), > (rightRay ! (right (refPerim ! b))) > \\ [b])] > > > -- ********************************************************************* > -- * * > -- * Corners get special handling. The corner in the upper left is * > -- * always piece 1, because of rotational symmetry. * > -- * * > -- ********************************************************************* > -- > > > corner last > leftRay > rightRay > oneCor > iAm > > | -- trace ((show last)++" "++(show iAm)) > iAm == 15 = if (gTst3 leftRay rightRay) then > (trace "goOn") > goOn (snd4 oneCor) > else > trace "fail" > [] > | -- trace "goo" > iAm == 30 = goOn (thd4 oneCor) > | -- trace "gah" > iAm == 45 = goOn (fth4 oneCor) > | -- trace "gii" > iAm == 0 = if (lastLeft == rightCor 1) then [[1]] > else [] > | otherwise = error ("\n\n *** You can't get here"++ > " *** \n\n") > > > where lastLeft = left (refPerim ! last) > rightCor b = right (refPerim ! b) > botCor b = bot (refPerim ! b) > nLeft b = left (refPerim ! b) > > goOn q = if (lastLeft /= rightCor q) then > [] > else [q:c:d | c <- (leftRay ! > (botCor q)), > d <- > -- trace ((show q)++" "++ > -- (show c)++"xx ") > > restPerim c > (newleft c) > (newright c) > oneCor > (iAm - 2) > ] > newleft c = leftRay // > [((nLeft c), > leftRay!(nLeft c)\\[c])] > newright c = rightRay // > [((rightCor c), > rightRay!(rightCor c)\\ > [c])] > > -- ********************************************************************* > -- * * > -- * agTst is a simple heuristic test to determine whether it is * > -- * possible for a perimeter to be built with the remaining * > -- * pieces: it tests to find out whether there are an equal no. of * > -- * pieces whose right side matches the left sides of available * > -- * pieces, except, perhaps for 1, which will fit a corner piece. * > -- * * > -- * And it doesn't work, at least at the beginning of the solution.* > -- * In the first 10,000,000 passages through corner 15, there is * > -- * only 1 fail. * > -- * * > -- ********************************************************************* > > gTst :: Array Int [Int] -> Array Int [Int] -> Bool > gTst right left = and $ map tryme (indices right) > > where iList = indices right > tryme x | (length (right ! x)) == > (length (left ! x)) = True > > | abs ((length (right ! x))- > (length (left ! x))) == > 1 = True > | otherwise = False > > gTst1:: Array Int [Int] -> Array Int [Int] -> Bool > gTst1 right left = if (sum $ map tryme (indices right)) > 2 then False > else True > where tryme x = abs ((length (right ! x)) - > (length (left ! x))) > gTst2 right left = if (length (left ! 2)) > 0 then True else False > > gTst3 right left = if ((lr > ll+2)||(lr < ll-2)) then False else True > where lr = length (right ! 2) > ll = length (left ! 2) > > -- ********************************************************************* > -- * * > -- * Here we make up a list of the 6 possible corner configurations * > -- * There are only 6 such because the remaining permutations of * > -- * corner pieces are merely rotations of the six used here. * > -- * * > -- ********************************************************************* > > corTemp :: [(Int,Int,Int,Int)] > corTemp = [(1,2,3,4),(1,2,4,3),(1,3,2,4),(1,3,4,2),(1,4,2,3),(1,4,3,2)] > > corns = [(0,0,0,0,0), (0,0,2,1,1),(0,0,2,3,2),(0,0,4,1,3),(0,0,1,4,4)] > > > -- ********************************************************************* > -- * * > -- * Construct an array in which each entry is a list of pieces * > -- * that have the same color on the left side. This array will be * > -- * used to construct the perimeters of the puzzle. * > -- * * > -- * We use pArray as an array of available pieces, and refPerim * > -- * in order to find the matching colors; since it changes a lot, * > -- * the reduced item count will reduce overhead from building new * > -- * pArray's. * > -- * * > -- ********************************************************************* > > pSides:: [(Int,Int,Int,Int,Int)] > pSides = [(2,0,2,5,5),(4,0,2,6,6),(2,0,2,7,7),(8,0,2,7,8),(1,0,2,9,9), > (3,0,2,10,10),(4,0,2,11,11),(3,0,2,12,12),(8,0,2,12,13), > (3,0,2,13,14),(2,0,4,6,15),(1,0,4,14,16),(8,0,4,15,17), > (8,0,4,16,18),(4,0,4,10,19),(4,0,4,11,20),(3,0,4,17,21), > (2,0,4,18,22),(8,0,4,18,23),(2,0,4,19,24),(2,0,4,13,25), > (4,0,1,5,26),(1,0,1,5,27),(1,0,1,6,28),(1,0,1,14,29), > (8,0,1,10,30),(4,0,1,11,31),(1,0,1,19,32),(4,0,1,12,33), > > (3,0,1,12,34),(8,0,1,20,35),(3,0,1,21,36),(2,0,3,14,37), > (8,0,3,22,38),(8,0,3,9,39),(4,0,3,16,40),(1,0,3,16,41), > (2,0,3,11,42),(4,0,3,11,43),(1,0,3,11,44),(2,0,3,17,45), > (3,0,3,19,46),(3,0,3,12,47),(3,0,3,20,48),(8,0,8,5,49), > > (2,0,8,6,50),(4,0,8,6,51),(2,0,8,7,52),(3,0,8,10,53), > (3,0,8,17,54),(8,0,8,17,55),(1,0,8,12,56),(2,0,8,20,57), > (8,0,8,20,58),(4,0,8,13,59),(1,0,8,21,60)] > > > pArray:: [(Int,Int,Int,Int,Int)] -> Array (Int) > [Int] > pArray pSides = accumArray (++) [] (1,8) accumPlist > > rightArray:: Array (Int) [Int] > rightArray = accumArray (++) [] (1,8) rightAccum > rightAccum = map (\item ->((right item),[piece item])) pSides > > > accumPlist = map (\item ->((left item),[piece item])) pSides > > refPerim:: Array (Int) (Int,Int,Int,Int,Int) > > refPerim = listArray (1,60) (trace "don't get here"(drop 1 corns)++pSides) > > -- ********************************************************************* > -- * * > -- * Pretty-printer for corner configurations. * > -- * * > -- * * > -- ********************************************************************* > > corpic = concat $ map oneSq corTemp > > oneSq (a,b,c,d) = show (corns !! a) ++ " " ++ show (corns !! b) ++ > "\n\n" ++ > show (corns !! c)++" "++show (corns !! d) ++ "\n\n\n" > > > -- ********************************************************************* > -- * * > -- * Ugly-printer for pArray, the array of pieces for the * > -- * perimeter. * > -- * * > -- * * > -- ********************************************************************* > > pArrayPic myray = concatMap (\x-> (show x)++"\n\n") (elems myray) > > > -- ********************************************************************* > -- * * > -- * Convenience functions. * > -- * * > -- ********************************************************************* > > left:: (Int,Int,Int,Int,Int) -> Int > left (a,b,c,d,e) = a > fst4 (a,b,c,d) = a > > top (a,b,c,d,e) = b > snd4 (a,b,c,d) =b > > right (a,b,c,d,e) = c > thd4 (a,b,c,d) = c > > bot (a,b,c,d,e) = d > fth4 (a,b,c,d) = d > > > piece (a,b,c,d,e) = e > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From roma at ro-che.info Tue Jan 6 13:51:12 2009 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue Jan 6 13:42:50 2009 Subject: [Haskell-cafe] Re: bug in HPDF? In-Reply-To: References: <20090106182404.GA11316@flit> Message-ID: <20090106185112.GA14466@flit> Thanks for helping! * alpheccar [2009-01-06 19:47:21+0100] > Roman, > > Here is the source code to do what you want: > > import Graphics.PDF > import Complex > > main = runPdf "bug.pdf" standardDocInfo (PDFRect 0 0 100 100) pdf > where > pdf = do > p <- addPage Nothing > drawWithPage p $ do > moveto $ 10 :+ 10 > sequence $ replicate 10 $ drawText $ text (PDFFont Helvetica > 10) 0 0 (toPDFString "ABC") > > > It is the Text monad that needs to be replicated. Each copy will start > drawing the text lines at (10,10) as specified by the moveto. > But, inside the text monad, each "text" will create a new line. > > Thanks, > Christophe. > > >> Here is a program which illustrates an unexpected behaviour: >> >> import Graphics.PDF >> >> main = runPdf "bug.pdf" standardDocInfo (PDFRect 0 0 100 100) pdf >> where >> pdf = do >> p <- addPage Nothing >> drawWithPage p $ drawText $ >> sequence $ replicate 10 $ >> text (PDFFont Helvetica 10) 10 10 (toPDFString "ABC") >> >> What I expect here is "ABC" printed 10 times on the same place >> (starting >> at (10,10)). What I see (in Okular) is ABC printed each time in the new >> place like this: >> >> ABC >> ABC >> ABC >> ABC >> >> What's happening here? I'm using HPDF-1.4.1 from Hackage. >> >> -- >> Roman I. Cheplyaka :: http://ro-che.info/ >> "Don't let school get in the way of your education." - Mark Twain > -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain From dons at galois.com Tue Jan 6 14:32:31 2009 From: dons at galois.com (Don Stewart) Date: Tue Jan 6 14:23:53 2009 Subject: [Haskell-cafe] Lack of inlining -> slow parsing with Data.Binary In-Reply-To: <5e0214850812260137t62d9770aw19d4469c5da43663@mail.gmail.com> References: <5e0214850812260137t62d9770aw19d4469c5da43663@mail.gmail.com> Message-ID: <20090106193231.GE15794@scytale.galois.com> ekirpichov: > Hi, > > I'm parsing Java classfiles with Data.Binary, the code is here: > http://paste.org/index.php?id=4625 > > The problem is that the resulting code parses rt.jar from JDK6 (about > 15K classes, 47Mb zipped) in 15 seconds (run the program with main > -mclose rt.jar, for instance), which is 10 times slower than my Java > version of the same code. > > I compile the program with -O2 ; I tried -ddump-inlinings and it turns > out that my readByte/readWord16/readWord32 functions don't get > inlined, despite being simply aliases for 'get::Get WordXX'; so, in > places where my Java version does a pointer access (after being > JIT-compiled), the Haskell version does two function calls. > > What can be the reason of this lack of inlining? Or how do I > understand the output of -ddump-inlinings? > Which version of GHC and Data.Binary are you using? If using 6.8.x, use the previous Data.Binary release. If using 6.10.x, use the latest. -- Don From daniel.is.fischer at web.de Tue Jan 6 14:48:51 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Jan 6 14:37:56 2009 Subject: [Haskell-cafe] Maybe a compiler bug? In-Reply-To: References: <404396ef0901060735w4d1dc4c4w6559d6c26bddef9c@mail.gmail.com> Message-ID: <200901062048.51420.daniel.is.fischer@web.de> Am Dienstag, 6. Januar 2009 18:32 schrieb Murray Gross: > My last note had an error in it, and the code originally sent to the list > should be ignored. I have attached the current version of the code, and > here is some further information (the behavior is different, by the way, > but still apparently wrong). > > I have attached the current version of the program, which behaves > slightly differently from the version originally sent. > > I am running ghc 6.6, gcc 4.1.2, g++ 4.1.1, on Debian Linux. The compile > lines are ghc -threaded solve.hs or ghc -threaded -O2 solve.hs. The > execution line is ./a.out, which should give me single-threaded execution. > > Ignore the output on stdout; it is the same for both versions. > > On stderr, the unoptimized version of the attached code gives me both > "fail" and "goOn" (see lines #150 and #153). The optimized version gives > me only "goOn." I think that both should give me both "fail" and "goOn." I get one "fail" and many "goOn" with optimisation using both, ghc-6.6 and ghc-6.8.3. That should indeed be so, because with optimisation, the branch else trace "fail" [] is only evaluated once, the result ([]) being reused. Without optimisation, that branch is re-evaluated every time it is hit, so many "fail" are printed. > > Were circumstances different, I might suspect that laziness and > optimization had something to do with this. However, earlier tests showed > inconsistency between the result of the test in gTst3 and the code where > the value of gTst3 is used. Could you elaborate? I couldn't find an inconsistency using your previous code, it behaved as it should (until I ^C-ed it). HTH, Daniel From dave at zednenem.com Tue Jan 6 14:58:47 2009 From: dave at zednenem.com (David Menendez) Date: Tue Jan 6 14:50:22 2009 Subject: [Haskell-cafe] Re: Pattern combinators In-Reply-To: References: <494DAB4A.5080509@mcmaster.ca> <49a77b7a0812202137j23ff10edw1853f5a24eb6aae9@mail.gmail.com> <49a77b7a0812221320r28b35e3ak179e7275c34e3bd1@mail.gmail.com> Message-ID: <49a77b7a0901061158v72c64412naab30d5898e5e974@mail.gmail.com> On Sat, Jan 3, 2009 at 4:06 PM, Massimiliano Gubinelli wrote: > I've tried to undestand the paper, in particular the relation between > the combinators written in cps style and combinators written using a > Maybe type (i.e pattern matching functions returning Maybe to signal > success or failure). In your implementation, they are (almost) equivalent. > newtype PatA a b = PatA { > unPatA :: forall ans. (b -> ans) -> ans -> a -> ans > } > newtype PatB a b = PatB { unPatB :: a -> Maybe b } Specifically, "PatA a b" is isomorphic to "a -> (forall ans. (b -> ans) -> ans -> ans)" and "forall ans. (b -> ans) -> ans -> ans" is (mostly) isomorphic to "Maybe b". maybe :: Maybe b -> (b -> ans) -> ans -> ans maybe (Just x) f z = f x maybe Nothing f z = z unMaybe :: (forall ans. (b -> ans) -> ans -> ans) -> Maybe b unMaybe f = f Just Nothing (As usual, seq prevents this from being a true isomorphism, because maybe (unMaybe _|_) = const (const _|_), and seq allows us to distinguish _|_ from const _|_.) I'm not sure which form is preferable. I suspect the continuation version will do less allocation, but with enough in-lining, GHC can effectively convert the Maybe version into the continuation version on its own. -- Dave Menendez From ekirpichov at gmail.com Tue Jan 6 15:05:49 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Tue Jan 6 14:57:23 2009 Subject: [Haskell-cafe] Lack of inlining -> slow parsing with Data.Binary In-Reply-To: <20090106193231.GE15794@scytale.galois.com> References: <5e0214850812260137t62d9770aw19d4469c5da43663@mail.gmail.com> <20090106193231.GE15794@scytale.galois.com> Message-ID: <5e0214850901061205k3539b045w7742915e4ae82b5d@mail.gmail.com> Thanks; I'm using GHC 6.10.1 and the latest binary now, and things get inlined perfectly well. Anyways, the main bottleneck turned out to be the performance of zip-archive , which is now (since 1-2 days ago) ~25x better, and now the Haskell version is about just 2.5x slower than the Java one, and I'm quite satisfied with this result and with the process that led to it. (Surprisingly, the bottleneck is now in a conversion from a linked list to an STArray) In case anyone is interested, here are the results of my hacking: - http://hackage.haskell.org/cgi-bin/hackage-scripts/package/digest - bindings to crc32 and adler32 from zlib - http://hackage.haskell.org/cgi-bin/hackage-scripts/package/zip-archive - updated version of zip-archive that uses digest and doesn't suffer from a crc32 bottleneck - http://hackage.haskell.org/cgi-bin/hackage-scripts/package/jarfind - the very utility in question (the classfile searcher) All in all, Haskell rocks :) 2009/1/6 Don Stewart : > ekirpichov: >> Hi, >> >> I'm parsing Java classfiles with Data.Binary, the code is here: >> http://paste.org/index.php?id=4625 >> >> The problem is that the resulting code parses rt.jar from JDK6 (about >> 15K classes, 47Mb zipped) in 15 seconds (run the program with main >> -mclose rt.jar, for instance), which is 10 times slower than my Java >> version of the same code. >> >> I compile the program with -O2 ; I tried -ddump-inlinings and it turns >> out that my readByte/readWord16/readWord32 functions don't get >> inlined, despite being simply aliases for 'get::Get WordXX'; so, in >> places where my Java version does a pointer access (after being >> JIT-compiled), the Haskell version does two function calls. >> >> What can be the reason of this lack of inlining? Or how do I >> understand the output of -ddump-inlinings? >> > > > Which version of GHC and Data.Binary are you using? > If using 6.8.x, use the previous Data.Binary release. If using 6.10.x, > use the latest. > > -- Don > -- ??????? ???????? ??????????? ??????.??????? From westondan at imageworks.com Tue Jan 6 16:25:48 2009 From: westondan at imageworks.com (Dan Weston) Date: Tue Jan 6 16:17:32 2009 Subject: [Haskell-cafe] Re: Updating doubly linked lists In-Reply-To: References: <495B6E91.8050809@van.steenbergen.nl> <2f9b2d30812311311k51d2a5adq48697976cb48af75@mail.gmail.com> <49629ED0.8080102@imageworks.com> Message-ID: <4963CC5C.9040209@imageworks.com> Apfelmus, Thanks for the reply. >>From your description (without reading the code ;)) I hope the code is better than my description! :) The structure is more like Nothing(RK 0 _) Nothing(RK 1 _) A(RK 2 4) B(RK 3 6) C(RK 2 0) > The root of the tree is the center and you can descend on the right. > But with this structure, walking from A to B is O(d) = O(n) > (where d is the distance from the origin, > n the side length of the grid) instead of O(1). No. The tree is [[Node]], where the outer list has one element for each radius that has an occupied node and each inner list has the number of nodes at the given radius. You descend the spine of the outer list radially in O(deltaR) time, which for incremental moves is O(1). Then you search for an existing inner list element in O(nk(r)), which stays fairly constant for reasonable paths (basically, the width of a path swath). > I mean, O(d) may be fine for you, but it's not O(1) for everything as > advertised. :) d is not the distance from the origin, it is nk(r), the number of nodes at a given radius: d(2) = 2, d(3) = 1. An outward radial path will only expand the tree linearly, not quadratically, in size. > Put differently, using Data.Tree.Zipper.parent on B will move you to > C, not to A. The parent of C is either A or B, depending on the path that created it, but parent teleports you in O(1). Walking from A to B only involves: (bX,bY) = (-3,0) (aX,aY) = (-2,0) (bR,bK) = (|bX| + |bY|, bR - bX) = (3,6) -- left halfplane (aR,aK) = (|aX| + |aY|, aR - aX) = (2,4) -- left halfplane deltaR = bR - aR = 1 maybe (insertDownFirst (newNode rk) z) (moveAround rk) $ firstChild z When firstChild fails, insertDownFirst and we're done! All operations are O(1). When firstChild succeeds, moveAround queries each of the defined nodes -- but not any of the undefined nodes! -- at that radius. There is at most one defined node with Nothing value to ensure a path from the origin to every node (where path is not contiguous in X,Y, or K, only in R!) The diagram you describe can be created with: Prelude> :l GridZipper *GridZipper> let f &&& g = \x -> (f x, g x) *GridZipper> let f >>> g = g . f *GridZipper> const (newGrid :: Grid String) >>> fromTree >>> west >>> west >>> setValue (Just "A: X=-2,Y=0,R=2,K=4") >>> west >>> setValue (Just "B: X=-3,Y=0,R=3,K=6") >>> east >>> east >>> east >>> east >>> east >>> setValue (Just "C: X= 2,Y=0,R=2,K=0") >>> assocList >>> show >>> putStrLn $ () -- The tree is this: [(XY (-2) 0,"A: X=-2,Y=0,R=2,K=4"), (XY (-3) 0,"B: X=-3,Y=0,R=3,K=6"), (XY 2 0,"C: X= 2,Y=0,R=2,K=0")] -- Zipper starts at origin: Loc {tree = Node {rootLabel = GridLabel (RK 0 0) Nothing, subForest = []}, lefts = [], rights = [], parents = []} -- Zipper after walking to A and setting value: Loc {tree = Node {rootLabel = GridLabel (RK 2 4) (Just "A: X=-2,Y=0,R=2,K=4"), subForest = []}, lefts = [], rights = [], parents = [([],GridLabel (RK 1 2) Nothing,[]) ,([],GridLabel (RK 0 0) Nothing,[])]} -- Zipper after walking to B and setting value: Loc {tree = Node {rootLabel = GridLabel (RK 3 6) (Just "B: X=-3,Y=0,R=3,K=6"), subForest = []}, lefts = [], rights = [], parents = [([],GridLabel (RK 2 4) (Just "A: X=-2,Y=0,R=2,K=4"), []),([],GridLabel (RK 1 2) Nothing,[]) ,([],GridLabel (RK 0 0) Nothing,[])]} -- Zipper where it left off at C: (Loc {tree = Node {rootLabel = GridLabel (RK 2 0) (Just "C: X=2,Y=0,R=2,K=0"), subForest = []}, lefts = [], rights = [], parents = [([Node {rootLabel = GridLabel (RK 1 2) Nothing, subForest = [Node {rootLabel = GridLabel (RK 2 4) (Just "A: X=-2,Y=0,R=2,K=4"), subForest = [Node {rootLabel = GridLabel (RK 3 6) (Just "B: X=-3,Y=0,R=3,K=6"), subForest = []}]}]}], GridLabel (RK 1 0) Nothing,[]), ([],GridLabel (RK 0 0) Nothing,[])]}, -- Zipper at origin Loc {tree = Node {rootLabel = GridLabel (RK 0 0) Nothing, subForest = [Node {rootLabel = GridLabel (RK 1 2) Nothing, subForest = [Node {rootLabel = GridLabel (RK 2 4) (Just "A: X=-2,Y=0,R=2,K=4"), subForest = [Node {rootLabel = GridLabel (RK 3 6) (Just "B: X=-3,Y=0,R=3,K=6"), subForest = [] } ]} ]}, Node {rootLabel = GridLabel (RK 1 0) Nothing, subForest = [Node {rootLabel = GridLabel (RK 2 0) (Just "C: X=2,Y=0,R=2,K=0"), subForest = [] }] }]}, lefts = [], rights = [], parents = []}) Apfelmus, Heinrich wrote: > Dan Weston wrote: >>> For the 2D grid zipper above, moving around is O(1) but update is O(log >>> n). This is acceptable; also because I'm quite confident that a zipper >>> for a 2D grid with everything O(1) does not exist. I can prove that for >>> a special case and should probably write it down at some point. >> Really? My solution (rose tree zipper where tree depth is manhattan >> distance from origin and forest width is nodes around concentric >> diamonds, see >> http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/49948) was >> designed specifically to be amortized constant for everything for paths >> that do not specifically move helically around the origin. The >> complexity of lookup is O(d) where d is the number of defined nodes at a >> given radius. Until the grid gets pretty dense, d grows very slowly for >> most sane paths. >> >> Have I missed something? > >>From your description (without reading the code ;)), I gather that your > tree looks something like this? > > -+- > / \ > -+ -+- +- > / / \ \ > -+ -+ -+- +- +- > / / / \ \ \ > -+ -+ -+ -+- +- +- +- > / / / / \ \ \ \ > + B A + +--+--C--+--+-- ... > \ \ \ \ / / / / > -+ -+ -+ -+- +- +- +- > \ \ \ / / / > -+ -+ -+- +- +- > \ \ / / > -+ -+- +- > \ / > -+- > > The root of the tree is the center and you can descend on the right. But > with this structure, walking from A to B is O(d) = O(n) (where d is the > distance from the origin, n the side length of the grid) instead of O(1). > > Put differently, using Data.Tree.Zipper.parent on B will move you to > C, not to A. > > > I mean, O(d) may be fine for you, but it's not O(1) for everything as > advertised. :) > > > Regards, > H. Apfelmus > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From newhoggy at gmail.com Tue Jan 6 18:05:56 2009 From: newhoggy at gmail.com (John Ky) Date: Tue Jan 6 17:57:31 2009 Subject: [Haskell-cafe] Tying a simple circularly STM linked list Message-ID: Hi, I've written a circularly linked list, but there is some code in it I feel is redundant, but don't know how to get rid of: -- Transactional loop. A loop is a circular link list. data Loop a = ItemLink { item :: a , prev :: TVar (Loop a) , next :: TVar (Loop a) } | InitLink -- Create a new empty transactional loop. newLoop :: a -> STM (TVar (Loop a)) newLoop item = do tLoop <- newTVar InitLink writeTVar tLoop (ItemLink item tLoop tLoop) return tLoop In the above, the InitLink value is only ever used in the newLoop function to create a single one element circular linked list. Is there a way to write newLoop to avoid using this value? Thanks -John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090107/53ec2cae/attachment.htm From manlio_perillo at libero.it Tue Jan 6 18:11:29 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Tue Jan 6 18:03:07 2009 Subject: [Haskell-cafe] how out of memory is handled in Haskell Message-ID: <4963E521.1050405@libero.it> Hi. Here: http://damienkatz.net/2008/03/what_sucks_abou.html I found how Erlang (or at least old versions of Erlang) handles out of memory failure: it just calls exit(1). How is this handled in GHC? - exit(1)? - abort()? - IO exception? Thanks Manlio Perillo From eelco at lempsink.nl Tue Jan 6 18:23:45 2009 From: eelco at lempsink.nl (Eelco Lempsink) Date: Tue Jan 6 18:15:26 2009 Subject: [Haskell-cafe] Template Haskell question In-Reply-To: <4165d3a70901060908y1c47665atb6b204bbce07a852@mail.gmail.com> References: <4165d3a70901060908y1c47665atb6b204bbce07a852@mail.gmail.com> Message-ID: <326254A1-FD8B-4B7C-A1BD-344987E79967@lempsink.nl> On 6 jan 2009, at 18:08, Jeff Heard wrote: > Alright... I *think* I'm nearly there, but I can't figure out how to > derive a class instance using record accessors and updaters... Can > anyone help? There are [| XXXf |] instances at the end of the module > and they all need replaced, but I can't figure out what to replace > them with. ... > -- usage: $(deriveUIState ''MyTypeWithUIState) > {- > - Derive an instance of UIState from some type that has had UIState > fields added to it. > -} > deriveUIState tp = do > return [InstanceD [] > (appUIState $ appType tp []) > [FunD 'mousePosition [| > mousePositionf |] ... > ,FunD 'setMousePosition [| \b a -> > a{ mousePositionf=b } |] ... Quick guess: this doesn't typecheck? FunD :: Name -> [Clause] -> Dec while [| ... |] will return something of type ExpQ (which is the same as Q Exp). You're indeed nearly there, but if you use the quotation brackets you need to write monadic code (for the Q monad) and use functions like clause and funD. The tutorials on the wiki (you've probably seen them, http://www.haskell.org/haskellwiki/Template_Haskell) or pretty good and you could also look at packages at hackage for inspiration/ examples, e.g. http://hackage.haskell.org/packages/archive/haxr-th/3000.0.0/doc/html/src/Network-XmlRpc-THDeriveXmlRpcType.html -- Regards, Eelco Lempsink -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090107/089b99c4/PGP.bin From dons at galois.com Tue Jan 6 18:32:02 2009 From: dons at galois.com (Don Stewart) Date: Tue Jan 6 18:23:23 2009 Subject: [Haskell-cafe] how out of memory is handled in Haskell In-Reply-To: <4963E521.1050405@libero.it> References: <4963E521.1050405@libero.it> Message-ID: <20090106233202.GQ15794@scytale.galois.com> manlio_perillo: > Hi. > > Here: > http://damienkatz.net/2008/03/what_sucks_abou.html > > I found how Erlang (or at least old versions of Erlang) handles out of > memory failure: it just calls exit(1). > > > How is this handled in GHC? > - exit(1)? > - abort()? > - IO exception? > > GHC: $ ./A +RTS -M2M Heap exhausted; Current maximum heap size is 1998848 bytes (1 MB); use `+RTS -M' to increase it Which is invoked via the OutOfHeapHook function: #include "Rts.h" #include void OutOfHeapHook (lnat request_size, lnat heap_size) /* both sizes in bytes */ { /* fprintf(stderr, "Heap exhausted;\nwhile trying to allocate %lu bytes in a %lu-byte heap;\nuse `+RTS -H' to increase the total heap size.\n", */ (void)request_size; /* keep gcc -Wall happy */ fprintf(stderr, "Heap exhausted;\nCurrent maximum heap size is %lu bytes (%lu MB);\nuse `+RTS -M' to increase it.\n", heap_size, heap_size / (1024*1024)); } Which you can modify yourself at link time. It is invoked as: void heapOverflow(void) { OutOfHeapHook(0/*unknown request size*/, RtsFlags.GcFlags.maxHeapSize * BLOCK_SIZE); stg_exit(EXIT_HEAPOVERFLOW); } That is, your OutOfHeapHook is called, and then stg_exit is called to shut down the runtime with: void stg_exit(int n) { #ifdef PAR if (exit_started) return; exit_started=rtsTrue; shutdownParallelSystem(n); #endif if (exitFn) (*exitFn)(n); exit(n); } Where you can also set your own exitFn, before, if all else fails, exit() is called. -- Don From manlio_perillo at libero.it Tue Jan 6 18:48:53 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Tue Jan 6 18:40:27 2009 Subject: [Haskell-cafe] how out of memory is handled in Haskell In-Reply-To: <4963E521.1050405@libero.it> References: <4963E521.1050405@libero.it> Message-ID: <4963EDE5.9090102@libero.it> Manlio Perillo ha scritto: > [...] > > How is this handled in GHC? > - exit(1)? > - abort()? > - IO exception? > Ok, found it by myself: http://hackage.haskell.org/trac/ghc/ticket/1791 It is also explicitly documented in: http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html and it's very strange that I have not seen it, sorry. Manlio Perillo From schlepptop at henning-thielemann.de Tue Jan 6 19:15:32 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Tue Jan 6 19:01:05 2009 Subject: [Haskell-cafe] Template Haskell question In-Reply-To: <4165d3a70901060908y1c47665atb6b204bbce07a852@mail.gmail.com> References: <4165d3a70901060908y1c47665atb6b204bbce07a852@mail.gmail.com> Message-ID: <4963F424.9070802@henning-thielemann.de> Jeff Heard schrieb: > Alright... I *think* I'm nearly there, but I can't figure out how to > derive a class instance using record accessors and updaters... Has this something to do with http://hackage.haskell.org/cgi-bin/hackage-scripts/package/data-accessor-template ? From haskell at list.mightyreason.com Tue Jan 6 19:11:32 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Tue Jan 6 19:03:24 2009 Subject: [Haskell-cafe] Re: Tying a simple circularly STM linked list In-Reply-To: References: Message-ID: You can use "undefined" or "error ..." : > {-# LANGUAGE RecursiveDo #-} > import Control.Concurrent.STM > import Control.Monad.Fix > > -- Transactional loop. A loop is a circular link list. > data Loop a > = ItemLink > { item :: a > , prev :: TVar (Loop a) > , next :: TVar (Loop a) > } > > -- Create a new empty transactional loop. > newLoop :: a -> STM (TVar (Loop a)) > newLoop item = do > tLoop <- newTVar undefined > writeTVar tLoop (ItemLink item tLoop tLoop) > return tLoop Hmmm.. STM does not have a MonadFix instance. But IO does: > > -- Use MonadFix instance of newLoopIO > newLoopIO :: a -> IO (TVar (Loop a)) > newLoopIO item = mfix (\ tLoop -> newTVarIO (ItemLink item tLoop tLoop)) But mfix (like fix) is difficult to read in large amounts, so there is "mdo": > -- Use RecursiveDo notation > newLoopMDO :: a -> IO (TVar (Loop a)) > newLoopMDO item = mdo > tLoop <- newTVarIO (ItemLink item tLoop tLoop) > return tLoop > Cheers, Chris From mgross21 at verizon.net Tue Jan 6 19:40:37 2009 From: mgross21 at verizon.net (Murray Gross) Date: Tue Jan 6 19:07:09 2009 Subject: [Haskell-cafe] Maybe a compiler bug? In-Reply-To: <200901062048.51420.daniel.is.fischer@web.de> References: <404396ef0901060735w4d1dc4c4w6559d6c26bddef9c@mail.gmail.com> <200901062048.51420.daniel.is.fischer@web.de> Message-ID: On Tue, 6 Jan 2009, Daniel Fischer wrote: > > Could you elaborate? I couldn't find an inconsistency using your previous > code, it behaved as it should (until I ^C-ed it). > In several versions of the code, now unfortunately lost because of a crash on a power failure (which is extremely rare where I live), I did not get any "goOn" despite the value of gTst3 indicating I should, or where, according to your analysis, I should have gotten a single "fail," I didn't. If I can prod myself into recreating now lost code (unfortunate, sending out the wrong version of the code and losing the right one, only to replace it with one that seems to work now [yes, I'm careful about deleting .o and .hi files]), I'll do so, and report it as a bug according to the instructions in another post. Since I have workarounds and I am using a back-dated version of GHC, it probably isn't worth too much more attention, although I'll keep a wary eye open. Thanks to all for attention. Best, Murray Gross From michael.lesniak at gmail.com Wed Jan 7 04:35:25 2009 From: michael.lesniak at gmail.com (Michael Lesniak) Date: Wed Jan 7 04:26:58 2009 Subject: [Haskell-cafe] ideas for a phd in the area of paralleism? Message-ID: <5f8b37690901070135x203bc234mcfacf451eb71ade0@mail.gmail.com> Hello, currently I'm searching for a topic for my phd-thesis or at least for a workshop-paper (as a starting point, to get my feet wet...). My academic group has specialized itself on (practical, i.e. not too theoretical stuff like verification, etc...) parallel programming and related topics, so my future thesis has to be in this area, but as long as its related I'm free to choose whatever I want. Since I've been interested in FP in general for a few years as a "private hobby" and since Haskell has as a pure language a lot of potential in the area of parallelism, and it's community (esp. #haskell and this list) is really nice and supportive I'd like to do something in this area; I've been hacking in Haskell more intensive for about six month now. I've looked at the different parallelism/concurrency models in Haskell (dph, gph, nested data parallelism) and (after a preliminary overview-reading) it seems that a lot of research has already been done on the basic topics, except for distributed Haskell, where I could not found current papers (i.e. newer than ~2003). If anyone could give me further advice, tips, or hints in general, what could be interesting or where I should take a more deeper look to find a niche I'd really be thankful (and you'll get a special thanks in my foreword in 3 years! ;-)). Best regards, Michael -- Dipl.-Inf. Michael C. Lesniak University of Kassel Programming Languages / Methodologies Research Group Department of Computer Science and Electrical Engineering Wilhelmsh?her Allee 73 34121 Kassel Phone: +49-(0)561-804-6269 From apfelmus at quantentunnel.de Wed Jan 7 04:55:26 2009 From: apfelmus at quantentunnel.de (Apfelmus, Heinrich) Date: Wed Jan 7 04:46:46 2009 Subject: [Haskell-cafe] Re: Updating doubly linked lists In-Reply-To: <4963CC5C.9040209@imageworks.com> References: <495B6E91.8050809@van.steenbergen.nl> <2f9b2d30812311311k51d2a5adq48697976cb48af75@mail.gmail.com> <49629ED0.8080102@imageworks.com> <4963CC5C.9040209@imageworks.com> Message-ID: Dan Weston wrote: > > I hope the code is better than my description! :) The structure is more > like > > Nothing(RK 0 _) > Nothing(RK 1 _) > A(RK 2 4) > B(RK 3 6) > C(RK 2 0) > >> The root of the tree is the center and you can descend on the right. >> But with this structure, walking from A to B is O(d) = O(n) >> (where d is the distance from the origin, >> n the side length of the grid) instead of O(1). > > No. The tree is [[Node]], where the outer list has one element for each > radius that has an occupied node and each inner list has the number of > nodes at the given radius. > > You descend the spine of the outer list radially in O(deltaR) time, > which for incremental moves is O(1). > > Then you search for an existing inner list element in O(nk(r)), which > stays fairly constant for reasonable paths (basically, the width of a > path swath). Ah, so you're using a sparse representation for grids. That's a good idea! Unfortunately, it doesn't help when the grid is a full rectangle, i.e. when nk(r) becomes proportional to r. The (most likely unattainable) goal I had in mind is to create a zipper for the full grid that supports O(1) operations. >> I mean, O(d) may be fine for you, but it's not O(1) for everything as >> advertised. :) > > d is not the distance from the origin, it is nk(r), the number of nodes > at a given radius: d(2) = 2, d(3) = 1. Oh, right. > An outward radial path will only expand the tree linearly, not > quadratically, in size. Well, that's still linear in the side length of a full grid. Directly using Data.Map (Integer,Integer) a would improve that to a logarithm. Of course, your structure can be enhanced by using a Data.Map instead of a linked list for each ring ? la [Data.Map Integer a] This will give O(log nk(r)) movements, but that's still not constant time. Regards, H. Apfelmus From frederik.deweerdt at xprog.eu Wed Jan 7 05:16:42 2009 From: frederik.deweerdt at xprog.eu (Frederik Deweerdt) Date: Wed Jan 7 05:08:22 2009 Subject: [Haskell-cafe] ideas for a phd in the area of paralleism? In-Reply-To: <5f8b37690901070135x203bc234mcfacf451eb71ade0@mail.gmail.com> References: <5f8b37690901070135x203bc234mcfacf451eb71ade0@mail.gmail.com> Message-ID: <20090107101552.GA9470@gambetta> On Wed, Jan 07, 2009 at 10:35:25AM +0100, Michael Lesniak wrote: > Hello, > > currently I'm searching for a topic for my phd-thesis or at least for > a workshop-paper (as a starting point, to get my feet wet...). My > academic group has specialized itself on (practical, i.e. not too > theoretical stuff like verification, etc...) parallel programming and > related topics, so my future thesis has to be in this area, but as > long as its related I'm free to choose whatever I want. GPU programming seems to be hot: http://www.cse.unsw.edu.au/~chak/papers/gpugen.pdf http://www.cs.chalmers.se/Cs/Education/Courses/svh/Slides/may-15-Obsidian-short.pdf Regards, Frederik From jac at informatik.uni-kiel.de Wed Jan 7 06:07:07 2009 From: jac at informatik.uni-kiel.de (Jan Christiansen) Date: Wed Jan 7 05:59:08 2009 Subject: [Haskell-cafe] Maintaining laziness Message-ID: <715BD1A7-EBEA-4B88-A11F-599DE9E27428@informatik.uni-kiel.de> This is great. I am working on the very same topic for quite a while now. My aim is to develop a tool that tells you whether a function is least strict. My work is based on an idea by Olaf Chitil: http://www.cs.kent.ac.uk/people/staff/oc/ I think he was the first who introduced the idea of least strictness. In a paper in the pre-proceedings of IFL 2006 he introduced the term least strict and presented the idea behind a tool called StrictCheck. This tool was supposed to check whether a function is least strict. The problem with this tool was that it proposes non-sequential function definitions that are not implementable in Haskell. The main example in the StrictCheck paper is the definition of unzip by using foldr. This one is very similar to your partition example as it is too strict if you do not use lazy pattern matching for the tuple structure. unzip2 :: [(a, b)] -> ([a], [b]) unzip2 = foldr (\(x,y) (xs,ys) -> (x:xs,y:ys)) ([],[]) My favorite example right now is the multiplication of Peano numbers. Suppose the definition of a data type for Peano numbers and addition and multiplication. data Natural = Z | S Natural (+) :: Natural -> Natural -> Natural Z + y = y S x + y = S (x + y) (*) :: Natural -> Natural -> Natural Z * _ = Z S x * y = y + (x * y) Now we can define an infinite Peano number as follows infinity :: Natural infinity = S infinity The evaluation of Z * infinity yields Z while infinity * Z does not terminate. The tool I am working on is supposed to yield the following information. Natural> strictCheck2 (*) 5 100 You have to fulfil f (S _|_) Z = Z (_|_) This states that the evaluation of S _|_ * Z yields _|_ but it could yield Z. Therefore we can improve the function as follows (*) :: Natural -> Natural -> Natural Z * _ = Z S _ * Z = Z S x * y = y + (x * y) Now the evaluation of infinity * Z yields Z as we wanted it to. If we test this new implementation using StrictCheck we get *Natural> strictCheck2 (*) 5 100 The function seems to be least strict The non least strict definition of (*) is taken from the module Data.Number.Natural which was published by Lennart Augustsson in the numbers package at hackage. I mention this here because I think it clearly shows that it is even hard for experienced Haskell programmers to define least strict functions. An even more promising area of application are functional logic programs as least strict functions result in smaller search spaces. For example I was able to improve the enumeration of pythagorean triples in Curry by a factor of 4 only by making a function least strict. Cheers, Jan From lemming at henning-thielemann.de Wed Jan 7 08:47:46 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Jan 7 08:39:22 2009 Subject: [Haskell-cafe] Maintaining laziness In-Reply-To: <715BD1A7-EBEA-4B88-A11F-599DE9E27428@informatik.uni-kiel.de> References: <715BD1A7-EBEA-4B88-A11F-599DE9E27428@informatik.uni-kiel.de> Message-ID: On Wed, 7 Jan 2009, Jan Christiansen wrote: > The non least strict definition of (*) is taken from the module > Data.Number.Natural which was published by Lennart Augustsson in the numbers > package at hackage. I mention this here because I think it clearly shows that > it is even hard for experienced Haskell programmers to define least strict > functions. very interesting ... It's the third time within about 2 months were I was pointed to a lack of laziness in my own Peano implementation! From denbuen at sandia.gov Wed Jan 7 10:56:36 2009 From: denbuen at sandia.gov (Bueno, Denis) Date: Wed Jan 7 10:46:26 2009 Subject: [Haskell-cafe] Blitting one IOUArray into another Message-ID: Hi all, I'm seeing a lot of unexpected memory allocation with some simple code that copies the contents of one vector (IOUArray Int Int64) into another of the same type and dimensions. In particular, profiling reveals that `copyInto' is allocating oodles and oodles of memory. My small test case creates two 50000-element arrays and performs 10000 copies from one into the other. Since the elements are Int64s and the arrays are unboxed, each array should be 50000 elements * 8 bytes per element = 400,000 bytes and so the arrays should only take 800,000 bytes total. I understand there's some overhead for thunks and whatnot, but the profiler reported allocation is around 40 billion bytes. And almost all of that allocation is in my copying function, not in main (main allocates the arrays). I've attached two versions of the code, just for comparison. The only difference is the way the copying is done. One calls `getBounds' to figure out the bounds, and one is given the bounds for copying. They're both about the same speed and allocation (originally I was using IOUArray Int64 Int64, and there was a much greater allocation difference between the two versions; but that went away. Oh well). So, does anyone know why copying takes so much allocation? I expect there is _some_ way to just move memory from one array to another, like a memcpy -- how can I do that? Denis -------------- next part -------------- A non-text attachment was scrubbed... Name: ArrayCopyGetBounds.hs Type: application/octet-stream Size: 815 bytes Desc: ArrayCopyGetBounds.hs Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090107/09d377a9/ArrayCopyGetBounds.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: arraycopygetbounds.prof Type: application/octet-stream Size: 1889 bytes Desc: arraycopygetbounds.prof Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090107/09d377a9/arraycopygetbounds.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: ArrayCopyWithBounds.hs Type: application/octet-stream Size: 807 bytes Desc: ArrayCopyWithBounds.hs Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090107/09d377a9/ArrayCopyWithBounds.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: arraycopywithbounds.prof Type: application/octet-stream Size: 1825 bytes Desc: arraycopywithbounds.prof Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090107/09d377a9/arraycopywithbounds.obj From bulat.ziganshin at gmail.com Wed Jan 7 11:16:18 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Jan 7 11:08:04 2009 Subject: [Haskell-cafe] Blitting one IOUArray into another In-Reply-To: References: Message-ID: <12010587426.20090107191618@gmail.com> Hello Denis, Wednesday, January 7, 2009, 6:56:36 PM, you wrote: memory allocated for i :))) each new copy of i needs one word. the situation was much worse with Int64, of course :) > Hi all, > I'm seeing a lot of unexpected memory allocation with some simple code that > copies the contents of one vector (IOUArray Int Int64) into another of the > same type and dimensions. In particular, profiling reveals that `copyInto' > is allocating oodles and oodles of memory. > My small test case creates two 50000-element arrays and performs 10000 > copies from one into the other. Since the elements are Int64s and the > arrays are unboxed, each array should be > 50000 elements * 8 bytes per element = 400,000 bytes > and so the arrays should only take 800,000 bytes total. I understand > there's some overhead for thunks and whatnot, but the profiler reported > allocation is around 40 billion bytes. And almost all of that allocation is > in my copying function, not in main (main allocates the arrays). > I've attached two versions of the code, just for comparison. The only > difference is the way the copying is done. One calls `getBounds' to figure > out the bounds, and one is given the bounds for copying. They're both about > the same speed and allocation (originally I was using IOUArray Int64 Int64, > and there was a much greater allocation difference between the two versions; > but that went away. Oh well). > So, does anyone know why copying takes so much allocation? I expect there > is _some_ way to just move memory from one array to another, like a memcpy > -- how can I do that? > Denis -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lemming at henning-thielemann.de Wed Jan 7 11:17:16 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Jan 7 11:08:49 2009 Subject: [Haskell-cafe] Maintaining laziness In-Reply-To: <715BD1A7-EBEA-4B88-A11F-599DE9E27428@informatik.uni-kiel.de> References: <715BD1A7-EBEA-4B88-A11F-599DE9E27428@informatik.uni-kiel.de> Message-ID: On Wed, 7 Jan 2009, Jan Christiansen wrote: > This is great. I am working on the very same topic for quite a while now. My > aim is to develop a tool that tells you whether a function is least strict. > My work is based on an idea by Olaf Chitil: > > http://www.cs.kent.ac.uk/people/staff/oc/ Although it seems to be overkill for a single module - How about a cabalized version on Hackage and a darcs repository? It would simplify using and updating it. From lemming at henning-thielemann.de Wed Jan 7 11:17:52 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Jan 7 11:09:23 2009 Subject: [Haskell-cafe] Maintaining laziness In-Reply-To: References: <715BD1A7-EBEA-4B88-A11F-599DE9E27428@informatik.uni-kiel.de> Message-ID: On Wed, 7 Jan 2009, Henning Thielemann wrote: > > On Wed, 7 Jan 2009, Jan Christiansen wrote: > >> This is great. I am working on the very same topic for quite a while now. >> My aim is to develop a tool that tells you whether a function is least >> strict. My work is based on an idea by Olaf Chitil: >> >> http://www.cs.kent.ac.uk/people/staff/oc/ > > Although it seems to be overkill for a single module - How about a cabalized > version on Hackage and a darcs repository? It would simplify using and > updating it. ... I meant StrictCheck.hs From dons at galois.com Wed Jan 7 11:23:46 2009 From: dons at galois.com (Don Stewart) Date: Wed Jan 7 11:15:05 2009 Subject: [Haskell-cafe] Blitting one IOUArray into another In-Reply-To: <12010587426.20090107191618@gmail.com> References: <12010587426.20090107191618@gmail.com> Message-ID: <20090107162346.GB18753@scytale.galois.com> You can of course memcpy unboxed arrays fairly easily. bulat.ziganshin: > Hello Denis, > > Wednesday, January 7, 2009, 6:56:36 PM, you wrote: > > memory allocated for i :))) > > each new copy of i needs one word. the situation was much worse with > Int64, of course :) > > > > Hi all, > > > I'm seeing a lot of unexpected memory allocation with some simple code that > > copies the contents of one vector (IOUArray Int Int64) into another of the > > same type and dimensions. In particular, profiling reveals that `copyInto' > > is allocating oodles and oodles of memory. > > > My small test case creates two 50000-element arrays and performs 10000 > > copies from one into the other. Since the elements are Int64s and the > > arrays are unboxed, each array should be > > > 50000 elements * 8 bytes per element = 400,000 bytes > > > and so the arrays should only take 800,000 bytes total. I understand > > there's some overhead for thunks and whatnot, but the profiler reported > > allocation is around 40 billion bytes. And almost all of that allocation is > > in my copying function, not in main (main allocates the arrays). > > > I've attached two versions of the code, just for comparison. The only > > difference is the way the copying is done. One calls `getBounds' to figure > > out the bounds, and one is given the bounds for copying. They're both about > > the same speed and allocation (originally I was using IOUArray Int64 Int64, > > and there was a much greater allocation difference between the two versions; > > but that went away. Oh well). > > > So, does anyone know why copying takes so much allocation? I expect there > > is _some_ way to just move memory from one array to another, like a memcpy > > -- how can I do that? > > Denis > > > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From icfp.publicity at googlemail.com Wed Jan 7 11:40:44 2009 From: icfp.publicity at googlemail.com (Matthew Fluet (ICFP Publicity Chair)) Date: Wed Jan 7 11:32:17 2009 Subject: [Haskell-cafe] ICFP: Child care at conference Message-ID: <53ff55480901070840k770375cej2a1ff9797329f485@mail.gmail.com> Potential ICFP attendees: The ACM-SIGPLAN Executive Committee, which oversees and sponsors ICFP, is considering expanding its travel grants for event participants in need of child care assistance. (Such expansion would also apply to other major SIGPLAN-sponsored conferences, such as PLDI, POPL, OOPSLA.) The purpose of this message is to solicit feedback from potential attendees regarding the desirability for child care assistance and what forms of assistance be most appropriate. If child care assistance at ICFP (or other SIGPLAN events) is of interest to you, please contact me (at icfp.publicity@gmail.com -or- fluet@tti-c.org) with your comments. Some questions of particular interest: * What age groups of children are most appropriate to cover? * What types of costs might SIGPLAN cover to facilitate your participation in events? Sincerely, -Matthew Fluet (ICFP Publicity Chair) From denbuen at sandia.gov Wed Jan 7 11:52:32 2009 From: denbuen at sandia.gov (Bueno, Denis) Date: Wed Jan 7 11:44:32 2009 Subject: [Haskell-cafe] Blitting one IOUArray into another In-Reply-To: <20090107162346.GB18753@scytale.galois.com> References: <12010587426.20090107191618@gmail.com>, <20090107162346.GB18753@scytale.galois.com> Message-ID: Ooh, great -- could you point me in the right direction for that? ________________________________________ From: Don Stewart [dons@galois.com] Sent: Wednesday, January 07, 2009 9:23 AM To: Bulat Ziganshin Cc: Bueno, Denis; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Blitting one IOUArray into another You can of course memcpy unboxed arrays fairly easily. bulat.ziganshin: > Hello Denis, > > Wednesday, January 7, 2009, 6:56:36 PM, you wrote: > > memory allocated for i :))) > > each new copy of i needs one word. the situation was much worse with > Int64, of course :) > > > > Hi all, > > > I'm seeing a lot of unexpected memory allocation with some simple code that > > copies the contents of one vector (IOUArray Int Int64) into another of the > > same type and dimensions. In particular, profiling reveals that `copyInto' > > is allocating oodles and oodles of memory. > > > My small test case creates two 50000-element arrays and performs 10000 > > copies from one into the other. Since the elements are Int64s and the > > arrays are unboxed, each array should be > > > 50000 elements * 8 bytes per element = 400,000 bytes > > > and so the arrays should only take 800,000 bytes total. I understand > > there's some overhead for thunks and whatnot, but the profiler reported > > allocation is around 40 billion bytes. And almost all of that allocation is > > in my copying function, not in main (main allocates the arrays). > > > I've attached two versions of the code, just for comparison. The only > > difference is the way the copying is done. One calls `getBounds' to figure > > out the bounds, and one is given the bounds for copying. They're both about > > the same speed and allocation (originally I was using IOUArray Int64 Int64, > > and there was a much greater allocation difference between the two versions; > > but that went away. Oh well). > > > So, does anyone know why copying takes so much allocation? I expect there > > is _some_ way to just move memory from one array to another, like a memcpy > > -- how can I do that? > > Denis > > > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From daniel.is.fischer at web.de Wed Jan 7 11:59:00 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Jan 7 11:48:13 2009 Subject: [Haskell-cafe] Blitting one IOUArray into another In-Reply-To: References: Message-ID: <200901071759.00623.daniel.is.fischer@web.de> Am Mittwoch, 7. Januar 2009 16:56 schrieb Bueno, Denis: > Hi all, > > I'm seeing a lot of unexpected memory allocation with some simple code that > copies the contents of one vector (IOUArray Int Int64) into another of the > same type and dimensions. In particular, profiling reveals that `copyInto' > is allocating oodles and oodles of memory. > > My small test case creates two 50000-element arrays and performs 10000 > copies from one into the other. Since the elements are Int64s and the > arrays are unboxed, each array should be > > 50000 elements * 8 bytes per element = 400,000 bytes > > and so the arrays should only take 800,000 bytes total. I understand > there's some overhead for thunks and whatnot, but the profiler reported > allocation is around 40 billion bytes. And almost all of that allocation > is in my copying function, not in main (main allocates the arrays). I think you've run into a profiling/optimising incopatibility. Compiling the code just with -O2 --make and running with -sstderr, both report 899,944 bytes allocated in the heap 1,272 bytes copied during GC (scavenged) 0 bytes copied during GC (not scavenged) 16,384 bytes maximum residency (1 sample(s)) 2 collections in generation 0 ( 0.00s) 1 collections in generation 1 ( 0.00s) 2 Mb total memory in use which looks reasonable, but it is dog slow on my box, 26.7/26.9 seconds :( Compiled with -prof -auto-all -O2 --make, both allocate madly (~40G) and take nearly ten times as long. It is known that profiling and optimising don't mix too well, but this is remarkable, maybe it's worth an investigation. Cheers, Daniel From denbuen at sandia.gov Wed Jan 7 11:56:19 2009 From: denbuen at sandia.gov (Bueno, Denis) Date: Wed Jan 7 11:48:18 2009 Subject: [Haskell-cafe] Blitting one IOUArray into another In-Reply-To: <20090107162346.GB18753@scytale.galois.com> References: <12010587426.20090107191618@gmail.com>, <20090107162346.GB18753@scytale.galois.com> Message-ID: Oh, do you mean by actually calling memcpy via ffi? ________________________________________ From: Don Stewart [dons@galois.com] Sent: Wednesday, January 07, 2009 9:23 AM To: Bulat Ziganshin Cc: Bueno, Denis; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Blitting one IOUArray into another You can of course memcpy unboxed arrays fairly easily. bulat.ziganshin: > Hello Denis, > > Wednesday, January 7, 2009, 6:56:36 PM, you wrote: > > memory allocated for i :))) > > each new copy of i needs one word. the situation was much worse with > Int64, of course :) > > > > Hi all, > > > I'm seeing a lot of unexpected memory allocation with some simple code that > > copies the contents of one vector (IOUArray Int Int64) into another of the > > same type and dimensions. In particular, profiling reveals that `copyInto' > > is allocating oodles and oodles of memory. > > > My small test case creates two 50000-element arrays and performs 10000 > > copies from one into the other. Since the elements are Int64s and the > > arrays are unboxed, each array should be > > > 50000 elements * 8 bytes per element = 400,000 bytes > > > and so the arrays should only take 800,000 bytes total. I understand > > there's some overhead for thunks and whatnot, but the profiler reported > > allocation is around 40 billion bytes. And almost all of that allocation is > > in my copying function, not in main (main allocates the arrays). > > > I've attached two versions of the code, just for comparison. The only > > difference is the way the copying is done. One calls `getBounds' to figure > > out the bounds, and one is given the bounds for copying. They're both about > > the same speed and allocation (originally I was using IOUArray Int64 Int64, > > and there was a much greater allocation difference between the two versions; > > but that went away. Oh well). > > > So, does anyone know why copying takes so much allocation? I expect there > > is _some_ way to just move memory from one array to another, like a memcpy > > -- how can I do that? > > Denis > > > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From trin.cz at gmail.com Wed Jan 7 12:02:52 2009 From: trin.cz at gmail.com (Trin) Date: Wed Jan 7 11:54:32 2009 Subject: [Haskell-cafe] ideas for a phd in the area of paralleism? In-Reply-To: <20090107101552.GA9470@gambetta> References: <5f8b37690901070135x203bc234mcfacf451eb71ade0@mail.gmail.com> <20090107101552.GA9470@gambetta> Message-ID: <4964E03C.1010809@gmail.com> Frederik Deweerdt wrote: > On Wed, Jan 07, 2009 at 10:35:25AM +0100, Michael Lesniak wrote: > >> Hello, >> >> currently I'm searching for a topic for my phd-thesis or at least for >> a workshop-paper (as a starting point, to get my feet wet...). My >> academic group has specialized itself on (practical, i.e. not too >> theoretical stuff like verification, etc...) parallel programming and >> related topics, so my future thesis has to be in this area, but as >> long as its related I'm free to choose whatever I want. >> > > GPU programming seems to be hot: > > http://www.cse.unsw.edu.au/~chak/papers/gpugen.pdf > http://www.cs.chalmers.se/Cs/Education/Courses/svh/Slides/may-15-Obsidian-short.pdf > Make OpenCL bindings please, please ... pretty please. Martin > Regards, > Frederik > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jefferson.r.heard at gmail.com Wed Jan 7 15:58:30 2009 From: jefferson.r.heard at gmail.com (Jeff Heard) Date: Wed Jan 7 15:50:01 2009 Subject: [Haskell-cafe] Template Haskell question In-Reply-To: <326254A1-FD8B-4B7C-A1BD-344987E79967@lempsink.nl> References: <4165d3a70901060908y1c47665atb6b204bbce07a852@mail.gmail.com> <326254A1-FD8B-4B7C-A1BD-344987E79967@lempsink.nl> Message-ID: <4165d3a70901071258i32d9d22fhb361dd8fb8c85e57@mail.gmail.com> It doesn't typecheck, no, but it also doesn't check out in scope. It complains in [FunD 'mousePosition [| mousePositionf |] ... that mousePositionf isn't in scope. What I believe I need to do is use mkName "mousePositionf", but how do I bind the record getter "mousePositionf" that is defined by the code in the function named "additions" to mousePosition -- a.k.a. how do I write that template? Is it a ConE? And how do I encode a{ mousePositionf = b } in template haskell without using the [| |] syntax, so that I can use mkName? -- Jeff On Tue, Jan 6, 2009 at 6:23 PM, Eelco Lempsink wrote: > On 6 jan 2009, at 18:08, Jeff Heard wrote: >> >> Alright... I *think* I'm nearly there, but I can't figure out how to >> derive a class instance using record accessors and updaters... Can >> anyone help? There are [| XXXf |] instances at the end of the module >> and they all need replaced, but I can't figure out what to replace >> them with. > > ... >> >> -- usage: $(deriveUIState ''MyTypeWithUIState) >> {- >> - Derive an instance of UIState from some type that has had UIState >> fields added to it. >> -} >> deriveUIState tp = do >> return [InstanceD [] >> (appUIState $ appType tp []) >> [FunD 'mousePosition [| mousePositionf |] > > ... >> >> ,FunD 'setMousePosition [| \b a -> a{ >> mousePositionf=b } |] > > ... > > Quick guess: this doesn't typecheck? > > FunD :: Name -> [Clause] -> Dec > > while [| ... |] will return something of type ExpQ (which is the same as Q > Exp). > > You're indeed nearly there, but if you use the quotation brackets you need > to write monadic code (for the Q monad) and use functions like clause and > funD. The tutorials on the wiki (you've probably seen them, > http://www.haskell.org/haskellwiki/Template_Haskell) or pretty good and you > could also look at packages at hackage for inspiration/examples, e.g. > http://hackage.haskell.org/packages/archive/haxr-th/3000.0.0/doc/html/src/Network-XmlRpc-THDeriveXmlRpcType.html > > -- > Regards, > > Eelco Lempsink > > From brianchina60221 at gmail.com Wed Jan 7 16:03:36 2009 From: brianchina60221 at gmail.com (brian) Date: Wed Jan 7 15:55:08 2009 Subject: [Haskell-cafe] template haskell Message-ID: <22f6a8f70901071303p285f7b5of80a5bc28d1b5aff@mail.gmail.com> Smart constructors sometimes need to generate errors like "Foo.Bar.Baz.create: invalid value, etc". Can TH generate the module and function names? From wqeqweuqy at hotmail.com Wed Jan 7 16:36:19 2009 From: wqeqweuqy at hotmail.com (Neal Alexander) Date: Wed Jan 7 16:28:15 2009 Subject: [Haskell-cafe] Re: Blitting one IOUArray into another In-Reply-To: References: <12010587426.20090107191618@gmail.com>, <20090107162346.GB18753@scytale.galois.com> Message-ID: Bueno, Denis wrote: > Oh, do you mean by actually calling memcpy via ffi? http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-Marshal-Utils.html From immanuel203 at gmail.com Wed Jan 7 17:53:30 2009 From: immanuel203 at gmail.com (Immanuel Litzroth) Date: Wed Jan 7 17:45:01 2009 Subject: [Haskell-cafe] Taking Exception to Exceptions Message-ID: I'm trying to use the new (for me at least) extensible exceptions and I am little amazed that I cannot get catch, try or mapException to work without telling them which exceptions I want to catch. What is the rationale behind this? How does bracket manage to catch all exceptions? What should onException do? Is there some example code that uses these exceptions, or better documentation? Thanks in advance, Immanuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090107/6b657e98/attachment.htm From mad.one at gmail.com Wed Jan 7 18:32:59 2009 From: mad.one at gmail.com (Austin Seipp) Date: Wed Jan 7 18:24:32 2009 Subject: [Haskell-cafe] Taking Exception to Exceptions In-Reply-To: References: Message-ID: <1231370528-sup-5395@existential.local> Excerpts from Immanuel Litzroth's message of Wed Jan 07 16:53:30 -0600 2009: > I'm trying to use the new (for me at least) extensible exceptions and > I am little amazed that I cannot get catch, try or mapException to work > without telling them which exceptions I want to catch. > What is the rationale behind this? The rational is that it's normally not a good idea to simply gobble all exceptions; although the library makes it possible to do this anyway. You can either use the ScopedTypeVariables extension and do: ... `catch` \(e::SomeException) -> ... Or without an extension you can do: ... `catch` handler where handler :: SomeException -> IO a handler e = ... (It's really a matter of taste if you want to use a non-haskell98 extension, although considering that the new extensible exceptions library uses deriving data/typeable and existentials anyway, I think ScopedTypeVariables are the way to go.) > How does bracket manage to catch all exceptions? > What should onException do? onException takes an IO action and what to do if it fails - if the IO action fails, it is caught and your 'failure action' is run, followed by onException re-throwing the error. > Is there some example code that uses these exceptions, or better > documentation? The GHC docs don't have source-code links (don't know why,) but luckily in order to aid in using the new extensions system with older GHCs there has been a hackage package uploaded that provides the identical functionality: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/extensible-exceptions The source is here: http://hackage.haskell.org/packages/archive/extensible-exceptions/0.1.1.0/doc/html/src/Control-Exception-Extensible.html As for documentation e.g. haddock stuff, this is currently a bug as there is none: http://hackage.haskell.org/trac/ghc/ticket/2655 I recommend this paper for info, it's very easy to follow: http://www.haskell.org/~simonmar/papers/ext-exceptions.pdf Austin From sigbjorn.finne at gmail.com Wed Jan 7 18:46:24 2009 From: sigbjorn.finne at gmail.com (Sigbjorn Finne) Date: Wed Jan 7 18:38:06 2009 Subject: [Haskell-cafe] Linking in GMP as a Windows DLL w/ GHC Message-ID: <49653ED0.5040200@gmail.com> Hi, a number of folks have been asking/looking for ways to avoid statically linking in GMP into GHC binaries under Windows. I've written up some notes on how to go about doing this, which are now available from http://haskell.forkio.com/gmpwindows Let me know if it is useful (or works ;-) ) enjoy --sigbjorn From tonyhannan2 at gmail.com Wed Jan 7 19:01:12 2009 From: tonyhannan2 at gmail.com (Tony Hannan) Date: Wed Jan 7 18:52:43 2009 Subject: [Haskell-cafe] Hypothetical Haskell job in New York Message-ID: Hello Haskellers, I'm trying to convince my boss to use Haskell. His main concern is finding people who know Haskell when hiring. He is comfortable with Java because he knows he can always find a Java developer. So if I advertised we were looking for Haskell programmers in New York City, how many would respond? Please reply to this email if you would respond. Email me privately if you like and I will post the results to haskell-cafe later. Thanks, Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090107/1664d95e/attachment.htm From tonyhannan2 at gmail.com Wed Jan 7 19:25:21 2009 From: tonyhannan2 at gmail.com (Tony Hannan) Date: Wed Jan 7 19:16:52 2009 Subject: [Haskell-cafe] Re: Hypothetical Haskell job in New York In-Reply-To: References: Message-ID: Let me give you more information about this hypothetical job posting. Our company is a startup CDN ( http://en.wikipedia.org/wiki/Content_Delivery_Network) about 3 years old and doing well. You would hythothetically be one of 7 programmer who write all the software involved in a CDN including http server, dns server, monitoring, load balancing, customer and operator user interface, etc. The pay depends on experience but is good. I already got a few replies, keep them coming. Thanks, Tony On Wed, Jan 7, 2009 at 7:01 PM, Tony Hannan wrote: > Hello Haskellers, > > I'm trying to convince my boss to use Haskell. His main concern is finding > people who know Haskell when hiring. He is comfortable with Java because he > knows he can always find a Java developer. So if I advertised we were > looking for Haskell programmers in New York City, how many would respond? > Please reply to this email if you would respond. Email me privately if you > like and I will post the results to haskell-cafe later. > > Thanks, > Tony > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090107/5ed9c093/attachment.htm From pbeadling at mail2web.com Wed Jan 7 20:52:05 2009 From: pbeadling at mail2web.com (Phil) Date: Wed Jan 7 20:46:04 2009 Subject: [Haskell-cafe] State Monad - using the updated state Message-ID: Hi, I?m a newbie looking to get my head around using the State Monad for random number generation. I?ve written non-monad code that achieves this no problem. When attempting to use the state monad I can get what I know to be the correct initial value and state, but can?t figure out for the life of me how to then increment it without binding more calls there and then. Doing several contiguous calls is not what I want to do here ? and the examples I?ve read all show this (using something like liftM2 (,) myRandom myRandom). I want to be able to do: Get_a_random_number < a whole load of other stuff > Get the next number as defined by the updated state in the first call Get another number, and so on. I get the first number fine, but am lost at how to get the second, third, forth etc without binding there and then. I just want each number one at a time where and when I want it, rather than saying give 1,2,10 or even ?n? numbers now. I?m sure it?s blindly obvious! Note: I?m not using Haskell?s built in Random functionality (nor is that an option), I?ll spare the details of the method I?m using (NRC?s ranq1) as I know it works for the non-Monad case, and it?s irrelevent to the question. So the code is: ranq1 :: Word64 -> ( Double, Word64 ) ranq1 state = ( output, newState ) where newState = ranq1Increment state output = convert_to_double newState ranq1Init :: Word64 -> Word64 ranq1Init = convert_to_word64 . ranq1Increment . xor_v_init -- I?ll leave the detail of how ranq1Increment works out for brevity. I know this bit works fine. Same goes for the init function it?s just providing an initial state. -- The Monad State Attempt getRanq1 :: State Word64 Double getRanq1 = do state <- get let ( randDouble, newState ) = ranq1 state put newState return randDouble _________ And then in my main _________ -- 124353542542 is just an arbitrary seed main :: IO() main = do let x = evalState getRanq1 (ranq1Init 124353542542) print (x) As I said this works fine; x gives me the correct first value for this sequence, but how do I then get the second and third without writing the giveMeTenRandoms style function? I guess what I want is a next() type function, imperatively speaking. Many thanks for any help, Phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090108/ca9078af/attachment.htm From ryani.spam at gmail.com Wed Jan 7 20:54:46 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Jan 7 20:46:18 2009 Subject: [Haskell-cafe] Template Haskell question In-Reply-To: <4165d3a70901071258i32d9d22fhb361dd8fb8c85e57@mail.gmail.com> References: <4165d3a70901060908y1c47665atb6b204bbce07a852@mail.gmail.com> <326254A1-FD8B-4B7C-A1BD-344987E79967@lempsink.nl> <4165d3a70901071258i32d9d22fhb361dd8fb8c85e57@mail.gmail.com> Message-ID: <2f9b2d30901071754i43802e80oba84a064b787636f@mail.gmail.com> On Wed, Jan 7, 2009 at 12:58 PM, Jeff Heard wrote: > And how do I encode > > a{ mousePositionf = b } > > in template haskell without using the [| |] syntax, so that I can use mkName? Whenever I have a question like that, I just ask ghci: $ ghci -fth ghci> :m Control.Monad.Identity Language.Haskell.TH ghci> runQ [| 1 + 1 |] InfixE (Just (LitE (IntegerL 1))) (VarE GHC.Num.+) (Just (LitE (IntegerL 1))) ghci> runQ [| \x -> x { runIdentity = 1 } |] LamE [VarP x_1] (RecUpdE (VarE x_1) [(Control.Monad.Identity.runIdentity,LitE (I ntegerL 1))]) Note that GHCi shows TH names without "mkName" or quotes, so you need to add those. But it shows you the structure you want to generate. You can also use $() and [| |] inside [| |] to generate additional data in TH directly: ghci> runQ $ do { VarE n <- [| runIdentity |] ; [| \x -> $(recUpdE [| x |] [ fmap (\e -> (n,e)) [| 1 |] ]) |] } LamE [VarP x_2] (RecUpdE (VarE x_2) [(Control.Monad.Identity.runIdentity,LitE (I ntegerL 1))]) Note the "VarE n <- [| identifier |]" trick to extract the name from an identifier. -- ryan From pbeadling at mail2web.com Wed Jan 7 20:58:30 2009 From: pbeadling at mail2web.com (Phil) Date: Wed Jan 7 20:50:11 2009 Subject: [Haskell-cafe] State Monad - using the updated state in an adhoc manner Message-ID: Hi, I?m a newbie looking to get my head around using the State Monad for random number generation. I?ve written non-monad code that achieves this no problem. When attempting to use the state monad I can get what I know to be the correct initial value and state, but can?t figure out for the life of me how to then increment it without binding more calls there and then. Doing several contiguous calls is not what I want to do here ? and the examples I?ve read all show this (using something like liftM2 (,) myRandom myRandom). I want to be able to do: Get_a_random_number < a whole load of other stuff > Get the next number as defined by the updated state in the first call Get another number, and so on. I get the first number fine, but am lost at how to get the second, third, forth etc without binding there and then. I just want each number one at a time where and when I want it, rather than saying give 1,2,10 or even ?n? numbers now. I?m sure it?s blindly obvious! Note: I?m not using Haskell?s built in Random functionality (nor is that an option), I?ll spare the details of the method I?m using (NRC?s ranq1) as I know it works for the non-Monad case, and it?s irrelevent to the question. So the code is: ranq1 :: Word64 -> ( Double, Word64 ) ranq1 state = ( output, newState ) where newState = ranq1Increment state output = convert_to_double newState ranq1Init :: Word64 -> Word64 ranq1Init = convert_to_word64 . ranq1Increment . xor_v_init -- I?ll leave the detail of how ranq1Increment works out for brevity. I know this bit works fine. Same goes for the init function it?s just providing an initial state. -- The Monad State Attempt getRanq1 :: State Word64 Double getRanq1 = do state <- get let ( randDouble, newState ) = ranq1 state put newState return randDouble _________ And then in my main _________ -- 124353542542 is just an arbitrary seed main :: IO() main = do let x = evalState getRanq1 (ranq1Init 124353542542) print (x) As I said this works fine; x gives me the correct first value for this sequence, but how do I then get the second and third without writing the giveMeTenRandoms style function? I guess what I want is a next() type function, imperatively speaking. Many thanks for any help, Phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090108/d9572e4b/attachment-0001.htm From ryani.spam at gmail.com Wed Jan 7 21:28:33 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Jan 7 21:20:05 2009 Subject: [Haskell-cafe] State Monad - using the updated state In-Reply-To: References: Message-ID: <2f9b2d30901071828j45251bbfg85760421cee891d@mail.gmail.com> Hi Phil. First a quick style comment, then I'll get to the meat of your question. getRanq1 is correct; although quite verbose. A simpler definition is this: getRanq1 = State ranq1 This uses the State constructor from Control.Monad.State: State :: (s -> (a,s)) -> State s a What it sounds like you want is this: main = do x <- getARandomNumber ... do some other stuff y <- getAnotherRandomNumber .. etc. using State. There are two ways to go about this; the first is, if the entire computation is pure, that is, the "do some other stuff" doesn't do IO, you can embed the whole computation in "State": seed = 124353542542 main = do result <- evalState randomComputation (ranq1Init seed) ... some IO using result ... randomComputation = do x <- getRanq1 let y = some pure computation using x z <- getRanq1 w <- something that uses x, y, and z that also uses the random source ... etc. return (some result) The other option, if you want to do IO in between, is to use a "transformer" version of State: type MyMonad a = StateT Word64 IO a main = withStateT (ranq1Init seed) $ do x <- getRanq1_t liftIO $ print x ... y <- getRanq1_t ... getRanq1_t :: MyMonad Double getRanq1_t = liftStateT getRanq1 liftStateT :: State s a -> MyMonad a liftStateT m = StateT $ \s -> return (runState m s) withStateT :: Word64 -> MyMonad a -> IO a withStateT s m = evalStateT m s -- can also just use "withStateT = flip evalStateT" This uses these functions from Control.Monad.State: liftIO :: MonadIO m => IO a -> m a This takes any IO action and puts it into any monad that supports IO. In this case, StateT s IO a fits. runState :: StateT s a -> s -> (a,s) This evaluates a pure stateful computation and gives you the result. StateT :: (s -> m (a,s)) -> StateT s m a This builds a StateT directly. You could get away without it like this: liftStateT m = do s <- get let (a, s') = runState m s put s' return a (note the similarity to your getRanq1 function!) evalStateT :: StateT s m a -> s -> m a This is just evalState for the transformer version of State. In our case it has the type (MyMonad a -> Word64 -> IO a) This said, as a beginner I recommend trying to make more of your code pure so you can avoid IO; you do need side effects for some things, but while learning it makes sense to try as hard as you can to avoid it. You can make a lot of interesting programs with just "interact" and pure functions. If you're just doing text operations, try to make your program look like this: main = interact pureMain pureMain :: String -> String pureMain s = ... You'll find it will teach you a lot about laziness & the power of purity! A key insight is that State *is* pure, even though code using it looks somewhat imperative. -- ryan P.S. If you can't quite get out of the imperative mindset you can visit imperative island via the ST boat. 2009/1/7 Phil : > Hi, > > I'm a newbie looking to get my head around using the State Monad for random > number generation. I've written non-monad code that achieves this no > problem. When attempting to use the state monad I can get what I know to be > the correct initial value and state, but can't figure out for the life of me > how to then increment it without binding more calls there and then. Doing > several contiguous calls is not what I want to do here ? and the examples > I've read all show this (using something like liftM2 (,) myRandom myRandom). > I want to be able to do: > > Get_a_random_number > > < a whole load of other stuff > > > Get the next number as defined by the updated state in the first call > > > > Get another number, and so on. > > I get the first number fine, but am lost at how to get the second, third, > forth etc without binding there and then. I just want each number one at a > time where and when I want it, rather than saying give 1,2,10 or even 'n' > numbers now. I'm sure it's blindly obvious! > > Note: I'm not using Haskell's built in Random functionality (nor is that an > option), I'll spare the details of the method I'm using (NRC's ranq1) as I > know it works for the non-Monad case, and it's irrelevent to the question. > So the code is: > > ranq1 :: Word64 -> ( Double, Word64 ) > ranq1 state = ( output, newState ) > where > newState = ranq1Increment state > output = convert_to_double newState > > ranq1Init :: Word64 -> Word64 > ranq1Init = convert_to_word64 . ranq1Increment . xor_v_init > > -- I'll leave the detail of how ranq1Increment works out for brevity. I > know this bit works fine. Same goes for the init function it's just > providing an initial state. > > -- The Monad State Attempt > getRanq1 :: State Word64 Double > getRanq1 = do > state <- get > let ( randDouble, newState ) = ranq1 state > put newState > return randDouble > > > _________ And then in my main _________ > > -- 124353542542 is just an arbitrary seed > main :: IO() > main = do > let x = evalState getRanq1 (ranq1Init 124353542542) > print (x) > > > As I said this works fine; x gives me the correct first value for this > sequence, but how do I then get the second and third without writing the > giveMeTenRandoms style function? I guess what I want is a next() type > function, imperatively speaking. > > > Many thanks for any help, > > > Phil. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From newhoggy at gmail.com Wed Jan 7 21:54:23 2009 From: newhoggy at gmail.com (John Ky) Date: Wed Jan 7 21:45:55 2009 Subject: [Haskell-cafe] Re: Tying a simple circularly STM linked list In-Reply-To: References: Message-ID: Thanks Chris, The undefined works for me. -John On Wed, Jan 7, 2009 at 11:11 AM, ChrisK wrote: > You can use "undefined" or "error ..." : > > {-# LANGUAGE RecursiveDo #-} >> import Control.Concurrent.STM >> import Control.Monad.Fix >> >> -- Transactional loop. A loop is a circular link list. >> data Loop a >> = ItemLink >> { item :: a >> , prev :: TVar (Loop a) >> , next :: TVar (Loop a) >> } >> >> -- Create a new empty transactional loop. >> newLoop :: a -> STM (TVar (Loop a)) >> newLoop item = do >> tLoop <- newTVar undefined >> writeTVar tLoop (ItemLink item tLoop tLoop) >> return tLoop >> > > Hmmm.. STM does not have a MonadFix instance. But IO does: > > >> -- Use MonadFix instance of newLoopIO >> newLoopIO :: a -> IO (TVar (Loop a)) >> newLoopIO item = mfix (\ tLoop -> newTVarIO (ItemLink item tLoop tLoop)) >> > > But mfix (like fix) is difficult to read in large amounts, so there is > "mdo": > > -- Use RecursiveDo notation >> newLoopMDO :: a -> IO (TVar (Loop a)) >> newLoopMDO item = mdo >> tLoop <- newTVarIO (ItemLink item tLoop tLoop) >> return tLoop >> >> > > Cheers, > Chris > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090108/b2418aca/attachment.htm From jgoerzen at complete.org Wed Jan 7 22:06:56 2009 From: jgoerzen at complete.org (John Goerzen) Date: Wed Jan 7 21:58:46 2009 Subject: [Haskell-cafe] databases in Haskell & type-safety In-Reply-To: <87eizkra83.fsf@nitai.hr> References: <87eizkra83.fsf@nitai.hr> Message-ID: <20090108030656.GA4430@complete.org> On Sat, Jan 03, 2009 at 10:48:44AM +0100, Gour wrote: > So, considering that HDBC nicely abstracts API enabling one to easily > switch from e.g. Sqlite3 to Postgres, and it is used as in example for > database programming, it seems as logical (and the only) choice for > Haskell database programming in a real-world? Sorry to come to this late, but I figured I'd jump in a bit, as someone that uses HDBC in the real world. I would say that database interactions are typically limited to a small part of code. In small programs, I generally have a DB module that does the queries, and marshals everything to/from the rich Haskell types I define. Any possible type issues are thus constrained to that small part of code. HDBC is a low-level abstraction, which can be used on its own or, of course, as a layer underlying HaskellDB or some such. I do not dispute the use of tools such as HaskellDB or others that try to automate the business of representing a database's schema -- and queries against it -- using a language's type system. There are a lot of these systems in a lot of languages. I've used some of them. And, almost universally, they annoy me. I find it takes longer to write code with them than without, and often they have issues representing some query that I know I can do easily in SQL but maybe can't as easy in the toolkit. As an example, when I last looked at HaskellDB in 2005, I found that it was impossible to do a SELECT without a DISTINCT [1]. There are many situations where such a thing is necessary, so I had to discard it for my projects. HDBC is more similar to Perl's DBI or Python's DB-API (or perhaps a sane version of JDBC). It is a standard interface to SQL RDBMS engines that provides some tools for marshaling data back and forth, but generally leaves you to construct the queries. It does not really solve the same problem as HaskellDB. I wrote HDBC because of some issues with HSQL. I had trouble with segfaults, referencing returned data by column number instead of name, and it did not support replacable parameters. HDBC supports all of that, and as a result, does not provide any functions to escape data for a SQL engine because its design renders such functions unnecessary. I have not followed HSQL development since. So, this was not intended as an HDBC commercial, just more of a braindump as to why I wrote it. Hope it helps. HDBC is actively used in mission-critical applications where I work. We use both the PostgreSQL and ODBC backends in production. We even use the ODBC backend along with the particularly nefarious ODBC interface for the Progress 4GL database. I use the Sqlite3 backend quite a bit in my own personal projects, such as hpodder and twidge. > I'm not familiar with Takusen which says: "Takusen's unique selling > point is safety and efficiency..." and I would appreciate if someone > could shed some more light to its 'safety' and the present status? [1] http://www.haskell.org/pipermail/haskell-cafe/2005-August/011026.html -- John From dave at zednenem.com Wed Jan 7 22:55:23 2009 From: dave at zednenem.com (David Menendez) Date: Wed Jan 7 22:46:53 2009 Subject: [Haskell-cafe] Template Haskell question In-Reply-To: <2f9b2d30901071754i43802e80oba84a064b787636f@mail.gmail.com> References: <4165d3a70901060908y1c47665atb6b204bbce07a852@mail.gmail.com> <326254A1-FD8B-4B7C-A1BD-344987E79967@lempsink.nl> <4165d3a70901071258i32d9d22fhb361dd8fb8c85e57@mail.gmail.com> <2f9b2d30901071754i43802e80oba84a064b787636f@mail.gmail.com> Message-ID: <49a77b7a0901071955t4fb4f7b6h22c89ddd95ed07f8@mail.gmail.com> On Wed, Jan 7, 2009 at 8:54 PM, Ryan Ingram wrote: > You can also use $() and [| |] inside [| |] to generate additional > data in TH directly: > > ghci> runQ $ do { VarE n <- [| runIdentity |] ; [| \x -> $(recUpdE [| > x |] [ fmap (\e -> (n,e)) [| 1 |] ]) |] } > LamE [VarP x_2] (RecUpdE (VarE x_2) [(Control.Monad.Identity.runIdentity,LitE (I > ntegerL 1))]) > > Note the "VarE n <- [| identifier |]" trick to extract the name from > an identifier. You can use the single quote to get the name of a value. ghci> runQ [| \x -> $(recUpdE [| x |] [ fmap (\e -> ('runIdentity, e)) [| 1 |] ]) |] LamE [VarP x_1] (RecUpdE (VarE x_1) [(Control.Monad.Identity.runIdentity,LitE (IntegerL 1))]) There's more in section 8.9.1 of the GHC manual. -- Dave Menendez From newsham at lava.net Wed Jan 7 23:22:36 2009 From: newsham at lava.net (Tim Newsham) Date: Wed Jan 7 23:14:07 2009 Subject: [Haskell-cafe] data declarations should provide fold functions Message-ID: I've had to use some fold functions recently and I've come to the conclusion that Haskell should automatically generate fold functions for data definitions. To clarify what I mean, for the data definition: data MyData = This Int Char | That String Int Int there should be a matching function definition: foldMyData f g (This a b) = f a b foldMyData f g (That a b c) = g a b c This definition is as natural as the constructors "This" and "That". Consider the tuple definition and its fold: data (,) a b = (a, b) foldTuple f (x, y) = f x y and the definition of Either and its fold: data Either a b = Left a | Right b foldEither f g (Left x) = f a foldEither f g (Right x) = g x In logic these constructors define the introduction rules ((,), Left and Right) and the folds define the elimination rules (exactly for Either, indirectly for tuples) for conjunction and disjunction. Further, while pattern-matching is very convenient for accessing the constituents of the data type, patterns are not first-class objects in Haskell. Fold functions, on the othe hand, are. They can be passed around and used in higher-order functions to extract constituents in a points-free manner. I know the short-term answer is "use TH" to derive folds if I want them, but I think such an important concept should probably be part of the language. Tim Newsham http://www.thenewsh.com/~newsham/ From wren at freegeek.org Wed Jan 7 23:25:45 2009 From: wren at freegeek.org (wren ng thornton) Date: Wed Jan 7 23:17:16 2009 Subject: [Haskell-cafe] Staged evaluation, names? Message-ID: <49658049.8060107@freegeek.org> Dear Cafe, Every now and then I find myself in the position where I'd like to define some hairy value as a CAF instead of a literal, but I'd like for it to be fully evaluated at compile-time rather than postponed until runtime. It'd be possible to bludgeon the CPP into doing this, but it seems easier to use an autocannon like Template Haskell to swat this fly. This seems like a common thing for folks to want but the TH documentation targets much higher-hanging fruit, which actually made it harder to figure out how to do something this basic (which would have been transparent with MetaML/MetaOCaml-like syntax). I've figured it out and circumvented the gotchas, and I was thinking of releasing the code as a counterpoint to all the very-high level TH tutorials. The question for y'all is what should I call it? I've been calling the template-function qaf (for Compiled Applicative Form ;) and the type class with that function would be the only thing in the package, but I'm not sure where QAF.hs should be in the module hierarchy. Thoughts? -- Live well, ~wren From wren at freegeek.org Wed Jan 7 23:44:21 2009 From: wren at freegeek.org (wren ng thornton) Date: Wed Jan 7 23:35:52 2009 Subject: [Haskell-cafe] data declarations should provide fold functions In-Reply-To: References: Message-ID: <496584A5.7080508@freegeek.org> Tim Newsham wrote: > I know the short-term answer is "use TH" to derive folds if > I want them, but I think such an important concept should probably > be part of the language. If you don't mind the hairy code, there's always this generic answer from #haskell almost a year ago: http://hpaste.org/7682 You'd need to hook it up with a preprocessor script since it's a String->String function. It should be pretty easy to rewrite that into TH code in order to clean it up. I agree, it'd be nice to have it as a standard deriving clause, but since every fold has a different type it's challenging to make it fit into the language rather than being a wart. Some of the stuff in Data.Generics, Data.Typable, etc might could help. If you come up with anything you like, it shouldn't be too hard to (convince someone to) convert the logic into a language extension. -- Live well, ~wren From allbery at ece.cmu.edu Thu Jan 8 00:06:40 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Jan 7 23:58:16 2009 Subject: [Haskell-cafe] State Monad - using the updated state in an adhoc manner In-Reply-To: References: Message-ID: <41452A0C-CF48-4A58-9E05-BBF9C6972673@ece.cmu.edu> On 2009 Jan 7, at 20:58, Phil wrote: > -- 124353542542 is just an arbitrary seed > main :: IO() > main = do > let x = evalState getRanq1 (ranq1Init 124353542542) > print (x) You're throwing away the state you want to keep by using evalState there. But you're also missing the point of using State; done right the evalState *is* what you want. What you want to do is run all of your operations within State, exiting it only when you're done: > main = do > print (evalState doRanqs (ranq1init 124353542542)) > > doRanqs = do > r <- getRanq1 > -- do something involving it > another <- getRanq1 > -- do more stuff Alternately you may use a tail recursive function or a fold, etc., depending on what exactly you're trying to accomplish. You do *not* want to execState or runState every individual time you want a random number; if you do that you'll have to carry the random state around yourself (in effect you'd be rewriting the State monad by hand, poorly). Stay in State and let it do the carrying for you. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090108/7821d06c/attachment.htm From noteed at gmail.com Thu Jan 8 03:28:27 2009 From: noteed at gmail.com (minh thu) Date: Thu Jan 8 03:19:56 2009 Subject: [Haskell-cafe] How to give unique name/id to nodes outside any monad ? Message-ID: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> Hi, I'd like to process some kind of graph data structure, say something like data DS = A [DS] | B DS DS | C. but I want to be able to discover any sharing. Thus, in b = B a a where a = A [C], if I want to malloc a similar data structure, I have to handle to the node representing B two times the same pointer (the one returned after allocating A [C]). To discover sharing, I thought it would be necessary to give unique name to node and then compare them while traversing the graph. I could give the name by hand but it would be cumbersome. But at least it would not require any monad for the bookkeeping of ungiven names. Is it possible to give those names automatically but outside any monad ? Thanks, Thu From simonpj at microsoft.com Thu Jan 8 03:31:10 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Jan 8 03:22:41 2009 Subject: [Haskell-cafe] Template Haskell question In-Reply-To: <2f9b2d30901071754i43802e80oba84a064b787636f@mail.gmail.com> References: <4165d3a70901060908y1c47665atb6b204bbce07a852@mail.gmail.com> <326254A1-FD8B-4B7C-A1BD-344987E79967@lempsink.nl> <4165d3a70901071258i32d9d22fhb361dd8fb8c85e57@mail.gmail.com> <2f9b2d30901071754i43802e80oba84a064b787636f@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3328704726E@EA-EXMSG-C334.europe.corp.microsoft.com> Good tricks! Would one of you like to write them up on the Wiki? http://haskell.org/haskellwiki/Template_Haskell Simon | -----Original Message----- | From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | Ryan Ingram | Sent: 08 January 2009 01:55 | To: Jeff Heard | Cc: haskell | Subject: Re: [Haskell-cafe] Template Haskell question | | On Wed, Jan 7, 2009 at 12:58 PM, Jeff Heard wrote: | > And how do I encode | > | > a{ mousePositionf = b } | > | > in template haskell without using the [| |] syntax, so that I can use mkName? | | Whenever I have a question like that, I just ask ghci: | | $ ghci -fth | ghci> :m Control.Monad.Identity Language.Haskell.TH | ghci> runQ [| 1 + 1 |] | InfixE (Just (LitE (IntegerL 1))) (VarE GHC.Num.+) (Just (LitE (IntegerL 1))) | ghci> runQ [| \x -> x { runIdentity = 1 } |] | LamE [VarP x_1] (RecUpdE (VarE x_1) [(Control.Monad.Identity.runIdentity,LitE (I | ntegerL 1))]) | | Note that GHCi shows TH names without "mkName" or quotes, so you need | to add those. But it shows you the structure you want to generate. | | You can also use $() and [| |] inside [| |] to generate additional | data in TH directly: | | ghci> runQ $ do { VarE n <- [| runIdentity |] ; [| \x -> $(recUpdE [| | x |] [ fmap (\e -> (n,e)) [| 1 |] ]) |] } | LamE [VarP x_2] (RecUpdE (VarE x_2) [(Control.Monad.Identity.runIdentity,LitE (I | ntegerL 1))]) | | Note the "VarE n <- [| identifier |]" trick to extract the name from | an identifier. | | -- ryan | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe From lrpalmer at gmail.com Thu Jan 8 03:40:57 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Jan 8 03:32:28 2009 Subject: [Haskell-cafe] How to give unique name/id to nodes outside any monad ? In-Reply-To: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> References: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> Message-ID: <7ca3f0160901080040p2a9a38e0rea4bc2b939533d35@mail.gmail.com> On Thu, Jan 8, 2009 at 1:28 AM, minh thu wrote: > Hi, > > I'd like to process some kind of graph data structure, > say something like > > data DS = A [DS] | B DS DS | C. > > but I want to be able to discover any sharing. > Thus, in > > b = B a a where a = A [C], > > if I want to malloc a similar data structure, > I have to handle to the node representing B > two times the same pointer (the one returned > after allocating A [C]). > > To discover sharing, I thought it would be > necessary to give unique name to node and > then compare them while traversing the graph. > I could give the name by hand but it would be > cumbersome. But at least it would not require > any monad for the bookkeeping of ungiven > names. Is it possible to give those names > automatically but outside any monad ? If your graphs are acyclic, then you can label each node with a hash and use that for comparison. This usually works very well in practice. Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090108/f2820cbf/attachment.htm From lennart at augustsson.net Thu Jan 8 03:48:45 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Jan 8 03:40:14 2009 Subject: [Haskell-cafe] How to give unique name/id to nodes outside any monad ? In-Reply-To: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> References: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> Message-ID: Of course you don't need a monad, but you need to do the same operations as you would with a state monad to number the nodes. This is the only way in (pure) Haskell. There is no object identity in Haskell, so if you want the nodes to have identity you need to provide it. GHC does have a library for stable names which (in the IO monad) allows you to get something akin to the address of a value in memory. But that's not the functional way of doing this. -- Lennart On Thu, Jan 8, 2009 at 9:28 AM, minh thu wrote: > Hi, > > I'd like to process some kind of graph data structure, > say something like > > data DS = A [DS] | B DS DS | C. > > but I want to be able to discover any sharing. > Thus, in > > b = B a a where a = A [C], > > if I want to malloc a similar data structure, > I have to handle to the node representing B > two times the same pointer (the one returned > after allocating A [C]). > > To discover sharing, I thought it would be > necessary to give unique name to node and > then compare them while traversing the graph. > I could give the name by hand but it would be > cumbersome. But at least it would not require > any monad for the bookkeeping of ungiven > names. Is it possible to give those names > automatically but outside any monad ? > > Thanks, > Thu > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From noteed at gmail.com Thu Jan 8 03:49:04 2009 From: noteed at gmail.com (minh thu) Date: Thu Jan 8 03:40:34 2009 Subject: [Haskell-cafe] How to give unique name/id to nodes outside any monad ? In-Reply-To: <7ca3f0160901080040p2a9a38e0rea4bc2b939533d35@mail.gmail.com> References: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> <7ca3f0160901080040p2a9a38e0rea4bc2b939533d35@mail.gmail.com> Message-ID: <40a414c20901080049w3cd2d202w9e71137b9868bd7@mail.gmail.com> 2009/1/8 Luke Palmer : > On Thu, Jan 8, 2009 at 1:28 AM, minh thu wrote: >> >> Hi, >> >> I'd like to process some kind of graph data structure, >> say something like >> >> data DS = A [DS] | B DS DS | C. >> >> but I want to be able to discover any sharing. >> Thus, in >> >> b = B a a where a = A [C], >> >> if I want to malloc a similar data structure, >> I have to handle to the node representing B >> two times the same pointer (the one returned >> after allocating A [C]). >> >> To discover sharing, I thought it would be >> necessary to give unique name to node and >> then compare them while traversing the graph. >> I could give the name by hand but it would be >> cumbersome. But at least it would not require >> any monad for the bookkeeping of ungiven >> names. Is it possible to give those names >> automatically but outside any monad ? > > If your graphs are acyclic, then you can label each node with a hash and use > that for comparison. This usually works very well in practice. Precisely ! How do you give that label to each node; i.e. how to ensure they are unique ? I don't want to end up with do c <- newNodeC a <- newNodeA [c] b <- newNodeB a a where newNodeX hides the handling of label. I'd like to simply write, like above, b = B a a where a = A [C] or, maybe, b = B label a a where a = A label [C] The question is : how can label be different each time ? Thanks, Thu From noteed at gmail.com Thu Jan 8 03:53:46 2009 From: noteed at gmail.com (minh thu) Date: Thu Jan 8 03:45:16 2009 Subject: [Haskell-cafe] How to give unique name/id to nodes outside any monad ? In-Reply-To: References: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> Message-ID: <40a414c20901080053n7fd36430he551f27c8fc06e58@mail.gmail.com> Well, the processing of the data structure has to be done in the IO monad. What is the library you talk about ? Could it give the "stable names" (in IO) for each node of the mentioned graph (I mean, after the graph has been constructed purely) ? Thanks, Thu 2009/1/8 Lennart Augustsson : > Of course you don't need a monad, but you need to do the same > operations as you would with a state monad to number the nodes. This > is the only way in (pure) Haskell. There is no object identity in > Haskell, so if you want the nodes to have identity you need to provide > it. > > GHC does have a library for stable names which (in the IO monad) > allows you to get something akin to the address of a value in memory. > But that's not the functional way of doing this. > > -- Lennart > > On Thu, Jan 8, 2009 at 9:28 AM, minh thu wrote: >> Hi, >> >> I'd like to process some kind of graph data structure, >> say something like >> >> data DS = A [DS] | B DS DS | C. >> >> but I want to be able to discover any sharing. >> Thus, in >> >> b = B a a where a = A [C], >> >> if I want to malloc a similar data structure, >> I have to handle to the node representing B >> two times the same pointer (the one returned >> after allocating A [C]). >> >> To discover sharing, I thought it would be >> necessary to give unique name to node and >> then compare them while traversing the graph. >> I could give the name by hand but it would be >> cumbersome. But at least it would not require >> any monad for the bookkeeping of ungiven >> names. Is it possible to give those names >> automatically but outside any monad ? >> >> Thanks, >> Thu >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > From noteed at gmail.com Thu Jan 8 03:58:52 2009 From: noteed at gmail.com (minh thu) Date: Thu Jan 8 03:50:21 2009 Subject: [Haskell-cafe] How to give unique name/id to nodes outside any monad ? In-Reply-To: <40a414c20901080053n7fd36430he551f27c8fc06e58@mail.gmail.com> References: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> <40a414c20901080053n7fd36430he551f27c8fc06e58@mail.gmail.com> Message-ID: <40a414c20901080058m5654289bu24e1f3d19af3e5d6@mail.gmail.com> Great, System.Mem.StableName [1] seems to be able to do the trick. Thank you. [1] http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-StableName.html 2009/1/8 minh thu : > Well, the processing of the data structure has to be done in the IO monad. > What is the library you talk about ? Could it give the "stable names" > (in IO) for > each node of the mentioned graph (I mean, after the graph has been constructed > purely) ? > > Thanks, > Thu > > 2009/1/8 Lennart Augustsson : >> Of course you don't need a monad, but you need to do the same >> operations as you would with a state monad to number the nodes. This >> is the only way in (pure) Haskell. There is no object identity in >> Haskell, so if you want the nodes to have identity you need to provide >> it. >> >> GHC does have a library for stable names which (in the IO monad) >> allows you to get something akin to the address of a value in memory. >> But that's not the functional way of doing this. >> >> -- Lennart >> >> On Thu, Jan 8, 2009 at 9:28 AM, minh thu wrote: >>> Hi, >>> >>> I'd like to process some kind of graph data structure, >>> say something like >>> >>> data DS = A [DS] | B DS DS | C. >>> >>> but I want to be able to discover any sharing. >>> Thus, in >>> >>> b = B a a where a = A [C], >>> >>> if I want to malloc a similar data structure, >>> I have to handle to the node representing B >>> two times the same pointer (the one returned >>> after allocating A [C]). >>> >>> To discover sharing, I thought it would be >>> necessary to give unique name to node and >>> then compare them while traversing the graph. >>> I could give the name by hand but it would be >>> cumbersome. But at least it would not require >>> any monad for the bookkeeping of ungiven >>> names. Is it possible to give those names >>> automatically but outside any monad ? >>> >>> Thanks, >>> Thu >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> > From lennart at augustsson.net Thu Jan 8 04:01:59 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Jan 8 03:53:28 2009 Subject: [Haskell-cafe] How to give unique name/id to nodes outside any monad ? In-Reply-To: <40a414c20901080053n7fd36430he551f27c8fc06e58@mail.gmail.com> References: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> <40a414c20901080053n7fd36430he551f27c8fc06e58@mail.gmail.com> Message-ID: Look at http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-StableName.html. But what's wrong with constructing the graph in a monad? On Thu, Jan 8, 2009 at 9:53 AM, minh thu wrote: > Well, the processing of the data structure has to be done in the IO monad. > What is the library you talk about ? Could it give the "stable names" > (in IO) for > each node of the mentioned graph (I mean, after the graph has been constructed > purely) ? > > Thanks, > Thu > > 2009/1/8 Lennart Augustsson : >> Of course you don't need a monad, but you need to do the same >> operations as you would with a state monad to number the nodes. This >> is the only way in (pure) Haskell. There is no object identity in >> Haskell, so if you want the nodes to have identity you need to provide >> it. >> >> GHC does have a library for stable names which (in the IO monad) >> allows you to get something akin to the address of a value in memory. >> But that's not the functional way of doing this. >> >> -- Lennart >> >> On Thu, Jan 8, 2009 at 9:28 AM, minh thu wrote: >>> Hi, >>> >>> I'd like to process some kind of graph data structure, >>> say something like >>> >>> data DS = A [DS] | B DS DS | C. >>> >>> but I want to be able to discover any sharing. >>> Thus, in >>> >>> b = B a a where a = A [C], >>> >>> if I want to malloc a similar data structure, >>> I have to handle to the node representing B >>> two times the same pointer (the one returned >>> after allocating A [C]). >>> >>> To discover sharing, I thought it would be >>> necessary to give unique name to node and >>> then compare them while traversing the graph. >>> I could give the name by hand but it would be >>> cumbersome. But at least it would not require >>> any monad for the bookkeeping of ungiven >>> names. Is it possible to give those names >>> automatically but outside any monad ? >>> >>> Thanks, >>> Thu >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> > From lrpalmer at gmail.com Thu Jan 8 04:04:36 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Jan 8 03:56:07 2009 Subject: [Haskell-cafe] How to give unique name/id to nodes outside any monad ? In-Reply-To: <40a414c20901080049w3cd2d202w9e71137b9868bd7@mail.gmail.com> References: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> <7ca3f0160901080040p2a9a38e0rea4bc2b939533d35@mail.gmail.com> <40a414c20901080049w3cd2d202w9e71137b9868bd7@mail.gmail.com> Message-ID: <7ca3f0160901080104r6d6ab520if64d44b737aa81f2@mail.gmail.com> On Thu, Jan 8, 2009 at 1:49 AM, minh thu wrote: > I'd like to simply write, like above, > > b = B a a where a = A [C] > > or, maybe, > > b = B label a a where a = A label [C] > > The question is : how can label be different each time ? Haskell is pure, so I can answer this precisely: obviously you cannot. Sharing is *not* observable in Haskell, because it breaks referential transparency, a very important property. So what I meant by hashing was, eg.: newtype Hash = ... data Foo = Foo Hash Int [Foo] mkFoo :: Int -> [Foo] -> Foo mkFoo n xs = Foo (hash (show n ++ concatMap (\(Foo h _ _) -> show h))) n xs hash :: String -> Hash hash = ... -- some cryptographic hash function Probably going through Strings is not the smartest way, but you get the idea? Then when two Foos have the same hash, you have odds of 1/2^64 or whatever that they are the same object. You could also compare directly without hashes, but that is slower for large data structures (more correct though -- hash comparisons always gave me the creeps). I just saw your reply to the StableName suggestion. I should warn you -- you should use this information only for optimization internal to your program. If you use it for observable effects, e.g. generating code or writing to a file[1], you are writing *bad haskell*, and you will not only lose the benefits of Haskell's purity, but you will be bitten by the unpredictable zeal of the optimizer. Luke [1] Unless you read the file back into the data structure, where the sharing is once again not observable. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090108/d8eb3bcb/attachment.htm From noteed at gmail.com Thu Jan 8 04:21:30 2009 From: noteed at gmail.com (minh thu) Date: Thu Jan 8 04:13:01 2009 Subject: [Haskell-cafe] How to give unique name/id to nodes outside any monad ? In-Reply-To: References: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> <40a414c20901080053n7fd36430he551f27c8fc06e58@mail.gmail.com> Message-ID: <40a414c20901080121u2038f1e1mcb3085769db18973@mail.gmail.com> Nothing, simply the notation. Now, with the remark of Luke, I'm wondering how bad it is to use makeStableName/hashStableName to "copy" the data structure in a similar one with explicit reference (that is, using pointer or keys in a map or whatever). Thank you, Thu 2009/1/8 Lennart Augustsson : > Look at http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-StableName.html. > > But what's wrong with constructing the graph in a monad? > > On Thu, Jan 8, 2009 at 9:53 AM, minh thu wrote: >> Well, the processing of the data structure has to be done in the IO monad. >> What is the library you talk about ? Could it give the "stable names" >> (in IO) for >> each node of the mentioned graph (I mean, after the graph has been constructed >> purely) ? >> >> Thanks, >> Thu >> >> 2009/1/8 Lennart Augustsson : >>> Of course you don't need a monad, but you need to do the same >>> operations as you would with a state monad to number the nodes. This >>> is the only way in (pure) Haskell. There is no object identity in >>> Haskell, so if you want the nodes to have identity you need to provide >>> it. >>> >>> GHC does have a library for stable names which (in the IO monad) >>> allows you to get something akin to the address of a value in memory. >>> But that's not the functional way of doing this. >>> >>> -- Lennart >>> >>> On Thu, Jan 8, 2009 at 9:28 AM, minh thu wrote: >>>> Hi, >>>> >>>> I'd like to process some kind of graph data structure, >>>> say something like >>>> >>>> data DS = A [DS] | B DS DS | C. >>>> >>>> but I want to be able to discover any sharing. >>>> Thus, in >>>> >>>> b = B a a where a = A [C], >>>> >>>> if I want to malloc a similar data structure, >>>> I have to handle to the node representing B >>>> two times the same pointer (the one returned >>>> after allocating A [C]). >>>> >>>> To discover sharing, I thought it would be >>>> necessary to give unique name to node and >>>> then compare them while traversing the graph. >>>> I could give the name by hand but it would be >>>> cumbersome. But at least it would not require >>>> any monad for the bookkeeping of ungiven >>>> names. Is it possible to give those names >>>> automatically but outside any monad ? >>>> >>>> Thanks, >>>> Thu >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe@haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>> >> > From newhoggy at gmail.com Thu Jan 8 05:26:55 2009 From: newhoggy at gmail.com (John Ky) Date: Thu Jan 8 05:18:25 2009 Subject: [Haskell-cafe] Debugging STM Message-ID: Hi, Does anyone have any advice on how to inspect complex TVar data structures that may include cycles? They're opaque as far as Show goes. And sometimes I'd like a more comprehensive view of my data structures at the ghci prompt rather than the dribs and drabs I get by typing "x <- atomically $ readTVar var" and the like all the time. Also, do TVars have a printable identity for debugging purposes? Thanks -John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090108/1e7e14a4/attachment.htm From manlio_perillo at libero.it Thu Jan 8 05:58:37 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Thu Jan 8 05:50:21 2009 Subject: [Haskell-cafe] Re: Hypothetical Haskell job in New York In-Reply-To: References: Message-ID: <4965DC5D.1050006@libero.it> Tony Hannan ha scritto: > Let me give you more information about this hypothetical job posting. > Our company is a startup CDN > (http://en.wikipedia.org/wiki/Content_Delivery_Network) about 3 years > old and doing well. You would hythothetically be one of 7 programmer who > write all the software involved in a CDN including http server, dns > server, monitoring, load balancing, customer and operator user > interface, etc. The pay depends on experience but is good. > Isn't it better to use Erlang for the http and dns server ? I don't really like the syntax, but you have many things already implemented. Unfortunately Haskell is not yet ready for this task. http://eddie.sourceforge.net/what.html http://yaws.hyber.org/ > [...] Regards Manlio Perillo From arumakanil at gmail.com Thu Jan 8 05:59:18 2009 From: arumakanil at gmail.com (nml) Date: Thu Jan 8 05:50:49 2009 Subject: [Haskell-cafe] ideas for a phd in the area of paralleism? In-Reply-To: <5f8b37690901070135x203bc234mcfacf451eb71ade0@mail.gmail.com> References: <5f8b37690901070135x203bc234mcfacf451eb71ade0@mail.gmail.com> Message-ID: <531137340901080259w2199cfcbx181df0dc7546b276@mail.gmail.com> Hi, check http://www.intellasys.net/index.php?option=com_content&task=view&id=35 http://groups.google.com.tw/group/seaforth That's a FORTH cpu I ever took a look one year ago when my professor introduced it. It has some very promising features as the above links claims.The most impressive one for me is its mechanism of inter-core commuication. Unfortunately(FORTH advocators may disagree), it seems to require native FORTH programming and manual parallelism among the processor arrary. I wonder whether it's possible to implement a compiler with parallelism capability(coordinate those cores) on it, especially for functional languages. Regards, Mura From briqueabraque at yahoo.com Thu Jan 8 06:05:04 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Thu Jan 8 05:56:55 2009 Subject: [Haskell-cafe] Computer time, independent of date Message-ID: Hi, I'm writing a program where I need to know elapsed times between some events, but I can't depende on Data.Time since ntpd or user can change that while my program is running. Is there an alternative? Something like how much time has passed since the program has started would be great. Thanks, Maur?cio From barsoap at web.de Thu Jan 8 06:10:15 2009 From: barsoap at web.de (Achim Schneider) Date: Thu Jan 8 06:01:57 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] References: <4965DC5D.1050006@libero.it> Message-ID: <20090108121015.3bc72877@solaris> Manlio Perillo wrote: > Unfortunately Haskell is not yet ready for this task. > Could you -- or someone else -- please elaborate on this? I've heard it once in the context of a webbrowser, the reason given was that ghc doesn't deallocate memory, that is, the gc heap only increases. I doubt it'd be hard to fix, not to mention that, iff a Haskell process is more or less the only process running on a system, deallocation becomes practically irrelevant... which'd be the case with e.g. a HAppS production server. Any other known problems? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From manlio_perillo at libero.it Thu Jan 8 06:24:59 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Thu Jan 8 06:16:53 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <20090108121015.3bc72877@solaris> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> Message-ID: <4965E28B.1000602@libero.it> Achim Schneider ha scritto: > Manlio Perillo wrote: > >> Unfortunately Haskell is not yet ready for this task. >> > Could you -- or someone else -- please elaborate on this? > Here is a list of things that I would like to see in GHC to start developing a server application (in order of importance) 1) Support for scalable IO multiplexing. The GHC runtime only supports select. I find the ideas from the Unify paper interesting, however I don't really know if the implementation is "robust". I would also like to have epoll/kqueue support in single threaded applications 2) Convenient and flexible method for reading a stream of data. Lazy IO is not the answer. Iteratee seems interesting. 3) Support for process supervisor in the runtime. Of course I'm not interested in the Erlang supervisor system (spread over multiple machine), but I would like a simple master/slave system, like Nginx > [...] Regards Manlio Perillo From marco-oweber at gmx.de Thu Jan 8 06:50:29 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Thu Jan 8 06:42:02 2009 Subject: [Haskell-cafe] Computer time, independent of date In-Reply-To: References: Message-ID: <20090108115029.GA20403@gmx.de> > Is there an alternative? Something like how much > time has passed since the program has started would > be great. Have a look at benchpress on hackage. Sincerly Marc Weber From es at ertes.de Thu Jan 8 07:13:40 2009 From: es at ertes.de (Ertugrul Soeylemez) Date: Thu Jan 8 07:05:19 2009 Subject: [Haskell-cafe] Re: How to give unique name/id to nodes outside any monad ? References: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> <40a414c20901080053n7fd36430he551f27c8fc06e58@mail.gmail.com> <40a414c20901080121u2038f1e1mcb3085769db18973@mail.gmail.com> Message-ID: <20090108131340.0b9f48e6@tritium.xx> "minh thu" wrote: > Nothing, simply the notation. Now, with the remark of Luke, I'm > wondering how bad it is to use makeStableName/hashStableName to "copy" > the data structure in a similar one with explicit reference (that is, > using pointer or keys in a map or whatever). Probably you're misusing the notation. I don't see any reason, why monadic notation should be less readable. Usually it's even more readable. Luke's remark is very valid. Haskell is the wrong language for imperative programming. You don't have _any_ benefit of Haskell, if you use it like C. Try to change your mind. Monads aren't evil. They are there to make your life easier. Way easier than imperative methods. Greets, Ertugrul. > Thank you, > Thu > > 2009/1/8 Lennart Augustsson : > > Look at http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-StableName.html. > > > > But what's wrong with constructing the graph in a monad? > > > > On Thu, Jan 8, 2009 at 9:53 AM, minh thu wrote: > >> Well, the processing of the data structure has to be done in the IO monad. > >> What is the library you talk about ? Could it give the "stable names" > >> (in IO) for > >> each node of the mentioned graph (I mean, after the graph has been constructed > >> purely) ? > >> > >> Thanks, > >> Thu > >> > >> 2009/1/8 Lennart Augustsson : > >>> Of course you don't need a monad, but you need to do the same > >>> operations as you would with a state monad to number the nodes. This > >>> is the only way in (pure) Haskell. There is no object identity in > >>> Haskell, so if you want the nodes to have identity you need to provide > >>> it. > >>> > >>> GHC does have a library for stable names which (in the IO monad) > >>> allows you to get something akin to the address of a value in memory. > >>> But that's not the functional way of doing this. > >>> > >>> -- Lennart > >>> > >>> On Thu, Jan 8, 2009 at 9:28 AM, minh thu wrote: > >>>> Hi, > >>>> > >>>> I'd like to process some kind of graph data structure, > >>>> say something like > >>>> > >>>> data DS = A [DS] | B DS DS | C. > >>>> > >>>> but I want to be able to discover any sharing. > >>>> Thus, in > >>>> > >>>> b = B a a where a = A [C], > >>>> > >>>> if I want to malloc a similar data structure, > >>>> I have to handle to the node representing B > >>>> two times the same pointer (the one returned > >>>> after allocating A [C]). > >>>> > >>>> To discover sharing, I thought it would be > >>>> necessary to give unique name to node and > >>>> then compare them while traversing the graph. > >>>> I could give the name by hand but it would be > >>>> cumbersome. But at least it would not require > >>>> any monad for the bookkeeping of ungiven > >>>> names. Is it possible to give those names > >>>> automatically but outside any monad ? > >>>> > >>>> Thanks, > >>>> Thu > >>>> _______________________________________________ > >>>> Haskell-Cafe mailing list > >>>> Haskell-Cafe@haskell.org > >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe > >>>> > >>> > >> > > -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/ From briqueabraque at yahoo.com Thu Jan 8 07:21:45 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Thu Jan 8 07:13:24 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: <20090108115029.GA20403@gmx.de> References: <20090108115029.GA20403@gmx.de> Message-ID: >> Is there an alternative? Something like how much >> time has passed since the program has started would >> be great. > > Have a look at benchpress on hackage. > But benchpress uses Data.Time.Clock.getCurrentTime. I understand that is dependent from configuration. It's okay to benchmark a fast application, but mine will be running for days, so it would not be reliable. Best, Maur?cio From noteed at gmail.com Thu Jan 8 08:03:10 2009 From: noteed at gmail.com (minh thu) Date: Thu Jan 8 07:54:40 2009 Subject: [Haskell-cafe] Re: How to give unique name/id to nodes outside any monad ? In-Reply-To: <20090108131340.0b9f48e6@tritium.xx> References: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> <40a414c20901080053n7fd36430he551f27c8fc06e58@mail.gmail.com> <40a414c20901080121u2038f1e1mcb3085769db18973@mail.gmail.com> <20090108131340.0b9f48e6@tritium.xx> Message-ID: <40a414c20901080503l56a05d1u8988ec89913bf1f8@mail.gmail.com> 2009/1/8 Ertugrul Soeylemez : > "minh thu" wrote: > >> Nothing, simply the notation. Now, with the remark of Luke, I'm >> wondering how bad it is to use makeStableName/hashStableName to "copy" >> the data structure in a similar one with explicit reference (that is, >> using pointer or keys in a map or whatever). > > Probably you're misusing the notation. I don't see any reason, why > monadic notation should be less readable. Usually it's even more > readable. Luke's remark is very valid. Haskell is the wrong language > for imperative programming. You don't have _any_ benefit of Haskell, if > you use it like C. Try to change your mind. Monads aren't evil. They > are there to make your life easier. Way easier than imperative methods. Well, maybe it's is just my opinion, but I found the non-monadic code in the previous mail easier to write than the monadic one... I don't know against what you're making the compareason to say it's more readable. Although I agree using Haskell requires some change of thinking, statement like yours are a bit too much for me. I find Haskell a nice language even for imperative programming... Cheers, Thu > Greets, > Ertugrul. > > >> Thank you, >> Thu >> >> 2009/1/8 Lennart Augustsson : >> > Look at http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-StableName.html. >> > >> > But what's wrong with constructing the graph in a monad? >> > >> > On Thu, Jan 8, 2009 at 9:53 AM, minh thu wrote: >> >> Well, the processing of the data structure has to be done in the IO monad. >> >> What is the library you talk about ? Could it give the "stable names" >> >> (in IO) for >> >> each node of the mentioned graph (I mean, after the graph has been constructed >> >> purely) ? >> >> >> >> Thanks, >> >> Thu >> >> >> >> 2009/1/8 Lennart Augustsson : >> >>> Of course you don't need a monad, but you need to do the same >> >>> operations as you would with a state monad to number the nodes. This >> >>> is the only way in (pure) Haskell. There is no object identity in >> >>> Haskell, so if you want the nodes to have identity you need to provide >> >>> it. >> >>> >> >>> GHC does have a library for stable names which (in the IO monad) >> >>> allows you to get something akin to the address of a value in memory. >> >>> But that's not the functional way of doing this. >> >>> >> >>> -- Lennart >> >>> >> >>> On Thu, Jan 8, 2009 at 9:28 AM, minh thu wrote: >> >>>> Hi, >> >>>> >> >>>> I'd like to process some kind of graph data structure, >> >>>> say something like >> >>>> >> >>>> data DS = A [DS] | B DS DS | C. >> >>>> >> >>>> but I want to be able to discover any sharing. >> >>>> Thus, in >> >>>> >> >>>> b = B a a where a = A [C], >> >>>> >> >>>> if I want to malloc a similar data structure, >> >>>> I have to handle to the node representing B >> >>>> two times the same pointer (the one returned >> >>>> after allocating A [C]). >> >>>> >> >>>> To discover sharing, I thought it would be >> >>>> necessary to give unique name to node and >> >>>> then compare them while traversing the graph. >> >>>> I could give the name by hand but it would be >> >>>> cumbersome. But at least it would not require >> >>>> any monad for the bookkeeping of ungiven >> >>>> names. Is it possible to give those names >> >>>> automatically but outside any monad ? >> >>>> >> >>>> Thanks, >> >>>> Thu >> >>>> _______________________________________________ >> >>>> Haskell-Cafe mailing list >> >>>> Haskell-Cafe@haskell.org >> >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >>>> >> >>> >> >> >> > > > > > -- > nightmare = unsafePerformIO (getWrongWife >>= sex) > http://blog.ertes.de/ > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From kelanslists at gmail.com Thu Jan 8 08:27:24 2009 From: kelanslists at gmail.com (Kurt Hutchinson) Date: Thu Jan 8 08:18:52 2009 Subject: [Haskell-cafe] State Monad - using the updated state In-Reply-To: References: Message-ID: Ryan gave some great advice about restructuring your program to do what you want, but I wanted to give a small explanation of why that's necessary. 2009/1/7 Phil : > I want to be able to do: > > Get_a_random_number > > < a whole load of other stuff > > > Get the next number as defined by the updated state in the first call > > > > Get another number, and so on. The issue you're having is that you're trying to do the "other stuff" in your 'main', but main isn't inside the State monad. The only State computation you're calling from main is getRanq1, but you really need another State computation that does "other stuff" and calls getRanq1 itself. That's what Ryan's first suggestion implements. You need all your "other stuff" to be done inside the State monad so that it has read/update access to the current random state. So all your main does is run a State computation. That computation calls getRanq1 itself and then "other stuff" in between calls to getRanq1. Does that make sense? Kurt From hallgren at altocumulus.org Thu Jan 8 09:13:02 2009 From: hallgren at altocumulus.org (Thomas Hallgren) Date: Thu Jan 8 09:04:32 2009 Subject: [Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <20090108121015.3bc72877@solaris> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> Message-ID: <496609EE.1060909@altocumulus.org> On 2009-01-08 12:10, Achim Schneider wrote: > Manlio Perillo wrote: > >> Unfortunately Haskell is not yet ready for this task. >> > Could you -- or someone else -- please elaborate on this? I think Haskell is ready for a lot more than most people think. How about an operating system in Haskell, for example? I think House shows that it could be done. http://programatica.cs.pdx.edu/House/ > > I've heard it once in the context of a webbrowser, the reason given was > that ghc doesn't deallocate memory, that is, the gc heap only > increases. I doubt it'd be hard to fix, Even if the GHC RTS doesn't return unused heap memory to the operating system, I don't see why this would prevent you from implementing a useful web browser in Haskell. As a comparison, my Firefox process currently uses 717MB of memory. I usually restart Firefox every day to bring the memory use down to a reasonable level. The situation would probably be the same if I used a browser implemented in Haskell. Incidentally, I did implement a web browser in Haskell back in the 90s, and it worked fine :-) But that was before JavaScript and CSS, so it would take some work to make it useful on the web of today... http://www.cs.chalmers.se/~hallgren/wwwbrowser.html Thomas Hallgren From john at n-brain.net Thu Jan 8 09:32:37 2009 From: john at n-brain.net (John A. De Goes) Date: Thu Jan 8 09:24:10 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <20090108121015.3bc72877@solaris> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> Message-ID: <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> Haskell's networking support is very rudimentary. Erlang's is quite sophisticated. For network intensive applications, especially those requiring messaging, fault-tolerance, distribution, and so forth, there's no doubt that Erlang is a more productive choice. Not because of the language, per se, but because of all the stuff that is packaged with it, or available for it. Regards, John On Jan 8, 2009, at 4:10 AM, Achim Schneider wrote: > Manlio Perillo wrote: > >> Unfortunately Haskell is not yet ready for this task. >> > Could you -- or someone else -- please elaborate on this? > > I've heard it once in the context of a webbrowser, the reason given > was > that ghc doesn't deallocate memory, that is, the gc heap only > increases. I doubt it'd be hard to fix, not to mention that, iff a > Haskell process is more or less the only process running on a system, > deallocation becomes practically irrelevant... which'd be the case > with > e.g. a HAppS production server. > > Any other known problems? > > -- > (c) this sig last receiving data processing entity. Inspect headers > for copyright history. All rights reserved. Copying, hiring, renting, > performance and/or quoting of this signature prohibited. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From frodo at theshire.org Thu Jan 8 09:36:08 2009 From: frodo at theshire.org (Cristiano Paris) Date: Thu Jan 8 09:27:39 2009 Subject: [Haskell-cafe] Taking Exception to Exceptions In-Reply-To: <1231370528-sup-5395@existential.local> References: <1231370528-sup-5395@existential.local> Message-ID: On Thu, Jan 8, 2009 at 12:32 AM, Austin Seipp wrote: > Excerpts from Immanuel Litzroth's message of Wed Jan 07 16:53:30 -0600 2009: > ... >> I am little amazed that I cannot get catch, try or mapException to work >> without telling them which exceptions I want to catch. >> What is the rationale behind this? > > The rational is that it's normally not a good idea to simply gobble > all exceptions; although the library makes it possible to do this > anyway. I'd advice always putting an additional generic catch-all at the top level, at least to present the user a (possibly generic) error message, just to stay in control. This avoids the possibility of having an unwanted/unknown behavior from the run-time stack (for example, having the web server returning a generic 500 Internal Server error report, filled with every sort of goods a cracker would be happy for). Cristiano From denbuen at sandia.gov Thu Jan 8 09:51:31 2009 From: denbuen at sandia.gov (Bueno, Denis) Date: Thu Jan 8 09:41:12 2009 Subject: [Haskell-cafe] Re: Blitting one IOUArray into another In-Reply-To: Message-ID: On 01/07/2009 14:36 , "Neal Alexander" wrote: > Bueno, Denis wrote: >> Oh, do you mean by actually calling memcpy via ffi? > > http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-Marshal-Uti > ls.html Ah, thanks. Is there a way to simply "cast" an IOUArray Int Int64 into something like a Ptr Int64, or will I need to change my code to allocate the arrays differently (using something in Foreign.*)? I hoogle'd functions "IOUArray a b -> Ptr b", but couldn't find anything. Denis From martijn at van.steenbergen.nl Thu Jan 8 10:00:57 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Thu Jan 8 09:52:28 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: References: <20090108115029.GA20403@gmx.de> Message-ID: <49661529.3030309@van.steenbergen.nl> Mauricio wrote: > But benchpress uses Data.Time.Clock.getCurrentTime. I understand > that is dependent from configuration. It's okay to benchmark a > fast application, but mine will be running for days, so it > would not be reliable. benchpress also uses System.CPUTime -- is that what you are looking for? Martijn. From immanuel203 at gmail.com Thu Jan 8 10:37:11 2009 From: immanuel203 at gmail.com (Immanuel Litzroth) Date: Thu Jan 8 10:28:40 2009 Subject: [Haskell-cafe] Taking Exception to Exceptions In-Reply-To: <1231370528-sup-5395@existential.local> References: <1231370528-sup-5395@existential.local> Message-ID: > > > I recommend this paper for info, it's very easy to follow: > > http://www.haskell.org/~simonmar/papers/ext-exceptions.pdf > > Austin > That paper cleared up most of my issues and it is amazing that it is not amongst the papers that are referenced at the top of the the page describing Control.Exception. Anyway, there is one more problem I have related to exceptions that is about forcing strictness. It relates to option parsing. I have an option -t that says which track from a file of tracks to print. So I go data Flags = TrackNumber !Int deriving(Read, Show, Eq) makeTrackNumber :: String -> Flags makeTrackNumber str = TrackNumber $ read str options = [GetOpt.Option ['t'] ["tracknumber"] (GetOpt.ReqArg makeTrackNumber "tracknumber") "number of track to show"] Now my main goes main = do args <- getArgs opts <- evaluate $ GetOpt.getOpt GetOpt.RequireOrder options args print "done getting the opts" case opts of ... which of course first prints "done getting opts" and then throws an exception if I give it a flag -t abc. What would be the way to proceed here? Do I increase the strictness or do I write a handler around my complete main? Even if I map the exception in makeTrackNumber to my very own exception how do I find out which exact call gave a problem i.e. which is the call stack at the moment the exception was thrown -- I might use makeTrackNumber in other contexts too. Thanks in advance, Immanuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090108/50349221/attachment.htm From wchogg at gmail.com Thu Jan 8 10:41:40 2009 From: wchogg at gmail.com (Creighton Hogg) Date: Thu Jan 8 10:33:10 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> Message-ID: <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> On Thu, Jan 8, 2009 at 8:32 AM, John A. De Goes wrote: > > Haskell's networking support is very rudimentary. Erlang's is quite > sophisticated. For network intensive applications, especially those > requiring messaging, fault-tolerance, distribution, and so forth, there's no > doubt that Erlang is a more productive choice. > > Not because of the language, per se, but because of all the stuff that is > packaged with it, or available for it. Now I understand that there aren't(?) any Haskell implementations that can act as distributed nodes the way the Erlang implementation can, but I'm not familiar enough with Erlang to understand what it has for networking that the Haskell network packages don't have. Could you explain a bit further? I've been thinking a lot about network programming anyway lately & am looking for library opportunities. From john at n-brain.net Thu Jan 8 10:52:01 2009 From: john at n-brain.net (John A. De Goes) Date: Thu Jan 8 10:43:32 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> Message-ID: Take, for example, RabbitMQ. There's nothing even remotely close in Haskell-land. RabbitMQ is written in 100% Erlang. It's built on Open Telecom Platform, which again is without equal in Haskell. There are a lot of theoretical reasons why Haskell would be a good choice to build libraries such as these, but lacking any production implementations, it's all just theory. Regards, John On Jan 8, 2009, at 8:41 AM, Creighton Hogg wrote: > On Thu, Jan 8, 2009 at 8:32 AM, John A. De Goes > wrote: >> >> Haskell's networking support is very rudimentary. Erlang's is quite >> sophisticated. For network intensive applications, especially those >> requiring messaging, fault-tolerance, distribution, and so forth, >> there's no >> doubt that Erlang is a more productive choice. >> >> Not because of the language, per se, but because of all the stuff >> that is >> packaged with it, or available for it. > > Now I understand that there aren't(?) any Haskell implementations that > can act as distributed nodes the way the Erlang implementation can, > but I'm not familiar enough with Erlang to understand what it has for > networking that the Haskell network packages don't have. Could you > explain a bit further? I've been thinking a lot about network > programming anyway lately & am looking for library opportunities. From dav.vire+haskell at gmail.com Thu Jan 8 11:27:04 2009 From: dav.vire+haskell at gmail.com (david48) Date: Thu Jan 8 11:18:32 2009 Subject: [Haskell-cafe] Re: Hypothetical Haskell job in New York In-Reply-To: <4965DC5D.1050006@libero.it> References: <4965DC5D.1050006@libero.it> Message-ID: <4c88418c0901080827l12c4d7c8x3ab0b2bc33a14ac6@mail.gmail.com> On Thu, Jan 8, 2009 at 11:58 AM, Manlio Perillo wrote: > Unfortunately Haskell is not yet ready for this task. What makes you say that ? From jefferson.r.heard at gmail.com Thu Jan 8 12:04:40 2009 From: jefferson.r.heard at gmail.com (Jeff Heard) Date: Thu Jan 8 11:56:09 2009 Subject: [Haskell-cafe] Defining methods generically for a class Message-ID: <4165d3a70901080904n3fb37f67jf56312f9dbbd1c5e@mail.gmail.com> I have the following class: class Region a where numDimensions :: a -> Int dim :: Int -> a -> (Double,Double) merge :: a -> a -> a and several ancillary methods defined, the most importance of which is: bounds :: Region a => a -> [(Double,Double)] bounds r = take (numDimensions r) . map dim . iterate (+1) $ 0 Let's say that I want all Regions to also be of class Eq, where regiona == regionb = all $ zipWith (==) (bounds regiona) (bounds regionb) How do I declare all Regions to be Eqs without putting it in the class body (since I define a function over all Regions that is independent of datatype that is an instance of Region)? Is it merely: instance Region a => Eq a where regiona == regionb = all $ zipWith (==) (bounds regiona) (bounds regionb) -- Jeff From frodo at theshire.org Thu Jan 8 12:16:53 2009 From: frodo at theshire.org (Cristiano Paris) Date: Thu Jan 8 12:08:21 2009 Subject: [Haskell-cafe] Defining methods generically for a class In-Reply-To: <4165d3a70901080904n3fb37f67jf56312f9dbbd1c5e@mail.gmail.com> References: <4165d3a70901080904n3fb37f67jf56312f9dbbd1c5e@mail.gmail.com> Message-ID: On Thu, Jan 8, 2009 at 6:04 PM, Jeff Heard wrote: > ... > How do I declare all Regions to be Eqs without putting it in the class > body (since I define a function over all Regions that is independent > of datatype that is an instance of Region)? Would this be a solution? class Eq a => Region a where ... Cristiano From martijn at van.steenbergen.nl Thu Jan 8 12:26:14 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Thu Jan 8 12:17:43 2009 Subject: [Haskell-cafe] Defining methods generically for a class In-Reply-To: <4165d3a70901080904n3fb37f67jf56312f9dbbd1c5e@mail.gmail.com> References: <4165d3a70901080904n3fb37f67jf56312f9dbbd1c5e@mail.gmail.com> Message-ID: <49663736.7030105@van.steenbergen.nl> Hi Jeff, Jeff Heard wrote: > instance Region a => Eq a where > regiona == regionb = all $ zipWith (==) (bounds regiona) (bounds regionb) If you want to be Haskell98 compliant, why not define regionEquals :: Region a => a -> a -> Bool as above and use that everywhere instead of (==)? If you insist on using the overloaded (==), then in Haskell98 you will need to define individual Eq instances for all your custom region types. However, you can simply define (==) = regionEquals for all those types. Hope this helps, Martijn. From jefferson.r.heard at gmail.com Thu Jan 8 12:27:54 2009 From: jefferson.r.heard at gmail.com (Jeff Heard) Date: Thu Jan 8 12:19:22 2009 Subject: Fwd: [Haskell-cafe] Defining methods generically for a class In-Reply-To: <4165d3a70901080926o3638e06ch30e72870a5428e32@mail.gmail.com> References: <4165d3a70901080904n3fb37f67jf56312f9dbbd1c5e@mail.gmail.com> <4165d3a70901080926o3638e06ch30e72870a5428e32@mail.gmail.com> Message-ID: <4165d3a70901080927w19affed2i466e677618b891ae@mail.gmail.com> ---------- Forwarded message ---------- From: Jeff Heard Date: Thu, Jan 8, 2009 at 12:26 PM Subject: Re: [Haskell-cafe] Defining methods generically for a class To: Cristiano Paris Not really... I'm not testing if each of the items a are equal, but rather that in the context of them being a Region, they are equal.As long "dim" (which is in the class) can be defined, then equality is defined over all types Region. On Thu, Jan 8, 2009 at 12:16 PM, Cristiano Paris wrote: > On Thu, Jan 8, 2009 at 6:04 PM, Jeff Heard wrote: >> ... >> How do I declare all Regions to be Eqs without putting it in the class >> body (since I define a function over all Regions that is independent >> of datatype that is an instance of Region)? > > Would this be a solution? > > class Eq a => Region a where > ... > > Cristiano > From jefferson.r.heard at gmail.com Thu Jan 8 12:28:14 2009 From: jefferson.r.heard at gmail.com (Jeff Heard) Date: Thu Jan 8 12:19:43 2009 Subject: [Haskell-cafe] Defining methods generically for a class In-Reply-To: <4165d3a70901080927j1e24d14dvfef9fe0f884af2a5@mail.gmail.com> References: <4165d3a70901080904n3fb37f67jf56312f9dbbd1c5e@mail.gmail.com> <49663736.7030105@van.steenbergen.nl> <4165d3a70901080927j1e24d14dvfef9fe0f884af2a5@mail.gmail.com> Message-ID: <4165d3a70901080928x331ddc56ua99cf266c7f99367@mail.gmail.com> That's probably the best thing to do, yes. The purpose of doing so was for Data.List.delete, but I see now there's a Data.List.deleteBy, so I can use the regionEquals function as my equality predicate. On Thu, Jan 8, 2009 at 12:26 PM, Martijn van Steenbergen wrote: > Hi Jeff, > > Jeff Heard wrote: >> >> instance Region a => Eq a where >> regiona == regionb = all $ zipWith (==) (bounds regiona) (bounds >> regionb) > > If you want to be Haskell98 compliant, why not define regionEquals :: Region > a => a -> a -> Bool as above and use that everywhere instead of (==)? > > If you insist on using the overloaded (==), then in Haskell98 you will need > to define individual Eq instances for all your custom region types. However, > you can simply define (==) = regionEquals for all those types. > > Hope this helps, > > Martijn. > From newsham at lava.net Thu Jan 8 12:31:08 2009 From: newsham at lava.net (Tim Newsham) Date: Thu Jan 8 12:22:38 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> Message-ID: > Take, for example, RabbitMQ. There's nothing even remotely close in > Haskell-land. That would be useful for systems that require an "enterprise messaging system," I agree, but I don't see how that would be terribly important for a web server or most other networking services I might want to implement. > John Tim Newsham http://www.thenewsh.com/~newsham/ From john at n-brain.net Thu Jan 8 12:36:32 2009 From: john at n-brain.net (John A. De Goes) Date: Thu Jan 8 12:28:06 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> Message-ID: <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> The number of applications requiring the implementation of a custom web server is an insignificant fraction of the number of applications requiring a messaging system. I don't think anyone would dispute Haskell's ability to do low-level, raw networking, of the type that few people actually need to do. It's the higher level stuff where there's a huge amount of room for improvement. Regards, John On Jan 8, 2009, at 10:31 AM, Tim Newsham wrote: > That would be useful for systems that require an "enterprise > messaging system," I agree, but I don't see how that would > be terribly important for a web server or most other networking > services I might want to implement. From max.rabkin at gmail.com Thu Jan 8 12:50:36 2009 From: max.rabkin at gmail.com (Max Rabkin) Date: Thu Jan 8 12:42:14 2009 Subject: [Haskell-cafe] Taking Exception to Exceptions In-Reply-To: References: <1231370528-sup-5395@existential.local> Message-ID: On Thu, Jan 8, 2009 at 6:36 AM, Cristiano Paris wrote: > This avoids the possibility of having an unwanted/unknown behavior > from the run-time stack (for example, having the web server returning > a generic 500 Internal Server error report, filled with every sort of > goods a cracker would be happy for). So the information should be written to the log rather than the browser, at least in production, but there's no reason not to catch the exception. > Cristiano --Max From dons at galois.com Thu Jan 8 13:04:56 2009 From: dons at galois.com (Don Stewart) Date: Thu Jan 8 12:56:14 2009 Subject: [Haskell-cafe] Re: Hypothetical Haskell job in New York In-Reply-To: <4965DC5D.1050006@libero.it> References: <4965DC5D.1050006@libero.it> Message-ID: <20090108180456.GD22269@scytale.galois.com> manlio_perillo: > Tony Hannan ha scritto: > >Let me give you more information about this hypothetical job posting. > >Our company is a startup CDN > >(http://en.wikipedia.org/wiki/Content_Delivery_Network) about 3 years > >old and doing well. You would hythothetically be one of 7 programmer who > >write all the software involved in a CDN including http server, dns > >server, monitoring, load balancing, customer and operator user > >interface, etc. The pay depends on experience but is good. > > > > Isn't it better to use Erlang for the http and dns server ? > > I don't really like the syntax, but you have many things already > implemented. > Unfortunately Haskell is not yet ready for this task. > > http://eddie.sourceforge.net/what.html > http://yaws.hyber.org/ > Umm... http and dns? You're kidding right? Half of hackage.haskell.org is devoted to networking tasks. -- Don From dons at galois.com Thu Jan 8 13:06:19 2009 From: dons at galois.com (Don Stewart) Date: Thu Jan 8 12:57:34 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> Message-ID: <20090108180619.GE22269@scytale.galois.com> wchogg: > On Thu, Jan 8, 2009 at 8:32 AM, John A. De Goes wrote: > > > > Haskell's networking support is very rudimentary. Erlang's is quite > > sophisticated. For network intensive applications, especially those > > requiring messaging, fault-tolerance, distribution, and so forth, there's no > > doubt that Erlang is a more productive choice. > > > > Not because of the language, per se, but because of all the stuff that is > > packaged with it, or available for it. > > Now I understand that there aren't(?) any Haskell implementations that > can act as distributed nodes the way the Erlang implementation can, > but I'm not familiar enough with Erlang to understand what it has for > networking that the Haskell network packages don't have. Could you > explain a bit further? I've been thinking a lot about network > programming anyway lately & am looking for library opportunities. Note that there even exists an FFI binding to Erlang for Haskell, so that Haskell nodes can seamlessly interact with other nodes speaking Erlang's protocol format. There's nothing stopping you using Haskell nodes in a distributed fashion, and indeed there are groups doing this. -- Don From john at n-brain.net Thu Jan 8 13:14:18 2009 From: john at n-brain.net (John A. De Goes) Date: Thu Jan 8 13:05:51 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <20090108180619.GE22269@scytale.galois.com> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> Message-ID: There's a JavaScript binding to Java, and there's a Java binding to Erlang, so nothing's stopping you from using JavaScript nodes in a distributed fashion -- if you have a weird obsession with proving that JavaScript is well-suited for every task. But really, what's the point? FFI code is fragile, often uncompilable and unsupported, and doesn't observe the idioms of Haskell nor take advantage of its powerful language features. Rather than coding through FFI, a messaging application is better off written in 100% Erlang, because the libraries are native there and so confer all the benefits unique to native libraries. You can indeed fit a square peg in a round hole, if you pound hard enough. That doesn't mean it's a good thing to do. Here's hoping someone develops a native messaging framework for Haskell, which is the equal of RabbitMQ. Regards, John On Jan 8, 2009, at 11:06 AM, Don Stewart wrote: > wchogg: >> On Thu, Jan 8, 2009 at 8:32 AM, John A. De Goes >> wrote: >>> >>> Haskell's networking support is very rudimentary. Erlang's is quite >>> sophisticated. For network intensive applications, especially those >>> requiring messaging, fault-tolerance, distribution, and so forth, >>> there's no >>> doubt that Erlang is a more productive choice. >>> >>> Not because of the language, per se, but because of all the stuff >>> that is >>> packaged with it, or available for it. >> >> Now I understand that there aren't(?) any Haskell implementations >> that >> can act as distributed nodes the way the Erlang implementation can, >> but I'm not familiar enough with Erlang to understand what it has for >> networking that the Haskell network packages don't have. Could you >> explain a bit further? I've been thinking a lot about network >> programming anyway lately & am looking for library opportunities. > > Note that there even exists an FFI binding to Erlang for Haskell, so > that Haskell nodes can seamlessly interact with other nodes speaking > Erlang's protocol format. > > There's nothing stopping you using Haskell nodes in a distributed > fashion, and indeed there are groups doing this. > > -- Don From wchogg at gmail.com Thu Jan 8 13:36:01 2009 From: wchogg at gmail.com (Creighton Hogg) Date: Thu Jan 8 13:27:30 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <20090108180619.GE22269@scytale.galois.com> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> Message-ID: <814617240901081036n722047dbh5f25912ebae90ec0@mail.gmail.com> On Thu, Jan 8, 2009 at 12:06 PM, Don Stewart wrote: > wchogg: >> On Thu, Jan 8, 2009 at 8:32 AM, John A. De Goes wrote: >> > >> > Haskell's networking support is very rudimentary. Erlang's is quite >> > sophisticated. For network intensive applications, especially those >> > requiring messaging, fault-tolerance, distribution, and so forth, there's no >> > doubt that Erlang is a more productive choice. >> > >> > Not because of the language, per se, but because of all the stuff that is >> > packaged with it, or available for it. >> >> Now I understand that there aren't(?) any Haskell implementations that >> can act as distributed nodes the way the Erlang implementation can > There's nothing stopping you using Haskell nodes in a distributed > fashion, and indeed there are groups doing this. Didn't realize it was charted territory. Sorry about that. From haskell at list.mightyreason.com Thu Jan 8 13:38:47 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Thu Jan 8 13:30:29 2009 Subject: [Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> Message-ID: John A. De Goes wrote: > > Here's hoping someone develops a native messaging framework for Haskell, > which is the equal of RabbitMQ. > The first thing would be to make a Haskell client library to speak AMQP (Advanced Message Queuing Protocol) on the wire. It is a very open binary standard (with defined semantics!) at http://jira.amqp.org/confluence/display/AMQP/Advanced+Message+Queuing+Protocol I would be mildly surprised if zero people were working on this. Once that is in place then the question of a Haskell Broker for AMQP arises. But I suspect that Erlang's runtime will still rule there for "production use". -- Chris From jgoerzen at complete.org Thu Jan 8 13:42:11 2009 From: jgoerzen at complete.org (John Goerzen) Date: Thu Jan 8 13:33:45 2009 Subject: [Haskell-cafe] HookedBuildInfo and Cabal Message-ID: <20090108184211.GB25272@hustlerturf.com> Hi Brian & everyone, Got this bug report, which appears to be related to your autoconf patch. Did you test it on Windows? As a more general question, how can one use Cabal to detect PostgreSQL paths in a way that works with both GHC 6.8 and 6.10? The commit here was: commit 57c723873b020643b9062941a2ece130cd0f36c6 Author: Brian Bloniarz Date: Fri Dec 26 14:33:43 2008 -0500 Update hdbc-postgresql for GHC 6.10 & Cabal 1.6. This switches over to use autoconf rathe r than Cabal hooks to detect postgres paths; there's no backwards-compatible way to use write HookedBuildInfo with Cabal 1.2 and Cabal 1.6 (see http://www.haskell.org/pipermail/glasgow-ha skell-users/2008-October/015707.html) -- John ----- Forwarded message from software-noreply@complete.org ----- From: software-noreply@complete.org Date: Thu, 08 Jan 2009 12:37:12 -0600 Subject: [HDBC PostgreSQL driver - Bug #131] Throw exception when use data type "timpstamp without time zone" Issue #131 has been updated by Benjamin Cao. by the way, I cannot configure 1.1.6.0.0 successfully on my windows OS because of the Expr command(which is a linux command, even if I got a windows version of it, it keep crash on windows.) The function isFixedPointUnderConversionToLocalTime in 1.1.6.0.0 is the same. So I think it should be a same issue on 1.1.6.0.0 ---------------------------------------- Bug #131: Throw exception when use data type "timpstamp without time zone" http://software.complete.org/software/issues/show/131 Author: Benjamin Cao Status: New Priority: Normal Assigned to: Category: Target version: 1.1.4.1.0 Resolution: The database is like CREATE TABLE test ( "name" character varying(200) NOT NULL, "time" timestamp with time zone, timenotz timestamp without time zone, CONSTRAINT test_pkey PRIMARY KEY (name) ) WITH (OIDS=FALSE); ALTER TABLE test OWNER TO postgres; when call st <- prepare c "select name,time, timenotz from test" execute st [] Will get this error: Time.toClockTime: timezone offset out of range So I modified the function in statement.hsc to: isFixedPointUnderConversionToLocalTime calTime = do let hasError = False calTime' <- Control.Exception.catch (toLocalCalTime calTime) (\_->do let hasError = True return calTime) if hasError then return False else return $ eqParts calTime calTime' ---------------------------------------- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://software.complete.org/software/my/account ----- End forwarded message ----- From noteed at gmail.com Thu Jan 8 13:54:22 2009 From: noteed at gmail.com (minh thu) Date: Thu Jan 8 13:45:52 2009 Subject: [Haskell-cafe] Re: How to give unique name/id to nodes outside any monad ? In-Reply-To: <40a414c20901080503l56a05d1u8988ec89913bf1f8@mail.gmail.com> References: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> <40a414c20901080053n7fd36430he551f27c8fc06e58@mail.gmail.com> <40a414c20901080121u2038f1e1mcb3085769db18973@mail.gmail.com> <20090108131340.0b9f48e6@tritium.xx> <40a414c20901080503l56a05d1u8988ec89913bf1f8@mail.gmail.com> Message-ID: <40a414c20901081054i62f98377ma225fb1b3015b906@mail.gmail.com> Interestingly, I failed to detect sharing with StableName. But using the graph node as a key turned to work... If you're interested in the experiment, see attached code. Cheers, Thu 2009/1/8 minh thu : > 2009/1/8 Ertugrul Soeylemez : >> "minh thu" wrote: >> >>> Nothing, simply the notation. Now, with the remark of Luke, I'm >>> wondering how bad it is to use makeStableName/hashStableName to "copy" >>> the data structure in a similar one with explicit reference (that is, >>> using pointer or keys in a map or whatever). >> >> Probably you're misusing the notation. I don't see any reason, why >> monadic notation should be less readable. Usually it's even more >> readable. Luke's remark is very valid. Haskell is the wrong language >> for imperative programming. You don't have _any_ benefit of Haskell, if >> you use it like C. Try to change your mind. Monads aren't evil. They >> are there to make your life easier. Way easier than imperative methods. > > Well, maybe it's is just my opinion, but I found the non-monadic code > in the previous mail > easier to write than the monadic one... I don't know against what > you're making the compareason to say it's more readable. > > Although I agree using Haskell requires some change of thinking, > statement like yours > are a bit too much for me. I find Haskell a nice language even for > imperative programming... > > Cheers, > Thu > >> Greets, >> Ertugrul. >> >> >>> Thank you, >>> Thu >>> >>> 2009/1/8 Lennart Augustsson : >>> > Look at http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-StableName.html. >>> > >>> > But what's wrong with constructing the graph in a monad? >>> > >>> > On Thu, Jan 8, 2009 at 9:53 AM, minh thu wrote: >>> >> Well, the processing of the data structure has to be done in the IO monad. >>> >> What is the library you talk about ? Could it give the "stable names" >>> >> (in IO) for >>> >> each node of the mentioned graph (I mean, after the graph has been constructed >>> >> purely) ? >>> >> >>> >> Thanks, >>> >> Thu >>> >> >>> >> 2009/1/8 Lennart Augustsson : >>> >>> Of course you don't need a monad, but you need to do the same >>> >>> operations as you would with a state monad to number the nodes. This >>> >>> is the only way in (pure) Haskell. There is no object identity in >>> >>> Haskell, so if you want the nodes to have identity you need to provide >>> >>> it. >>> >>> >>> >>> GHC does have a library for stable names which (in the IO monad) >>> >>> allows you to get something akin to the address of a value in memory. >>> >>> But that's not the functional way of doing this. >>> >>> >>> >>> -- Lennart >>> >>> >>> >>> On Thu, Jan 8, 2009 at 9:28 AM, minh thu wrote: >>> >>>> Hi, >>> >>>> >>> >>>> I'd like to process some kind of graph data structure, >>> >>>> say something like >>> >>>> >>> >>>> data DS = A [DS] | B DS DS | C. >>> >>>> >>> >>>> but I want to be able to discover any sharing. >>> >>>> Thus, in >>> >>>> >>> >>>> b = B a a where a = A [C], >>> >>>> >>> >>>> if I want to malloc a similar data structure, >>> >>>> I have to handle to the node representing B >>> >>>> two times the same pointer (the one returned >>> >>>> after allocating A [C]). >>> >>>> >>> >>>> To discover sharing, I thought it would be >>> >>>> necessary to give unique name to node and >>> >>>> then compare them while traversing the graph. >>> >>>> I could give the name by hand but it would be >>> >>>> cumbersome. But at least it would not require >>> >>>> any monad for the bookkeeping of ungiven >>> >>>> names. Is it possible to give those names >>> >>>> automatically but outside any monad ? >>> >>>> >>> >>>> Thanks, >>> >>>> Thu >>> >>>> _______________________________________________ >>> >>>> Haskell-Cafe mailing list >>> >>>> Haskell-Cafe@haskell.org >>> >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>>> >>> >>> >>> >> >>> > >> >> >> >> -- >> nightmare = unsafePerformIO (getWrongWife >>= sex) >> http://blog.ertes.de/ >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: Graph.hs Type: text/x-haskell Size: 3763 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090108/89d83753/Graph.bin From newsham at lava.net Thu Jan 8 14:56:37 2009 From: newsham at lava.net (Tim Newsham) Date: Thu Jan 8 14:48:06 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> Message-ID: > The number of applications requiring the implementation of a custom web > server is an insignificant fraction of the number of applications requiring a > messaging system. I don't think anyone would dispute Haskell's ability to do > low-level, raw networking, of the type that few people actually need to do. > It's the higher level stuff where there's a huge amount of room for > improvement. You replied to someone discussing using Haskell at a CDN to implement things like web servers by saying that Haskell wasn't suitable for the task. > John Tim Newsham http://www.thenewsh.com/~newsham/ From pbeadling at mail2web.com Thu Jan 8 14:56:45 2009 From: pbeadling at mail2web.com (Phil) Date: Thu Jan 8 14:51:44 2009 Subject: [Haskell-cafe] State Monad - using the updated state In-Reply-To: Message-ID: I think I've got this now - thanks to you all for the superb advice! The reason I cannot increment state inside main is because main is not a State monad (it's an IO monad). Thus in order to use my State Monad, I have execute inside a State monad as that the state is encapsulated in there. I'll have to have a think about how I'm going to structure the rest of my code inside something like Ryan's randomComputation example - the basic example works perfectly! I'm writing a Monte Carlo simulator for financial portfolios - it's something I've done in several languages so I often use it to test drive a new language. Most imperative implementations of this sort thing are very state-heavy, so I thought it would fun to re-think it a bit in Haskell. My initial thoughts before delving into Monads was to take advantage of Haskell's lazy evaluation and create an 'infinite' list of randoms using something like the below: ranq1List :: (Word64 -> a ) -> Word64 -> [a] ranq1List converter state = converter newState : ranq1List converter newState where newState = ranq1Increment state This works fine - the converter is an extra parameter that carrys a partially defined function used to numerically translate from word64->whatever_type__we_want as stipulated in Numerical Recipes' C++ example. It was at this point I felt it was getting a bit ugly and started to look at Monads (plus I wanted to see what all 'fuss' was about with Monads too!). One more question on this - the other concern I had with the recursive list approach was that although lazy evaluation prevents me generating numbers before I 'ask' for them, I figured that if I was going to be asking for say 10 million over the course of one simulation, that although I request them one by one, over hours or even days, at the end of the simulation I will still have a list of 10 million word64s - each of which I could throw away within minutes of asking for it. This seemed like huge memory bloat, and thus probably I was taking the wrong approach. I'd be interested to know if you have any thoughts on the various solutions? Ryan's randomComputation strikes me as the most practical and there's an old adage that if a language provides a facility (i.e. The State Monad here), you shouldn't be rewriting similar functionality yourself unless there is a very very good reason to go it alone. Thus I figure that Haskell's State Monad used as described is always going to beat anything I come up with to do the same thing - unless I spend an awful lot of time tailoring a specific solution. If you think there is a nicer non-Monadic, pure solution to this type of problem, I'd be interested to hear them. Thanks again for all your help, Phil. On 08/01/2009 13:27, "Kurt Hutchinson" wrote: > Ryan gave some great advice about restructuring your program to do > what you want, but I wanted to give a small explanation of why that's > necessary. > > 2009/1/7 Phil : >> I want to be able to do: >> >> Get_a_random_number >> >> < a whole load of other stuff > >> >> Get the next number as defined by the updated state in the first call >> >> >> >> Get another number, and so on. > > The issue you're having is that you're trying to do the "other stuff" > in your 'main', but main isn't inside the State monad. The only State > computation you're calling from main is getRanq1, but you really need > another State computation that does "other stuff" and calls getRanq1 > itself. That's what Ryan's first suggestion implements. You need all > your "other stuff" to be done inside the State monad so that it has > read/update access to the current random state. So all your main does > is run a State computation. That computation calls getRanq1 itself and > then "other stuff" in between calls to getRanq1. > > Does that make sense? > > Kurt From john at n-brain.net Thu Jan 8 15:02:37 2009 From: john at n-brain.net (John A. De Goes) Date: Thu Jan 8 14:54:07 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> Message-ID: On Jan 8, 2009, at 12:56 PM, Tim Newsham wrote: > You replied to someone discussing using Haskell at a CDN to implement > things like web servers by saying that Haskell wasn't suitable for > the task. That is incorrect. I replied to Achim's message asking for elaboration on Haskell's unsuitability. It was a convenient point to discuss Haskell's networking deficiencies. Regards, John From polyomino at f2s.com Thu Jan 8 15:11:38 2009 From: polyomino at f2s.com (DavidA) Date: Thu Jan 8 15:03:16 2009 Subject: [Haskell-cafe] "Inconsistency" in support for phantom types? Message-ID: Hi, I have run into what appears to be an inconsistency in the support for using phantom types to parameterize other types. Here's an example (don't pay too much attention to the maths, it's just there to motivate the example). I want to define types for the finite fields with 2, 3 and 5 elements (clock arithmetic modulo 2, 3 or 5). {-# OPTIONS_GHC -fglasgow-exts #-} class IntegerAsType a where value :: a -> Integer -- three phantom types: data T2 instance IntegerAsType T2 where value _ = 2 data T3 instance IntegerAsType T3 where value _ = 3 data T5 instance IntegerAsType T5 where value _ = 5 newtype Fp n = Fp Integer deriving (Eq,Ord) -- our three finite field types: type F2 = Fp T2 type F3 = Fp T3 type F5 = Fp T5 -- Show and Num instances instance Show (Fp n) where show (Fp x) = show x instance IntegerAsType n => Num (Fp n) where Fp x + Fp y = Fp $ (x+y) `mod` value (undefined :: n) negate (Fp 0) = 0 negate (Fp x) = Fp $ value (undefined :: n) - x Fp x * Fp y = Fp $ (x*y) `mod` value (undefined :: n) fromInteger m = Fp $ m `mod` value (undefined :: n) Now, we can also define a Fractional instance, using the extended Euclid algorithm (given at the end) -- n must be prime instance IntegerAsType n => Fractional (Fp n) where recip 0 = error "Fp.recip 0" recip (Fp x) = let p = value (undefined :: n) (u,v,1) = extendedEuclid x p -- so ux+vp = 1. (We know the gcd is 1 as p prime) in Fp $ u `mod` p Now, the problem I've run into is, what do I do if I want to define a function parameterised over the phantom types, but without doing it as part of a type class instance? For example, suppose that I had just wanted to define "inv" as a synonym for "recip": inv :: IntegerAsType n => Fp n -> Fp n inv 0 = error "Fp,inv 0" inv (Fp x) = let p = value (undefined :: n) (u,v,1) = extendedEuclid x p in Fp $ u `mod` p "inv" has exactly the same code as "recip", but now the IntegerAsType constraint is part of the type signature, rather than an instance constraint. It seems that this means that the constraint is not available to the code during compilation, because when I try to compile this I get Ambiguous type variable `n' in the constraint: `IntegerAsType n' arising from a use of `value' at Test.hs:52:21-42 Probable fix: add a type signature that fixes these type variable(s) It seems to me highly desirable that this code should compile as expected, just as the recip code compiles. Is it a bug in GHC, or a missing language feature, or is there a "better" way to do what I'm trying to do? Thanks, David -- extendedEuclid a b returns (u,v,d) such that u*a + v*b = d extendedEuclid a b | a >= 0 && b >= 0 = extendedEuclid' a b [] where extendedEuclid' d 0 qs = let (u,v) = unwind 1 0 qs in (u,v,d) extendedEuclid' a b qs = let (q,r) = quotRem a b in extendedEuclid' b r (q:qs) unwind u v [] = (u,v) unwind u v (q:qs) = unwind v (u-v*q) qs From wchogg at gmail.com Thu Jan 8 15:16:14 2009 From: wchogg at gmail.com (Creighton Hogg) Date: Thu Jan 8 15:07:43 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> Message-ID: <814617240901081216t7232b5b6u884efd6e2b0bad40@mail.gmail.com> On Thu, Jan 8, 2009 at 2:02 PM, John A. De Goes wrote: > > On Jan 8, 2009, at 12:56 PM, Tim Newsham wrote: >> >> You replied to someone discussing using Haskell at a CDN to implement >> things like web servers by saying that Haskell wasn't suitable for >> the task. > > > That is incorrect. I replied to Achim's message asking for elaboration on > Haskell's unsuitability. It was a convenient point to discuss Haskell's > networking deficiencies. Part of the problem I'm having with this discussion, though, is that it's still not clear to me what critical features are lacking. I know you've said Haskell doesn't have anything quite like the Erlang OTP library, but that doesn't really help me much. I've only looked a little at OTP & I don't think I understand what you get from its behaviors that you don't get from Control.Concurrent + mtl, i.e. various forms of state & error handling independent of the concurrency underneath. Can you elucidate a bit more? I don't want the conversation to degenerate. From dave at zednenem.com Thu Jan 8 15:19:41 2009 From: dave at zednenem.com (David Menendez) Date: Thu Jan 8 15:11:09 2009 Subject: [Haskell-cafe] "Inconsistency" in support for phantom types? In-Reply-To: References: Message-ID: <49a77b7a0901081219t30c217bag68a4bc2de876ef78@mail.gmail.com> On Thu, Jan 8, 2009 at 3:11 PM, DavidA wrote: > Hi, > > I have run into what appears to be an inconsistency in the support for using > phantom types to parameterize other types. Here's an example (don't pay too much > attention to the maths, it's just there to motivate the example). I want to > define types for the finite fields with 2, 3 and 5 elements (clock arithmetic > modulo 2, 3 or 5). > > {-# OPTIONS_GHC -fglasgow-exts #-} > > class IntegerAsType a where > value :: a -> Integer > > -- three phantom types: > data T2 > instance IntegerAsType T2 where value _ = 2 > data T3 > instance IntegerAsType T3 where value _ = 3 > data T5 > instance IntegerAsType T5 where value _ = 5 > > newtype Fp n = Fp Integer deriving (Eq,Ord) > > -- our three finite field types: > type F2 = Fp T2 > type F3 = Fp T3 > type F5 = Fp T5 > > -- Show and Num instances > instance Show (Fp n) where > show (Fp x) = show x > > instance IntegerAsType n => Num (Fp n) where > Fp x + Fp y = Fp $ (x+y) `mod` value (undefined :: n) > negate (Fp 0) = 0 > negate (Fp x) = Fp $ value (undefined :: n) - x > Fp x * Fp y = Fp $ (x*y) `mod` value (undefined :: n) > fromInteger m = Fp $ m `mod` value (undefined :: n) > > Now, we can also define a Fractional instance, using the extended Euclid > algorithm (given at the end) > > -- n must be prime > instance IntegerAsType n => Fractional (Fp n) where > recip 0 = error "Fp.recip 0" > recip (Fp x) = let p = value (undefined :: n) > (u,v,1) = extendedEuclid x p > -- so ux+vp = 1. (We know the gcd is 1 as p prime) > in Fp $ u `mod` p > > Now, the problem I've run into is, what do I do if I want to define a function > parameterised over the phantom types, but without doing it as part of a type > class instance? For example, suppose that I had just wanted to define "inv" as a > synonym for "recip": > > inv :: IntegerAsType n => Fp n -> Fp n > inv 0 = error "Fp,inv 0" > inv (Fp x) = let p = value (undefined :: n) > (u,v,1) = extendedEuclid x p > in Fp $ u `mod` p > > "inv" has exactly the same code as "recip", but now the IntegerAsType constraint > is part of the type signature, rather than an instance constraint. It seems that > this means that the constraint is not available to the code during compilation, > because when I try to compile this I get > Ambiguous type variable `n' in the constraint: > `IntegerAsType n' arising from a use of `value' at Test.hs:52:21-42 > Probable fix: add a type signature that fixes these type variable(s) > > It seems to me highly desirable that this code should compile as expected, just > as the recip code compiles. Is it a bug in GHC, or a missing language feature, > or is there a "better" way to do what I'm trying to do? Type variables don't scope over function definitions, so your example is equivalent to: > inv :: IntegerAsType n => Fp n -> Fp n > inv 0 = error "Fp,inv 0" > inv (Fp x) = let p = value (undefined :: a) > (u,v,1) = extendedEuclid x p > in Fp $ u `mod` p In GHC, you can use the ScopedTypeVariables extension to avoid that problem. (See section 8.8.6 of the manual.) > {-# LANGUAGE ScopedTypeVariables #-} ... > inv :: forall n. IntegerAsType n => Fp n -> Fp n > inv 0 = error "Fp,inv 0" > inv (Fp x) = let p = value (undefined :: n) > (u,v,1) = extendedEuclid x p > in Fp $ u `mod` p Or, for Haskell 98 compatibility, you can use a function to transform the types. > getFpType :: Fp n -> n > getFpType _ = undefined > > inv :: IntegerAsType n => Fp n -> Fp n > inv 0 = error "Fp,inv 0" > inv n@(Fp x) = let p = value (getFpType n) > (u,v,1) = extendedEuclid x p > in Fp $ u `mod` p -- Dave Menendez From jgoerzen at complete.org Thu Jan 8 15:20:25 2009 From: jgoerzen at complete.org (John Goerzen) Date: Thu Jan 8 15:11:53 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> Message-ID: <20090108202025.GB27569@hustlerturf.com> On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote: > > The number of applications requiring the implementation of a custom web > server is an insignificant fraction of the number of applications > requiring a messaging system. I don't think anyone would dispute > Haskell's ability to do low-level, raw networking, of the type that few > people actually need to do. It's the higher level stuff where there's a > huge amount of room for improvement. I disagree on both points. Haskell has had somewhat of a deficit in the low-level networking stuff, not even supporting IPv6 in the standard stack until just recently. (That is, things like AF_INET6 were not present.) I think it has pretty much caught up by now though. On the other hand, I see nothing in Haskell that would prevent its use for any of your purposes. There are numerous high-level web infrastructures already. Perhaps they are more or less suited to your needs, but that's a library issue, not a language issue. Saying "WASH sucks" or "Happs sucks" is like saying "rails sucks". May or may not be true, but it doesn't imply anything about whether Haskell is suited to that problem domain. And much as I detest Rails, it doesn't necessarily mean that Ruby *must* suck for web apps. -- John From jonathanccast at fastmail.fm Thu Jan 8 15:21:18 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Jan 8 15:12:43 2009 Subject: [Haskell-cafe] "Inconsistency" in support for phantom types? In-Reply-To: References: Message-ID: <1231446078.5169.16.camel@jcchost> On Thu, 2009-01-08 at 20:11 +0000, DavidA wrote: > Hi, > > I have run into what appears to be an inconsistency in the support for using > phantom types to parameterize other types. Here's an example (don't pay too much > attention to the maths, it's just there to motivate the example). I want to > define types for the finite fields with 2, 3 and 5 elements (clock arithmetic > modulo 2, 3 or 5). > ... > Now, the problem I've run into is, what do I do if I want to define a function > parameterised over the phantom types, but without doing it as part of a type > class instance? For example, suppose that I had just wanted to define "inv" as a > synonym for "recip": > > inv :: IntegerAsType n => Fp n -> Fp n > inv 0 = error "Fp,inv 0" > inv (Fp x) = let p = value (undefined :: n) > (u,v,1) = extendedEuclid x p > in Fp $ u `mod` p > "inv" has exactly the same code as "recip", but now the IntegerAsType constraint > is part of the type signature, rather than an instance constraint. It seems that > this means that the constraint is not available to the code during compilation, > because when I try to compile this I get > Ambiguous type variable `n' in the constraint: > `IntegerAsType n' arising from a use of `value' at Test.hs:52:21-42 > Probable fix: add a type signature that fixes these type variable(s) > > It seems to me highly desirable that this code should compile as expected, just > as the recip code compiles. Is it a bug in GHC, or a missing language feature, It's missing in Haskell 98. If you add the pragma {-# LANGUAGE ScopedTypeVariables #-} then GHC (at least) will accept the variant syntax inv :: forall n. IntegerAsType n => Fp n -> Fp n and the definition as you gave it. Since Haskell 98 doesn't have any feature like this, GHC can't really introduce it without requiring you to deviate from Haskell 98 syntax as well :( jcc From newsham at lava.net Thu Jan 8 15:33:20 2009 From: newsham at lava.net (Tim Newsham) Date: Thu Jan 8 15:24:48 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> Message-ID: > On Jan 8, 2009, at 12:56 PM, Tim Newsham wrote: >> You replied to someone discussing using Haskell at a CDN to implement >> things like web servers by saying that Haskell wasn't suitable for >> the task. > > That is incorrect. I replied to Achim's message asking for elaboration on > Haskell's unsuitability. It was a convenient point to discuss Haskell's > networking deficiencies. Oops. My apologies. > Regards, > John Tim Newsham http://www.thenewsh.com/~newsham/ From miguelimo38 at yandex.ru Thu Jan 8 15:34:39 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Thu Jan 8 15:26:27 2009 Subject: [Haskell-cafe] "Inconsistency" in support for phantom types? In-Reply-To: References: Message-ID: <8BCD3666-71BE-4BE4-8DC2-2A3C55BFEB12@yandex.ru> On 8 Jan 2009, at 23:11, DavidA wrote: > inv :: IntegerAsType n => Fp n -> Fp n ^ ^ ^ this "n" --------------+-------+-------| > inv 0 = error "Fp,inv 0" > inv (Fp x) = let p = value (undefined :: n) ^ and this one ------------------------------| are different beasts. You can try something like this: getN :: Fp n -> n getN _ = undefined inv a@(Fp x) = let p = value $ getN a ... From manlio_perillo at libero.it Thu Jan 8 15:46:36 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Thu Jan 8 15:38:10 2009 Subject: [Haskell-cafe] Re: Hypothetical Haskell job in New York In-Reply-To: <20090108180456.GD22269@scytale.galois.com> References: <4965DC5D.1050006@libero.it> <20090108180456.GD22269@scytale.galois.com> Message-ID: <4966662C.4050009@libero.it> Don Stewart ha scritto: > manlio_perillo: >> Tony Hannan ha scritto: >>> Let me give you more information about this hypothetical job posting. >>> Our company is a startup CDN >>> (http://en.wikipedia.org/wiki/Content_Delivery_Network) about 3 years >>> old and doing well. You would hythothetically be one of 7 programmer who >>> write all the software involved in a CDN including http server, dns >>> server, monitoring, load balancing, customer and operator user >>> interface, etc. The pay depends on experience but is good. >>> >> Isn't it better to use Erlang for the http and dns server ? >> >> I don't really like the syntax, but you have many things already >> implemented. >> Unfortunately Haskell is not yet ready for this task. >> >> http://eddie.sourceforge.net/what.html >> http://yaws.hyber.org/ >> > > Umm... http and dns? You're kidding right? Half of hackage.haskell.org > is devoted to networking tasks. > I'm speaking about servers, not clients. How much of pure Haskell internet servers are used in a production environment, in the "open internet" (and not in restricted LANs)? How much traffic they handle? How hard are to maintain/update/develope/? Personally, I only know http://hpaste.org/, based on Server: HAppS/0.8.4 And about HAppS, I'm not an Haskell expert, but reading the source I see that static files are server (in the HTTP server) using Data.ByteString.Lazy's hGetContents Is this ok? > -- Don > Manlio Perillo From lemming at henning-thielemann.de Thu Jan 8 15:59:19 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 8 15:50:49 2009 Subject: [Haskell-cafe] advanced class constraints in Haskell 98? Message-ID: GHC accepts a class declaration like class Monad (m Maybe) => C m where ... without having any language extension switched on. But it isn't Haskell 98, is it? Hugs 2005 also accepts this. From manlio_perillo at libero.it Thu Jan 8 16:07:37 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Thu Jan 8 15:59:19 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <20090108202025.GB27569@hustlerturf.com> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> Message-ID: <49666B19.8040500@libero.it> John Goerzen ha scritto: > On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote: > [...] > > On the other hand, I see nothing in Haskell that would prevent its use > for any of your purposes. There are numerous high-level web > infrastructures already. Perhaps they are more or less suited to your > needs, but that's a library issue, not a language issue. The question is not about Haskell language. I think that Haskell is far better than Erlang, and in fact I'm studying Haskell and not Erlang; and one of the reason I choosed Haskell is for its support to concurrency. The problem, IMHO, is with the availability of solid, production ready servers implemented in Haskell, that can be used as case study. The major web framework in Haskell is HAppS, if I'm correct, and yet in the HAppS code I see some things that make me worry about the robustess of the code. I you grep for hGetsContent, it appears in place where I'm not sure if it is safe to use. One example is in serving static files. Another example is the multipart parser: -- | Read a multi-part message from a 'Handle'. -- Fails on parse errors. hGetMultipartBody :: String -- ^ Boundary -> Handle -> IO MultiPart hGetMultipartBody b h = do s <- BS.hGetContents h case parseMultipartBody b s of Nothing -> fail "Error parsing multi-part message" Just m -> return m Now, if you read the paper about iteratee: http://okmij.org/ftp/Haskell/Iteratee/ you should have doubts about how robust all of this is. The other problem is with the use of select in the GHC runtime for IO multiplexing. I know that things works, but using select in a server that should support many concurrent requests, is not really what you really want. Regards Manlio Perillo From ross at soi.city.ac.uk Thu Jan 8 16:12:50 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Jan 8 16:04:21 2009 Subject: [Haskell-cafe] advanced class constraints in Haskell 98? In-Reply-To: References: Message-ID: <20090108211250.GA8746@soi.city.ac.uk> On Thu, Jan 08, 2009 at 09:59:19PM +0100, Henning Thielemann wrote: > > GHC accepts a class declaration like > class Monad (m Maybe) => C m where > ... > without having any language extension switched on. But it isn't Haskell > 98, is it? Hugs 2005 also accepts this. Yes, it is. The Report is a good reference for questions like this. From miguelimo38 at yandex.ru Thu Jan 8 16:16:22 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Thu Jan 8 16:08:09 2009 Subject: [Haskell-cafe] advanced class constraints in Haskell 98? In-Reply-To: References: Message-ID: <22CE9CB9-AC08-4214-8DFC-E271F758F6EF@yandex.ru> On 8 Jan 2009, at 23:59, Henning Thielemann wrote: > > GHC accepts a class declaration like > class Monad (m Maybe) => C m where > ... > without having any language extension switched on. But it isn't > Haskell 98, is it? It is. From Report: ======================== A class assertion has form qtycls tyvar, and indicates the membership of the type tyvar in the class qtycls. A class identifier begins with an uppercase letter. A context consists of zero or more class assertions, and has the general form ( C1 u1, ..., Cn un ) where C1, ..., Cn are class identifiers, and each of the u1, ..., un is either a type variable, or the application of type variable to one or more types. ======================== "atype" is defined as ======================== atype -> gtycon | tyvar | ( type1 , ... , typek ) (tuple type, k>=2) | [ type ] (list type) | ( type ) (parenthesised constructor) ======================== > Hugs 2005 also accepts this. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From lennart at augustsson.net Thu Jan 8 16:20:40 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Jan 8 16:12:10 2009 Subject: [Haskell-cafe] Re: How to give unique name/id to nodes outside any monad ? In-Reply-To: <40a414c20901081054i62f98377ma225fb1b3015b906@mail.gmail.com> References: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> <40a414c20901080053n7fd36430he551f27c8fc06e58@mail.gmail.com> <40a414c20901080121u2038f1e1mcb3085769db18973@mail.gmail.com> <20090108131340.0b9f48e6@tritium.xx> <40a414c20901080503l56a05d1u8988ec89913bf1f8@mail.gmail.com> <40a414c20901081054i62f98377ma225fb1b3015b906@mail.gmail.com> Message-ID: Using StableName is really a last resort when you need to do low level strange things. I would not use it when there's another way. Which there is. -- Lennart 2009/1/8 minh thu : > Interestingly, I failed to detect sharing with StableName. > But using the graph node as a key turned to work... > If you're interested in the experiment, see attached code. > > Cheers, > Thu > > 2009/1/8 minh thu : >> 2009/1/8 Ertugrul Soeylemez : >>> "minh thu" wrote: >>> >>>> Nothing, simply the notation. Now, with the remark of Luke, I'm >>>> wondering how bad it is to use makeStableName/hashStableName to "copy" >>>> the data structure in a similar one with explicit reference (that is, >>>> using pointer or keys in a map or whatever). >>> >>> Probably you're misusing the notation. I don't see any reason, why >>> monadic notation should be less readable. Usually it's even more >>> readable. Luke's remark is very valid. Haskell is the wrong language >>> for imperative programming. You don't have _any_ benefit of Haskell, if >>> you use it like C. Try to change your mind. Monads aren't evil. They >>> are there to make your life easier. Way easier than imperative methods. >> >> Well, maybe it's is just my opinion, but I found the non-monadic code >> in the previous mail >> easier to write than the monadic one... I don't know against what >> you're making the compareason to say it's more readable. >> >> Although I agree using Haskell requires some change of thinking, >> statement like yours >> are a bit too much for me. I find Haskell a nice language even for >> imperative programming... >> >> Cheers, >> Thu >> >>> Greets, >>> Ertugrul. >>> >>> >>>> Thank you, >>>> Thu >>>> >>>> 2009/1/8 Lennart Augustsson : >>>> > Look at http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-StableName.html. >>>> > >>>> > But what's wrong with constructing the graph in a monad? >>>> > >>>> > On Thu, Jan 8, 2009 at 9:53 AM, minh thu wrote: >>>> >> Well, the processing of the data structure has to be done in the IO monad. >>>> >> What is the library you talk about ? Could it give the "stable names" >>>> >> (in IO) for >>>> >> each node of the mentioned graph (I mean, after the graph has been constructed >>>> >> purely) ? >>>> >> >>>> >> Thanks, >>>> >> Thu >>>> >> >>>> >> 2009/1/8 Lennart Augustsson : >>>> >>> Of course you don't need a monad, but you need to do the same >>>> >>> operations as you would with a state monad to number the nodes. This >>>> >>> is the only way in (pure) Haskell. There is no object identity in >>>> >>> Haskell, so if you want the nodes to have identity you need to provide >>>> >>> it. >>>> >>> >>>> >>> GHC does have a library for stable names which (in the IO monad) >>>> >>> allows you to get something akin to the address of a value in memory. >>>> >>> But that's not the functional way of doing this. >>>> >>> >>>> >>> -- Lennart >>>> >>> >>>> >>> On Thu, Jan 8, 2009 at 9:28 AM, minh thu wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>> I'd like to process some kind of graph data structure, >>>> >>>> say something like >>>> >>>> >>>> >>>> data DS = A [DS] | B DS DS | C. >>>> >>>> >>>> >>>> but I want to be able to discover any sharing. >>>> >>>> Thus, in >>>> >>>> >>>> >>>> b = B a a where a = A [C], >>>> >>>> >>>> >>>> if I want to malloc a similar data structure, >>>> >>>> I have to handle to the node representing B >>>> >>>> two times the same pointer (the one returned >>>> >>>> after allocating A [C]). >>>> >>>> >>>> >>>> To discover sharing, I thought it would be >>>> >>>> necessary to give unique name to node and >>>> >>>> then compare them while traversing the graph. >>>> >>>> I could give the name by hand but it would be >>>> >>>> cumbersome. But at least it would not require >>>> >>>> any monad for the bookkeeping of ungiven >>>> >>>> names. Is it possible to give those names >>>> >>>> automatically but outside any monad ? >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Thu >>>> >>>> _______________________________________________ >>>> >>>> Haskell-Cafe mailing list >>>> >>>> Haskell-Cafe@haskell.org >>>> >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>>> >>>> >>> >>>> >> >>>> > >>> >>> >>> >>> -- >>> nightmare = unsafePerformIO (getWrongWife >>= sex) >>> http://blog.ertes.de/ >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From lemming at henning-thielemann.de Thu Jan 8 16:22:18 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 8 16:13:46 2009 Subject: [Haskell-cafe] advanced class constraints in Haskell 98? In-Reply-To: <22CE9CB9-AC08-4214-8DFC-E271F758F6EF@yandex.ru> References: <22CE9CB9-AC08-4214-8DFC-E271F758F6EF@yandex.ru> Message-ID: On Fri, 9 Jan 2009, Miguel Mitrofanov wrote: > On 8 Jan 2009, at 23:59, Henning Thielemann wrote: > >> >> GHC accepts a class declaration like >> class Monad (m Maybe) => C m where >> ... >> without having any language extension switched on. But it isn't Haskell 98, >> is it? > > It is. > > From Report: > > ======================== > > A class assertion has form qtycls tyvar, and indicates the membership of the > type tyvar in the class qtycls. A class identifier begins with an uppercase > letter. A context consists of zero or more class assertions, and has the > general form > > ( C1 u1, ..., Cn un ) > > where C1, ..., Cn are class identifiers, and each of the u1, ..., un is > either a type variable, or the application of type variable to one or more > types. A nice. I jumped into 4.3 and found ? ? R? 32 ? ? 6 ? ? ? 32 ? R? ? ? ? 7 ? ? ? ? 7 5? ? ? ? class => where ? ? ? ? ? ? ? ? ? 2 ? 6 ? R? 7 From lemming at henning-thielemann.de Thu Jan 8 16:27:59 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 8 16:19:27 2009 Subject: [Haskell-cafe] advanced class constraints in Haskell 98? In-Reply-To: References: <22CE9CB9-AC08-4214-8DFC-E271F758F6EF@yandex.ru> Message-ID: On Thu, 8 Jan 2009, Henning Thielemann wrote: > On Fri, 9 Jan 2009, Miguel Mitrofanov wrote: > >> On 8 Jan 2009, at 23:59, Henning Thielemann wrote: >> >>> >>> GHC accepts a class declaration like >>> class Monad (m Maybe) => C m where >>> ... >>> without having any language extension switched on. But it isn't Haskell >>> 98, is it? >> >> It is. >> >> From Report: >> >> ======================== >> >> A class assertion has form qtycls tyvar, and indicates the membership of >> the type tyvar in the class qtycls. A class identifier begins with an >> uppercase letter. A context consists of zero or more class assertions, and >> has the general form >> >> ( C1 u1, ..., Cn un ) >> >> where C1, ..., Cn are class identifiers, and each of the u1, ..., un is >> either a type variable, or the application of type variable to one or more >> types. > > A nice. I jumped into 4.3 and found > > ? ? R? 32 ? ... copying from Haskell 98 report did not only insert rubbish, but also triggered sending the e-mail. I hope it did not more damage ... scontext -> simpleclass | (simpleclass_1, ..., simpleclass_n) simpleclass -> qtycls tyvar So it must be 'atype' instead of 'tyvar'? Haskell 98 is really mighty. From spam at scientician.net Thu Jan 8 16:37:55 2009 From: spam at scientician.net (Bardur Arantsson) Date: Thu Jan 8 16:29:35 2009 Subject: [Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <49666B19.8040500@libero.it> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49666B19.8040500@libero.it> Message-ID: Manlio Perillo wrote: > John Goerzen ha scritto: >> On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote: >> [...] >> >> On the other hand, I see nothing in Haskell that would prevent its use >> for any of your purposes. There are numerous high-level web >> infrastructures already. Perhaps they are more or less suited to your >> needs, but that's a library issue, not a language issue. > > > The question is not about Haskell language. > I think that Haskell is far better than Erlang, and in fact I'm studying > Haskell and not Erlang; and one of the reason I choosed Haskell is for > its support to concurrency. > > The problem, IMHO, is with the availability of solid, production ready > servers implemented in Haskell, that can be used as case study. > > The major web framework in Haskell is HAppS, if I'm correct, and yet in > the HAppS code I see some things that make me worry about the robustess > of the code. > [--snip--] Indeed. I've been looking for a Haskell HTTP server implementation that can actually handle file serving using strictly limited memory (for a simple UPnP server, as of yet unreleased) and that also doesn't leak handles like a sieve, but I haven't found anything yet. I don't know, maybe my hackage-foo is lacking. In the end I just rolled my own implementation using the HTTP package for parsing requests and doing all the socket I/O myself using low-level primitives. It seemed to be the only way to guarantee reasonable resource usage while serving multi-gigabyte files to fickle HTTP clients that like to drop connections willy-nilly. Don't get me wrong -- the socket support is pretty decent, but there are also some weird idiosyncrasies, for example requiring that the PortNum is specified in network byte order and lacking a function to convert host->network byte order (hton). Oleg's Iteratee does look very interesting though. Maybe I'll have a go at trying to use his ideas in my UPnP server. Cheers, Bardur Arantsson From lrpalmer at gmail.com Thu Jan 8 16:44:17 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Jan 8 16:35:45 2009 Subject: [Haskell-cafe] State Monad - using the updated state In-Reply-To: References: Message-ID: <7ca3f0160901081344q2017271w6e7bef0811c056bc@mail.gmail.com> On Thu, Jan 8, 2009 at 12:56 PM, Phil wrote: > One more question on this - the other concern I had with the recursive list > approach was that although lazy evaluation prevents me generating numbers > before I 'ask' for them, I figured that if I was going to be asking for say > 10 million over the course of one simulation, that although I request them > one by one, over hours or even days, at the end of the simulation I will > still have a list of 10 million word64s - each of which I could throw away > within minutes of asking for it. This seemed like huge memory bloat, and > thus probably I was taking the wrong approach. if you don't hold on to the whole list, i.e. you use the head of the list and then pass the tail around, the garbage collector will collect the unused prefix. In Haskell lists are used like loops. If a list is used in a sufficiently forgetful fashion, it will use constant space. Luke > > > I'd be interested to know if you have any thoughts on the various > solutions? > Ryan's randomComputation strikes me as the most practical and there's an > old > adage that if a language provides a facility (i.e. The State Monad here), > you shouldn't be rewriting similar functionality yourself unless there is a > very very good reason to go it alone. Thus I figure that Haskell's State > Monad used as described is always going to beat anything I come up with to > do the same thing - unless I spend an awful lot of time tailoring a > specific > solution. > > If you think there is a nicer non-Monadic, pure solution to this type of > problem, I'd be interested to hear them. > > Thanks again for all your help, > > Phil. > > > > On 08/01/2009 13:27, "Kurt Hutchinson" wrote: > > > Ryan gave some great advice about restructuring your program to do > > what you want, but I wanted to give a small explanation of why that's > > necessary. > > > > 2009/1/7 Phil : > >> I want to be able to do: > >> > >> Get_a_random_number > >> > >> < a whole load of other stuff > > >> > >> Get the next number as defined by the updated state in the first call > >> > >> > >> > >> Get another number, and so on. > > > > The issue you're having is that you're trying to do the "other stuff" > > in your 'main', but main isn't inside the State monad. The only State > > computation you're calling from main is getRanq1, but you really need > > another State computation that does "other stuff" and calls getRanq1 > > itself. That's what Ryan's first suggestion implements. You need all > > your "other stuff" to be done inside the State monad so that it has > > read/update access to the current random state. So all your main does > > is run a State computation. That computation calls getRanq1 itself and > > then "other stuff" in between calls to getRanq1. > > > > Does that make sense? > > > > Kurt > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090108/c6ff0b42/attachment.htm From lemming at henning-thielemann.de Thu Jan 8 16:49:31 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 8 16:40:59 2009 Subject: [Haskell-cafe] Re: Hypothetical Haskell job in New York In-Reply-To: <4966662C.4050009@libero.it> References: <4965DC5D.1050006@libero.it> <20090108180456.GD22269@scytale.galois.com> <4966662C.4050009@libero.it> Message-ID: On Thu, 8 Jan 2009, Manlio Perillo wrote: > Personally, I only know http://hpaste.org/, based on > Server: HAppS/0.8.4 I'm using a modified HWS for the parallel webs, e.g. the Real Monad Transformer: http://www.haskell.org.monadtransformer.parallelnetz.de/haskellwiki/Category:Monad However, recently a lot of accesses made the server quite unusable. From vanenkj at gmail.com Thu Jan 8 16:57:00 2009 From: vanenkj at gmail.com (John Van Enk) Date: Thu Jan 8 16:48:32 2009 Subject: [Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49666B19.8040500@libero.it> Message-ID: > PortNum is specified in network byte order and lacking a function to convert host->network byte order (hton). Perhaps this is another argument for my thread from a while back? http://www.nabble.com/Missing-Network-Functions-td21188779.html /jve On Thu, Jan 8, 2009 at 4:37 PM, Bardur Arantsson wrote: > Manlio Perillo wrote: > >> John Goerzen ha scritto: >> >>> On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote: >>> [...] >>> >>> On the other hand, I see nothing in Haskell that would prevent its use >>> for any of your purposes. There are numerous high-level web >>> infrastructures already. Perhaps they are more or less suited to your >>> needs, but that's a library issue, not a language issue. >>> >> >> >> The question is not about Haskell language. >> I think that Haskell is far better than Erlang, and in fact I'm studying >> Haskell and not Erlang; and one of the reason I choosed Haskell is for its >> support to concurrency. >> >> The problem, IMHO, is with the availability of solid, production ready >> servers implemented in Haskell, that can be used as case study. >> >> The major web framework in Haskell is HAppS, if I'm correct, and yet in >> the HAppS code I see some things that make me worry about the robustess of >> the code. >> >> [--snip--] > > Indeed. I've been looking for a Haskell HTTP server implementation that can > actually handle file serving using strictly limited memory (for a simple > UPnP server, as of yet unreleased) and that also doesn't leak handles like a > sieve, but I haven't found anything yet. I don't know, maybe my hackage-foo > is lacking. In the end I just rolled my own implementation using the HTTP > package for parsing requests and doing all the socket I/O myself using > low-level primitives. It seemed to be the only way to guarantee reasonable > resource usage while serving multi-gigabyte files to fickle HTTP clients > that like to drop connections willy-nilly. > > Don't get me wrong -- the socket support is pretty decent, but there are > also some weird idiosyncrasies, for example requiring that the PortNum is > specified in network byte order and lacking a function to convert > host->network byte order (hton). > > Oleg's Iteratee does look very interesting though. Maybe I'll have a go at > trying to use his ideas in my UPnP server. > > Cheers, > > Bardur Arantsson > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090108/001c98fd/attachment.htm From jgoerzen at complete.org Thu Jan 8 17:05:05 2009 From: jgoerzen at complete.org (John Goerzen) Date: Thu Jan 8 16:56:34 2009 Subject: [Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49666B19.8040500@libero.it> Message-ID: <20090108220505.GA30259@hustlerturf.com> On Thu, Jan 08, 2009 at 10:37:55PM +0100, Bardur Arantsson wrote: > Don't get me wrong -- the socket support is pretty decent, but there are > also some weird idiosyncrasies, for example requiring that the PortNum > is specified in network byte order and lacking a function to convert > host->network byte order (hton). Look at Haddock for PortNumber: newtype PortNumber Constructors PortNum Word16 Instances Enum PortNumber Eq PortNumber Integral PortNumber Num PortNumber Ord PortNumber Real PortNumber Show PortNumber Typeable PortNumber Storable PortNumber Try it in ghci: Prelude Network.Socket> 15 :: PortNumber 15 Prelude Network.Socket> PortNum 15 3840 Prelude Network.Socket> (fromIntegral (15::Int))::PortNumber 15 So, in essence, there are *many* functions that let you do this. You should not be needing to construct PortNum by hand. From jgoerzen at complete.org Thu Jan 8 17:15:49 2009 From: jgoerzen at complete.org (John Goerzen) Date: Thu Jan 8 17:07:22 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> Message-ID: <20090108221549.GA30539@hustlerturf.com> On Thu, Jan 08, 2009 at 11:14:18AM -0700, John A. De Goes wrote: > But really, what's the point? FFI code is fragile, often uncompilable > and unsupported, and doesn't observe the idioms of Haskell nor take > advantage of its powerful language features. Rather than coding through That is an extraordinarily cruel, and inaccurate, sweep of FFI. I've worked with C bindings to several high-level languages, and I must say that I like FFI the best of any I've used. It's easy to use correctly, stable, and solid. If anything, it suffers from under-documentation. The whole point of FFI is to bring other languages into the Haskell fold. So you can, say, talk to a database using its C library and wind up putting the strongly-typed HaskellDB atop it. Or you can write an MD5 algorithm in C and make it look like a regular Haskell function. > You can indeed fit a square peg in a round hole, if you pound hard > enough. That doesn't mean it's a good thing to do. And with that, I fully agree. -- Joh From es at ertes.de Thu Jan 8 17:16:52 2009 From: es at ertes.de (Ertugrul Soeylemez) Date: Thu Jan 8 17:08:37 2009 Subject: [Haskell-cafe] Monads aren't evil Message-ID: <20090108231652.24b75fe3@tritium.xx> Hello fellow Haskellers, When I read questions from Haskell beginners, it somehow seems like they try to avoid monads and view them as a last resort, if there is no easy non-monadic way. I'm really sure that the cause for this is that most tutorials deal with monads very sparingly and mostly in the context of input/output. Also usually monads are associated with the do-notation, which makes them appear even more special, although there is really nothing special about them. I appeal to all experienced Haskell programmers, especially to tutorial writers, to try to focus more on how monads are nothing special, when talking to beginners. Let me tell you that usually 90% of my code is monadic and there is really nothing wrong with that. I use especially State monads and StateT transformers very often, because they are convenient and are just a clean combinator frontend to what you would do manually without them: passing state. Greets, Ertugrul. -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/ From jgoerzen at complete.org Thu Jan 8 17:18:44 2009 From: jgoerzen at complete.org (John Goerzen) Date: Thu Jan 8 17:10:15 2009 Subject: [Haskell-cafe] Re: Hypothetical Haskell job in New York In-Reply-To: <4966662C.4050009@libero.it> References: <4965DC5D.1050006@libero.it> <20090108180456.GD22269@scytale.galois.com> <4966662C.4050009@libero.it> Message-ID: <20090108221844.GB30539@hustlerturf.com> On Thu, Jan 08, 2009 at 09:46:36PM +0100, Manlio Perillo wrote: > I'm speaking about servers, not clients. > > How much of pure Haskell internet servers are used in a production > environment, in the "open internet" (and not in restricted LANs)? Does that really matter? I tend to judge technology based on its merits for my work, not on who uses it. The fact that Google uses Python didn't impact my decision to start using it, and it also didn't impact my decision to start using Haskell. > How much traffic they handle? > How hard are to maintain/update/develope/? Those, of course, are pretty good questions. > Personally, I only know http://hpaste.org/, based on > Server: HAppS/0.8.4 Take a look at Hackage. There are quite a few other Haskell web frameworks as well: everything from the low-level FastCGI to higher-level HSP and WASH. > And about HAppS, I'm not an Haskell expert, but reading the source I see > that static files are server (in the HTTP server) using > Data.ByteString.Lazy's hGetContents > > Is this ok? In what respect? The fact that something uses ByteString.Lazy.hGetContents doesn't imply a problem to me. It's a useful function. It can be used properly, or not, just as while or read() in C can be. It's not evil incarnate like sprintf() or anything :-) -- John From spam at scientician.net Thu Jan 8 17:23:47 2009 From: spam at scientician.net (Bardur Arantsson) Date: Thu Jan 8 17:15:22 2009 Subject: [Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <20090108220505.GA30259@hustlerturf.com> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49666B19.8040500@libero.it> <20090108220505.GA30259@hustlerturf.com> Message-ID: John Goerzen wrote: > On Thu, Jan 08, 2009 at 10:37:55PM +0100, Bardur Arantsson wrote: >> Don't get me wrong -- the socket support is pretty decent, but there are >> also some weird idiosyncrasies, for example requiring that the PortNum >> is specified in network byte order and lacking a function to convert >> host->network byte order (hton). > > Look at Haddock for PortNumber: > > newtype PortNumber > Constructors > PortNum Word16 > > Instances > > Enum PortNumber > Eq PortNumber > Integral PortNumber > Num PortNumber > Ord PortNumber > Real PortNumber > Show PortNumber > Typeable PortNumber > Storable PortNumber > > Try it in ghci: > > Prelude Network.Socket> 15 :: PortNumber > 15 > Prelude Network.Socket> PortNum 15 > 3840 > Prelude Network.Socket> (fromIntegral (15::Int))::PortNumber > 15 > > So, in essence, there are *many* functions that let you do this. You > should not be needing to construct PortNum by hand. Thanks. For some reason I hadn't thought to use (fromIntegral x)::PortNumber I guess I got stuck on the idea of constructing a PortNum directly and didn't think beyond that. (Maybe PortNum should really be an abstract type to force indirect construction...?) I guess the API isn't all that idiosyncratic after all :). Cheers, Bardur Arantsson From lemming at henning-thielemann.de Thu Jan 8 17:26:35 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 8 17:18:04 2009 Subject: [Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49666B19.8040500@libero.it> <20090108220505.GA30259@hustlerturf.com> Message-ID: On Thu, 8 Jan 2009, Bardur Arantsson wrote: > Thanks. For some reason I hadn't thought to use > > (fromIntegral x)::PortNumber > > I guess I got stuck on the idea of constructing a PortNum directly and didn't > think beyond that. (Maybe PortNum should really be an abstract type to force > indirect construction...?) I also think that a Num instance for PortNumber is not a good idea. How shall (+) and (*) be defined? From andrewcoppin at btinternet.com Thu Jan 8 16:29:10 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Jan 8 17:27:26 2009 Subject: [Haskell-cafe] Low-level networking [Haskell not ready for Foo] In-Reply-To: <20090108202025.GB27569@hustlerturf.com> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> Message-ID: <49667026.9060702@btinternet.com> John Goerzen wrote: > On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote: > >> The number of applications requiring the implementation of a custom web >> server is an insignificant fraction of the number of applications >> requiring a messaging system. I don't think anyone would dispute >> Haskell's ability to do low-level, raw networking, of the type that few >> people actually need to do. It's the higher level stuff where there's a >> huge amount of room for improvement. >> > > I disagree on both points. > > Haskell has had somewhat of a deficit in the low-level networking > stuff, not even supporting IPv6 in the standard stack until just > recently. (That is, things like AF_INET6 were not present.) > > I think it has pretty much caught up by now though. > Any idea how I get Haskell to send ICMP ECHO packets? (And, obviously, receive the replies.) From mad.one at gmail.com Thu Jan 8 17:47:18 2009 From: mad.one at gmail.com (Austin Seipp) Date: Thu Jan 8 17:38:54 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> Message-ID: <1231454154-sup-7772@existential.local> Excerpts from John A. De Goes's message of Thu Jan 08 12:14:18 -0600 2009: > But really, what's the point? FFI code is fragile, often uncompilable > and unsupported, and doesn't observe the idioms of Haskell nor take > advantage of its powerful language features. This is a completely unfair generalization. The FFI is an excellent way to interoperate with an extraordinary amount of external libraries, and if you ask me, it's *worth* taking those pieces of C code and wrapping them up in a nice, safe haskell interface. I will also mention that Haskell has *the* simplest FFI I have ever used, which to me only means it's easier to get it right (the fact that there are customized *languages* like e.g. cython to make writing python extensions easier makes me wonder.) I suggest you take a look at the haskell llvm bindings - they are extraordinarily well documented, and the high level interface uses *many* haskell idioms that make the library safe and easy to use: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/llvm-0.4.2.0 This code most certainly takes advantage of powerful features and idioms that only Haskell can provide. Please do not take your bad experiences with a few crappy binding (or not even crappy bindings, perhaps bindings that just aren't very abstract) and extend them to the bindings that are excellent with a sweeping statement like that. Austin From jgoerzen at complete.org Thu Jan 8 17:48:20 2009 From: jgoerzen at complete.org (John Goerzen) Date: Thu Jan 8 17:39:50 2009 Subject: [Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49666B19.8040500@libero.it> <20090108220505.GA30259@hustlerturf.com> Message-ID: <496682B4.6070503@complete.org> Bardur Arantsson wrote: > Thanks. For some reason I hadn't thought to use > > (fromIntegral x)::PortNumber > > I guess I got stuck on the idea of constructing a PortNum directly and > didn't think beyond that. (Maybe PortNum should really be an abstract No problem. I knew exactly what your problem was because I had the exact same blinders on when I first learned the Haskell networking API. It would be helpful to have a pointer to this in the Haddock docs, because it is non-intuitive to somebody just learning it. > I guess the API isn't all that idiosyncratic after all :). Just a touch under-documented ;-) From spam at scientician.net Thu Jan 8 17:48:46 2009 From: spam at scientician.net (Bardur Arantsson) Date: Thu Jan 8 17:40:26 2009 Subject: [Haskell-cafe] Re: Hypothetical Haskell job in New York In-Reply-To: <20090108221844.GB30539@hustlerturf.com> References: <4965DC5D.1050006@libero.it> <20090108180456.GD22269@scytale.galois.com> <4966662C.4050009@libero.it> <20090108221844.GB30539@hustlerturf.com> Message-ID: John Goerzen wrote: > On Thu, Jan 08, 2009 at 09:46:36PM +0100, Manlio Perillo wrote: >> I'm speaking about servers, not clients. >> > >> Personally, I only know http://hpaste.org/, based on >> Server: HAppS/0.8.4 > > Take a look at Hackage. There are quite a few other Haskell web > frameworks as well: everything from the low-level FastCGI to > higher-level HSP and WASH. > FastCGI is not a HTTP server. WASH seems so include one, but the latest version ("Wash and go") seems to be from mid-2007 ("tested with GHC 6.6" as the web page states), unless of course I'm looking at the wrong page. That doesn't exactly inspire a lot of confidence. Now, if you're talking about using, say, Apache + FastCGI then you'll probably have something pretty robust, but I don't think that counts as a "Haskell server". Generally my experience has been that most of the Haskell server stuff hasn't been very mature. >> And about HAppS, I'm not an Haskell expert, but reading the source I see >> that static files are server (in the HTTP server) using >> Data.ByteString.Lazy's hGetContents >> >> Is this ok? > > In what respect? The fact that something uses > ByteString.Lazy.hGetContents doesn't imply a problem to me. It's a > useful function. It can be used properly, or not, just as while or > read() in C can be. It's a great way to introduce unavoidable handle leaks, that's for sure. Cheers, Bardur Arantsson From jgoerzen at complete.org Thu Jan 8 17:50:24 2009 From: jgoerzen at complete.org (John Goerzen) Date: Thu Jan 8 17:41:53 2009 Subject: [Haskell-cafe] Low-level networking [Haskell not ready for Foo] In-Reply-To: <49667026.9060702@btinternet.com> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49667026.9060702@btinternet.com> Message-ID: <49668330.2000701@complete.org> Andrew Coppin wrote: > John Goerzen wrote: >> On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote: >> >>> The number of applications requiring the implementation of a custom web >>> server is an insignificant fraction of the number of applications >>> requiring a messaging system. I don't think anyone would dispute >>> Haskell's ability to do low-level, raw networking, of the type that few >>> people actually need to do. It's the higher level stuff where there's a >>> huge amount of room for improvement. >>> >> I disagree on both points. >> >> Haskell has had somewhat of a deficit in the low-level networking >> stuff, not even supporting IPv6 in the standard stack until just >> recently. (That is, things like AF_INET6 were not present.) >> >> I think it has pretty much caught up by now though. >> > > Any idea how I get Haskell to send ICMP ECHO packets? (And, obviously, > receive the replies.) SocketType claims to support Raw, which I think is the conventional means for doing this. Whether all the infrastructure for that is there, I don't know. I have never worked with raw sockets though, so I may be leading you down a dark mugger-laden alley here ;-) -- John From bos at serpentine.com Thu Jan 8 18:17:59 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu Jan 8 18:09:29 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <20090108180619.GE22269@scytale.galois.com> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> Message-ID: On Thu, Jan 8, 2009 at 10:06 AM, Don Stewart wrote: > Note that there even exists an FFI binding to Erlang for Haskell, so > that Haskell nodes can seamlessly interact with other nodes speaking > Erlang's protocol format. > Actually, the erlang package doesn't use the FFI: it speaks the Erlang wire protocol to send and receive terms. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090108/7ac2fb49/attachment.htm From s.clover at gmail.com Thu Jan 8 18:30:13 2009 From: s.clover at gmail.com (Sterling Clover) Date: Thu Jan 8 18:20:04 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <20090108221549.GA30539@hustlerturf.com> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> <20090108221549.GA30539@hustlerturf.com> Message-ID: <7707D2AF-1FD0-437D-AC0F-1943D3424A0E@gmail.com> > On Thu, Jan 08, 2009 at 11:14:18AM -0700, John A. De Goes wrote: >> But really, what's the point? FFI code is fragile, often uncompilable >> and unsupported, and doesn't observe the idioms of Haskell nor take >> advantage of its powerful language features. Rather than coding >> through > Just for clarity's sake, we should specify that the Erlang ffi interface that's been worked on (not my project, I've just browsed the code) is *not* low-level via C, but rather a set of parsers/ unparsers between haskell data types and the Erlang wire format and a set of behaviors for message queuing that between them let a haskell program act as a node to Erlang programs, or let Haskell programs communicate between themselves as nodes, which just coincidentally happen to use the same wire format as Erlang. Which is not to say that Erlang does not have specific excellent libraries that allow *certain types* of network programming do be done very easily. The Haskell library-space has lots of room to grow, and lots of inspiration to take from the OTP (although less for "hot-swapping" which is somewhat overrated, and more from supervision-tree type stuff). However, even now an adequate subset of whatever functionality is needed can be whipped up pretty quickly for any project requiring only that subset. Cheers, S. From bos at serpentine.com Thu Jan 8 18:34:00 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu Jan 8 18:25:29 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <49666B19.8040500@libero.it> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49666B19.8040500@libero.it> Message-ID: On Thu, Jan 8, 2009 at 1:07 PM, Manlio Perillo wrote: > Another example is the multipart parser: > > -- | Read a multi-part message from a 'Handle'. > -- Fails on parse errors. > hGetMultipartBody :: String -- ^ Boundary > -> Handle > -> IO MultiPart > hGetMultipartBody b h = > do > s <- BS.hGetContents h > case parseMultipartBody b s of > Nothing -> fail "Error parsing multi-part message" > Just m -> return m > Yes, that's definitely on the scary side of things. However, you don't have to go all the way to drinking the Iteratee Kool-Aid in order to write safer networking code that is still performant. Here are a few projects I'm actively working on in this area: - I'm adding epoll support to the threaded RTS. This is a necessity for server performance. - I've added support for sending and receiving lazy ByteStrings to Johan Tibbell's network-bytestring library. A quick benchmark with a toy HTTP server has shown this to be about 2x faster than writing ByteStrings to a Handle (i.e. 14,000 requests per second, vs 7,000). - I've got a continuation-based resumable parser combinator module for attoparsec in progress, which uses lazy ByteStrings for blazing performance. You can use this to write protocol parsers in a completely clean way, decoupled from the underlying network receive operations. While much of this isn't quite ready for use yet, this just represents one person's work, and there are lots of people beavering away actively at corners of the problem space that interest them. I actually think that we're very close to being in fantastic shape here. I'm working on a memcached client library that uses the above libraries, and it's faster than the absolute best C memcached client (libmemcached), while also far smaller and elegantly layered. As a community, we are developing many proofs that you can have beautiful code without sacrificing performance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090108/ffebdfb4/attachment.htm From ross at soi.city.ac.uk Thu Jan 8 18:47:36 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Jan 8 18:39:08 2009 Subject: [Haskell-cafe] advanced class constraints in Haskell 98? In-Reply-To: References: <22CE9CB9-AC08-4214-8DFC-E271F758F6EF@yandex.ru> Message-ID: <20090108234736.GA9217@soi.city.ac.uk> On Thu, Jan 08, 2009 at 10:27:59PM +0100, Henning Thielemann wrote: > A nice. I jumped into 4.3 and found > > scontext -> simpleclass > | (simpleclass_1, ..., simpleclass_n) > > simpleclass -> qtycls tyvar > > So it must be 'atype' instead of 'tyvar'? Haskell 98 is really mighty. Oh. Don't I look silly? You were absolutely right, it's not Haskell 98. Actually Hugs does reject it without flags. Maybe you have a -98 stored somewhere? From duncan.coutts at worc.ox.ac.uk Thu Jan 8 19:03:57 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 8 18:53:06 2009 Subject: [Haskell-cafe] HookedBuildInfo and Cabal In-Reply-To: <20090108184211.GB25272@hustlerturf.com> References: <20090108184211.GB25272@hustlerturf.com> Message-ID: <1231459437.14054.27.camel@lantern> On Thu, 2009-01-08 at 12:42 -0600, John Goerzen wrote: > As a more general question, how can one use Cabal to detect PostgreSQL > paths in a way that works with both GHC 6.8 and 6.10? Yes: The following is using "build-type: Simple" in HDBC-postgresql.cabal and it does not use HDBC-postgresql.buildinfo.in or the other autoconf files. Note that I've not actually tested that this builds HDBC-postgresql fully (I don't have postgres installed). But with a suitable hacked up pgconfig/pg_config on the $PATH that it does pass the output to ghc, hsc2hs etc. It works with Cabal-1.2 and 1.6. I've not done it but you can also require a minimum pgconfig version if you modify pgconfigProgram below to discover the version number. You'd put the following in the .cabal file: build-tools: pgconfig >= 7.3 or whatever. Duncan Setup.hs: import Distribution.Simple import Distribution.PackageDescription import Distribution.Version import Distribution.Simple.LocalBuildInfo import Distribution.Simple.Program import Distribution.Verbosity import Control.Monad main = defaultMainWithHooks simpleUserHooks { hookedPrograms = [pgconfigProgram], confHook = \pkg flags -> do lbi <- confHook defaultUserHooks pkg flags bi <- psqlBuildInfo lbi return lbi { localPkgDescr = updatePackageDescription (Just bi, []) (localPkgDescr lbi) } } pgconfigProgram = (simpleProgram "pgconfig") { programFindLocation = \verbosity -> do pgconfig <- findProgramOnPath "pgconfig" verbosity pg_config <- findProgramOnPath "pg_config" verbosity return (pgconfig `mplus` pg_config) } psqlBuildInfo :: LocalBuildInfo -> IO BuildInfo psqlBuildInfo lbi = do (pgconfigProg, _) <- requireProgram verbosity pgconfigProgram AnyVersion (withPrograms lbi) let pgconfig = rawSystemProgramStdout verbosity pgconfigProg incDir <- pgconfig ["--includedir"] libDir <- pgconfig ["--libdir"] return emptyBuildInfo { extraLibDirs = [libDir], includeDirs = [incDir] } where verbosity = normal -- honestly, this is a hack From miguelimo38 at yandex.ru Thu Jan 8 19:03:14 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Thu Jan 8 18:54:55 2009 Subject: [Haskell-cafe] advanced class constraints in Haskell 98? In-Reply-To: <20090108234736.GA9217@soi.city.ac.uk> References: <22CE9CB9-AC08-4214-8DFC-E271F758F6EF@yandex.ru> <20090108234736.GA9217@soi.city.ac.uk> Message-ID: On 9 Jan 2009, at 02:47, Ross Paterson wrote: > On Thu, Jan 08, 2009 at 10:27:59PM +0100, Henning Thielemann wrote: >> A nice. I jumped into 4.3 and found >> >> scontext -> simpleclass >> | (simpleclass_1, ..., simpleclass_n) >> >> simpleclass -> qtycls tyvar >> >> So it must be 'atype' instead of 'tyvar'? Haskell 98 is really >> mighty. > > Oh. Don't I look silly? You were absolutely right, it's not > Haskell 98. Me too. I've looked at the type declaration syntax instead of instance declaration one. > > > Actually Hugs does reject it without flags. Maybe you have a -98 > stored > somewhere? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From schlepptop at henning-thielemann.de Thu Jan 8 19:12:03 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 8 18:57:29 2009 Subject: [Haskell-cafe] Staged evaluation, names? In-Reply-To: <49658049.8060107@freegeek.org> References: <49658049.8060107@freegeek.org> Message-ID: <49669653.5020600@henning-thielemann.de> wren ng thornton schrieb: > Every now and then I find myself in the position where I'd like to > define some hairy value as a CAF instead of a literal, but I'd like for > it to be fully evaluated at compile-time rather than postponed until > runtime. It'd be possible to bludgeon the CPP into doing this, but it > seems easier to use an autocannon like Template Haskell to swat this fly. Is it really necessary to use CPP or TemplateHaskell for this kind of optimization? Can a pragma help? Maybe {-# INLINE #-} ? From lemming at henning-thielemann.de Thu Jan 8 19:11:12 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 8 19:02:40 2009 Subject: [Haskell-cafe] advanced class constraints in Haskell 98? In-Reply-To: References: <22CE9CB9-AC08-4214-8DFC-E271F758F6EF@yandex.ru> <20090108234736.GA9217@soi.city.ac.uk> Message-ID: On Fri, 9 Jan 2009, Miguel Mitrofanov wrote: > On 9 Jan 2009, at 02:47, Ross Paterson wrote: > >> On Thu, Jan 08, 2009 at 10:27:59PM +0100, Henning Thielemann wrote: >>> A nice. I jumped into 4.3 and found >>> >>> scontext -> simpleclass >>> | (simpleclass_1, ..., simpleclass_n) >>> >>> simpleclass -> qtycls tyvar >>> >>> So it must be 'atype' instead of 'tyvar'? Haskell 98 is really mighty. >> >> Oh. Don't I look silly? You were absolutely right, it's not Haskell 98. > > Me too. I've looked at the type declaration syntax instead of instance > declaration one. Maybe the report is not complete? I mean, the current behaviour of Hugs and GHC (as I observed it) is more consistent, and maybe that's what the designers had in mind. >> Actually Hugs does reject it without flags. Maybe you have a -98 stored >> somewhere? When starting, my Hugs tells Haskell 98 mode: Restart with command line option -98 to enable extensions From sanzhiyan at gmail.com Thu Jan 8 19:13:06 2009 From: sanzhiyan at gmail.com (Andrea Vezzosi) Date: Thu Jan 8 19:04:34 2009 Subject: [Haskell-cafe] Staged evaluation, names? In-Reply-To: <49658049.8060107@freegeek.org> References: <49658049.8060107@freegeek.org> Message-ID: <8625cd9c0901081613ie216be5xbb54804920860e76@mail.gmail.com> On Thu, Jan 8, 2009 at 5:25 AM, wren ng thornton wrote: > > The question for y'all is what should I call it? I've been calling the template-function qaf (for Compiled Applicative Form ;) and the type class with that function would be the only thing in the package, but I'm not sure where QAF.hs should be in the module hierarchy. Thoughts? Isn't Lift[1] already the right class for this? class Lift t where lift :: t -> Q Exp [1] http://haskell.org/ghc/docs/latest/html/libraries/template-haskell/Language-Haskell-TH-Syntax.html#t%3ALift From tonyhannan2 at gmail.com Thu Jan 8 19:21:22 2009 From: tonyhannan2 at gmail.com (Tony Hannan) Date: Thu Jan 8 19:12:50 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49666B19.8040500@libero.it> Message-ID: That's great to hear Bryan. I look forward to all of your projects you just mentioned, and work from others like you said, so one day soon we can built really high-performance web servers in elegant Haskell code. I also like Reactive (or FRP in general) as a declarative alternative to message passing, and hope it will be high-performance as well. Cheers, Tony 2009/1/8 Bryan O'Sullivan > On Thu, Jan 8, 2009 at 1:07 PM, Manlio Perillo wrote: > > >> Another example is the multipart parser: >> >> -- | Read a multi-part message from a 'Handle'. >> -- Fails on parse errors. >> hGetMultipartBody :: String -- ^ Boundary >> -> Handle >> -> IO MultiPart >> hGetMultipartBody b h = >> do >> s <- BS.hGetContents h >> case parseMultipartBody b s of >> Nothing -> fail "Error parsing multi-part message" >> Just m -> return m >> > > Yes, that's definitely on the scary side of things. > > However, you don't have to go all the way to drinking the Iteratee Kool-Aid > in order to write safer networking code that is still performant. Here are a > few projects I'm actively working on in this area: > > - I'm adding epoll support to the threaded RTS. This is a necessity for > server performance. > - I've added support for sending and receiving lazy ByteStrings to > Johan Tibbell's network-bytestring library. A quick benchmark with a toy > HTTP server has shown this to be about 2x faster than writing ByteStrings to > a Handle (i.e. 14,000 requests per second, vs 7,000). > - I've got a continuation-based resumable parser combinator module for > attoparsec in progress, which uses lazy ByteStrings for blazing performance. > You can use this to write protocol parsers in a completely clean way, > decoupled from the underlying network receive operations. > > While much of this isn't quite ready for use yet, this just represents one > person's work, and there are lots of people beavering away actively at > corners of the problem space that interest them. > > I actually think that we're very close to being in fantastic shape here. > I'm working on a memcached client library that uses the above libraries, and > it's faster than the absolute best C memcached client (libmemcached), while > also far smaller and elegantly layered. As a community, we are developing > many proofs that you can have beautiful code without sacrificing > performance. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090108/5e77b1f1/attachment.htm From schlepptop at henning-thielemann.de Thu Jan 8 19:31:17 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 8 19:16:38 2009 Subject: [Haskell-cafe] Taking Exception to Exceptions In-Reply-To: References: <1231370528-sup-5395@existential.local> Message-ID: <49669AD5.3020309@henning-thielemann.de> Immanuel Litzroth schrieb: > Anyway, there is one more problem I have related to exceptions that is > about forcing strictness. It relates to option parsing. I have an option -t > that says which track from a file of tracks to print. So I go > > data Flags = TrackNumber !Int deriving(Read, Show, Eq) > > makeTrackNumber :: String -> Flags > makeTrackNumber str = > TrackNumber $ read str > > options = [GetOpt.Option ['t'] ["tracknumber"] (GetOpt.ReqArg > makeTrackNumber "tracknumber") "number of track to show"] > > Now my main goes > main = do > args <- getArgs > opts <- evaluate $ GetOpt.getOpt GetOpt.RequireOrder options args > print "done getting the opts" > case opts of ... > > which of course first prints "done getting opts" and then throws an > exception if I give it a flag > -t abc. 'evaluate' is strange here. Is it ok to put the print after the case ? But I have probably still not understood the problem. Let me point to two other issues: An elegant way to use GetOpt is: http://www.haskell.org/haskellwiki/High-level_option_handling_with_GetOpt I find it bad style to hide the exceptions, that can be raised. The type of an action should reflect what exceptions are to be expected. You can achieve this with Control.Monad.Exception.Synchronous from http://hackage.haskell.org/cgi-bin/hackage-scripts/package/explicit-exception or Control.Monad.Error from http://hackage.haskell.org/cgi-bin/hackage-scripts/package/transformers For an application, using these techniques, see: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/equal-files From ross at soi.city.ac.uk Thu Jan 8 19:25:27 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Jan 8 19:17:06 2009 Subject: [Haskell-cafe] advanced class constraints in Haskell 98? In-Reply-To: References: <22CE9CB9-AC08-4214-8DFC-E271F758F6EF@yandex.ru> <20090108234736.GA9217@soi.city.ac.uk> Message-ID: <20090109002527.GA11670@soi.city.ac.uk> On Fri, Jan 09, 2009 at 01:11:12AM +0100, Henning Thielemann wrote: > Maybe the report is not complete? I mean, the current behaviour of Hugs > and GHC (as I observed it) is more consistent, and maybe that's what the > designers had in mind. I'm puzzled by the Hugs behaviour. The current version rejects it, and I downloaded and built the Mar2005 version just to check, and it also rejected it, saying Illegal Haskell 98 class constraint in class declaration I think the GHC behaviour is connected with GHC's deferred context reduction, which also does not conform to Haskell 98. From thomas.dubuisson at gmail.com Thu Jan 8 19:35:13 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Thu Jan 8 19:26:41 2009 Subject: [Haskell-cafe] Low-level networking [Haskell not ready for Foo] In-Reply-To: <49668330.2000701@complete.org> References: <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49667026.9060702@btinternet.com> <49668330.2000701@complete.org> Message-ID: <4c44d90b0901081635u69f9a1ffx5aa2e7fcdd946c03@mail.gmail.com> Not all the data structures you need are there last I looked. As you could infer from my recent posts, one of my dozen future projects is to add netinet/*.h like data structures to the Haskell network library (i.e. TCP, IPv4, UDP headers with Binary instances). This isn't to say your task would be much more difficult, but it would be nice to have a community wide definition available. Tom On Thu, Jan 8, 2009 at 10:50 PM, John Goerzen wrote: > Andrew Coppin wrote: >> John Goerzen wrote: >>> On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote: >>> >>>> The number of applications requiring the implementation of a custom web >>>> server is an insignificant fraction of the number of applications >>>> requiring a messaging system. I don't think anyone would dispute >>>> Haskell's ability to do low-level, raw networking, of the type that few >>>> people actually need to do. It's the higher level stuff where there's a >>>> huge amount of room for improvement. >>>> >>> I disagree on both points. >>> >>> Haskell has had somewhat of a deficit in the low-level networking >>> stuff, not even supporting IPv6 in the standard stack until just >>> recently. (That is, things like AF_INET6 were not present.) >>> >>> I think it has pretty much caught up by now though. >>> >> >> Any idea how I get Haskell to send ICMP ECHO packets? (And, obviously, >> receive the replies.) > > SocketType claims to support Raw, which I think is the conventional > means for doing this. Whether all the infrastructure for that is there, > I don't know. I have never worked with raw sockets though, so I may be > leading you down a dark mugger-laden alley here ;-) > > -- John > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From lemming at henning-thielemann.de Thu Jan 8 19:50:59 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 8 19:42:31 2009 Subject: [Haskell-cafe] advanced class constraints in Haskell 98? In-Reply-To: <20090109002527.GA11670@soi.city.ac.uk> References: <22CE9CB9-AC08-4214-8DFC-E271F758F6EF@yandex.ru> <20090108234736.GA9217@soi.city.ac.uk> <20090109002527.GA11670@soi.city.ac.uk> Message-ID: On Fri, 9 Jan 2009, Ross Paterson wrote: > On Fri, Jan 09, 2009 at 01:11:12AM +0100, Henning Thielemann wrote: >> Maybe the report is not complete? I mean, the current behaviour of Hugs >> and GHC (as I observed it) is more consistent, and maybe that's what the >> designers had in mind. > > I'm puzzled by the Hugs behaviour. The current version rejects it, and > I downloaded and built the Mar2005 version just to check, and it also > rejected it, saying > > Illegal Haskell 98 class constraint in class declaration You are right. I don't know, what I made different before. Btw. 2005 was the copyright year, Hugs' version is September 2006: __ __ __ __ ____ ___ _________________________________________ || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2005 ||---|| ___|| World Wide Web: http://haskell.org/hugs || || Bugs: http://hackage.haskell.org/trac/hugs || || Version: September 2006 _________________________________________ Haskell 98 mode: Restart with command line option -98 to enable extensions ERROR "src/Data/Spreadsheet/CharSource.hs":14 - Illegal Haskell 98 class constraint in class declaration *** Constraint : Monad (a Maybe) *** Context : (Monad (a Maybe), Monad (a Identity)) So, since GHC allows this extension without an option - how can I tell Cabal, which extension I'm using? Has it a name anyway? From niklas.broberg at gmail.com Thu Jan 8 19:51:20 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu Jan 8 19:42:48 2009 Subject: [Haskell-cafe] ANNOUNCE: haskell-src-exts 0.4.8 Message-ID: Fellow Haskelleers, it is my pleasure to announce the new release of the haskell-src-exts package, version 0.4.8: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.4.8 darcs get http://code.haskell.org/HSP/haskell-src-exts This is a bug-fix release in the wake of the flurry of bug reports I received due to Neil Mitchell's release of hlint. Not all bugs have been squashed, but all the ones that I could handle with fairly small changes to the library should be. Those include deriving for MPTCs, importing constructor symbols, inline pragmas in instance declarations, scoped type variables, and a few more. There are some minor non-backwards compatible changes to the abstract syntax, but nothing too serious. The most pervasive is that the Match and PatBind constructors have an extra argument of type Maybe Type, representing an optional type signature. Derivings also are no longer just a list of class names, since those classes can now have extra parameters. Four things remain on the bug list: - Support for explicitly kinded arguments to type families. Shouldn't be too hard, but will require changes to the AST that I will leave for the next release. - Support for (un-parenthesised) higher-ranked types as arguments. haskell-src-exts supports e.g. foo :: b -> (forall a . [a]) -> b but not foo :: b -> forall a . [a] -> b. Supporting the latter is simply a parser issue, but a rather tricky one. - Correct handling of hyphened vars (an artifact of HSX/HSP) vs minus operators. This one is nasty. - Support for Unicode symbols for e.g. ->. Fixing that would require me to have a Unicode-compliant editor, which it appears I don't. And I couldn't have someone else submit a patch either, since then I couldn't open the file anymore in my editor. So unless someone can point out a good Unicode-aware editor for Windows, I'm afraid this is a feature that won't be implemented. If you find anything else that haskell-src-exts fails on, please report it. Cheers and Happy Haskelling, /Niklas From tonyhannan2 at gmail.com Thu Jan 8 20:13:11 2009 From: tonyhannan2 at gmail.com (Tony Hannan) Date: Thu Jan 8 20:04:39 2009 Subject: [Haskell-cafe] Re: Hypothetical Haskell job in New York In-Reply-To: References: Message-ID: Well, I received 20 responses in 24 hours, many who would move from abroad to New York! I am very pleased with this number. Hopefully this will ease my boss's concern. But please continue to reply to me if you would be interested and haven't done so yet. The higher the number the more convincing the argument to my boss. Thank you to all who replied. What a great mailing list. I will let you know if it actually turns into a real job opportunity. Cheers, Tony On Wed, Jan 7, 2009 at 7:01 PM, Tony Hannan wrote: > Hello Haskellers, > > I'm trying to convince my boss to use Haskell. His main concern is finding > people who know Haskell when hiring. He is comfortable with Java because he > knows he can always find a Java developer. So if I advertised we were > looking for Haskell programmers in New York City, how many would respond? > Please reply to this email if you would respond. Email me privately if you > like and I will post the results to haskell-cafe later. > Our company is a startup CDN ( > http://en.wikipedia.org/wiki/Content_Delivery_Network) about 3 years old > and doing well. You would hythothetically be one of 7 programmer who write > all the software involved in a CDN including http server, dns server, > monitoring, load balancing, customer and operator user interface, etc. The > pay depends on experience but is good. > > Thanks, > Tony > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090108/6b91eb0d/attachment.htm From max.rabkin at gmail.com Thu Jan 8 20:15:48 2009 From: max.rabkin at gmail.com (Max Rabkin) Date: Thu Jan 8 20:07:17 2009 Subject: [Haskell-cafe] ANNOUNCE: haskell-src-exts 0.4.8 In-Reply-To: References: Message-ID: On Thu, Jan 8, 2009 at 4:51 PM, Niklas Broberg wrote: > So unless someone can > point out a good Unicode-aware editor for Windows, I'm afraid this is > a feature that won't be implemented. A Windows port of a Unix editor? I know Vim is available on Windows. Otherwise, Notepad++ appears to have Unicode support. > Cheers and Happy Haskelling, > > /Niklas From jwlato at gmail.com Thu Jan 8 20:48:49 2009 From: jwlato at gmail.com (John Lato) Date: Thu Jan 8 20:40:17 2009 Subject: [Haskell-cafe] Re: State Monad - using the updated state Message-ID: <9979e72e0901081748m619f09a4qd86b4934970f15f9@mail.gmail.com> It sounds like you've got the monadic solution figured out, so that's good. Even though I would recommend using State (or StateT if necessary), I wanted to be sure this question was answered. > ranq1List :: (Word64 -> a ) -> Word64 -> [a] > ranq1List converter state = converter newState : ranq1List converter > newState > where > newState = ranq1Increment state > > > One more question on this - the other concern I had with the recursive list > approach was that although lazy evaluation prevents me generating numbers > before I 'ask' for them, I figured that if I was going to be asking for say > 10 million over the course of one simulation, that although I request them > one by one, over hours or even days, at the end of the simulation I will > still have a list of 10 million word64s - each of which I could throw away > within minutes of asking for it. This seemed like huge memory bloat, and > thus probably I was taking the wrong approach. This "memory bloat" is a space leak. In general they are to be avoided. GHC's garbage collection is quite efficient, so if you structure your program properly the space will be reclaimed after the values are used. Values will only be collected if they cannot be referenced from live code (just like Java, Python, C#, or other languages with GC). If you are able to structure your code like this: doSomething :: [Word64] -> IO () doSomething (rand:rands) = do someIO rand otherIO rand ... if endFlag then return () else doSomething rands main = do let rands = ranq1List id 1 doSomething rands you won't have a space leak. The head of the list is used within doSomething, while only the tail is passed in the recursion. At the time of the recursive call to doSomething, the head 'rand' value is no longer accessible by any running code, so it can be GC'd. Contrast that with this version (somewhat contrived): doSomething2 :: [Word64] -> Int -> IO () -- the Int is an index into the list. doSomething2 rands i = do let rand = rands !! i someIO rand otherIO rand ... if endFlag then return () else doSomething2 rands (i + 1) This version is Really Bad. Firstly the entire list is passed on each recursion. Every element remains within scope, so nothing is GC'd. That's the space leak. There's another big problem: the current random value is computed by traversing from the head of the list. As the index value grows, it takes progressively longer to traverse the list to retrieve the current value. (N.B. I haven't tested these specific examples, but I think I'm right.) Cheers, John Lato From ryani.spam at gmail.com Thu Jan 8 21:37:32 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Jan 8 21:29:00 2009 Subject: [Haskell-cafe] Re: Blitting one IOUArray into another In-Reply-To: References: Message-ID: <2f9b2d30901081837h3d88da63xe6863940ec5fe7e6@mail.gmail.com> You can't safely convert an IOUArray into a Ptr; Ptr is a raw value which isn't noticed by the garbage collector, so if the data is relocated or GC'd while you have a pointer to it, further access will corrupt memory. Rather, the data inside of an IOUArray is held in a MutableByteArray#. In Data.Array.IO.Internals you can get at the newtype for IOUArray. I have some code that looks like this: > import Foreign.Ptr > import Data.Array.Base > import Data.Array.IO.Internals > import GHC.Exts > import Data.Word > foreign import ccall unsafe clear_bitmap :: > MutableByteArray# RealWorld -> Word32 -> Word32 -> IO () > {-# INLINE unsafeGetMutableArray# #-} > unsafeGetMutableArray# :: IOUArray Int Word32 -> MutableByteArray# RealWorld > unsafeGetMutableArray# (IOUArray (STUArray _ _ array#)) = array# > > clearBitmap :: IOUArray Int Word32 -> Word32 -> Word32 -> IO () > clearBitmap a1 color size > = clear_bitmap (unsafeGetMutableArray# a1) color size Then the I have a small amount of C code implementing "clear_bitmap": void clear_bitmap(HsWord32* img, HsWord32 color, HsWord32 size) { for(; size; --size, ++img) { *img = color; } } This is OK to do because the "unsafe" ccall guarantees that no GC can happen during the outcall to clear_bitmap, so we can manipulate the pointer directly. If you want to stay entirely in Haskell, there are a bunch of operations on MutableByteArray# in GHC.Exts; see http://www.haskell.org/ghc/docs/6.10-latest/html/libraries/ghc-prim/GHC-Prim.html#12 You probably need {-# LANGUAGE MagicHash #-} in order to get these to work; it makes # be a legal symbol in identifiers. It also helps to know the newtype for IO, if you want to write actually usable functions on top of these internal bits. > newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #)) Of course all of this is GHC-specific, and internal to base and subject to change. But I found it useful. -- ryan On Thu, Jan 8, 2009 at 6:51 AM, Bueno, Denis wrote: > On 01/07/2009 14:36 , "Neal Alexander" wrote: > >> Bueno, Denis wrote: >>> Oh, do you mean by actually calling memcpy via ffi? >> >> http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-Marshal-Uti >> ls.html > > Ah, thanks. Is there a way to simply "cast" an IOUArray Int Int64 into > something like a Ptr Int64, or will I need to change my code to allocate the > arrays differently (using something in Foreign.*)? > > I hoogle'd functions "IOUArray a b -> Ptr b", but couldn't find anything. > Denis > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ryani.spam at gmail.com Thu Jan 8 21:43:05 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Jan 8 21:34:34 2009 Subject: [Haskell-cafe] Re: How to give unique name/id to nodes outside any monad ? In-Reply-To: <40a414c20901081054i62f98377ma225fb1b3015b906@mail.gmail.com> References: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> <40a414c20901080053n7fd36430he551f27c8fc06e58@mail.gmail.com> <40a414c20901080121u2038f1e1mcb3085769db18973@mail.gmail.com> <20090108131340.0b9f48e6@tritium.xx> <40a414c20901080503l56a05d1u8988ec89913bf1f8@mail.gmail.com> <40a414c20901081054i62f98377ma225fb1b3015b906@mail.gmail.com> Message-ID: <2f9b2d30901081843w5390f857nc7b4cf58b595d574@mail.gmail.com> I seem to recall reading somewhere that an object's StableName can change when it becomes evaluated; so it's possible you aren't detecting sharing because of this. You might try this instead: > mkStableName' a = mkStableName $! a This forces the object to become evaluated before calling mkStableName. Of course I haven't tested this, it's just a shot in the dark. -- ryan 2009/1/8 minh thu : > Interestingly, I failed to detect sharing with StableName. > But using the graph node as a key turned to work... > If you're interested in the experiment, see attached code. > > Cheers, > Thu > > 2009/1/8 minh thu : >> 2009/1/8 Ertugrul Soeylemez : >>> "minh thu" wrote: >>> >>>> Nothing, simply the notation. Now, with the remark of Luke, I'm >>>> wondering how bad it is to use makeStableName/hashStableName to "copy" >>>> the data structure in a similar one with explicit reference (that is, >>>> using pointer or keys in a map or whatever). >>> >>> Probably you're misusing the notation. I don't see any reason, why >>> monadic notation should be less readable. Usually it's even more >>> readable. Luke's remark is very valid. Haskell is the wrong language >>> for imperative programming. You don't have _any_ benefit of Haskell, if >>> you use it like C. Try to change your mind. Monads aren't evil. They >>> are there to make your life easier. Way easier than imperative methods. >> >> Well, maybe it's is just my opinion, but I found the non-monadic code >> in the previous mail >> easier to write than the monadic one... I don't know against what >> you're making the compareason to say it's more readable. >> >> Although I agree using Haskell requires some change of thinking, >> statement like yours >> are a bit too much for me. I find Haskell a nice language even for >> imperative programming... >> >> Cheers, >> Thu >> >>> Greets, >>> Ertugrul. >>> >>> >>>> Thank you, >>>> Thu >>>> >>>> 2009/1/8 Lennart Augustsson : >>>> > Look at http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-StableName.html. >>>> > >>>> > But what's wrong with constructing the graph in a monad? >>>> > >>>> > On Thu, Jan 8, 2009 at 9:53 AM, minh thu wrote: >>>> >> Well, the processing of the data structure has to be done in the IO monad. >>>> >> What is the library you talk about ? Could it give the "stable names" >>>> >> (in IO) for >>>> >> each node of the mentioned graph (I mean, after the graph has been constructed >>>> >> purely) ? >>>> >> >>>> >> Thanks, >>>> >> Thu >>>> >> >>>> >> 2009/1/8 Lennart Augustsson : >>>> >>> Of course you don't need a monad, but you need to do the same >>>> >>> operations as you would with a state monad to number the nodes. This >>>> >>> is the only way in (pure) Haskell. There is no object identity in >>>> >>> Haskell, so if you want the nodes to have identity you need to provide >>>> >>> it. >>>> >>> >>>> >>> GHC does have a library for stable names which (in the IO monad) >>>> >>> allows you to get something akin to the address of a value in memory. >>>> >>> But that's not the functional way of doing this. >>>> >>> >>>> >>> -- Lennart >>>> >>> >>>> >>> On Thu, Jan 8, 2009 at 9:28 AM, minh thu wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>> I'd like to process some kind of graph data structure, >>>> >>>> say something like >>>> >>>> >>>> >>>> data DS = A [DS] | B DS DS | C. >>>> >>>> >>>> >>>> but I want to be able to discover any sharing. >>>> >>>> Thus, in >>>> >>>> >>>> >>>> b = B a a where a = A [C], >>>> >>>> >>>> >>>> if I want to malloc a similar data structure, >>>> >>>> I have to handle to the node representing B >>>> >>>> two times the same pointer (the one returned >>>> >>>> after allocating A [C]). >>>> >>>> >>>> >>>> To discover sharing, I thought it would be >>>> >>>> necessary to give unique name to node and >>>> >>>> then compare them while traversing the graph. >>>> >>>> I could give the name by hand but it would be >>>> >>>> cumbersome. But at least it would not require >>>> >>>> any monad for the bookkeeping of ungiven >>>> >>>> names. Is it possible to give those names >>>> >>>> automatically but outside any monad ? >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Thu >>>> >>>> _______________________________________________ >>>> >>>> Haskell-Cafe mailing list >>>> >>>> Haskell-Cafe@haskell.org >>>> >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>>> >>>> >>> >>>> >> >>>> > >>> >>> >>> >>> -- >>> nightmare = unsafePerformIO (getWrongWife >>= sex) >>> http://blog.ertes.de/ >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From wqeqweuqy at hotmail.com Thu Jan 8 22:07:39 2009 From: wqeqweuqy at hotmail.com (Neal Alexander) Date: Thu Jan 8 21:59:26 2009 Subject: [Haskell-cafe] Re: Monads aren't evil In-Reply-To: <20090108231652.24b75fe3@tritium.xx> References: <20090108231652.24b75fe3@tritium.xx> Message-ID: Ertugrul Soeylemez wrote: > Hello fellow Haskellers, > > When I read questions from Haskell beginners, it somehow seems like they > try to avoid monads and view them as a last resort, if there is no easy > non-monadic way. I'm really sure that the cause for this is that most > tutorials deal with monads very sparingly and mostly in the context of > input/output. Also usually monads are associated with the do-notation, > which makes them appear even more special, although there is really > nothing special about them. > Yea, i was the same way when i started learning Haskell. I understood how Monads worked, and what the motivation was for them, but not why i would want to restructure code to use them in specific instances. "Why should i care about monads when i can use Arrows or (.)" was also a factor. Its kinda like getting advice from an adult as a child. You have no particular reason to distrust the advice, but the value of it doesn't set in until something happens to you first hand to verify it. For me the turning point was writing some code that needed to handle running code locally/remotely in a transparent manner. Maybe having a list of real-world usage scenarios or exercises on the wiki may help. From tim at goddard.net.nz Fri Jan 9 01:11:30 2009 From: tim at goddard.net.nz (Timothy Goddard) Date: Fri Jan 9 01:03:03 2009 Subject: [Haskell-cafe] How to give unique name/id to nodes outside any monad ? In-Reply-To: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> References: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> Message-ID: <200901091911.31267.tim@goddard.net.nz> On Thu, 08 Jan 2009 21:28:27 minh thu wrote: > Hi, > > I'd like to process some kind of graph data structure, > say something like > > data DS = A [DS] | B DS DS | C. Graphs in funtional languages aren't usually represented in this sort of manner. Trees are fine to represent like that as they're acyclic and have exactly one parent for each node but for graphs it's much more difficult. Say that you have a graph with directed connections like this: 0 -> 1 1 -> 2 2 -> 3 1 -> 3 3 -> 4 Now you want to alter node 4. Node 3 has to be updated to point to the new version of 4, node 1 has to be changed to point to the new version of 3, node 2 has to be changed to point to the new version of node 3, then node 1 has to be changed again to point to the new version of 2, then finally 0 can be changed to point to the new version of 1 and returned. There is no simple way using this representation to handle that double-update to node 1, or to handle disconnected or cyclic graphs. Updates are extremely difficult since Haskell data structures are not mutable and have no concept of identity. The approach of treating nodes as structures with pointers to each other cannot be cleanly and efficiently implemented in an immutable fashion. It only really makes sense in a stateful, imperative context. An approach that suits functional languages better is to store a flat structure listing the edges leaving each node. This, I believe, is the approach taken by Haskell's main graph library, FGL (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fgl). You would now have something like: data MyNode nv = MyNode {nodeId::Int, nodeValue::nv} data MyEdge ev = MyEdge {edgeDestination::Int, edgeValue::ev} data MyGraph nv ev = MyGraph { maxNode :: Int, nodes :: (Map Int nv), edges :: (Map Int [MyEdge ev])} emptyGraph :: MyGraph nv ev emptyGraph = MyGraph 0 (Data.Map.empty) (Data.Map.empty) getNode :: MyGraph nv ev -> Int -> Maybe (MyNode nv) getNode g id = ((nodes g) `lookup` id) >>= (\v -> MyNode id v) getEdgesLeaving :: MyGraph nv ev -> Int -> [MyEdge ev] getEdgesLeaving g id = fromMaybe [] ((edges g) `lookup` id) addNode :: nv -> MyGraph nv ev -> (Int, MyGraph nv ev) addNode val g = (maxNode newGraph, newGraph) where newNodeId = (maxNode g) + 1 newGraph = MyGraph newNodeId (insert newNodeId val (nodes g)) (edges g) ... and so on. (This is all totally untested - use at your own peril.) Each node in the graph has a unique identifying number, issued in sequence using maxNode as a counter. This makes identifying cycles easy. The nodes map contains the value for each node based on its id. The edges map contains a list of links from each node to others in the graph. Finding links entering a node is quite expensive - if you need to do this often then maintaining a second list of edges entering each node would speed it up. Each node and each edge can have a custom data structure attached. New nodes and edges can be added without having to modify references elsewhere, nodes have a distinct identity given by the associated Int and the graph is immutable - operations on it produce modified copies. Cheers, Tim From bulat.ziganshin at gmail.com Fri Jan 9 01:13:03 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Jan 9 01:08:38 2009 Subject: [Haskell] Re: [Haskell-cafe] ANNOUNCE: haskell-src-exts 0.4.8 In-Reply-To: References: Message-ID: <558014897.20090109091303@gmail.com> Hello Max, Friday, January 9, 2009, 4:15:48 AM, you wrote: > Otherwise, Notepad++ appears to have Unicode support. even notepad (on my vista box) supports utf-8, utf16be and utf16le :))) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From noteed at gmail.com Fri Jan 9 03:11:21 2009 From: noteed at gmail.com (minh thu) Date: Fri Jan 9 03:02:47 2009 Subject: [Haskell-cafe] How to give unique name/id to nodes outside any monad ? In-Reply-To: <200901091911.31267.tim@goddard.net.nz> References: <40a414c20901080028x331e1e00ga3c1d300354f3337@mail.gmail.com> <200901091911.31267.tim@goddard.net.nz> Message-ID: <40a414c20901090011t3ac64e7bned41ef32b8d9f369@mail.gmail.com> 2009/1/9 Timothy Goddard : > On Thu, 08 Jan 2009 21:28:27 minh thu wrote: >> Hi, >> >> I'd like to process some kind of graph data structure, >> say something like >> >> data DS = A [DS] | B DS DS | C. > > Graphs in funtional languages aren't usually represented in this sort of > manner. Trees are fine to represent like that as they're acyclic and have > exactly one parent for each node but for graphs it's much more difficult. Say > that you have a graph with directed connections like this: > > 0 -> 1 > 1 -> 2 > 2 -> 3 > 1 -> 3 > 3 -> 4 > > Now you want to alter node 4. Node 3 has to be updated to point to the new > version of 4, node 1 has to be changed to point to the new version of 3, node > 2 has to be changed to point to the new version of node 3, then node 1 has to > be changed again to point to the new version of 2, then finally 0 can be > changed to point to the new version of 1 and returned. > > There is no simple way using this representation to handle that double-update > to node 1, or to handle disconnected or cyclic graphs. Updates are extremely > difficult since Haskell data structures are not mutable and have no concept > of identity. The approach of treating nodes as structures with pointers to > each other cannot be cleanly and efficiently implemented in an immutable > fashion. It only really makes sense in a stateful, imperative context. > > An approach that suits functional languages better is to store a flat > structure listing the edges leaving each node. This, I believe, is the > approach taken by Haskell's main graph library, FGL > (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fgl). You would > now have something like: > > data MyNode nv = MyNode {nodeId::Int, nodeValue::nv} > > data MyEdge ev = MyEdge {edgeDestination::Int, edgeValue::ev} > > data MyGraph nv ev = MyGraph { > maxNode :: Int, > nodes :: (Map Int nv), > edges :: (Map Int [MyEdge ev])} > > emptyGraph :: MyGraph nv ev > emptyGraph = MyGraph 0 (Data.Map.empty) (Data.Map.empty) > > getNode :: MyGraph nv ev -> Int -> Maybe (MyNode nv) > getNode g id = ((nodes g) `lookup` id) >>= (\v -> MyNode id v) > > getEdgesLeaving :: MyGraph nv ev -> Int -> [MyEdge ev] > getEdgesLeaving g id = fromMaybe [] ((edges g) `lookup` id) > > addNode :: nv -> MyGraph nv ev -> (Int, MyGraph nv ev) > addNode val g = (maxNode newGraph, newGraph) > where > newNodeId = (maxNode g) + 1 > newGraph = MyGraph newNodeId (insert newNodeId val (nodes g)) (edges g) > > ... and so on. (This is all totally untested - use at your own peril.) > > Each node in the graph has a unique identifying number, issued in sequence > using maxNode as a counter. This makes identifying cycles easy. The nodes map > contains the value for each node based on its id. The edges map contains a > list of links from each node to others in the graph. Finding links entering a > node is quite expensive - if you need to do this often then maintaining a > second list of edges entering each node would speed it up. > > Each node and each edge can have a custom data structure attached. New nodes > and edges can be added without having to modify references elsewhere, nodes > have a distinct identity given by the associated Int and the graph is > immutable - operations on it produce modified copies. Indeed, the processing I'm refering to is to copy something like my representation into something like yours. Thanks ! Thu From dominic.steinitz at blueyonder.co.uk Fri Jan 9 03:23:09 2009 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Fri Jan 9 03:14:49 2009 Subject: [Haskell-cafe] Re: Low-level networking [Haskell not ready for Foo] References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49667026.9060702@btinternet.com> <49668330.2000701@complete.org> Message-ID: John Goerzen complete.org> writes: > > Any idea how I get Haskell to send ICMP ECHO packets? (And, obviously, > > receive the replies.) > > SocketType claims to support Raw, which I think is the conventional > means for doing this. Whether all the infrastructure for that is there, > I don't know. I have never worked with raw sockets though, so I may be > leading you down a dark mugger-laden alley here Here's an example of a Haskell version of ping, now sadly bit-rotted. Dominic. http://haskell.org/networktools/src/ping/test.hs http://haskell.org/networktools/src/ping/ From miguelimo38 at yandex.ru Fri Jan 9 04:00:20 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Fri Jan 9 03:51:51 2009 Subject: [Haskell-cafe] ANNOUNCE: haskell-src-exts 0.4.8 In-Reply-To: References: Message-ID: <8E31B59B-1197-4194-A3DC-C16F7F64AB42@yandex.ru> On 9 Jan 2009, at 03:51, Niklas Broberg wrote: > - Support for Unicode symbols for e.g. ->. Fixing that would require > me to have a Unicode-compliant editor, which it appears I don't. And I > couldn't have someone else submit a patch either, since then I > couldn't open the file anymore in my editor. So unless someone can > point out a good Unicode-aware editor for Windows, I'm afraid this is > a feature that won't be implemented. Emacs? From marlowsd at gmail.com Fri Jan 9 04:16:52 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jan 9 04:08:24 2009 Subject: [Haskell-cafe] Re: GHC libraries documentation and links to source files In-Reply-To: <494EB026.2030103@libero.it> References: <494EB026.2030103@libero.it> Message-ID: <49671604.7040803@gmail.com> Manlio Perillo wrote: > Hi. > > I have noted that recent versions of the GHC libraries documentation, no > longer have links to the source code. > > What is the reason? > I find it very useful. This was an oversight in the GHC 6.10.1 release, we'll make sure it gets remedied for 6.10.2. Cheers, Simon From gour at mail.inet.hr Fri Jan 9 04:25:15 2009 From: gour at mail.inet.hr (Gour) Date: Fri Jan 9 04:16:29 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety References: <87eizkra83.fsf@nitai.hr> <20090108030656.GA4430@complete.org> Message-ID: <87hc48zv9g.fsf@nitai.hr> >>>>> "John" == John Goerzen writes: Hello John, John> I would say that database interactions are typically limited to a John> small part of code. In small programs, I generally have a DB John> module that does the queries, and marshals everything to/from the John> rich Haskell types I define. Any possible type issues are thus John> constrained to that small part of code. That's right. However, I envision application for which a significant part would require querying (kind of research base for querying common stuff in thousands of records.) John> HDBC is a low-level abstraction, which can be used on its own or, John> of course, as a layer underlying HaskellDB or some such. I do not John> dispute the use of tools such as HaskellDB or others that try to John> automate the business of representing a database's schema -- and John> queries against it -- using a language's type system. There are a John> lot of these systems in a lot of languages. I've used some of John> them. Have you maybe tried Takusen (HaskellDB which you reference above does not seem very much alive)? John> And, almost universally, they annoy me. I find it takes longer to John> write code with them than without, and often they have issues John> representing some query that I know I can do easily in SQL but John> maybe can't as easy in the toolkit. As an example, when I last John> looked at HaskellDB in 2005, I found that it was impossible to do John> a SELECT without a DISTINCT [1]. There are many situations where John> such a thing is necessary, so I had to discard it for my projects. Hmm, that's interesting to hear...I'm curious what could be reply from Takusen devs... John> HDBC is more similar to Perl's DBI or Python's DB-API (or perhaps John> a sane version of JDBC). It is a standard interface to SQL RDBMS John> engines that provides some tools for marshaling data back and John> forth, but generally leaves you to construct the queries. Well, that's not too bad... John> So, this was not intended as an HDBC commercial, just more of a John> braindump as to why I wrote it. Hope it helps. Sure, it helps. Thanks a lot for your input. Otoh, I believe that, considering it is mentioned in RWH, HDBC does not need much commercial, just contrary, you can expect new feature requests From the new army of Haskell developers cultivated by the book :-) I'll e.g. open ticket for BLOB support :-D John> HDBC is actively used in mission-critical applications where I John> work. We use both the PostgreSQL and ODBC backends in production. John> We even use the ODBC backend along with the particularly nefarious John> ODBC interface for the Progress 4GL database. I use the Sqlite3 John> backend quite a bit in my own personal projects, such as hpodder John> and twidge. Database abstraction offered by HDBC is very nice feature allowing one to change back-end driver without too much hassle, so I'll try to investigate a bit about possible BLOB support on HDBC-level. It's definitely something used in real-world databases... Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090109/5c8a80fa/attachment.bin From marlowsd at gmail.com Fri Jan 9 04:25:54 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jan 9 04:17:30 2009 Subject: [Haskell-cafe] Re: concurrent haskell: thread priorities In-Reply-To: <11545907.20081222231446@gmail.com> References: <11545907.20081222231446@gmail.com> Message-ID: <49671822.1080201@gmail.com> Bulat Ziganshin wrote: > Monday, December 22, 2008, 11:07:32 PM, you wrote: > >> The threaded RT creates an OS thread for each CPU/core on the system and >> uses them to multiplex userland threads. These are context switched >> whenever they block/yield/gc and no priorities can be assigned. > > not exactly. amount of OS threads created controlled by +RTS -N option > to the program; unless program has special function that RTS calls to > set up this value There might be multiple OS threads per CPU, if for example one of the Haskell threads makes a safe foreign call another OS thread takes over running the rest of the Haskell threads on that CPU. When you say "+RTS -N2" all you are saying is "I want to allow up to 2 Haskell threads to run simultaneously". The actual mapping between Haskell threads and OS threads is decided by the RTS, hopefully in a sensible way, within this constraint. > they are switched on every minor GC which by default occurs after > each 256kb allocated which is rather frequent event 512Kb by default (caches are bigger these days), and configurable with +RTS -A. Cheers, Simon From marlowsd at gmail.com Fri Jan 9 04:29:21 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jan 9 04:20:54 2009 Subject: [Haskell-cafe] Re: concurrent haskell: thread priorities In-Reply-To: References: <11545907.20081222231446@gmail.com> Message-ID: <496718F1.3020604@gmail.com> Neal Alexander wrote: > Bulat Ziganshin wrote: >> Hello Neal, >> >> Monday, December 22, 2008, 11:07:32 PM, you wrote: >> >>> The threaded RT creates an OS thread for each CPU/core on the system and >>> uses them to multiplex userland threads. These are context switched >>> whenever they block/yield/gc and no priorities can be assigned. >> >> not exactly. amount of OS threads created controlled by +RTS -N option >> to the program; unless program has special function that RTS calls to >> set up this value >> >> they are switched on every minor GC which by default occurs after >> each 256kb allocated which is rather frequent event >> >>> It seems like we could get some priority based scheduling (and still be >>> slackers) if we allow marked green threads to be strictly associated >>> with a specific OS thread (forkChildIO?). >> >> forkOS creates new haskell thread and new OS thread specially for it >> > > The docs say that the forkOS thread is still scheduled by the Haskell RT > though. What would happen if you bump its priority through FFI? Probably not much, unless you had specified a larger -N value than the number of cores in your machine, in which case the OS threads are being multiplexed by the OS onto the available cores. In that case the relative priorities of the OS threads would affect the scheduling decisions made by the OS. > What about this scenario: > > forkOS = OS thread A1, Haskell Thread A2 > forkIO = Haskell thread B > > Could thread B potentially be run on thread A1? No. > Would the RT yield > thread A2 to give time to another Haskell thread? Sure, A2 behaves like any other Haskell thread. Cheers, Simon From marlowsd at gmail.com Fri Jan 9 04:36:07 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jan 9 04:27:54 2009 Subject: [Haskell-cafe] Re: concurrent haskell: thread priorities In-Reply-To: References: <4c44d90b0812221442p2933e84dl90c81bb2f986dd3c@mail.gmail.com> Message-ID: <49671A87.1040401@gmail.com> Neal Alexander wrote: > Thomas DuBuisson wrote: >> It seems like we could get some priority based scheduling (and still >> be slackers) if we allow marked green threads to be strictly >> associated with a specific OS thread (forkChildIO?). >> >> >> I think you want the GHC-only GHC.Conc.forkOnIO >> > GHC.Conc.forkOnIO is helpful but doest work in this case - it doesn't > attach them to the same OS thread. But it does attach the thread to a particular "virtual CPU" in the GHC RTS (we call them "capabilities"), with the intention that a virtual CPU corresponds more or less to a real CPU core. Cheers, Simon From ron at gamr7.com Fri Jan 9 04:52:56 2009 From: ron at gamr7.com (Ron de Bruijn) Date: Fri Jan 9 04:42:27 2009 Subject: [Haskell-cafe] Marshalling recursive data structures with the FFI Message-ID: <49671E78.6080105@gamr7.com> Hi, A few days ago we published an article (http://gamr7.com/blog/?p=66) on using the FFI to marshal recursive data structures between Haskell and C (or Python if you use ctypes). Best regards, Ron de Bruijn From nad at Cs.Nott.AC.UK Fri Jan 9 06:55:01 2009 From: nad at Cs.Nott.AC.UK (Nils Anders Danielsson) Date: Fri Jan 9 06:46:36 2009 Subject: [Haskell-cafe] ANNOUNCE: haskell-src-exts 0.4.8 In-Reply-To: References: Message-ID: <49673B15.5010906@cs.nott.ac.uk> On 2009-01-09 00:51, Niklas Broberg wrote: > - Support for Unicode symbols for e.g. ->. Fixing that would require > me to have a Unicode-compliant editor Can't you just use character literals like '\x2192'? -- /NAD This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From manlio_perillo at libero.it Fri Jan 9 07:06:44 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Fri Jan 9 06:58:30 2009 Subject: [Haskell-cafe] Re: Hypothetical Haskell job in New York In-Reply-To: <20090108221844.GB30539@hustlerturf.com> References: <4965DC5D.1050006@libero.it> <20090108180456.GD22269@scytale.galois.com> <4966662C.4050009@libero.it> <20090108221844.GB30539@hustlerturf.com> Message-ID: <49673DD4.4070309@libero.it> John Goerzen ha scritto: > On Thu, Jan 08, 2009 at 09:46:36PM +0100, Manlio Perillo wrote: >> I'm speaking about servers, not clients. >> >> How much of pure Haskell internet servers are used in a production >> environment, in the "open internet" (and not in restricted LANs)? > > Does that really matter? I tend to judge technology based on its > merits for my work, not on who uses it. Well, testing a server is not easy. You can have a server that works for you without problems, but in different environment it gives problems. > [...] Regard Manlio Perillo From manlio_perillo at libero.it Fri Jan 9 07:28:04 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Fri Jan 9 07:19:40 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49666B19.8040500@libero.it> Message-ID: <496742D4.3000909@libero.it> Bryan O'Sullivan ha scritto: > On Thu, Jan 8, 2009 at 1:07 PM, Manlio Perillo > wrote: > > > Another example is the multipart parser: > > -- | Read a multi-part message from a 'Handle'. > -- Fails on parse errors. > hGetMultipartBody :: String -- ^ Boundary > -> Handle > -> IO MultiPart > hGetMultipartBody b h = > do > s <- BS.hGetContents h > case parseMultipartBody b s of > Nothing -> fail "Error parsing multi-part message" > Just m -> return m > > > Yes, that's definitely on the scary side of things. > > However, you don't have to go all the way to drinking the Iteratee > Kool-Aid in order to write safer networking code that is still > performant. Here are a few projects I'm actively working on in this area: > > * I'm adding epoll support to the threaded RTS. This is a necessity > for server performance. How easy is to add support for other methods, like poll, kqueue, /dev/poll and Windows IOCP? > * I've added support for sending and receiving lazy ByteStrings to > Johan Tibbell's network-bytestring library. A quick benchmark with > a toy HTTP server has shown this to be about 2x faster than > writing ByteStrings to a Handle (i.e. 14,000 requests per second, > vs 7,000). I personally like Nginx concept of chained buffers. They are basically a linked list of buffers, where each buffer can be 1) an in memory buffer, where you have pointers to the start, end and current positions 2) file buffer, where you have a file descriptor and the current file offset This is a nice abstraction, since, as an example, a file based buffer can be sent to the network directly using sendfile. I think it should fits well with ByteStrings. > * I've got a continuation-based resumable parser combinator module > for attoparsec in progress, which uses lazy ByteStrings for > blazing performance. You can use this to write protocol parsers in > a completely clean way, decoupled from the underlying network > receive operations. > This is interesting. Writing clean protocol parsers is one of the things I think Haskell can be great with. > While much of this isn't quite ready for use yet, this just represents > one person's work, and there are lots of people beavering away actively > at corners of the problem space that interest them. > Well, I have no doubts that good networking can be done in Haskell. The problem is time. Erlang (and Twisted, from the Python world) have already years of use. So, if I need to write *now* a network application, should I *invest* in Haskell, or should I just *use* Erlang? As a counter example: I really don't like SQL. However I have to use it, if I don't want to re-implement a database by myself. The same can be said with Fortran. > [...] Regards Manlio From briqueabraque at yahoo.com Fri Jan 9 08:01:18 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Fri Jan 9 07:53:02 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: <49661529.3030309@van.steenbergen.nl> References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> Message-ID: > benchpress also uses System.CPUTime -- is > that what you are looking for? I'm writing a program that will read medical signs from many patients. It's important to have a precise measure of the time interval between some signs, and that can't depend on adjustments of time. (Supose my software is running midnight at the end of a year with leap seconds. I would get wrong time intervals.) System.CPUTime.getCPUTime is supposed to give cpu time my program have used. However, something like a platform independent way to know for how long the computer has been turned on would do all I need. Or, maybe, how much has elapsed since the program started. Thanks, Maur?cio From wren at freegeek.org Fri Jan 9 08:07:32 2009 From: wren at freegeek.org (wren ng thornton) Date: Fri Jan 9 07:59:00 2009 Subject: [Haskell-cafe] Staged evaluation, names? In-Reply-To: <8625cd9c0901081613ie216be5xbb54804920860e76@mail.gmail.com> References: <49658049.8060107@freegeek.org> <8625cd9c0901081613ie216be5xbb54804920860e76@mail.gmail.com> Message-ID: <49674C14.9040401@freegeek.org> Andrea Vezzosi wrote: > On Thu, Jan 8, 2009 at 5:25 AM, wren ng thornton wrote: >> The question for y'all is what should I call it? I've been calling the template-function qaf (for Compiled Applicative Form ;) and the type class with that function would be the only thing in the package, but I'm not sure where QAF.hs should be in the module hierarchy. Thoughts? > > Isn't Lift[1] already the right class for this? > > class Lift t where > lift :: t -> Q Exp > > [1] http://haskell.org/ghc/docs/latest/html/libraries/template-haskell/Language-Haskell-TH-Syntax.html#t%3ALift I don't see any documentation there to say what it does, so I'm not sure. (A common problem with TH, unfortunately.) -- Live well, ~wren From bulat.ziganshin at gmail.com Fri Jan 9 08:11:55 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Jan 9 08:03:30 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> Message-ID: <719973612.20090109161155@gmail.com> Hello Mauricio, Friday, January 9, 2009, 4:01:18 PM, you wrote: > computer has been turned on would do all I need. Or, > maybe, how much has elapsed since the program started. i think you should look into system counters (if you on windows). for example, task managet in vista shows time since reboot, i think that in registry it should be available in previous windowses too. at the cpu level, there is cpu ticks counter, it should be readable via special libraries -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From cetin.sert at gmail.com Fri Jan 9 08:29:04 2009 From: cetin.sert at gmail.com (Cetin Sert) Date: Fri Jan 9 08:20:32 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: <719973612.20090109161155@gmail.com> References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> <719973612.20090109161155@gmail.com> Message-ID: <1ff5dedc0901090529q98d5593h44708c20be6184fb@mail.gmail.com> Don't know if it might help but: http://en.wikipedia.org/wiki/RDTSC cabal install rdtsc http://hackage.haskell.org/packages/archive/rdtsc/1.1.1/doc/html/System-CPUTime-Rdtsc.html Regards, CS 2009/1/9 Bulat Ziganshin > Hello Mauricio, > > Friday, January 9, 2009, 4:01:18 PM, you wrote: > > > computer has been turned on would do all I need. Or, > > maybe, how much has elapsed since the program started. > > i think you should look into system counters (if you on windows). for > example, task managet in vista shows time since reboot, i think that > in registry it should be available in previous windowses too. at the > cpu level, there is cpu ticks counter, it should be readable via > special libraries > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090109/eefd814d/attachment.htm From bulat.ziganshin at gmail.com Fri Jan 9 08:34:29 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Jan 9 08:26:07 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: <1ff5dedc0901090529q98d5593h44708c20be6184fb@mail.gmail.com> References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> <719973612.20090109161155@gmail.com> <1ff5dedc0901090529q98d5593h44708c20be6184fb@mail.gmail.com> Message-ID: <757539520.20090109163429@gmail.com> Hello Cetin, Friday, January 9, 2009, 4:29:04 PM, you wrote: yes, i mean this lib but forget its name :) thank you > Don't know if it might help but: > http://en.wikipedia.org/wiki/RDTSC > cabal install rdtsc > http://hackage.haskell.org/packages/archive/rdtsc/1.1.1/doc/html/System-CPUTime-Rdtsc.html > > Regards, > CS > 2009/1/9 Bulat Ziganshin > Hello Mauricio, > > Friday, January 9, 2009, 4:01:18 PM, you wrote: > >> computer has been turned on would do all I need. Or, >> maybe, how much has elapsed since the program started. > > > i think you should look into system counters (if you on windows). for > example, task managet in vista shows time since reboot, i think that > in registry it should be available in previous windowses too. at the > cpu level, there is cpu ticks counter, it should be readable via > special libraries > > > -- > Best regards, > ?Bulat ? ? ? ? ? ? ? ? ? ? ? ? ? ?mailto:Bulat.Ziganshin@gmail.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jgoerzen at complete.org Fri Jan 9 08:36:55 2009 From: jgoerzen at complete.org (John Goerzen) Date: Fri Jan 9 08:28:29 2009 Subject: [Haskell-cafe] Re: Hypothetical Haskell job in New York In-Reply-To: <49673DD4.4070309@libero.it> References: <4965DC5D.1050006@libero.it> <20090108180456.GD22269@scytale.galois.com> <4966662C.4050009@libero.it> <20090108221844.GB30539@hustlerturf.com> <49673DD4.4070309@libero.it> Message-ID: <20090109133655.GA29565@complete.org> On Fri, Jan 09, 2009 at 01:06:44PM +0100, Manlio Perillo wrote: > John Goerzen ha scritto: >> On Thu, Jan 08, 2009 at 09:46:36PM +0100, Manlio Perillo wrote: >>> I'm speaking about servers, not clients. >>> >>> How much of pure Haskell internet servers are used in a production >>> environment, in the "open internet" (and not in restricted LANs)? >> >> Does that really matter? I tend to judge technology based on its >> merits for my work, not on who uses it. > > Well, testing a server is not easy. > You can have a server that works for you without problems, but in > different environment it gives problems. I completely understand that, as a sysadmin that has to maintain mission-critical systems. Unfortunately, it's also so often used as a justification for using "whatever everyone else has". So many people buy Exchange for that reason, as an example. Exchange has a pretty long history of bugs that make it really unsuitable for use in the Enterprise, yet people use it anyway because they think everyone uses it. A particularly amusing example is at http://software.complete.org/software/issues/show/114 - my little OfflineIMAP program appears to be able to take down entire Exchange databases and force a restore from backup, because Exchange has a hard-coded limit of 32k different mail header names *per installation*, and OfflineIMAP generates one unique header each time it uploads a message to the server. If my program can do that accidentally, imagine what someone with a will to do that could do. Nobody would have ever tried Haskell, Python, or Perl in mission-critical situations if they always thought like that. Somebody has to be first, and I see no problem with it being us, as long as we are confident of the outcome. Part of the calculus has to be: 1) Can we test it under stress? 2) How confident are we that it will behave right under conditions we can't test? (Esp. malicious ones) 3) Can we fix it ourselves if it breaks? How many others can fix it? I really like Haskell because of #2. While there is no 100% guarantee, I feel better about Haskell not throwing a type error in some obscure condition than I do about Python not doing so. I also like #2 because of the availability of both HUnit and QuickCheck. Write your code right, and you can QuickCheck a significant part of it. -- John From wren at freegeek.org Fri Jan 9 08:39:09 2009 From: wren at freegeek.org (wren ng thornton) Date: Fri Jan 9 08:30:37 2009 Subject: [Haskell-cafe] Staged evaluation, names? In-Reply-To: <49669653.5020600@henning-thielemann.de> References: <49658049.8060107@freegeek.org> <49669653.5020600@henning-thielemann.de> Message-ID: <4967537D.7030500@freegeek.org> Henning Thielemann wrote: > wren ng thornton schrieb: > >> Every now and then I find myself in the position where I'd like to >> define some hairy value as a CAF instead of a literal, but I'd like for >> it to be fully evaluated at compile-time rather than postponed until >> runtime. It'd be possible to bludgeon the CPP into doing this, but it >> seems easier to use an autocannon like Template Haskell to swat this fly. > > Is it really necessary to use CPP or TemplateHaskell for this kind of > optimization? Can a pragma help? Maybe {-# INLINE #-} ? Inlining the CAF will only copy the CAF definition to all the use sites, potentially increasing the work done at runtime. Inlining other functions or using GHC.Exts.inline liberally in the CAF will potentially blow up the code size, and while GHC may be so kind as to reduce the CAF at compile time, often times it doesn't.[1] The goal I have in mind is a very simple kind of metaprogramming. Consider for instance that you have a function which computes some arcane value. The results of this function are used in many places in inner loops of your program. You know that this arcane value is constant, but it would be troublesome to actually write it as a literal. If you did write it as a literal, then GHC could crank the optimizations on your inner loops, removing dead code and the like. These optimizations are often more important than the one-time cost of evaluating the arcane value and memoizing it (though that's wasted effort too). One example of where you'd like this sort of staged evaluation is to pre-compile textures and masks for graphics. You could compile the bits yourself and ship them with the code, or you could tell the compiler to generate them when it compiles the program. Another example is for architecture dependent bit-twiddling where you'd usually use a bunch of CPP to choose different implementations depending on endianness, word size, etc. It's not *that* common a problem, but it's come up often enough to pique my interest in trying out some TH. And it seems different enough from what most folks use TH for, so I thought I'd share. The only real solution I see other than TH or CPP would be if we had a JIT compiler, though I could still imagine cases where the staged version is better. [1] With good reason. It would be a bad idea to force many CAFs (e.g. lists of all Fibonacci numbers, or all primes), and deciding whether evaluation would finish is a pesky problem. Hence the need for a linguistic of metalinguistic way of telling the compiler it's okay. -- Live well, ~wren From manlio_perillo at libero.it Fri Jan 9 08:44:08 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Fri Jan 9 08:35:37 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> Message-ID: <496754A8.5060305@libero.it> Mauricio ha scritto: >> benchpress also uses System.CPUTime -- is > > that what you are looking for? > > I'm writing a program that will read medical signs > from many patients. It's important to have a precise > measure of the time interval between some signs, and > that can't depend on adjustments of time. (Supose > my software is running midnight at the end of a year > with leap seconds. I would get wrong time intervals.) > What precision do you need? On a recent POSIX platform you can use the real time clock: http://linux.die.net/man/2/clock_gettime http://www.opengroup.org/onlinepubs/009695399/functions/clock_getres.html CLOCK_MONOTONIC is what you need. > [...] Regards Manlio Perillo From wren at freegeek.org Fri Jan 9 08:50:10 2009 From: wren at freegeek.org (wren ng thornton) Date: Fri Jan 9 08:41:38 2009 Subject: [Haskell-cafe] Staged evaluation, names? In-Reply-To: <49674C14.9040401@freegeek.org> References: <49658049.8060107@freegeek.org> <8625cd9c0901081613ie216be5xbb54804920860e76@mail.gmail.com> <49674C14.9040401@freegeek.org> Message-ID: <49675612.2020702@freegeek.org> wren ng thornton wrote: > Andrea Vezzosi wrote: >> On Thu, Jan 8, 2009 at 5:25 AM, wren ng thornton >> wrote: >>> The question for y'all is what should I call it? I've been calling >>> the template-function qaf (for Compiled Applicative Form ;) and the >>> type class with that function would be the only thing in the package, >>> but I'm not sure where QAF.hs should be in the module hierarchy. >>> Thoughts? >> >> Isn't Lift[1] already the right class for this? >> >> class Lift t where >> lift :: t -> Q Exp >> >> [1] >> http://haskell.org/ghc/docs/latest/html/libraries/template-haskell/Language-Haskell-TH-Syntax.html#t%3ALift >> > > I don't see any documentation there to say what it does, so I'm not > sure. (A common problem with TH, unfortunately.) After hunting down the source code, yes it looks like Lift does the same thing as my code. (Though the Int instance looks like it's more liberal since it doesn't restrict the ExpQ to being an Int.) It'd be nice if the TH API had better documentation... -- Live well, ~wren From manlio_perillo at libero.it Fri Jan 9 08:57:02 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Fri Jan 9 08:48:52 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: <1ff5dedc0901090529q98d5593h44708c20be6184fb@mail.gmail.com> References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> <719973612.20090109161155@gmail.com> <1ff5dedc0901090529q98d5593h44708c20be6184fb@mail.gmail.com> Message-ID: <496757AE.7060904@libero.it> Cetin Sert ha scritto: > Don't know if it might help but: > http://en.wikipedia.org/wiki/RDTSC > cabal install rdtsc > http://hackage.haskell.org/packages/archive/rdtsc/1.1.1/doc/html/System-CPUTime-Rdtsc.html > Note that the use of RDTSC register has some issues on multicore CPU. More info at: http://en.wikipedia.org/wiki/Rdtsc Regards Manlio Perillo From briqueabraque at yahoo.com Fri Jan 9 09:06:49 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Fri Jan 9 08:58:29 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: <757539520.20090109163429@gmail.com> References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> <719973612.20090109161155@gmail.com> <1ff5dedc0901090529q98d5593h44708c20be6184fb@mail.gmail.com> <757539520.20090109163429@gmail.com> Message-ID: Both wikipedia and hackage rdtsc packages have lot of warnings regarding things I'm not able to control. It seems it doesn't work with many platforms, be it older or multi-core, hibernating computers. > yes, i mean this lib but forget its name :) thank you > >> Don't know if it might help but: >> http://en.wikipedia.org/wiki/RDTSC >> cabal install rdtsc >> http://hackage.haskell.org/packages/archive/rdtsc/1.1.1/doc/html/System-CPUTime-Rdtsc.html >> > >> computer has been turned on would do all I need. Or, > >> maybe, how much has elapsed since the program started. >> >> >> i think you should look into system counters (if you on windows). for >> example, task managet in vista shows time since reboot, i think that >> in registry it should be available in previous windowses too. at the >> cpu level, there is cpu ticks counter, it should be readable via >> special libraries From manlio_perillo at libero.it Fri Jan 9 09:26:05 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Fri Jan 9 09:17:33 2009 Subject: [Haskell-cafe] issues with posix-realtime package Message-ID: <49675E7D.9010909@libero.it> Hi. I'm testing the posix-realtime package, but I have found a problem. Configuration, build and install works well, but if I execute some code from ghci I get: GHCi runtime linker: fatal error: I found a duplicate definition for symbol __hsunix_wifexited whilst processing object file /usr/local/lib/posix-realtime-0.0.0.1/ghc-6.8.2/HSposix-realtime-0.0.0.1.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. If I comment the definition for __hsunix_wifexited, I get a duplicate definition for symbol pPrPr_disableITimers, and so on, for all the definitions in HsUnix.h and execvpe.h Thanks Manlio Perillo From john at n-brain.net Fri Jan 9 09:46:09 2009 From: john at n-brain.net (John A. De Goes) Date: Fri Jan 9 09:37:37 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> <1231454154-sup-7772@existential.local> Message-ID: <0AFF36A6-DF7F-40E7-9CF3-C2E2E08DEA5C@n-brain.net> Hi Austin, How do you know it's not your experience with FFI code that isn't biased? As far as I know, there has been no systematic attempt to document whether pure Haskell or FFI-based libraries are better designed and better maintained. Which means your statements come from your experience, and my statements come from my experience, and the truth is probably somewhere in between. In my experience, FFI code is often based on bulk translation of C header files into the IO monad. It requires an exact version of a library to work (usually much older than the current), it does not compile out of the box, there's scant documentation, and very little high-level design has been imposed on the low-level C interface (may as well use C!). Exceptions to this rule, there are, but as I said before, my experience leads me to believe they *are* exceptions to a *general* rule. Regards, John On Jan 8, 2009, at 3:47 PM, Austin Seipp wrote: > Excerpts from John A. De Goes's message of Thu Jan 08 12:14:18 -0600 > 2009: >> But really, what's the point? FFI code is fragile, often uncompilable >> and unsupported, and doesn't observe the idioms of Haskell nor take >> advantage of its powerful language features. > > This is a completely unfair generalization. The FFI is an excellent > way to interoperate with an extraordinary amount of external > libraries, and if you ask me, it's *worth* taking those pieces of C > code and wrapping them up in a nice, safe haskell interface. I will > also > mention that Haskell has *the* simplest FFI I have ever used, which to > me only means it's easier to get it right (the fact that there are > customized *languages* like e.g. cython to make writing python > extensions easier makes me wonder.) > > I suggest you take a look at the haskell llvm bindings - they are > extraordinarily well documented, and the high level interface uses > *many* haskell idioms that make the library safe and easy to use: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ > llvm-0.4.2.0 > > This code most certainly takes advantage of powerful features and > idioms that only Haskell can provide. Please do not take your bad > experiences with a few crappy binding (or not even crappy bindings, > perhaps bindings that just aren't very abstract) and extend them to > the bindings that are excellent with a sweeping statement like that. > > Austin > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090109/25fefe79/attachment.htm From john at n-brain.net Fri Jan 9 09:46:22 2009 From: john at n-brain.net (John A. De Goes) Date: Fri Jan 9 09:37:50 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <4438705C-9069-4780-B6A9-7E928997D6EA@n-brain.net> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> <20090108221549.GA30539@hustlerturf.com> <4438705C-9069-4780-B6A9-7E928997D6EA@n-brain.net> Message-ID: My statements refer not to the FFI, but as I said, to "FFI code". FFI- based libraries seldom compile without excessive amounts of work, they're often poorly documented, and in general they seem to be maintained much less than pure Haskell libraries. The FFI is necessary, of course, but in general I view it as a bootstrapping process leading to pure Haskell libraries -- a crutch you have to live with until you can afford to pay the price of walking. Regards, John On Jan 8, 2009, at 3:15 PM, John Goerzen wrote: > On Thu, Jan 08, 2009 at 11:14:18AM -0700, John A. De Goes wrote: >> But really, what's the point? FFI code is fragile, often uncompilable >> and unsupported, and doesn't observe the idioms of Haskell nor take >> advantage of its powerful language features. Rather than coding >> through > > That is an extraordinarily cruel, and inaccurate, sweep of FFI. > > I've worked with C bindings to several high-level languages, and I > must say that I like FFI the best of any I've used. It's easy to use > correctly, stable, and solid. If anything, it suffers from > under-documentation. > > The whole point of FFI is to bring other languages into the Haskell > fold. So you can, say, talk to a database using its C library and > wind up putting the strongly-typed HaskellDB atop it. Or you can > write an MD5 algorithm in C and make it look like a regular Haskell > function. > >> You can indeed fit a square peg in a round hole, if you pound hard >> enough. That doesn't mean it's a good thing to do. > > And with that, I fully agree. > > -- Joh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090109/9ee30510/attachment.htm From john at n-brain.net Fri Jan 9 09:46:38 2009 From: john at n-brain.net (John A. De Goes) Date: Fri Jan 9 09:38:12 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <5FEAB935-8572-4595-87C9-CF9C90A4C512@n-brain.net> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <5FEAB935-8572-4595-87C9-CF9C90A4C512@n-brain.net> Message-ID: > On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote: >> >> The number of applications requiring the implementation of a custom >> web >> server is an insignificant fraction of the number of applications >> requiring a messaging system. I don't think anyone would dispute >> Haskell's ability to do low-level, raw networking, of the type that >> few >> people actually need to do. It's the higher level stuff where >> there's a >> huge amount of room for improvement. > > I disagree on both points. > > Haskell has had somewhat of a deficit in the low-level networking > stuff, not even supporting IPv6 in the standard stack until just > recently. (That is, things like AF_INET6 were not present.) > > I think it has pretty much caught up by now though. If you think Haskell has caught up by now, then you DO NOT disagree with my statement that "[no one] would dispute Haskell's ability to do low-level, raw networking." Which makes me wonder what you mean by, "I disagree on both points." > On the other hand, I see nothing in Haskell that would prevent its use > for any of your purposes. There are numerous high-level web > infrastructures already. Perhaps they are more or less suited to your > needs, but that's a library issue, not a language issue. In other words, to quote myself, "it's the higher level stuff where there's a huge amount of room for [library] improvement." Nothing in the Haskell language prevents its use for high-level networking. But the sad fact of the matter is that there is no library support for it. So applications that need such networking today are better off written in Erlang. Regards, John From john at n-brain.net Fri Jan 9 09:46:56 2009 From: john at n-brain.net (John A. De Goes) Date: Fri Jan 9 09:38:24 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <30D797FA-F5B8-4267-8E16-33DF9C2BA3AD@n-brain.net> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <814617240901081216t7232b5b6u884efd6e2b0bad40@mail.gmail.com> <30D797FA-F5B8-4267-8E16-33DF9C2BA3AD@n-brain.net> Message-ID: If you're looking for a project to take on, I would suggest starting with the following: A high-level, type-safe AMQP client written in 100% Haskell, which provides a clean way of handling hundreds of unique message types. Then it would be possible to hook it up to any AMQP broker (most likely RabbitMQ). There are logical steps beyond the above (an embedded Haskell broker), but the above project is far from trivial. And the main undertaking, I think, consists not in coding to the spec (for which there is some help; a JSON representation of the AMQP specification can be processed and used to emit language-specific code), but in finding a design that works well in Haskell. Regards, John On Jan 8, 2009, at 1:16 PM, Creighton Hogg wrote: > On Thu, Jan 8, 2009 at 2:02 PM, John A. De Goes > wrote: >> >> On Jan 8, 2009, at 12:56 PM, Tim Newsham wrote: >>> >>> You replied to someone discussing using Haskell at a CDN to >>> implement >>> things like web servers by saying that Haskell wasn't suitable for >>> the task. >> >> >> That is incorrect. I replied to Achim's message asking for >> elaboration on >> Haskell's unsuitability. It was a convenient point to discuss >> Haskell's >> networking deficiencies. > > Part of the problem I'm having with this discussion, though, is that > it's still not clear to me what critical features are lacking. I know > you've said Haskell doesn't have anything quite like the Erlang OTP > library, but that doesn't really help me much. I've only looked a > little at OTP & I don't think I understand what you get from its > behaviors that you don't get from Control.Concurrent + mtl, i.e. > various forms of state & error handling independent of the concurrency > underneath. > > Can you elucidate a bit more? I don't want the conversation to > degenerate. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090109/474a0231/attachment.htm From john at n-brain.net Fri Jan 9 09:48:02 2009 From: john at n-brain.net (John A. De Goes) Date: Fri Jan 9 09:39:29 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> Message-ID: <21F061BF-6A3D-4169-ABC1-6928F63CF3C4@n-brain.net> You must be referring to "erlang-0.1", an alpha release of a package that impersonates an Erlang node. Which is surely useful to someone, somewhere, but is not useful to write a messaging application. Regards, John On Jan 8, 2009, at 4:17 PM, Bryan O'Sullivan wrote: > On Thu, Jan 8, 2009 at 10:06 AM, Don Stewart wrote: > Note that there even exists an FFI binding to Erlang for Haskell, so > that Haskell nodes can seamlessly interact with other nodes speaking > Erlang's protocol format. > > Actually, the erlang package doesn't use the FFI: it speaks the > Erlang wire protocol to send and receive terms. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090109/705f6348/attachment.htm From john at n-brain.net Fri Jan 9 09:54:06 2009 From: john at n-brain.net (John A. De Goes) Date: Fri Jan 9 09:45:34 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49666B19.8040500@libero.it> Message-ID: On Jan 8, 2009, at 4:34 PM, Bryan O'Sullivan wrote: > I actually think that we're very close to being in fantastic shape > here. I think that's Haskell zeal speaking. :-) Not that I don't appreciate your zeal (I do), and I'm definitely excited about the stuff you're working on, but we're a long way from having stable, mature, well-designed libraries that are fit for production use in high-level messaging applications. In this niche (and quite a few other networking-related niches), Erlang is the clear winner, at least for the immediate future (in the long-term, the purity of Haskell could lead to some high-performance, robust approaches not possible for Erlang). Regards, John From leimy2k at gmail.com Fri Jan 9 10:11:29 2009 From: leimy2k at gmail.com (David Leimbach) Date: Fri Jan 9 10:02:56 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <496742D4.3000909@libero.it> References: <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49666B19.8040500@libero.it> <496742D4.3000909@libero.it> Message-ID: <3e1162e60901090711u4a4dfe68t36329bf553474bea@mail.gmail.com> > > > So, if I need to write *now* a network application, should I *invest* in > Haskell, or should I just *use* Erlang? You're in Haskell-Cafe... the bias is there already for Haskell. Personally, I don't have experience doing network applications in Haskell, but I've got about a year's worth or more using Erlang, so for me it's a pretty easy choice, and I wouldn't pick Haskell today. (hearing boos in the background as I type this...) However, I would invest in learning to use Haskell, because my experience with Erlang has been that it really is pretty great, and has lovely features, like the ability to shell into a running process and poke around if something seems not quite right, or even to ssh into it if you run the right services. Plus there's tons of stuff pre-written for network applications that just comes with the Erlang distribution, meaning there's nothing else to install.... but even after all of that, I miss the type safety of Haskell, as it's really painful to do this in erlang function(T1, T2, T3) when is_list(T1) and is_integer(T2) and is_integer(T3) -> ....function body Even if you have a list, you don't know "what of" so you never really get the guarantees that you get when a Haskell program successfully compiles... That peace of mind is not easily won in Erlang, except by lots of testing. Dave > > > As a counter example: I really don't like SQL. > However I have to use it, if I don't want to re-implement a database by > myself. > The same can be said with Fortran. > > > [...] > > > Regards Manlio > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090109/5e966d84/attachment.htm From steve at fenestra.com Fri Jan 9 10:17:40 2009 From: steve at fenestra.com (Steve Schafer) Date: Fri Jan 9 10:09:07 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> Message-ID: <94oem4hfiqaskk4pdc5mn3d05l8p4hh6cf@4ax.com> On Fri, 09 Jan 2009 11:01:18 -0200, you wrote: >I'm writing a program that will read medical signs >from many patients. It's important to have a precise >measure of the time interval between some signs, and >that can't depend on adjustments of time. (Supose >my software is running midnight at the end of a year >with leap seconds. I would get wrong time intervals.) If you really need that level of accuracy, there is nothing available on an off-the-shelf machine that will do the job. You need an independent timekeeping source of some kind, one that is not subject to the vagaries of reboots and other upsets. Perhaps the simplest and least expensive of these is a computer-compatible GPS time receiver. Since GPS works on GPS time (which has a constant offset from International Atomic Time), rather than UTC, you avoid having to deal with leap seconds and the like. I haven't tried doing it myself, but I know that most recent-vintage GPS units have a computer interface over which you can download the current GPS time from the device. There are many other kinds of GPS time receivers available, including ones that plug directly into a PC slot. Here's one that I found using a Google search on "GPS time receiver": http://www.franklinclock.com/gps_receivers.htm The prices range anywhere from a couple of hundred dollars for consumer-grade equipment to many thousands for high-reliability devices. The only drawback to this approach that I can think of is if the hospital is in an urban area with lots of tall buildings, it might be difficult to obtain a GPS signal of high enough quality. Some of the purpose-built GPS time receivers have better antennas than a consumer-grade GPS device. Steve Schafer Fenestra Technologies Corp http://www.fenestra.com/ From jgoerzen at complete.org Fri Jan 9 10:23:27 2009 From: jgoerzen at complete.org (John Goerzen) Date: Fri Jan 9 10:14:53 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> <20090108221549.GA30539@hustlerturf.com> <4438705C-9069-4780-B6A9-7E928997D6EA@n-brain.net> Message-ID: <49676BEF.9050005@complete.org> John A. De Goes wrote: > > My statements refer not to the FFI, but as I said, to "FFI code". > FFI-based libraries seldom compile without excessive amounts of work, > they're often poorly documented, and in general they seem to be Examples? I maintain a couple of FFI libraries, and strive to have them just work with one line of calling cabal. There are plenty of other FFI libraries that also work that way. In fact, I don't really notice a difference these days, at least with the FFI libraries I've used. In any case, apt-get usually grabs stuff I want anyhow. I don't really see why the underlying details of an implementation (C or Haskell) would necessarily correlate with levels of documentation, and it doesn't seem to for me anyhow. > maintained much less than pure Haskell libraries. The FFI is necessary, > of course, but in general I view it as a bootstrapping process leading > to pure Haskell libraries -- a crutch you have to live with until you > can afford to pay the price of walking. Well, you pretty much always have to get down to the C level on a *nix platform at some point, anyhow. You've got to make syscalls somewhere. I don't think FFI is so evil. There is value in avoiding wheel reinvention, too. If zlib already works great, why re-invent it when you can easily just use what's there? -- John From jgoerzen at complete.org Fri Jan 9 10:28:49 2009 From: jgoerzen at complete.org (John Goerzen) Date: Fri Jan 9 10:20:21 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: <94oem4hfiqaskk4pdc5mn3d05l8p4hh6cf@4ax.com> References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> <94oem4hfiqaskk4pdc5mn3d05l8p4hh6cf@4ax.com> Message-ID: <49676D31.1090207@complete.org> Steve Schafer wrote: > On Fri, 09 Jan 2009 11:01:18 -0200, you wrote: > >> I'm writing a program that will read medical signs >>from many patients. It's important to have a precise >> measure of the time interval between some signs, and >> that can't depend on adjustments of time. (Supose >> my software is running midnight at the end of a year >> with leap seconds. I would get wrong time intervals.) > > If you really need that level of accuracy, there is nothing available on > an off-the-shelf machine that will do the job. You need an independent > timekeeping source of some kind, one that is not subject to the vagaries I'm not sure that the original question implied *that* level of need. Linux has High-Resolution Timers (HRTs) that may be appropriate. See the manpage for clock_gettime(), which defines these HRTs: CLOCK_REALTIME System-wide real-time clock. Setting this clock requires appropriate privi- leges. CLOCK_MONOTONIC Clock that cannot be set and represents monotonic time since some unspeci- fied starting point. CLOCK_PROCESS_CPUTIME_ID High-resolution per-process timer from the CPU. CLOCK_THREAD_CPUTIME_ID Thread-specific CPU-time clock. CLOCK_MONOTONIC, in particular, looks suitable. Using it could be a matter of just a few quick likes in FFI. I don't know if Windows has similar features. -- John From jgoerzen at complete.org Fri Jan 9 10:31:56 2009 From: jgoerzen at complete.org (John Goerzen) Date: Fri Jan 9 10:23:23 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety In-Reply-To: <87hc48zv9g.fsf@nitai.hr> References: <87eizkra83.fsf@nitai.hr> <20090108030656.GA4430@complete.org> <87hc48zv9g.fsf@nitai.hr> Message-ID: <49676DEC.9070208@complete.org> Gour wrote: > John> HDBC is a low-level abstraction, which can be used on its own or, > John> of course, as a layer underlying HaskellDB or some such. I do not > John> dispute the use of tools such as HaskellDB or others that try to > John> automate the business of representing a database's schema -- and > John> queries against it -- using a language's type system. There are a > John> lot of these systems in a lot of languages. I've used some of > John> them. > > Have you maybe tried Takusen (HaskellDB which you reference above does > not seem very much alive)? No, I haven't, unfortunately. > Otoh, I believe that, considering it is mentioned in RWH, HDBC does not > need much commercial, just contrary, you can expect new feature requests > From the new army of Haskell developers cultivated by the book :-) That's great. Even better if accompanied by a patch ;-) > I'll e.g. open ticket for BLOB support :-D Of course :-) > Database abstraction offered by HDBC is very nice feature allowing one > to change back-end driver without too much hassle, so I'll try to > investigate a bit about possible BLOB support on HDBC-level. That would be wonderful. > It's definitely something used in real-world databases... Yes, I'm quite aware of that. Just not *my* particular ones ;-) -- John From thomas.dubuisson at gmail.com Fri Jan 9 10:38:39 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Fri Jan 9 10:30:13 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <814617240901081216t7232b5b6u884efd6e2b0bad40@mail.gmail.com> <30D797FA-F5B8-4267-8E16-33DF9C2BA3AD@n-brain.net> Message-ID: <4c44d90b0901090738u4620ebb5g7ff97a178ef24d01@mail.gmail.com> John A. De Goes said: > If you're looking for a project to take on, I would suggest starting with [AMQP] See: http://www.reddit.com/r/haskell_proposals/comments/7ihpt/amqp_client/ This isn't a new proposal, not to imply you thought so. If you have a need for such a library please start working or start a team. Short of that, expressing your interest (or perhaps subsequent projects requiring AMQP) in our somewhat new "Proposed Projects" reddit community might draw attention to this cause. Tom From manlio_perillo at libero.it Fri Jan 9 10:45:40 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Fri Jan 9 10:37:20 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: <49676D31.1090207@complete.org> References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> <94oem4hfiqaskk4pdc5mn3d05l8p4hh6cf@4ax.com> <49676D31.1090207@complete.org> Message-ID: <49677124.7010407@libero.it> John Goerzen ha scritto: > Steve Schafer wrote: >> On Fri, 09 Jan 2009 11:01:18 -0200, you wrote: >> >>> I'm writing a program that will read medical signs >> >from many patients. It's important to have a precise >>> measure of the time interval between some signs, and >>> that can't depend on adjustments of time. (Supose >>> my software is running midnight at the end of a year >>> with leap seconds. I would get wrong time intervals.) >> If you really need that level of accuracy, there is nothing available on >> an off-the-shelf machine that will do the job. You need an independent >> timekeeping source of some kind, one that is not subject to the vagaries > > I'm not sure that the original question implied *that* level of need. > > Linux has High-Resolution Timers (HRTs) that may be appropriate. See > the manpage for clock_gettime(), which defines these HRTs: > > [...] > > CLOCK_MONOTONIC, in particular, looks suitable. Using it could be a > matter of just a few quick likes in FFI. > There is also an available package on Hackage: posix-realtime. > I don't know if Windows has similar features. > http://msdn.microsoft.com/en-us/library/ms632592(VS.85).aspx and QueryPerformanceCounter, in detail. Unfortunately, documentation is really bad, and it is not really clear what "high-resolution performance counter" means. > -- John Manlio Perillo From cetin.sert at gmail.com Fri Jan 9 10:53:01 2009 From: cetin.sert at gmail.com (Cetin Sert) Date: Fri Jan 9 10:44:56 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: <49676D31.1090207@complete.org> References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> <94oem4hfiqaskk4pdc5mn3d05l8p4hh6cf@4ax.com> <49676D31.1090207@complete.org> Message-ID: <1ff5dedc0901090753s4c9e385ai9d1684cece898690@mail.gmail.com> Here's a basic draft project for clock_gettime(CLOCK_MONOTONIC, ...) http://sert.homedns.org/hs/mnsec/ http://sert.homedns.org/hs/mnsec/dist/mnsec-1.0.0.tar.gz It could be extended to cover other clock types than just monotonic. Regards, CS 2009/1/9 John Goerzen > Steve Schafer wrote: > > On Fri, 09 Jan 2009 11:01:18 -0200, you wrote: > > > >> I'm writing a program that will read medical signs > >>from many patients. It's important to have a precise > >> measure of the time interval between some signs, and > >> that can't depend on adjustments of time. (Supose > >> my software is running midnight at the end of a year > >> with leap seconds. I would get wrong time intervals.) > > > > If you really need that level of accuracy, there is nothing available on > > an off-the-shelf machine that will do the job. You need an independent > > timekeeping source of some kind, one that is not subject to the vagaries > > I'm not sure that the original question implied *that* level of need. > > Linux has High-Resolution Timers (HRTs) that may be appropriate. See > the manpage for clock_gettime(), which defines these HRTs: > > CLOCK_REALTIME > System-wide real-time clock. Setting this clock requires > appropriate privi- > leges. > > CLOCK_MONOTONIC > Clock that cannot be set and represents monotonic time > since some unspeci- > fied starting point. > > CLOCK_PROCESS_CPUTIME_ID > High-resolution per-process timer from the CPU. > > CLOCK_THREAD_CPUTIME_ID > Thread-specific CPU-time clock. > > CLOCK_MONOTONIC, in particular, looks suitable. Using it could be a > matter of just a few quick likes in FFI. > > I don't know if Windows has similar features. > > -- John > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090109/f13c5992/attachment-0001.htm From mail at joachim-breitner.de Fri Jan 9 10:56:10 2009 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri Jan 9 10:47:16 2009 Subject: [Haskell-cafe] advanced class constraints in Haskell 98? In-Reply-To: References: <22CE9CB9-AC08-4214-8DFC-E271F758F6EF@yandex.ru> Message-ID: <1231516570.3864.4.camel@localhost> Hi, Am Donnerstag, den 08.01.2009, 22:22 +0100 schrieb Henning Thielemann: > > On 8 Jan 2009, at 23:59, Henning Thielemann wrote: > > From Report: > A nice. I jumped into 4.3 and found > > ? ? R 32 ? > ? 6 > ? ? 32 ? R ? ? ? > > 7 > > ? ? ? 7 > > 5? ? ? > class > => where > ? > > ? ? ? ? > ? ? ? 2 ? > 6 > ? R? > 7 now how about this for a good argument that Haskell is just line noise. :-) Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090109/f4ee45b9/attachment.bin From wchogg at gmail.com Fri Jan 9 11:01:54 2009 From: wchogg at gmail.com (Creighton Hogg) Date: Fri Jan 9 10:53:21 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <814617240901081216t7232b5b6u884efd6e2b0bad40@mail.gmail.com> <30D797FA-F5B8-4267-8E16-33DF9C2BA3AD@n-brain.net> Message-ID: <814617240901090801n955808oe3cc74ee8c42e470@mail.gmail.com> 2009/1/9 John A. De Goes : > > If you're looking for a project to take on, I would suggest starting with > the following: > > A high-level, type-safe AMQP client written in 100% Haskell, which provides > a clean way of handling hundreds of unique message types. > > Then it would be possible to hook it up to any AMQP broker (most likely > RabbitMQ). There are logical steps beyond the above (an embedded Haskell > broker), but the above project is far from trivial. And the main > undertaking, I think, consists not in coding to the spec (for which there is > some help; a JSON representation of the AMQP specification can be processed > and used to emit language-specific code), but in finding a design that works > well in Haskell. I apologize, but my question was geared more towards understanding what high-level OTP-like libraries Haskell is lacking, not full blown applications that haven't been written in Haskell. It sounded like you had some specific insight into this. Cheers, Creighton From agocorona at gmail.com Fri Jan 9 11:49:44 2009 From: agocorona at gmail.com (Alberto G. Corona ) Date: Fri Jan 9 11:41:13 2009 Subject: [Haskell-cafe] ANNOUNCE: Data.TCache 0.5.5 Message-ID: The main addition of this versi?n is the capablity to safely handle transact, and serialize to permanent storage many datatypes simultaneously in the same piece of code and incrementally. Just register each new datatype (with registerType :: ). So it is not necessary to glue all types in advance in a single algebraic datatype. I suppose taht "enhanced composablility" applies to this feature. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/TCache In this release: Added a Data.TCache.Dynamic. (SEE dynamicsample.hs) - Can handle, transact, and serialize to disk many datatypes simultaneously and incrementally - Dynamic uses the same interface than TCache and add *DResource(s) calls for handling many datatypes simultaneously - Safe dynamic data handling trough a lighter, indexable and serializable version of Data.Dynamic - Added KEY object for retrieving any object of any type. Data.Tcache is a transactional cache with configurable persistence. It tries to simulate Hibernate for Java or Rails for Ruby. The main difference is that transactions are done in memory trough STM. There are transactional cache implementations for some J2EE servers like JBOSS. TCache uses STM. It can atomically apply a function to a list of cached objects. The resulting objects go back to the cache (withResources). It also can retrieve these objects (getResources). Persistence can be syncronous (syncCache) or asyncronous, wtih configurable time between cache writes and configurable cache clearance strategy. the size of the cache can be configured too . All of this can be done trough clearSyncCacheProc. Even the TVar variables can be accessed directly (getTVar) to acceess all the semantic of atomic blocks while maintaining the persistence of the TVar updates. Persistence can be defined for each object: Each object must have a defined key, a default filename path (if applicable). Persistence is pre-defined in files, but the readResource writeResource and delResource methods can be redefined to persist in databases or whatever. There are Samples in the package that explain the main features. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090109/30f88266/attachment.htm From aslatter at gmail.com Fri Jan 9 11:57:58 2009 From: aslatter at gmail.com (Antoine Latter) Date: Fri Jan 9 11:49:25 2009 Subject: [Haskell-cafe] ANNOUNCE: X Haskell Bindings Message-ID: <694519c50901090857x4b3931d4pb891ed1d7f6a66bd@mail.gmail.com> Folks, I'd like to announce a preview-release of the X Haskell Bindings. The goal of the library is to provide low-level access to the X11 protocol, in the spirit of the X C Bindings This is a "preview" because I expect that the interface will still need to change - but I do plan on bump the minor-version number when that happens. On Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xhb What works: All X protocol requests have corresponding functions. I haven't tested all of them. Requests are sent asynchronously - the caller is not blocked until they need to examine the result of the request Errors and Events are unpacked into Haskell data types It should be safe to use the same connection in multiple threads What needs improvement: * There's no documentation - you pretty much need to be sitting down with the X Protocol reference while using this library. Once we can get documentation into the XML that this library is generated from, we should be able to generate Haddock documentation at the same time * A lot of parameters are specified using integer types, even though a proper Haskell enum-like data type exists. * Many functions take a ValueParam argument, which is not fun to work with in a language like Haskell. I have plans for how to make these more type-safe, but this is something else that requires more information in the XML protocol descriptions. * There's no way to share a connection between XHB and libraries built against the Xlib bindings. * I haven't done any benchmarking, so it's possible that all of this is pretty slow. Keep in mind that this is a library for the X Protocol - it alone is not a replacement for XLib - XLib does a lot more than pushing and pulling on a file-handle. Related releases: Spencer Janssen has released FFI bindings to Xauth: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Xauth-0.1 I've released a small library for determining the byte-ordering of the system: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/byteorder-1.0.0 Related projects: X C Bindings: http://xcb.freedesktop.org/ -Antoine From niklas.broberg at gmail.com Fri Jan 9 12:38:15 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Fri Jan 9 12:29:40 2009 Subject: [Haskell-cafe] ANNOUNCE: haskell-src-exts 0.4.8 In-Reply-To: <49673B15.5010906@cs.nott.ac.uk> References: <49673B15.5010906@cs.nott.ac.uk> Message-ID: Thanks all for the suggestions! VIM and I have never gone together well, probably mostly my fault I know. Maybe some day... Emacs isn't my favorite either. I do have Notepad++, but it only seems to support a small portion of the unicode I need. Normally I use TextPad, but it wouldn't show me any of the symbols I need, even though it supposedly should read the document as Unicode. But regardless of I find an editor I could use, NAD's suggestion is really the best: >> - Support for Unicode symbols for e.g. ->. Fixing that would require >> me to have a Unicode-compliant editor > > Can't you just use character literals like '\x2192'? Doh, of course! That's not only the simplest but also clearly the most portable solution, since then I (and others looking at the code) could use whatever editor I like. Thanks NAD! :-) Cheers, /Niklas From jonathanccast at fastmail.fm Fri Jan 9 12:47:40 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Fri Jan 9 12:39:08 2009 Subject: [Haskell-cafe] ANNOUNCE: haskell-src-exts 0.4.8 In-Reply-To: References: <49673B15.5010906@cs.nott.ac.uk> Message-ID: <1231523260.5861.0.camel@jcchost> On Fri, 2009-01-09 at 18:38 +0100, Niklas Broberg wrote: > Thanks all for the suggestions! > > VIM and I have never gone together well, probably mostly my fault I > know. Maybe some day... Emacs isn't my favorite either. I do have > Notepad++, but it only seems to support a small portion of the unicode > I need. Normally I use TextPad, but it wouldn't show me any of the > symbols I need, even though it supposedly should read the document as > Unicode. Isn't this a fonts issue? jcc From andrewcoppin at btinternet.com Fri Jan 9 13:18:12 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri Jan 9 13:49:57 2009 Subject: [Haskell-cafe] Low-level networking [Haskell not ready for Foo] In-Reply-To: <4c44d90b0901081635u69f9a1ffx5aa2e7fcdd946c03@mail.gmail.com> References: <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49667026.9060702@btinternet.com> <49668330.2000701@complete.org> <4c44d90b0901081635u69f9a1ffx5aa2e7fcdd946c03@mail.gmail.com> Message-ID: <496794E4.5030700@btinternet.com> Thomas DuBuisson wrote: > Not all the data structures you need are there last I looked. This was my conclusion as well. As with most network libraries I've seen, TCP works just great, and anything else... tough? (I couldn't even see UDP last time. Have I missed something?) > As you > could infer from my recent posts, one of my dozen future projects is > to add netinet/*.h like data structures to the Haskell network library > (i.e. TCP, IPv4, UDP headers with Binary instances). This isn't to > say your task would be much more difficult, but it would be nice to > have a community wide definition available. > That would, indeed, be nice. From andrewcoppin at btinternet.com Fri Jan 9 13:20:18 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri Jan 9 13:50:05 2009 Subject: [Haskell-cafe] Re: Low-level networking [Haskell not ready for Foo] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49667026.9060702@btinternet.com> <49668330.2000701@complete.org> Message-ID: <49679562.5060508@btinternet.com> Dominic Steinitz wrote: > John Goerzen complete.org> writes: > >>> Any idea how I get Haskell to send ICMP ECHO packets? (And, obviously, >>> receive the replies.) >>> >> SocketType claims to support Raw, which I think is the conventional >> means for doing this. Whether all the infrastructure for that is there, >> I don't know. I have never worked with raw sockets though, so I may be >> leading you down a dark mugger-laden alley here >> > > Here's an example of a Haskell version of ping, now sadly bit-rotted. > > Dominic. > > http://haskell.org/networktools/src/ping/test.hs > I have a worrying feeling this might be too Unix-specific to work on Windows. But I guess it's a start... From vanenkj at gmail.com Fri Jan 9 14:04:08 2009 From: vanenkj at gmail.com (John Van Enk) Date: Fri Jan 9 13:55:35 2009 Subject: [Haskell-cafe] Low-level networking [Haskell not ready for Foo] In-Reply-To: <496794E4.5030700@btinternet.com> References: <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49667026.9060702@btinternet.com> <49668330.2000701@complete.org> <4c44d90b0901081635u69f9a1ffx5aa2e7fcdd946c03@mail.gmail.com> <496794E4.5030700@btinternet.com> Message-ID: I've managed to get UDP NAT traversal working in my personal project. I haven't really had issues with the Networking libraries at all (except that htons and htonl aren't where i expected them to be... and yes, i did actually need them...) /jve On Fri, Jan 9, 2009 at 1:18 PM, Andrew Coppin wrote: > Thomas DuBuisson wrote: > >> Not all the data structures you need are there last I looked. >> > > This was my conclusion as well. > > As with most network libraries I've seen, TCP works just great, and > anything else... tough? (I couldn't even see UDP last time. Have I missed > something?) > > As you >> could infer from my recent posts, one of my dozen future projects is >> to add netinet/*.h like data structures to the Haskell network library >> (i.e. TCP, IPv4, UDP headers with Binary instances). This isn't to >> say your task would be much more difficult, but it would be nice to >> have a community wide definition available. >> >> > > That would, indeed, be nice. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090109/c8c7ad8c/attachment.htm From dons at galois.com Fri Jan 9 14:22:11 2009 From: dons at galois.com (Don Stewart) Date: Fri Jan 9 14:13:21 2009 Subject: [Haskell-cafe] Re: concurrent haskell: thread priorities In-Reply-To: <49671A87.1040401@gmail.com> References: <4c44d90b0812221442p2933e84dl90c81bb2f986dd3c@mail.gmail.com> <49671A87.1040401@gmail.com> Message-ID: <20090109192211.GJ25701@scytale.galois.com> marlowsd: > Neal Alexander wrote: > >Thomas DuBuisson wrote: > >> It seems like we could get some priority based scheduling (and still > >> be slackers) if we allow marked green threads to be strictly > >> associated with a specific OS thread (forkChildIO?). > >> > >> > >>I think you want the GHC-only GHC.Conc.forkOnIO > >> > >GHC.Conc.forkOnIO is helpful but doest work in this case - it doesn't > >attach them to the same OS thread. > > But it does attach the thread to a particular "virtual CPU" in the GHC RTS > (we call them "capabilities"), with the intention that a virtual CPU > corresponds more or less to a real CPU core. Every time Simon responds on questions of parallelism and the GHC runtime, I learn something. That indicates to me that we've got a 'bus error' situation with how to effectively use the smp runtime. Simon: time for a multicore FAQ wiki page to gather this knowledge, like we did for the performance tips? Somewhere to paste these insights? -- Don From briqueabraque at yahoo.com Fri Jan 9 14:45:06 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Fri Jan 9 14:37:22 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety In-Reply-To: <87eizkra83.fsf@nitai.hr> References: <87eizkra83.fsf@nitai.hr> Message-ID: > However options in d) do not offer, afaik, type-safety which is emblem of > Haskell language, so I wonder how much this could be the problem for > real-world usage? I've been doing a lot of low level sqlite3 lately (it's going to be on a hackage package as soon as I finish my current work). As long as I clearly isolate and test the marshalling of my data to SQL and back, my (personal, probably different from yours) experience using just sqlite3_exec has never got me into trouble. Best, Maur?cio From anishmuttreja at gmail.com Fri Jan 9 15:04:16 2009 From: anishmuttreja at gmail.com (Anish Muttreja) Date: Fri Jan 9 14:55:43 2009 Subject: [Haskell-cafe] Possible GC bug Message-ID: <2f0f9f340901091204v358d33bcs3974d349a483cf15@mail.gmail.com> Hi, I have a program that seems to run into occasional garbage collection-related core dumps. The problem typically only occurs after the program has been running for a while and is consuming a large amount of memory (5 - 16GB). The large memory consumption is expected because the program analyzes very large traces from verilog simulation and needs to maintain IntMaps with hundreds of thousands of entries. Is this a bug that I should report?I am afraid that my employer will not allow me to share my source code. I do have a stack trace, below. This was obtained using ghc 6.10.1, RTS -N2 on an RHEL 4 machine. Is there something I can do trace the problem or avoid it? Thanks. PS: This is my first Haskell program and one of the most complicated I ever wrote, in any language. Using Haskell has been (mostly :-)) a joy. (gdb) where #0 0x0000000000612f40 in slowIsHeapAlloced () #1 0x000000000060f868 in evacuate () #2 0x0000000000618d12 in scavenge_block () #3 0x0000000000617c8d in scavenge_loop () #4 0x0000000000610b25 in scavenge_until_all_done () #5 0x0000000000610d02 in gc_thread_entry () #6 0x000000000064859d in start_thread (arg=) at pthread_create.c:297 #7 0x000000000069e739 in clone () #8 0x0000000000000000 in ?? () -- As an adolescent I aspired to lasting fame, I craved factual certainty, and I thirsted for a meaningful vision of human life - so I became a scientist. This is like becoming an archbishop so you can meet girls. -Matt Cartmill, anthropology professor and author (1943- ) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090109/bda9bc8c/attachment.htm From briqueabraque at yahoo.com Fri Jan 9 15:32:14 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Fri Jan 9 15:23:48 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: <49677124.7010407@libero.it> References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> <94oem4hfiqaskk4pdc5mn3d05l8p4hh6cf@4ax.com> <49676D31.1090207@complete.org> <49677124.7010407@libero.it> Message-ID: >> Linux has High-Resolution Timers (HRTs) that may be appropriate. See >> the manpage for clock_gettime(), which defines these HRTs: >> [...] >> CLOCK_MONOTONIC, in particular, looks suitable. Using it could be a >> matter of just a few quick likes in FFI. >> >> I don't know if Windows has similar features. >> > > http://msdn.microsoft.com/en-us/library/ms632592(VS.85).aspx > and QueryPerformanceCounter, in detail. > Going from GetProcessTimes, which I found in ghc code in libraries/base/System/CPUTime.hsc, I was just able to find this in that same site: http://msdn.microsoft.com/en-us/library/ms724408(VS.85).aspx Seems simpler. Since linux (and unix?) have clock_gettime and windows has this GetTickCount, maybe it could be possible to add getSystemCPUTime to System.CPUTime. Thanks, Maur?cio From jgoerzen at complete.org Fri Jan 9 15:42:59 2009 From: jgoerzen at complete.org (John Goerzen) Date: Fri Jan 9 15:34:25 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <0AFF36A6-DF7F-40E7-9CF3-C2E2E08DEA5C@n-brain.net> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> <1231454154-sup-7772@existential.local> <0AFF36A6-DF7F-40E7-9CF3-C2E2E08DEA5C@n-brain.net> Message-ID: <4967B6D3.2020001@complete.org> John A. De Goes wrote: > > Hi Austin, > > How do you know it's not your experience with FFI code that isn't > biased? As far as I know, there has been no systematic attempt to > document whether pure Haskell or FFI-based libraries are better designed > and better maintained. Which means your statements come from your > experience, and my statements come from my experience, and the truth is > probably somewhere in between. > > In my experience, FFI code is often based on bulk translation of C > header files into the IO monad. It requires an exact version of a > library to work (usually much older than the current), it does not > compile out of the box, there's scant documentation, and very little > high-level design has been imposed on the low-level C interface (may as > well use C!). Exceptions to this rule, there are, but as I said before, > my experience leads me to believe they *are* exceptions to a *general* rule. Which libraries are you talking about? I haven't ever used *any* like that, as far as I know. Current libraries almost always do build right out of the box with standard cabal commands. Maybe part of what you state was accurate a few years ago, but right now? As far as selection bias is concerned, that would apply equally well to both of us, would it not? -- John From wqeqweuqy at hotmail.com Fri Jan 9 15:58:09 2009 From: wqeqweuqy at hotmail.com (Neal Alexander) Date: Fri Jan 9 15:50:01 2009 Subject: [Haskell-cafe] Re: concurrent haskell: thread priorities In-Reply-To: <49671A87.1040401@gmail.com> References: <4c44d90b0812221442p2933e84dl90c81bb2f986dd3c@mail.gmail.com> <49671A87.1040401@gmail.com> Message-ID: Simon Marlow wrote: > Neal Alexander wrote: >> Thomas DuBuisson wrote: >>> It seems like we could get some priority based scheduling (and still >>> be slackers) if we allow marked green threads to be strictly >>> associated with a specific OS thread (forkChildIO?). >>> >>> >>> I think you want the GHC-only GHC.Conc.forkOnIO >>> >> GHC.Conc.forkOnIO is helpful but doest work in this case - it doesn't >> attach them to the same OS thread. > > But it does attach the thread to a particular "virtual CPU" in the GHC > RTS (we call them "capabilities"), with the intention that a virtual CPU > corresponds more or less to a real CPU core. > > Cheers, > Simon Yea, but you still have the problem with FFI that uses TLS don't you? What about having a forkOnOS version with processor affinity? Or is there a way to "upgrade" a thread created with forkOnIO to Bound. I have a thread with soft real-time requirements that cooperatively yields and uses thread local state. Right now there just doesn't seem to be any options. From waldmann at imn.htwk-leipzig.de Fri Jan 9 16:30:49 2009 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Fri Jan 9 16:22:27 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety References: <87eizkra83.fsf@nitai.hr> <495F6C07.5050006@henning-thielemann.de> <871vvkqyao.fsf@nitai.hr> Message-ID: [on hsql] > Still, it would be nice to present some info 'cause web site still shows > 1.7 from Dec '05 as the latest release see http://article.gmane.org/gmane.comp.lang.haskell.libraries/10490 J.W. From vigalchin at gmail.com Fri Jan 9 16:58:17 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Fri Jan 9 16:49:43 2009 Subject: [Haskell-cafe] Re: Issues with posix-realtime package Message-ID: <5ae4f2ba0901091358j3e08366jad674d8b6ae69405@mail.gmail.com> Hi Manlio, I am the author of this package. Let me think about what you have said. Regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090109/d8daa4aa/attachment.htm From dons at galois.com Fri Jan 9 17:21:58 2009 From: dons at galois.com (Don Stewart) Date: Fri Jan 9 17:13:09 2009 Subject: [Haskell-cafe] Possible GC bug In-Reply-To: <2f0f9f340901091204v358d33bcs3974d349a483cf15@mail.gmail.com> References: <2f0f9f340901091204v358d33bcs3974d349a483cf15@mail.gmail.com> Message-ID: <20090109222158.GB26568@scytale.galois.com> Report it as a GHC bug to the GHC team, here: http://hackage.haskell.org/trac/ghc/newticket?type=bug if you believe it is a bug. Cheers, Don anishmuttreja: > Hi, > I have a program that seems to run into occasional garbage > collection-related core dumps. The problem typically only occurs after the > program has been running for a while and is consuming a large amount of > memory (5 - 16GB). The large memory consumption is expected because the > program analyzes very large traces from verilog simulation and needs to > maintain IntMaps with hundreds of thousands of entries. > > Is this a bug that I should report?I am afraid that my employer will not > allow me to share my source code. I do have a stack trace, below. > This was obtained using ghc 6.10.1, RTS -N2 on an RHEL 4 machine. > > Is there something I can do trace the problem or avoid it? > > Thanks. > PS: This is my first Haskell program and one of the most complicated I > ever wrote, in any language. Using Haskell has been (mostly :-)) a joy. > > (gdb) where > #0 0x0000000000612f40 in slowIsHeapAlloced () > #1 0x000000000060f868 in evacuate () > #2 0x0000000000618d12 in scavenge_block () > #3 0x0000000000617c8d in scavenge_loop () > #4 0x0000000000610b25 in scavenge_until_all_done () > #5 0x0000000000610d02 in gc_thread_entry () > #6 0x000000000064859d in start_thread (arg=) > at pthread_create.c:297 > #7 0x000000000069e739 in clone () > #8 0x0000000000000000 in ?? () > > -- > As an adolescent I aspired to lasting fame, I craved factual certainty, > and I thirsted for a meaningful vision of human life - so I became a > scientist. This is like becoming an archbishop so you can meet girls. > -Matt Cartmill, anthropology professor and author (1943- ) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From anishmuttreja at gmail.com Fri Jan 9 17:34:38 2009 From: anishmuttreja at gmail.com (Anish Muttreja) Date: Fri Jan 9 17:25:07 2009 Subject: [Haskell-cafe] Possible GC bug In-Reply-To: <20090109222158.GB26568@scytale.galois.com> References: <2f0f9f340901091204v358d33bcs3974d349a483cf15@mail.gmail.com> <20090109222158.GB26568@scytale.galois.com> Message-ID: <20090109223438.GA18089@amuttreja-dt> Thanks, I have reported a bug.I hope the stack trace is useful. Cheers, Anish On Fri, Jan 09, 2009 at 02:21:58PM -0800, Don Stewart wrote: > Report it as a GHC bug to the GHC team, here: > > http://hackage.haskell.org/trac/ghc/newticket?type=bug > > if you believe it is a bug. > > Cheers, > Don > > > anishmuttreja: > > Hi, > > I have a program that seems to run into occasional garbage > > collection-related core dumps. The problem typically only occurs after the > > program has been running for a while and is consuming a large amount of > > memory (5 - 16GB). The large memory consumption is expected because the > > program analyzes very large traces from verilog simulation and needs to > > maintain IntMaps with hundreds of thousands of entries. > > > > Is this a bug that I should report?I am afraid that my employer will not > > allow me to share my source code. I do have a stack trace, below. > > This was obtained using ghc 6.10.1, RTS -N2 on an RHEL 4 machine. > > > > Is there something I can do trace the problem or avoid it? > > > > Thanks. > > PS: This is my first Haskell program and one of the most complicated I > > ever wrote, in any language. Using Haskell has been (mostly :-)) a joy. > > > > (gdb) where > > #0 0x0000000000612f40 in slowIsHeapAlloced () > > #1 0x000000000060f868 in evacuate () > > #2 0x0000000000618d12 in scavenge_block () > > #3 0x0000000000617c8d in scavenge_loop () > > #4 0x0000000000610b25 in scavenge_until_all_done () > > #5 0x0000000000610d02 in gc_thread_entry () > > #6 0x000000000064859d in start_thread (arg=) > > at pthread_create.c:297 > > #7 0x000000000069e739 in clone () > > #8 0x0000000000000000 in ?? () > > > > -- > > As an adolescent I aspired to lasting fame, I craved factual certainty, > > and I thirsted for a meaningful vision of human life - so I became a > > scientist. This is like becoming an archbishop so you can meet girls. > > -Matt Cartmill, anthropology professor and author (1943- ) > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > From manlio_perillo at libero.it Fri Jan 9 18:30:05 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Fri Jan 9 18:21:32 2009 Subject: [Haskell-cafe] Re: Issues with posix-realtime package In-Reply-To: <5ae4f2ba0901091358j3e08366jad674d8b6ae69405@mail.gmail.com> References: <5ae4f2ba0901091358j3e08366jad674d8b6ae69405@mail.gmail.com> Message-ID: <4967DDFD.2090105@libero.it> Galchin, Vasili ha scritto: > Hi Manlio, > > I am the author of this package. Let me think about what you have > said. > > Regards, Vasili Thanks. Note that there are no problems if I compile my program, instead of running it using ghci. Manlio Perillo From jeffzaroyko at gmail.com Fri Jan 9 20:02:17 2009 From: jeffzaroyko at gmail.com (Jeff Zaroyko) Date: Fri Jan 9 19:53:45 2009 Subject: [Haskell-cafe] Re: Low-level networking [Haskell not ready for Foo] In-Reply-To: <49679562.5060508@btinternet.com> References: <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49667026.9060702@btinternet.com> <49668330.2000701@complete.org> <49679562.5060508@btinternet.com> Message-ID: On Sat, Jan 10, 2009 at 5:20 AM, Andrew Coppin wrote: > Dominic Steinitz wrote: >> >> John Goerzen complete.org> writes: >> >>>> >>>> Any idea how I get Haskell to send ICMP ECHO packets? (And, obviously, >>>> receive the replies.) >>>> >>> >>> SocketType claims to support Raw, which I think is the conventional >>> means for doing this. Whether all the infrastructure for that is there, >>> I don't know. I have never worked with raw sockets though, so I may be >>> leading you down a dark mugger-laden alley here >> >> Here's an example of a Haskell version of ping, now sadly bit-rotted. >> >> Dominic. >> >> http://haskell.org/networktools/src/ping/test.hs >> > > I have a worrying feeling this might be too Unix-specific to work on > Windows. But I guess it's a start... > If you want to "ping" on windows, you need to use IcmpCreateFile, IcmpSendEcho, IcmpCloseFile for IPv4 or for IPv6, use the Icmp6CreateFile, Icmp6SendEcho2, and Icmp6ParseReplies which are part of iphlpapi, should be fairly trivial to use the loadLibrary and getProcAddress functions from System.Win32.DLL module to access these. -Jeff From duncan.coutts at worc.ox.ac.uk Fri Jan 9 20:45:24 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Jan 9 20:34:27 2009 Subject: [Haskell-cafe] HookedBuildInfo and Cabal In-Reply-To: References: <20090108184211.GB25272@hustlerturf.com> <1231459437.14054.27.camel@lantern> Message-ID: <1231551924.22871.14.camel@lantern> On Sat, 2009-01-10 at 01:40 +0100, Brian B wrote: > Hi Duncan, > > This works for me too, many thanks. Great. > The only change I needed was that the real pg_config outputs a newline > where your fake one didn't: Ah yes, good point. Duncan From newsham at lava.net Fri Jan 9 20:51:55 2009 From: newsham at lava.net (Tim Newsham) Date: Fri Jan 9 20:43:35 2009 Subject: [Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49666B19.8040500@libero.it> Message-ID: > Don't get me wrong -- the socket support is pretty decent, but there are also > some weird idiosyncrasies, for example requiring that the PortNum is > specified in network byte order and lacking a function to convert > host->network byte order (hton). PortNum is indeed strange, but it does allow yo to specify the value in your local endian without swapping: > print (toEnum 0x0102 :: PortNumber) 258 what is misleading you is that the obvious construction doesn't: > print (PortNum 0x0102) 513 I'm suprised htonl comes up so often. You can unmarshall data directly from a byte stream to an Int type without caring about the underlying representation of your Int. Why do people want the htonl function? > Bardur Arantsson Tim Newsham http://www.thenewsh.com/~newsham/ From pbeadling at mail2web.com Fri Jan 9 21:26:53 2009 From: pbeadling at mail2web.com (Phil) Date: Fri Jan 9 21:18:41 2009 Subject: [Haskell-cafe] Shared library creating on Mac OS X Message-ID: Hi, I?m hitting a problem trying create shared haskell libs to be linked into a C program on Mac OS X. I?m using the latest download for Leopard from the GHC page: http://www.haskell.org/ghc/dist/6.10.1/witten/ghc-6.10.1-powerpc-apple-darwi n.tar.bz2 I can get basic executables working fine (with a C main() #including ghc?s stub header), using something like: ghc -optc-O invnorm.c InverseNormal.o InverseNormal_stub.o -o cTest I started off using the following line to try to create a shared lib: ghc --make -no-hs-main -optl '-shared' -o Inv.so InverseNormal.hs This doesn?t work on mac os x because Apple?s gcc annoyingly takes different switches, so I changed it to: ghc --make -no-hs-main -optl '-dynamiclib' -o Inv.dylib InverseNormal.hs Which still fails at the final link giving: Linking Inv.dylib ... Undefined symbols: "_environ", referenced from: _environ$non_lazy_ptr in libHSbase-4.0.0.0.a(PrelIOUtils.o) ld: symbol(s) not found I?ve seen similar things before, and I believe if you have full control over the source you just slip in a: #define environ (*_NSGetEnviron()) Sure enough, I can find references to environ in, for example HsBase.h Problem (as I see it) is that references to environ are already wrapped up in the static lib libHSbase-4.0.0.0.a, so without recompiling Haskell we can?t alter the C definition now. However, given that packager must have made this behave when he compiled the distribution there must be a way to make Mac gcc accept _envrion symbols?? Has anyone seen this before / can confirm my analysis / and by any chance have a solution? Many thanks, Phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090110/ab51d30d/attachment.htm From vigalchin at gmail.com Fri Jan 9 21:42:31 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Fri Jan 9 21:33:56 2009 Subject: [Haskell-cafe] Re: Issues with posix-realtime package In-Reply-To: <4967DDFD.2090105@libero.it> References: <5ae4f2ba0901091358j3e08366jad674d8b6ae69405@mail.gmail.com> <4967DDFD.2090105@libero.it> Message-ID: <5ae4f2ba0901091842q6ba87aa4pe097392b51eddb0a@mail.gmail.com> hmmmmmm .... Vasili On Fri, Jan 9, 2009 at 5:30 PM, Manlio Perillo wrote: > Galchin, Vasili ha scritto: > >> Hi Manlio, >> >> I am the author of this package. Let me think about what you have >> said. >> >> Regards, Vasili >> > > Thanks. > > Note that there are no problems if I compile my program, instead of running > it using ghci. > > > Manlio Perillo > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090109/266694dd/attachment.htm From steve at fenestra.com Fri Jan 9 21:55:22 2009 From: steve at fenestra.com (Steve Schafer) Date: Fri Jan 9 21:46:46 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: <49676D31.1090207@complete.org> References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> <94oem4hfiqaskk4pdc5mn3d05l8p4hh6cf@4ax.com> <49676D31.1090207@complete.org> Message-ID: <193gm4ldb2cichf8l3lgdbdhslhe7gifbf@4ax.com> On Fri, 09 Jan 2009 09:28:49 -0600, you wrote: >I'm not sure that the original question implied *that* level of need. I can't imagine being worried about leap seconds yet at the same time being willing to accept the potential vagaries of any of the built-in clocks. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ From allbery at ece.cmu.edu Fri Jan 9 23:08:15 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Jan 9 22:59:41 2009 Subject: [Haskell-cafe] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <20090108202025.GB27569@hustlerturf.com> <49666B19.8040500@libero.it> Message-ID: <4698EE10-ECC7-465C-8B94-3808F3671FD3@ece.cmu.edu> On 2009 Jan 9, at 20:51, Tim Newsham wrote: > I'm suprised htonl comes up so often. You can unmarshall data > directly from a byte stream to an Int type without caring about the > underlying representation of your Int. Why do people want the htonl > function? IP address math. (see @ipcalc in #lopsa's lambdabot) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From vigalchin at gmail.com Sat Jan 10 00:27:02 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat Jan 10 00:18:27 2009 Subject: [Haskell-cafe] Re: Issues with posix-realtime package In-Reply-To: <4967DDFD.2090105@libero.it> References: <5ae4f2ba0901091358j3e08366jad674d8b6ae69405@mail.gmail.com> <4967DDFD.2090105@libero.it> Message-ID: <5ae4f2ba0901092127p6228bb66ubf23b9b28e5f77c6@mail.gmail.com> Manlio, so compiling to native machine code works ok but if using ghci byte-code interpreter doesn't ..... can you supply your program please? Vasili On Fri, Jan 9, 2009 at 5:30 PM, Manlio Perillo wrote: > Galchin, Vasili ha scritto: > >> Hi Manlio, >> >> I am the author of this package. Let me think about what you have >> said. >> >> Regards, Vasili >> > > Thanks. > > Note that there are no problems if I compile my program, instead of running > it using ghci. > > > Manlio Perillo > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090109/fb68ea9b/attachment.htm From patperry at stanford.edu Sat Jan 10 05:16:05 2009 From: patperry at stanford.edu (Patrick Perry) Date: Sat Jan 10 05:07:31 2009 Subject: [Haskell-cafe] ANN: Haskell BLAS bindings version 0.7 Message-ID: <406497ED-A831-4684-B5EF-471EA706FAA9@stanford.edu> New version! The blas package is a set of bindings to the BLAS (Basic Linear Algebra Subprograms) library. On Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/blas-0.7 What's new: * Get rid of most functional dependencies in favor of type families. There is one remaining functional dependency that cannot be gotten rid of until GHC implements equality constraints in superclass contexts. * Put the right superclass constraints in ReadMatrix/ReadBanded. * Fix freeze/thaw functions. They used to be awkward to use. * Fix a bug in getting a row view of a banded matrix. * Make sure no NaNs/Infinities/Denormals are used when testing. * Documentation. * Export functions for writing QuickCheck tests. * Remove Perm and Diag. These will be in the LAPACK bindings. * Get rid of "UnsafeIOToM" type class. * Lots of INLINE everywhere. This will improve performance (?) * Switch to autoconf for build system. Requisite blog post: http://quantile95.com/2009/01/09/new-haskell-blas-bindings/ Not much example code. Here's some old stuff: http://github.com/patperry/blas/tree/master/examples/LU.hs Thanks for listening. Any feedback is always welcome. Patrick From patperry at stanford.edu Sat Jan 10 05:46:05 2009 From: patperry at stanford.edu (Patrick Perry) Date: Sat Jan 10 05:37:29 2009 Subject: [Haskell-cafe] ANN: Haskell BLAS bindings version 0.7 Message-ID: <56774369-38F2-4236-834B-DDC892401DDD@stanford.edu> Here's the haddock documentation; I'm not sure if Hackage honors {-# OPTIONS_HADDOCK hide #-} when it displays the exposed modules: http://quantile95.com/blas/ Patrick From david.waern at gmail.com Sat Jan 10 06:38:44 2009 From: david.waern at gmail.com (David Waern) Date: Sat Jan 10 06:30:07 2009 Subject: [Haskell-cafe] ANN: Haskell BLAS bindings version 0.7 In-Reply-To: <56774369-38F2-4236-834B-DDC892401DDD@stanford.edu> References: <56774369-38F2-4236-834B-DDC892401DDD@stanford.edu> Message-ID: 2009/1/10 Patrick Perry : > Here's the haddock documentation; I'm not sure if Hackage honors {-# > OPTIONS_HADDOCK hide #-} when it displays the exposed modules: > > http://quantile95.com/blas/ It should, so If it doesn't then please tell us about it. We have a trac at: http://trac.haskell.org/haddock/ David From manlio_perillo at libero.it Sat Jan 10 06:52:54 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Sat Jan 10 06:44:30 2009 Subject: [Haskell-cafe] Re: Issues with posix-realtime package In-Reply-To: <5ae4f2ba0901092127p6228bb66ubf23b9b28e5f77c6@mail.gmail.com> References: <5ae4f2ba0901091358j3e08366jad674d8b6ae69405@mail.gmail.com> <4967DDFD.2090105@libero.it> <5ae4f2ba0901092127p6228bb66ubf23b9b28e5f77c6@mail.gmail.com> Message-ID: <49688C16.8070506@libero.it> Galchin, Vasili ha scritto: > Manlio, > > so compiling to native machine code works ok but if using ghci byte-code > interpreter doesn't ..... can you supply your program please? > Right. Can't you reproduce the problem? The program is very simple (I was just testing your package, since I suggested the use of clock_gettime to Mauricio in a previous post): import System.Posix.Realtime.RTTime import System.Posix.Realtime.RTDataTypes main = do time <- clockGetTime Clock_Monotonic; print $ tvSec time print $ tvNsec time runghc rttime.hs I suspect that this is a problem with shared library loading in ghci, since the C code you use for your package, is also used by the base package (for the Posix subsystem). By the way: I don't see reasons to add all that code, since it is not used. However, when I tried to remove all the unused code, executing the program gave me a stack exception (maybe I have removed too many things...). One personal note: I don't like `tvSec` and `tvNsec`, I think `seconds` and `nanoSeconds` is a better choice. Also, it would useful a function to compute elapsed time (maybe a general class in base package, and a specialized instance declaration in posix-realtime for the timespec?) > Vasili > > [...] Manlio From johan.tibell at gmail.com Sat Jan 10 07:19:42 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Sat Jan 10 07:11:06 2009 Subject: [Haskell-cafe] Re: concurrent haskell: thread priorities In-Reply-To: <20090109192211.GJ25701@scytale.galois.com> References: <4c44d90b0812221442p2933e84dl90c81bb2f986dd3c@mail.gmail.com> <49671A87.1040401@gmail.com> <20090109192211.GJ25701@scytale.galois.com> Message-ID: <90889fe70901100419n25b520c1i8a53da2e860330b4@mail.gmail.com> On Fri, Jan 9, 2009 at 8:22 PM, Don Stewart wrote: > Every time Simon responds on questions of parallelism and the GHC > runtime, I learn something. That indicates to me that we've got a 'bus > error' situation with how to effectively use the smp runtime. > > Simon: time for a multicore FAQ wiki page to gather this knowledge, like > we did for the performance tips? Somewhere to paste these insights? A few weeks ago, during the weekly GHC meeting, Simon explained the internals of the threading system to me. Among other things he explained how many threads are run per core, how they are load balanced and migrated between cores. I found it very enlightening. Maybe, that could serve as a basis for a GHCThreadingInternals wiki page. Is #ghc channel logged anywhere? Cheers, Johan From johanj at cs.uu.nl Sat Jan 10 08:23:23 2009 From: johanj at cs.uu.nl (Johan Jeuring) Date: Sat Jan 10 08:14:55 2009 Subject: [Haskell-cafe] data declarations should provide fold functions In-Reply-To: References: Message-ID: <9D6BD2E0-F3EE-4757-AA08-467B61810F4A@cs.uu.nl> > I know the short-term answer is "use TH" to derive folds if > I want them, but I think such an important concept should probably > be part of the language. The fold function is an example of a generic program, which can be defined using generic programming libraries. Since the fold has to know about the recursive structure of a datatype, not all (actually, very few) generic programming libraries can be used to define a fold. An example of a recent library that can define folds is multirec (developed by our own group, blatant self promotion): http://hackage.haskell.org/cgi-bin/hackage-scripts/package/multirec A description of the library can be found in http://www.cs.uu.nl/research/techreps/UU-CS-2008-019.html Older generic programming approaches such as PolyP could define the fold too, be it only for so-called regular (non mutually recursive) datatypes. The multirec library defines folds for mutually recursive datatypes. The released version of multirec doesn't include the TH files for generating the boilerplate code (for example, embedding-projection pairs for datatypes) necessary for using the library. However, the head has TH support for this. All the best, Johan Jeuring > Tim Newsham > http://www.thenewsh.com/~newsham/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From redcom at fedoms.com Sat Jan 10 09:03:18 2009 From: redcom at fedoms.com (=?iso-8859-15?Q?G=FCnther_Schmidt?=) Date: Sat Jan 10 08:54:53 2009 Subject: [Haskell-cafe] Looking for Haskellers on Windows Message-ID: Hi all, I'm looking for Haskell programmer that use Windows as their OS-Plattform. I developing an application in Haskell on Windows and run into problems that seem to have a lower priority with the greater Haskell community as most of them are using Linux where the problems do not occur or are already solved. So it'd be nice to get in touch with other Haskellers that face the same problems. G?nther From manlio_perillo at libero.it Sat Jan 10 09:04:36 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Sat Jan 10 08:56:07 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: <193gm4ldb2cichf8l3lgdbdhslhe7gifbf@4ax.com> References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> <94oem4hfiqaskk4pdc5mn3d05l8p4hh6cf@4ax.com> <49676D31.1090207@complete.org> <193gm4ldb2cichf8l3lgdbdhslhe7gifbf@4ax.com> Message-ID: <4968AAF4.2040108@libero.it> Steve Schafer ha scritto: > On Fri, 09 Jan 2009 09:28:49 -0600, you wrote: > >> I'm not sure that the original question implied *that* level of need. > > I can't imagine being worried about leap seconds yet at the same time > being willing to accept the potential vagaries of any of the built-in > clocks. > POSIX realtime extensions have been developed to be high reliable. I don't know if the implementations on general purpose operating systems like Linux are reliable, but in case of problems one can try to switch to a real time operating system. This resources may be useful: http://juliusdavies.ca/posix_clocks/clock_realtime_linux_faq.html Timing is, however, a complex issue. > Steve Schafer > Fenestra Technologies Corp. > http://www.fenestra.com Manlio Perillo From redcom at fedoms.com Sat Jan 10 09:31:13 2009 From: redcom at fedoms.com (=?iso-8859-15?Q?G=FCnther_Schmidt?=) Date: Sat Jan 10 09:22:40 2009 Subject: [Haskell-cafe] Looking for Haskellers on Windows In-Reply-To: <887509072.20090110171802@gmail.com> References: <887509072.20090110171802@gmail.com> Message-ID: Hi Bulat, I do :), but I was amazed that there was no response to a post with, what I thought, would be a rather common problem for an application developer. That post was about writing to an MS-Access database via HDBC-ODBC, which fails. When I then asked the HDBC maintainer himself it turned out that he doesn't use Windows either and thus can't help. Thus my cry for help explicitly to Haskellers on Windows. G?nther Am 10.01.2009, 15:18 Uhr, schrieb Bulat Ziganshin : > Hello G?nther, > > Saturday, January 10, 2009, 5:03:18 PM, you wrote: > > there are lot of windows haskellers so you can just write your questions > in > haskell-cafe > >> Hi all, > >> I'm looking for Haskell programmer that use Windows as their >> OS-Plattform. >> I developing an application in Haskell on Windows and run into problems >> that seem to have a lower priority with the greater Haskell community as >> most of them are using Linux where the problems do not occur or are >> already solved. > >> So it'd be nice to get in touch with other Haskellers that face the same >> problems. > >> G?nther > >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Erstellt mit Operas revolution?rem E-Mail-Modul: http://www.opera.com/mail/ From bulat.ziganshin at gmail.com Sat Jan 10 09:33:32 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Jan 10 09:25:11 2009 Subject: [Haskell-cafe] Looking for Haskellers on Windows In-Reply-To: References: <887509072.20090110171802@gmail.com> Message-ID: <1528669320.20090110173332@gmail.com> Hello G?nther, Saturday, January 10, 2009, 5:31:13 PM, you wrote: i think that problem is not shortage of windows developers among haskellers, but shortage of db developers :) > Hi Bulat, > I do :), but I was amazed that there was no response to a post with, what > I thought, would be a rather common problem for an application developer. > That post was about writing to an MS-Access database via HDBC-ODBC, which > fails. When I then asked the HDBC maintainer himself it turned out that he > doesn't use Windows either and thus can't help. > Thus my cry for help explicitly to Haskellers on Windows. > G?nther > Am 10.01.2009, 15:18 Uhr, schrieb Bulat Ziganshin > : >> Hello G?nther, >> >> Saturday, January 10, 2009, 5:03:18 PM, you wrote: >> >> there are lot of windows haskellers so you can just write your questions >> in >> haskell-cafe >> >>> Hi all, >> >>> I'm looking for Haskell programmer that use Windows as their >>> OS-Plattform. >>> I developing an application in Haskell on Windows and run into problems >>> that seem to have a lower priority with the greater Haskell community as >>> most of them are using Linux where the problems do not occur or are >>> already solved. >> >>> So it'd be nice to get in touch with other Haskellers that face the same >>> problems. >> >>> G?nther >> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jason.dusek at gmail.com Sat Jan 10 09:54:25 2009 From: jason.dusek at gmail.com (Jason Dusek) Date: Sat Jan 10 09:45:47 2009 Subject: [Haskell-cafe] Looking for Haskellers on Windows In-Reply-To: References: Message-ID: <42784f260901100654r47550fb5j3bf7b48e987dc889@mail.gmail.com> I do have to ship things to Windows and so I have a small amount of interaction with that platform. This is, unfortunately, something we see all over open source environments. Python and Ruby lists both see posts like this from time to time. While it is important that the interests of Windows developers be represented -- I was myself surprised to discover that the UUID package only worked on Linux -- it would be unconstructive to carry out such discussions offlist. -- Jason Dusek From redcom at fedoms.com Sat Jan 10 10:11:44 2009 From: redcom at fedoms.com (=?iso-8859-15?Q?G=FCnther_Schmidt?=) Date: Sat Jan 10 10:03:09 2009 Subject: [Haskell-cafe] Looking for Haskellers on Windows In-Reply-To: <42784f260901100654r47550fb5j3bf7b48e987dc889@mail.gmail.com> References: <42784f260901100654r47550fb5j3bf7b48e987dc889@mail.gmail.com> Message-ID: Hi Jason, I don't mean to take this off-list at all. Quite the opposite, I just meant to draw the attention of other Haskellers who also use Windows and might feel a bit alone because of it. It certainly was my feeling, this is only for the windows specific Haskell stuff. G?nther Am 10.01.2009, 15:54 Uhr, schrieb Jason Dusek : > I do have to ship things to Windows and so I have a small > amount of interaction with that platform. > > This is, unfortunately, something we see all over open source > environments. Python and Ruby lists both see posts like this > from time to time. > > While it is important that the interests of Windows developers > be represented -- I was myself surprised to discover that the > UUID package only worked on Linux -- it would be > unconstructive to carry out such discussions offlist. > > -- > Jason Dusek -- Erstellt mit Operas revolution?rem E-Mail-Modul: http://www.opera.com/mail/ From redcom at fedoms.com Sat Jan 10 10:15:30 2009 From: redcom at fedoms.com (=?utf-8?Q?G=C3=BCnther_Schmidt?=) Date: Sat Jan 10 10:06:53 2009 Subject: [Haskell-cafe] Looking for Haskellers on Windows In-Reply-To: <4968B545.9050407@mail.ru> References: <4968B545.9050407@mail.ru> Message-ID: Hi Kyra, thanks for your reply. The problem I was facing is using an MS-Access backend with HDBC-ODBC. I try to export data to MS-Access and I can't get it to work. Otherwise HDBC works fine in other parts of my app but with MS-Access it blows up. I did of course post this on the haskell-cafe list first, but no response and the HDBC package maintainer himself was unable to help too since he's not using Windows. G?nther Am 10.01.2009, 15:48 Uhr, schrieb kyra : > G?nther Schmidt wrote: >> Hi all, >> I'm looking for Haskell programmer that use Windows as their >> OS-Plattform. I developing an application in Haskell on Windows and run >> into problems that seem to have a lower priority with the greater >> Haskell community as most of them are using Linux where the problems do >> not occur or are already solved. >> So it'd be nice to get in touch with other Haskellers that face the >> same problems. >> G?nther > > I don't know what problems You are talking about, but, since Windows is > my development platform and I'm a haskeller, I hope to be able to help > You. > > What problems are your facing? > > Kyra -- Erstellt mit Operas revolution?rem E-Mail-Modul: http://www.opera.com/mail/ From bugfact at gmail.com Sat Jan 10 10:23:56 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Sat Jan 10 10:15:20 2009 Subject: [Haskell-cafe] Re: Monads aren't evil In-Reply-To: References: <20090108231652.24b75fe3@tritium.xx> Message-ID: Related to this issue, I have a question here. I might be wrong, but it seems to me that some Haskellers don't like writing monads (with do notation) or arrows (with proc sugar) because of the fact they have to abandon the typical applicative syntax, which is so close to the beautiful lambda calculus core. Or is it maybe because some people choose monads were the less linear applicative style could be used instead, so the choice of monads is not always appropriate. Haskell is full of little hardcoded syntax extensions: list notation syntactic, list comprehensions, and even operator precedence that reduces the need for parentheses, etc... Of course IMHO the syntactic sugar is needed, e.g. a Yampa game written without the arrows syntax would be incomprehensible for the average programmer. But one could claim that this syntactic sugar hides what is really going on under the hood, so for newcomers these extensions might make it harder. It could also feel like a hack, a failure to keep things as simple as possible yet elegant. Some people I talked with like that about the Scheme/ & LISP languages: the syntax remains ultimately close to the core, with very little hardcoded syntactic extensions. And when one wants to add syntactic extensions, one uses syntactic macros. I'm not sure what others feel about the hardcoded syntax extensions in Haskell... Personally I'm not that much of a purist, I'm an old school hacker that mainly needs to get the job done. I like the syntax extensions in Haskell (and even C#/F# ;) because they let me write code shorter and clearer... On Fri, Jan 9, 2009 at 4:07 AM, Neal Alexander wrote: > Ertugrul Soeylemez wrote: > >> Hello fellow Haskellers, >> >> When I read questions from Haskell beginners, it somehow seems like they >> try to avoid monads and view them as a last resort, if there is no easy >> non-monadic way. I'm really sure that the cause for this is that most >> tutorials deal with monads very sparingly and mostly in the context of >> input/output. Also usually monads are associated with the do-notation, >> which makes them appear even more special, although there is really >> nothing special about them. >> >> > Yea, i was the same way when i started learning Haskell. I understood how > Monads worked, and what the motivation was for them, but not why i would > want to restructure code to use them in specific instances. > > "Why should i care about monads when i can use Arrows or (.)" was also a > factor. > > Its kinda like getting advice from an adult as a child. You have no > particular reason to distrust the advice, but the value of it doesn't set in > until something happens to you first hand to verify it. > > For me the turning point was writing some code that needed to handle > running code locally/remotely in a transparent manner. > > Maybe having a list of real-world usage scenarios or exercises on the wiki > may help. > > > ______________________________ _________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090110/90a8ae3b/attachment.htm From patperry at stanford.edu Sat Jan 10 10:39:19 2009 From: patperry at stanford.edu (Patrick Perry) Date: Sat Jan 10 10:30:44 2009 Subject: [Haskell-cafe] ANN: Haskell BLAS bindings version 0.7 In-Reply-To: References: <56774369-38F2-4236-834B-DDC892401DDD@stanford.edu> Message-ID: Hi David, The problem is with Hackage, not with haddock. Patrick On Jan 10, 2009, at 3:38 AM, David Waern wrote: > 2009/1/10 Patrick Perry : >> Here's the haddock documentation; I'm not sure if Hackage honors {-# >> OPTIONS_HADDOCK hide #-} when it displays the exposed modules: >> >> http://quantile95.com/blas/ > > It should, so If it doesn't then please tell us about it. We have a > trac at: > > http://trac.haskell.org/haddock/ > > David From ross at soi.city.ac.uk Sat Jan 10 10:54:31 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Jan 10 10:45:56 2009 Subject: [Haskell-cafe] ANN: Haskell BLAS bindings version 0.7 In-Reply-To: <56774369-38F2-4236-834B-DDC892401DDD@stanford.edu> References: <56774369-38F2-4236-834B-DDC892401DDD@stanford.edu> Message-ID: <20090110155431.GB6298@soi.city.ac.uk> On Sat, Jan 10, 2009 at 02:46:05AM -0800, Patrick Perry wrote: > Here's the haddock documentation; I'm not sure if Hackage honors {-# > OPTIONS_HADDOCK hide #-} when it displays the exposed modules: > > http://quantile95.com/blas/ Who do you want the same modules to be both exposed and hidden? From redcom at fedoms.com Sat Jan 10 11:09:03 2009 From: redcom at fedoms.com (=?iso-8859-15?Q?G=FCnther_Schmidt?=) Date: Sat Jan 10 11:00:28 2009 Subject: [Haskell-cafe] Looking for Haskellers on Windows In-Reply-To: <4968C650.3090900@mail.ru> References: <4968B545.9050407@mail.ru> <4968C650.3090900@mail.ru> Message-ID: Hi Kyra, and again, thanks for taking the effort. Kyra I've tried any sort of values to any sort of columns. I tried "insert into somesinglecolumntable (someNumbercolumn) values (?)" [toSql 5] ... and so on. So I'm not certain at all the error message does actually give the right clue. It just blows no matter what. What does work though is this: run dbc "insert into sometable (someVarcharcolumn) values ('some string value')" [] This would be a workaround for my app, but I hope I can do better. G?nther Am 10.01.2009, 17:01 Uhr, schrieb kyra : > G?nther Schmidt wrote: >> Hi Kyra, >> thanks for your reply. >> The problem I was facing is using an MS-Access backend with HDBC-ODBC. >> I try to export data to MS-Access and I can't get it to work. Otherwise >> HDBC works fine in other parts of my app but with MS-Access it blows up. >> I did of course post this on the haskell-cafe list first, but no >> response and the HDBC package maintainer himself was unable to help too >> since he's not using Windows. > > I've looked at Your problem now. What is the type of that single field > in 'mytable'? Google shows numerous similar cases, e.g. for date or memo > fields, that Access don't accept varchars and require longvarchars for. > > I'm in no way an Access expert. > > Cheers, > Kyra -- Erstellt mit Operas revolution?rem E-Mail-Modul: http://www.opera.com/mail/ From david.waern at gmail.com Sat Jan 10 11:12:54 2009 From: david.waern at gmail.com (David Waern) Date: Sat Jan 10 11:04:17 2009 Subject: [Haskell-cafe] ANN: Haskell BLAS bindings version 0.7 In-Reply-To: References: <56774369-38F2-4236-834B-DDC892401DDD@stanford.edu> Message-ID: 2009/1/10 Patrick Perry : > Hi David, > > The problem is with Hackage, not with haddock. Oops, Sorry. I misread Hackage as Haddock :) David From john at n-brain.net Sat Jan 10 11:35:09 2009 From: john at n-brain.net (John A. De Goes) Date: Sat Jan 10 11:26:33 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <069DF505-BA40-4CF9-9936-9E1373FEE9B4@n-brain.net> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> <1231454154-sup-7772@existential.local> <0AFF36A6-DF7F-40E7-9CF3-C2E2E08DEA5C@n-brain.net> <4967B6D3.2020001@complete.org> <069DF505-BA40-4CF9-9936-9E1373FEE9B4@n-brain.net> Message-ID: <9423EEAF-E02F-419D-8EE3-63C912550DC4@n-brain.net> Hi John, Take two examples I gave up getting to work: a Haskell wrapper for a popular GUI library; and a Haskell wrapper for a database. I understand the former has a new team of developers, so perhaps it's time to revisit the library. Then again, writing 5000 line GUIs in an imperative style in a Haskell program just doesn't seem very appealing to me. And that's one of the problem with FFI-based libraries: it exposes the functionality (when it works), but in a strictly imperative way. Selection bias applies to us both. To quote myself, "Which means your statements come from your experience, and my statements come from my experience, and the truth is probably somewhere in between." Regards, John On Jan 9, 2009, at 1:42 PM, John Goerzen wrote: > John A. De Goes wrote: >> >> Hi Austin, >> >> How do you know it's not your experience with FFI code that isn't >> biased? As far as I know, there has been no systematic attempt to >> document whether pure Haskell or FFI-based libraries are better >> designed >> and better maintained. Which means your statements come from your >> experience, and my statements come from my experience, and the >> truth is >> probably somewhere in between. >> >> In my experience, FFI code is often based on bulk translation of C >> header files into the IO monad. It requires an exact version of a >> library to work (usually much older than the current), it does not >> compile out of the box, there's scant documentation, and very little >> high-level design has been imposed on the low-level C interface >> (may as >> well use C!). Exceptions to this rule, there are, but as I said >> before, >> my experience leads me to believe they *are* exceptions to a >> *general* rule. > > Which libraries are you talking about? I haven't ever used *any* like > that, as far as I know. > > Current libraries almost always do build right out of the box with > standard cabal commands. > > Maybe part of what you state was accurate a few years ago, but right > now? > > As far as selection bias is concerned, that would apply equally well > to > both of us, would it not? > > -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090110/495ffa5b/attachment.htm From john at n-brain.net Sat Jan 10 11:38:17 2009 From: john at n-brain.net (John A. De Goes) Date: Sat Jan 10 11:29:41 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <814617240901090801n955808oe3cc74ee8c42e470@mail.gmail.com> References: <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <814617240901081216t7232b5b6u884efd6e2b0bad40@mail.gmail.com> <30D797FA-F5B8-4267-8E16-33DF9C2BA3AD@n-brain.net> <814617240901090801n955808oe3cc74ee8c42e470@mail.gmail.com> Message-ID: On Jan 9, 2009, at 9:01 AM, Creighton Hogg wrote: > 2009/1/9 John A. De Goes : >> >> If you're looking for a project to take on, I would suggest >> starting with >> the following: >> >> A high-level, type-safe AMQP client written in 100% Haskell, which >> provides >> a clean way of handling hundreds of unique message types. >> >> Then it would be possible to hook it up to any AMQP broker (most >> likely >> RabbitMQ). There are logical steps beyond the above (an embedded >> Haskell >> broker), but the above project is far from trivial. And the main >> undertaking, I think, consists not in coding to the spec (for which >> there is >> some help; a JSON representation of the AMQP specification can be >> processed >> and used to emit language-specific code), but in finding a design >> that works >> well in Haskell. > > I apologize, but my question was geared more towards understanding > what high-level OTP-like libraries Haskell is lacking, not full blown > applications that haven't been written in Haskell. It sounded like > you had some specific insight into this. A Haskell AMQP client is not an application, but a library that Haskell applications would use (if it existed). The use of the word "client" refers to the client/server metaphor used in centralized message broker systems like AMQP. Regarding the OTP specifically, Haskell doesn't have anything like it. Haskell has bits and pieces, but they're not integrated in a single stack, and much functionality is missing. For example, there's no way to dynamically poke running Haskell code, to see what it's doing; no way to update code on the fly as a process is running; no scalable distributed database system; etc. Regards, John From patperry at stanford.edu Sat Jan 10 11:54:26 2009 From: patperry at stanford.edu (Patrick Perry) Date: Sat Jan 10 11:45:49 2009 Subject: [Haskell-cafe] ANN: Haskell BLAS bindings version 0.7 In-Reply-To: References: <56774369-38F2-4236-834B-DDC892401DDD@stanford.edu> Message-ID: The reason I want to expose modules but hide the documentation is because there are a lot of "unsafeX" functions I want to provide access to, but which 99% of users don't care about. The array library does the same thing. Patrick From john at n-brain.net Sat Jan 10 12:05:49 2009 From: john at n-brain.net (John A. De Goes) Date: Sat Jan 10 11:57:17 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <49676BEF.9050005@complete.org> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> <20090108221549.GA30539@hustlerturf.com> <4438705C-9069-4780-B6A9-7E928997D6EA@n-brain.net> <49676BEF.9050005@complete.org> Message-ID: On Jan 9, 2009, at 8:23 AM, John Goerzen wrote: > Well, you pretty much always have to get down to the C level on a *nix > platform at some point, anyhow. You've got to make syscalls > somewhere. Take a language like Ruby or Python (or Java, or C#, etc.). The vast majority of code written in these languages does not "get down to the C level". When I say, "vast majority", I'm referring to > 99.999%. That's because the standard libraries provide sufficiently comprehensive platform-agnostic abstractions to do what most people need to do. As a result, libraries for these languages are built on the standard libraries, and do not require native code. > I don't think FFI is so evil. There is value in avoiding wheel > reinvention, too. If zlib already works great, why re-invent it when > you can easily just use what's there? There are lots of reasons: 1. If there's a bug in a library, Haskellers are more likely to fix the bug if the library is written in Haskell. 2. Haskellers are more likely to improve code that is written in Haskell. 3. A chain is only as strong as its weakest link -- libraries with more dependencies are more fragile, more likely to break, and less likely to work across platforms. 4. Haskell-only libraries are easier to build, easy to use, and easier to include in your program (this is subjective and we don't agree on this one, so ignore it if you like). 5. Haskell libraries are generally more commercial friendly than the GNU-licensed libraries that inevitably back FFI-based libraries. 6. Haskell libraries can more easily offer tight integration with Haskell code, and take advantage of features unique to Haskell, such as purity and laziness, and a declarative coding style. A shining role model is the Java ecosystem. No platform has as many open source, commercial-friendly, robust, feature-rich, and community- supported libraries than Java does. These libraries are, in the vast majority of cases, written in 100% Java, work identically on all platforms, are as easy to use as adding a single file to your project (Java also has Maven, which functions similarly to Cabal). That's where I'd like Haskell to be in 5 years. Regards, John From ekirpichov at gmail.com Sat Jan 10 12:07:29 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Sat Jan 10 11:58:52 2009 Subject: [Haskell-cafe] ANN: Haskell BLAS bindings version 0.7 In-Reply-To: References: <56774369-38F2-4236-834B-DDC892401DDD@stanford.edu> Message-ID: <5e0214850901100907p63aed22dw9ca7784a30f2d3b5@mail.gmail.com> Why don't you put them into a separate non-hidden Unsafe module and provide documentation for it? Users who don't care simply won't look there, whereas users who do care (for whom you are providing access) will still have a possibility to do so. 2009/1/10 Patrick Perry : > The reason I want to expose modules but hide the documentation is because > there are a lot of "unsafeX" functions I want to provide access to, but > which 99% of users don't care about. The array library does the same thing. > > > Patrick > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jgoerzen at complete.org Sat Jan 10 12:09:58 2009 From: jgoerzen at complete.org (John Goerzen) Date: Sat Jan 10 12:01:26 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <9423EEAF-E02F-419D-8EE3-63C912550DC4@n-brain.net> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> <1231454154-sup-7772@existential.local> <0AFF36A6-DF7F-40E7-9CF3-C2E2E08DEA5C@n-brain.net> <4967B6D3.2020001@complete.org> <069DF505-BA40-4CF9-9936-9E1373FEE9B4@n-brain.net> <9423EEAF-E02F-419D-8EE3-63C912550DC4@n-brain.net> Message-ID: <4968D666.8060909@complete.org> John A. De Goes wrote: > > Hi John, > > Take two examples I gave up getting to work: a Haskell wrapper for a > popular GUI library; and a Haskell wrapper for a database. I understand Is this database HDBC? If so, then I would appreciate detailed description of your problem so I can address it. If not, do you have the same criticism of HDBC? From jgoerzen at complete.org Sat Jan 10 12:12:32 2009 From: jgoerzen at complete.org (John Goerzen) Date: Sat Jan 10 12:04:03 2009 Subject: [Haskell-cafe] Looking for Haskellers on Windows In-Reply-To: References: <4968B545.9050407@mail.ru> <4968C650.3090900@mail.ru> Message-ID: <4968D700.8040907@complete.org> G?nther Schmidt wrote: > Hi Kyra, > > and again, thanks for taking the effort. > > Kyra I've tried any sort of values to any sort of columns. I tried "insert > into somesinglecolumntable (someNumbercolumn) values (?)" [toSql 5] ... > and so on. > > So I'm not certain at all the error message does actually give the right > clue. > > It just blows no matter what. > > What does work though is this: > > run dbc "insert into sometable (someVarcharcolumn) values ('some string > value')" [] It is probably good to avoid this. HDBC does not provide SQL string escaping functions because it is designed around the model of the replacable parameters, which are more secure and more performant. You will have to be very careful to sanitize input if you do take this approach. As to the larger question, there are quite a few Windows Haskell users out there. Some well-known Haskell personalities work for a division of Microsoft, even. I am not sure that there are all that many people talking to Access databases via ODBC to start with, though, but of course if anybody has a patch to contribute, I'd be happy to apply it. -- John From john at n-brain.net Sat Jan 10 12:13:32 2009 From: john at n-brain.net (John A. De Goes) Date: Sat Jan 10 12:05:00 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <4968D666.8060909@complete.org> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> <1231454154-sup-7772@existential.local> <0AFF36A6-DF7F-40E7-9CF3-C2E2E08DEA5C@n-brain.net> <4967B6D3.2020001@complete.org> <069DF505-BA40-4CF9-9936-9E1373FEE9B4@n-brain.net> <9423EEAF-E02F-419D-8EE3-63C912550DC4@n-brain.net> <4968D666.8060909@complete.org> Message-ID: <1FAD872B-F548-4B6A-B14D-481E62E4EA66@n-brain.net> No, it's not HDBC -- which I have not yet tried. I'll tell you what: I'll give HDBC a try this week and let you know if it's as easy as you say it is. :-) Regards, John On Jan 10, 2009, at 10:09 AM, John Goerzen wrote: > John A. De Goes wrote: >> >> Hi John, >> >> Take two examples I gave up getting to work: a Haskell wrapper for a >> popular GUI library; and a Haskell wrapper for a database. I >> understand > > Is this database HDBC? If so, then I would appreciate detailed > description of your problem so I can address it. If not, do you have > the same criticism of HDBC? From pbeadling at mail2web.com Sat Jan 10 12:17:29 2009 From: pbeadling at mail2web.com (Phil) Date: Sat Jan 10 12:09:04 2009 Subject: [Haskell-cafe] Shared library creating on Mac OS X In-Reply-To: Message-ID: I?ve made a bit of progress here after reading up on Darwin?s GCC a bit more: ghc --make -no-hs-main -fPIC -optl '-dynamiclib' -optl '-undefined' -optl 'suppress' -optl '-flat_namespace' -o Inv.dylib InverseNormal.hs This dies when it links against haskell?s own libraries, my guess is because they are position dependant. So the only way I see forward would be to recompile haskell with ??fPIC?. This seems like a lot of hassle, so I?m shelving this for now ? if anyone has any other (less distruptive) ways to proceed give me a shout ? even if it means linking statically. Cheers, Phil. Linker error now is: ld: warning codegen with reference kind 13 in _stg_CAF_BLACKHOLE_info prevents image from loading in dyld shared cache ld: absolute addressing (perhaps -mdynamic-no-pic) used in ___stginit_haskell98_Array_ from /usr/local/ghc/6.10.1/lib/ghc-6.10.1/haskell98-1.0.1.0/libHShaskell98-1.0.1. 0.a(Array__1.o) not allowed in slidable image collect2: ld returned 1 exit status On 10/01/2009 02:26, "Phil" wrote: > Hi, > > I?m hitting a problem trying create shared haskell libs to be linked into a C > program on Mac OS X. > > I?m using the latest download for Leopard from the GHC page: > http://www.haskell.org/ghc/dist/6.10.1/witten/ghc-6.10.1-powerpc-apple-darwin. > tar.bz2 > > I can get basic executables working fine (with a C main() #including ghc?s > stub header), using something like: > ghc -optc-O invnorm.c InverseNormal.o InverseNormal_stub.o -o cTest > > I started off using the following line to try to create a shared lib: > > ghc --make -no-hs-main -optl '-shared' -o Inv.so InverseNormal.hs > > This doesn?t work on mac os x because Apple?s gcc annoyingly takes different > switches, so I changed it to: > > ghc --make -no-hs-main -optl '-dynamiclib' -o Inv.dylib InverseNormal.hs > > Which still fails at the final link giving: > > Linking Inv.dylib ... > Undefined symbols: > "_environ", referenced from: > _environ$non_lazy_ptr in libHSbase-4.0.0.0.a(PrelIOUtils.o) > ld: symbol(s) not found > > I?ve seen similar things before, and I believe if you have full control over > the source you just slip in a: > > #define environ (*_NSGetEnviron()) > > Sure enough, I can find references to environ in, for example HsBase.h > > Problem (as I see it) is that references to environ are already wrapped up in > the static lib libHSbase-4.0.0.0.a, so without recompiling Haskell we can?t > alter the C definition now. However, given that packager must have made this > behave when he compiled the distribution there must be a way to make Mac gcc > accept _envrion symbols?? > > Has anyone seen this before / can confirm my analysis / and by any chance have > a solution? > > Many thanks, > > Phil. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090110/7e94a36c/attachment.htm From steve at fenestra.com Sat Jan 10 12:22:57 2009 From: steve at fenestra.com (Steve Schafer) Date: Sat Jan 10 12:14:20 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: <4968AAF4.2040108@libero.it> References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> <94oem4hfiqaskk4pdc5mn3d05l8p4hh6cf@4ax.com> <49676D31.109 0207@complete.org> <193gm4ldb2cichf8l3lgdbdhslhe7gifbf@4ax.com> <4968AAF4.2040108@libero.it> Message-ID: <59mhm496p2pjjjom5q11qcvhhshbsfotgi@4ax.com> On Sat, 10 Jan 2009 15:04:36 +0100, you wrote: >POSIX realtime extensions have been developed to be high reliable. I think people are missing the details here. Yes, the built-in real-time clocks have excellent long-term accuracy. They run UTC-based correction algorithms using NTP, and are thus traceable to TAI. However, they offer no guarantees on interval measurements, and the correction algorithms can cause the measurement of a time interval of an hour or so duration to be off by +/- 1 sec, especially within the first few hours after a cold boot. If you care about leap seconds, you should certainly care about that magnitude of error. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ From redcom at fedoms.com Sat Jan 10 13:14:28 2009 From: redcom at fedoms.com (=?iso-8859-15?Q?G=FCnther_Schmidt?=) Date: Sat Jan 10 13:06:09 2009 Subject: [Haskell-cafe] Re: Looking for Haskellers on Windows References: <4968B545.9050407@mail.ru> <4968C650.3090900@mail.ru> <4968D700.8040907@complete.org> Message-ID: Hi John, thx for responding :) I'm trying to analyze the HDBC code so that, maybe, I'm able to find the spot that's causing me trouble. Do you happen to have some documentation on how you desigend this? Also while digging through the code I learned some stuff that I found quite interessting. As an example I found the function "executeMany" to be part of a data declaration, now that's certainly something I as a newbie have never seen before, is there a special name for this technique? G?nther Am 10.01.2009, 18:12 Uhr, schrieb John Goerzen : > G?nther Schmidt wrote: >> Hi Kyra, >> >> and again, thanks for taking the effort. >> >> Kyra I've tried any sort of values to any sort of columns. I tried >> "insert >> into somesinglecolumntable (someNumbercolumn) values (?)" [toSql 5] ... >> and so on. >> >> So I'm not certain at all the error message does actually give the right >> clue. >> >> It just blows no matter what. >> >> What does work though is this: >> >> run dbc "insert into sometable (someVarcharcolumn) values ('some string >> value')" [] > > It is probably good to avoid this. HDBC does not provide SQL string > escaping functions because it is designed around the model of the > replacable parameters, which are more secure and more performant. You > will have to be very careful to sanitize input if you do take this > approach. > > As to the larger question, there are quite a few Windows Haskell users > out there. Some well-known Haskell personalities work for a division of > Microsoft, even. > > I am not sure that there are all that many people talking to Access > databases via ODBC to start with, though, but of course if anybody has a > patch to contribute, I'd be happy to apply it. > > -- John -- Erstellt mit Operas revolution?rem E-Mail-Modul: http://www.opera.com/mail/ From warrensomebody at gmail.com Sat Jan 10 13:21:31 2009 From: warrensomebody at gmail.com (Warren Harris) Date: Sat Jan 10 13:13:23 2009 Subject: [Haskell-cafe] teaching functional programming at work In-Reply-To: References: Message-ID: Thank you all for your responses on this. These ideas/materials are very helpful. In particular, the John Harrison book looks excellent (http://www.cl.cam.ac.uk/teaching/Lectures/funprog-jrh-1996/index.html ) -- a comprehensive and understandable introduction to all the concepts I had in mind. (I'm not sure what my audience's attention span will be though.) The WhyFP paper is also very good, although doesn't go into monads or types, it does a good job of illustrating modularity/composability. I'll send an update if this study group gets off the ground, to let you all know how it worked out. Warren -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090110/182d73c0/attachment.htm From andrewcoppin at btinternet.com Sat Jan 10 09:38:04 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Jan 10 13:26:16 2009 Subject: [Haskell-cafe] Looking for Haskellers on Windows In-Reply-To: References: <887509072.20090110171802@gmail.com> Message-ID: <4968B2CC.30302@btinternet.com> G?nther Schmidt wrote: > Hi Bulat, > > I do :), but I was amazed that there was no response to a post with, > what I thought, would be a rather common problem for an application > developer. That post was about writing to an MS-Access database via > HDBC-ODBC, which fails. When I then asked the HDBC maintainer himself > it turned out that he doesn't use Windows either and thus can't help. > > Thus my cry for help explicitly to Haskellers on Windows. If you managed to get HDBC-ODBC to compile on Windows in the first place, you got further than me... It's a pitty that Windows receives so little support, but I guess if nobody has a Windows box to test with, there's not much you can do about it. From dons at galois.com Sat Jan 10 13:37:40 2009 From: dons at galois.com (Don Stewart) Date: Sat Jan 10 13:28:56 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <1ECE588C-D97A-4807-A6AC-BE3F318D7BAA@n-brain.net> <814617240901081216t7232b5b6u884efd6e2b0bad40@mail.gmail.com> <30D797FA-F5B8-4267-8E16-33DF9C2BA3AD@n-brain.net> <814617240901090801n955808oe3cc74ee8c42e470@mail.gmail.com> Message-ID: <20090110183740.GA28848@scytale.galois.com> john: > On Jan 9, 2009, at 9:01 AM, Creighton Hogg wrote: > >2009/1/9 John A. De Goes : > >> > >>If you're looking for a project to take on, I would suggest > >>starting with > >>the following: > >> > >>A high-level, type-safe AMQP client written in 100% Haskell, which > >>provides > >>a clean way of handling hundreds of unique message types. > >> > >>Then it would be possible to hook it up to any AMQP broker (most > >>likely > >>RabbitMQ). There are logical steps beyond the above (an embedded > >>Haskell > >>broker), but the above project is far from trivial. And the main > >>undertaking, I think, consists not in coding to the spec (for which > >>there is > >>some help; a JSON representation of the AMQP specification can be > >>processed > >>and used to emit language-specific code), but in finding a design > >>that works > >>well in Haskell. > > > >I apologize, but my question was geared more towards understanding > >what high-level OTP-like libraries Haskell is lacking, not full blown > >applications that haven't been written in Haskell. It sounded like > >you had some specific insight into this. > > > A Haskell AMQP client is not an application, but a library that > Haskell applications would use (if it existed). The use of the word > "client" refers to the client/server metaphor used in centralized > message broker systems like AMQP. > > Regarding the OTP specifically, Haskell doesn't have anything like it. > Haskell has bits and pieces, but they're not integrated in a single > stack, and much functionality is missing. For example, there's no way > to dynamically poke running Haskell code, to see what it's doing; no > way to update code on the fly as a process is running; no scalable > distributed database system; etc. There are at least two ways to do dynamic code update, via compiled code, and via bytecode. -- Don From patperry at stanford.edu Sat Jan 10 13:43:52 2009 From: patperry at stanford.edu (Patrick Perry) Date: Sat Jan 10 13:35:21 2009 Subject: [Haskell-cafe] ANN: Haskell BLAS bindings version 0.7 In-Reply-To: <5e0214850901100907p63aed22dw9ca7784a30f2d3b5@mail.gmail.com> References: <56774369-38F2-4236-834B-DDC892401DDD@stanford.edu> <5e0214850901100907p63aed22dw9ca7784a30f2d3b5@mail.gmail.com> Message-ID: Thanks for the suggestion! Done and uploaded to hackage. Patrick On Jan 10, 2009, at 9:07 AM, Eugene Kirpichov wrote: > Why don't you put them into a separate non-hidden Unsafe module and > provide documentation for it? Users who don't care simply won't look > there, whereas users who do care (for whom you are providing access) > will still have a possibility to do so. > > 2009/1/10 Patrick Perry : >> The reason I want to expose modules but hide the documentation is >> because >> there are a lot of "unsafeX" functions I want to provide access to, >> but >> which 99% of users don't care about. The array library does the >> same thing. >> >> >> Patrick >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> From kyrab at mail.ru Sat Jan 10 13:48:02 2009 From: kyrab at mail.ru (kyra) Date: Sat Jan 10 13:39:33 2009 Subject: [Haskell-cafe] Looking for Haskellers on Windows In-Reply-To: <4968D700.8040907@complete.org> References: <4968B545.9050407@mail.ru> <4968C650.3090900@mail.ru> <4968D700.8040907@complete.org> Message-ID: <4968ED62.1040906@mail.ru> John Goerzen wrote: > G?nther Schmidt wrote: >> Kyra I've tried any sort of values to any sort of columns. I tried "insert >> into somesinglecolumntable (someNumbercolumn) values (?)" [toSql 5] ... >> and so on. >> >> So I'm not certain at all the error message does actually give the right >> clue. >> >> It just blows no matter what. It seems, I've managed to track down the issue. Access ODBC driver doesn't support sqlDescribeParam. bindCol (Database/HDBC/ODBC/Statement.hsc) contains the following stub for this: do poke pdtype #{const SQL_CHAR} poke pcolsize 0 poke pdecdigits 0 This does not work. I've made an experiment replacing 'poke pcolsize 0' with 'poke pcolsize 255'. Now all integer or varchar bindings work! It seems simpleSqlColumns or something similar must be used. Cheers, Kyra From redcom at fedoms.com Sat Jan 10 13:52:26 2009 From: redcom at fedoms.com (=?iso-8859-15?Q?G=FCnther_Schmidt?=) Date: Sat Jan 10 13:44:15 2009 Subject: [Haskell-cafe] Re: Looking for Haskellers on Windows References: <887509072.20090110171802@gmail.com> <4968B2CC.30302@btinternet.com> Message-ID: Andrew, even moral support is welcome. I'm on WinXP Pro here, using ghc 6.8.3, and cabal install. Maybe I can help with the installation problem, what did you do so far? G?nther Am 10.01.2009, 15:38 Uhr, schrieb Andrew Coppin : > G?nther Schmidt wrote: >> Hi Bulat, >> >> I do :), but I was amazed that there was no response to a post with, >> what I thought, would be a rather common problem for an application >> developer. That post was about writing to an MS-Access database via >> HDBC-ODBC, which fails. When I then asked the HDBC maintainer himself >> it turned out that he doesn't use Windows either and thus can't help. >> >> Thus my cry for help explicitly to Haskellers on Windows. > > If you managed to get HDBC-ODBC to compile on Windows in the first > place, you got further than me... > > It's a pitty that Windows receives so little support, but I guess if > nobody has a Windows box to test with, there's not much you can do about > it. -- Erstellt mit Operas revolution?rem E-Mail-Modul: http://www.opera.com/mail/ From dons at galois.com Sat Jan 10 14:15:25 2009 From: dons at galois.com (Don Stewart) Date: Sat Jan 10 14:06:58 2009 Subject: [Haskell-cafe] Looking for Haskellers on Windows In-Reply-To: References: Message-ID: <20090110191525.GB28848@scytale.galois.com> redcom: > Hi all, > > I'm looking for Haskell programmer that use Windows as their OS-Plattform. > I developing an application in Haskell on Windows and run into problems > that seem to have a lower priority with the greater Haskell community as > most of them are using Linux where the problems do not occur or are > already solved. > > So it'd be nice to get in touch with other Haskellers that face the same > problems. > Galois ships apps on Windows. We've developed windows installers and howtos for Haskell on Windows in the past, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bamse and this week, how to use a GMP DLL on Windows, http://haskell.forkio.com/gmpwindows There is a lack of a coherent 'Windows platform' as we have on the unix distros though, unfortunately. -- Don From redcom at fedoms.com Sat Jan 10 14:33:29 2009 From: redcom at fedoms.com (=?utf-8?Q?G=C3=BCnther_Schmidt?=) Date: Sat Jan 10 14:24:57 2009 Subject: [Haskell-cafe] Looking for Haskellers on Windows In-Reply-To: <4968ED62.1040906@mail.ru> References: <4968B545.9050407@mail.ru> <4968C650.3090900@mail.ru> <4968D700.8040907@complete.org> <4968ED62.1040906@mail.ru> Message-ID: Kyra, that is fantastic new! Victory is near, I can smell it hahahahahahahaha ... Um, sry for that, I'm just really really happy and glad I made that post today. I've been trying to get this issue resolved for more than 14 days now and if now solution had shown up on the horizon I would have been forced to dump Haskell and do it all over again in Smalltalk and really quick on top of it because the final deadline is Jan 19. The app is 95 % finished and really all that is missing is the bloody export to Access. Thank you very very much. G?nther Am 10.01.2009, 19:48 Uhr, schrieb kyra : > John Goerzen wrote: >> G?nther Schmidt wrote: >>> Kyra I've tried any sort of values to any sort of columns. I tried >>> "insert into somesinglecolumntable (someNumbercolumn) values (?)" >>> [toSql 5] ... and so on. >>> >>> So I'm not certain at all the error message does actually give the >>> right clue. >>> >>> It just blows no matter what. > > It seems, I've managed to track down the issue. > > Access ODBC driver doesn't support sqlDescribeParam. > > bindCol (Database/HDBC/ODBC/Statement.hsc) contains the following stub > for this: > > do poke pdtype #{const SQL_CHAR} > poke pcolsize 0 > poke pdecdigits 0 > > This does not work. > > I've made an experiment replacing 'poke pcolsize 0' with 'poke pcolsize > 255'. Now all integer or varchar bindings work! > > It seems simpleSqlColumns or something similar must be used. > > Cheers, > Kyra -- Erstellt mit Operas revolution?rem E-Mail-Modul: http://www.opera.com/mail/ From ryani.spam at gmail.com Sat Jan 10 14:45:26 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Sat Jan 10 14:36:50 2009 Subject: [Haskell-cafe] Re: Monads aren't evil In-Reply-To: References: <20090108231652.24b75fe3@tritium.xx> Message-ID: <2f9b2d30901101145q79041fe9q9781f90b2e533499@mail.gmail.com> My issue is that there seem to be many cases where the syntax extension does *almost* what I want, but not quite. And there isn't any method to extend it, so you are left with two choices: (1) Go back to unsugared syntax (2) Hack your technique into the constraints of the existing syntax extension. For example, "fail" is in the Monad class only because binding in "do" needs to handle pattern-match failure. But a better syntax extension wouldn't tie "do" to Monad only; it would allow pattern match failure to be handled by a separate class if needed, and allow additional extensions to deal with other cases where the existing syntax isn't quite good enough. This is where lisp-style syntactic macros show their real power. I'd go to TH but there's no way to make TH transparent. I almost wish that do ... and similar notations would just call a TH function to decode the expression! Then, if I wanted a different decoding I could just put a different "sugarDoNotation" function in scope. On a related note, I hate the explosion of <*>, <$>, liftM, etc. when working in monadic/applicative code. Often the code only typechecks with these lifting operators present, so why am I explaining to the compiler that I want it to use the applicative apply operator? When is strong typing going to help me write *less* code instead of *more*? We've solved the "type annotation" problem to my satisfaction via inference, but there is still a lot of what I would call "source annotation". For example, which of these is easier to read? f,g :: Int -> [Int] h1 :: Int -> [Int] h1 x = do fx <- f x gx <- g x return (fx + gx) h2 :: Int -> [Int] h2 x = (+) <$> f x <*> g x h3 :: Int -> [Int] h3 x = f x + g x -- not legal, of course, but wouldn't it be nice if it was? Of course this raises problems of order of evaluation, etc, but as long as such things were well-defined, that seems fine. If you want finer control, you can always go back to more verbose syntax. These cases are dominated by the cases where you simply don't care! This said, I don't want to sound overly negative; all of this pain is *worth* the correctness guarantees that I get when writing in Haskell. I just wish I could get the same guarantees with less pain! -- ryan 2009/1/10 Peter Verswyvelen : > Related to this issue, I have a question here. > I might be wrong, but it seems to me that some Haskellers don't like > writing monads (with do notation) or arrows (with proc sugar) because of the > fact they have to abandon the typical applicative syntax, which is so close > to the beautiful lambda calculus core. Or is it maybe because some people > choose monads were the less linear applicative style could be used instead, > so the choice of monads is not always appropriate. > Haskell is full of little hardcoded syntax extensions: list notation > syntactic, list comprehensions, and even operator precedence that reduces > the need for parentheses, etc... > > Of course IMHO the syntactic sugar is needed, e.g. a Yampa game written > without the arrows syntax would be incomprehensible for the average > programmer. But one could claim that this syntactic sugar hides what is > really going on under the hood, so for newcomers these extensions might make > it harder. It could also feel like a hack, a failure to keep things as > simple as possible yet elegant. > Some people I talked with like that about the Scheme/ & LISP languages: the > syntax remains ultimately close to the core, with very little hardcoded > syntactic extensions. And when one wants to add syntactic extensions, one > uses syntactic macros. > I'm not sure what others feel about the hardcoded syntax extensions in > Haskell... > > Personally I'm not that much of a purist, I'm an old school hacker that > mainly needs to get the job done. I like the syntax extensions in Haskell > (and even C#/F# ;) because they let me write code shorter and clearer... > On Fri, Jan 9, 2009 at 4:07 AM, Neal Alexander > wrote: >> >> Ertugrul Soeylemez wrote: >>> >>> Hello fellow Haskellers, >>> >>> When I read questions from Haskell beginners, it somehow seems like they >>> try to avoid monads and view them as a last resort, if there is no easy >>> non-monadic way. I'm really sure that the cause for this is that most >>> tutorials deal with monads very sparingly and mostly in the context of >>> input/output. Also usually monads are associated with the do-notation, >>> which makes them appear even more special, although there is really >>> nothing special about them. >>> >> >> Yea, i was the same way when i started learning Haskell. I understood how >> Monads worked, and what the motivation was for them, but not why i would >> want to restructure code to use them in specific instances. >> >> "Why should i care about monads when i can use Arrows or (.)" was also a >> factor. >> >> Its kinda like getting advice from an adult as a child. You have no >> particular reason to distrust the advice, but the value of it doesn't set in >> until something happens to you first hand to verify it. >> >> For me the turning point was writing some code that needed to handle >> running code locally/remotely in a transparent manner. >> >> Maybe having a list of real-world usage scenarios or exercises on the wiki >> may help. >> >> ______________________________ _________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From briqueabraque at yahoo.com Sat Jan 10 15:04:44 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Sat Jan 10 14:56:32 2009 Subject: [Haskell-cafe] Re: Looking for Haskellers on Windows In-Reply-To: <4968B2CC.30302@btinternet.com> References: <887509072.20090110171802@gmail.com> <4968B2CC.30302@btinternet.com> Message-ID: >> Hi Bulat, >> >> (...) >> >> Thus my cry for help explicitly to Haskellers on Windows. > > (...) > It's a pitty that Windows receives so little support, but I guess if > nobody has a Windows box to test with, there's not much you can do about > it. I think it deserves consideration: what about a mailing list like haskell-portability? If someone asks on this haskell-cafe for some way to do, say, USB on windows using Haskell, some answers would arrive; but if one asks at this, say, haskell-portability list, "I have a working Haskell USB library running everywhere except on Windows", it's likely to get the attention of people who do have deep OS understanding and are willing to do a big effort to solve a problem if that results in a new library that can be trusted at any OS. Maur?cio From bugfact at gmail.com Sat Jan 10 15:19:58 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Sat Jan 10 15:11:25 2009 Subject: [Haskell-cafe] Re: Monads aren't evil In-Reply-To: <2f9b2d30901101145q79041fe9q9781f90b2e533499@mail.gmail.com> References: <20090108231652.24b75fe3@tritium.xx> <2f9b2d30901101145q79041fe9q9781f90b2e533499@mail.gmail.com> Message-ID: > > For example, which of these is easier to read? > > f,g :: Int -> [Int] > > h1 :: Int -> [Int] > h1 x = do > fx <- f x > gx <- g x > return (fx + gx) > > h2 :: Int -> [Int] > h2 x = (+) <$> f x <*> g x > > h3 :: Int -> [Int] > h3 x = f x + g x -- not legal, of course, but wouldn't it be nice if it > was? > Yes, all that lifting is something that takes away lot of the beauty and simplicity of Haskell, but as far as my limited knowledge goes, I don't think this problem is easily solved :) Anyway, for your particular example, for newbies I guess the clearest would be: h0 x = [ fx+gx | fx <- f x, gx <- g x ] since one must recognize that a list monad exists and what it does... Now, for binary operators, Thomas Davie made a nice pair of combinators on Hackage (InfixApplicative) that would allow this to become: h3 x = f x <^(+)^> g x But in general, I guess you have a good point... > > Of course this raises problems of order of evaluation, etc, but as > long as such things were well-defined, that seems fine. If you want > finer control, you can always go back to more verbose syntax. These > cases are dominated by the cases where you simply don't care! > > This said, I don't want to sound overly negative; all of this pain is > *worth* the correctness guarantees that I get when writing in Haskell. > I just wish I could get the same guarantees with less pain! > > -- ryan > > > 2009/1/10 Peter Verswyvelen < bugfact@gmail.com>: > > Related to this issue, I have a question here. > > I might be wrong, but it seems to me that some Haskellers don't like > > writing monads (with do notation) or arrows (with proc sugar) because of > the > > fact they have to abandon the typical applicative syntax, which is so > close > > to the beautiful lambda calculus core. Or is it maybe because some people > > choose monads were the less linear applicative style could be used > instead, > > so the choice of monads is not always appropriate. > > Haskell is full of little hardcoded syntax extensions: list notation > > syntactic, list comprehensions, and even operator precedence that reduces > > the need for parentheses, etc... > > > > Of course IMHO the syntactic sugar is needed, e.g. a Yampa game written > > without the arrows syntax would be incomprehensible for the average > > programmer. But one could claim that this syntactic sugar hides what is > > really going on under the hood, so for newcomers these extensions might > make > > it harder. It could also feel like a hack, a failure to keep things as > > simple as possible yet elegant. > > Some people I talked with like that about the Scheme/ & LISP languages: > the > > syntax remains ultimately close to the core, with very little hardcoded > > syntactic extensions. And when one wants to add syntactic extensions, one > > uses syntactic macros. > > I'm not sure what others feel about the hardcoded syntax extensions in > > Haskell... > > > > Personally I'm not that much of a purist, I'm an old school hacker that > > mainly needs to get the job done. I like the syntax extensions in Haskell > > (and even C#/F# ;) because they let me write code shorter and clearer... > > On Fri, Jan 9, 2009 at 4:07 AM, Neal Alexander > > wrote: > >> > >> Ertugrul Soeylemez wrote: > >>> > >>> Hello fellow Haskellers, > >>> > >>> When I read questions from Haskell beginners, it somehow seems like > they > >>> try to avoid monads and view them as a last resort, if there is no easy > >>> non-monadic way. I'm really sure that the cause for this is that most > >>> tutorials deal with monads very sparingly and mostly in the context of > >>> input/output. Also usually monads are associated with the do-notation, > >>> which makes them appear even more special, although there is really > >>> nothing special about them. > >>> > >> > >> Yea, i was the same way when i started learning Haskell. I understood > how > >> Monads worked, and what the motivation was for them, but not why i would > >> want to restructure code to use them in specific instances. > >> > >> "Why should i care about monads when i can use Arrows or (.)" was also a > >> factor. > >> > >> Its kinda like getting advice from an adult as a child. You have no > >> particular reason to distrust the advice, but the value of it doesn't > set in > >> until something happens to you first hand to verify it. > >> > >> For me the turning point was writing some code that needed to handle > >> running code locally/remotely in a transparent manner. > >> > >> Maybe having a list of real-world usage scenarios or exercises on the > wiki > >> may help. > >> > >> ______________________________ _________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe@haskell.org > >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090110/6a970569/attachment.htm From briqueabraque at yahoo.com Sat Jan 10 15:25:37 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Sat Jan 10 15:17:23 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: <59mhm496p2pjjjom5q11qcvhhshbsfotgi@4ax.com> References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> <94oem4hfiqaskk4pdc5mn3d05l8p4hh6cf@4ax.com> <49676D31.109 0207@complete.org> <193gm4ldb2cichf8l3lgdbdhslhe7gifbf@4ax.com> <4968AAF4.2040108@libero.it> <59mhm496p2pjjjom5q11qcvhhshbsfotgi@4ax.com> Message-ID: >> POSIX realtime extensions have been developed to be high reliable. > > (...) However, they offer > no guarantees on interval measurements, and the correction algorithms > can cause the measurement of a time interval of an hour or so duration > to be off by +/- 1 sec, especially within the first few hours after a > cold boot. (...) At the start of this thread, my assumption was that all computers had a 100% reliable tick counter. Well, this shows I understand nothing about hardware. My problem is that the equipment I interact with is supposed to deliver data at a constant rate. Since I don't know how much its engineers care about patients, I wanted to be sure not to save wrong information. It wouldn't matter if the clock is saying we are on XVII century, as long as 10 seconds would never be 10.1. But, as I learned from you, my PC is not to be considered as a reference. Maybe the right approach is to ask people who understand hardware if mine is actually a valid concern. Thanks, Maur?cio From wagner.andrew at gmail.com Sat Jan 10 15:56:49 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Sat Jan 10 15:48:17 2009 Subject: [Haskell-cafe] Propositional logic implementation Message-ID: All, Is there some better way to do this? It seems like a lot of boilerplate. Thanks! http://hpaste.org/13807#a1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090110/2e6e9982/attachment.htm From manlio_perillo at libero.it Sat Jan 10 16:03:47 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Sat Jan 10 15:55:19 2009 Subject: [Haskell-cafe] Re: Issues with posix-realtime package In-Reply-To: <5ae4f2ba0901091358j3e08366jad674d8b6ae69405@mail.gmail.com> References: <5ae4f2ba0901091358j3e08366jad674d8b6ae69405@mail.gmail.com> Message-ID: <49690D33.5050005@libero.it> Galchin, Vasili ha scritto: > Hi Manlio, > > I am the author of this package. Let me think about what you have > said. > > Regards, Vasili If you can't reproduce the problem: there is a possibility that I have messed up my (GHC) system. I'm on Linux Debian Lenny. GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help :1:22: attempting to use module `System.IO' (System/IO.hs) which is not loaded :1:22: Not in scope: `System.IO.stderr' :1:22: Not in scope: `System.IO.stdin' ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): interactiveUI:setBuffering Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Yesterday there were no problems with ghci, and I don't remember having done something strange. P.S: the impossible can always happen! Thanks Manlio Perillo From manlio_perillo at libero.it Sat Jan 10 16:14:55 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Sat Jan 10 16:06:24 2009 Subject: [Haskell-cafe] System.CPUTime and picoseconds Message-ID: <49690FCF.3080704@libero.it> Hi. Just out of curiosity, but why Haskell 98 System.CPUTime library module uses picoseconds instead of, say, nanoseconds? At least on POSIX systems, picoseconds precision is *never* specified. Thanks Manlio Perillo From byorgey at seas.upenn.edu Sat Jan 10 16:30:08 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Jan 10 16:21:34 2009 Subject: [Haskell-cafe] Haskell Weekly News: Issue 100 - January 10, 2009 Message-ID: <20090110213008.GA8573@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20090110 Issue 100 - January 10, 2009 --------------------------------------------------------------------------- Welcome to issue 100 of HWN, a newsletter covering developments in the [1]Haskell community. Welcome to the 100th (!) issue of the Haskell Weekly News, suitably published on your friendly neighborhood HWN editor's 1000th birthday (base 3). If you ever have content to be included in the HWN (announcements, blog posts, major life news) or a suggestion on how the HWN could be more useful to you as a window into the goings-on of the Haskell community, please don't hesitate to send it along, using the contact information at the end of each issue. Announcements Haskell BLAS bindings version 0.7. Patrick Perry [2]announced the [3]release of version 0.7 of the [4]blas package, Haskell bindings to the BLAS (Basic Linear Algebra Subprograms) library. According to Patrick, this release is "a major milestone---it is finally the library with all of the features that I want." X Haskell Bindings. Antoine Latter [5]announced a preview release of the [6]X Haskell Bindings. The goal of the library is to provide low-level access to the X11 protocol, in the spirit of the [7]X C Bindings. Data.TCache 0.5.5. Alberto G. Corona [8]announced the 0.5.5 release of the [9]TCache package, a transactional data cache with configurable persistence. This version adds the the capability to safely handle transactions, and incrementally serialize many data types simultaneously in the same piece of code. haskell-src-exts 0.4.8. Niklas Broberg [10]announced a new release (0.4.8) of the [11]haskell-src-exts package. This is a bug-fix release in the wake of the flurry of bug reports due to [12]hlint. bytestring-trie 0.1.2 (bugfix). wren ng thornton [13]announced a bugfix release for [14]bytestring-trie, efficient finite maps from (byte)strings to values. This release fixes a bug in alterBy, and adds an Eq instance. wxHaskell 0.11.1. Jeremy O'Donoghue [15]announced the release of [16]wxHaskell 0.11.1, a Haskell binding for the wxWidgets GUI library. The main highlights include support for XRC resource files, support for wxWidgets 2.8.x and GHC 6.10, and preliminary support for Cabal and Hackage. cabal2doap 0.1. Greg Heartsfield [17]announced the [18]release of [19]Cabal2doap, which generates Description of a Project (DOAP) XML/RDF data representing a Haskell project. This should make it possible for semantic web project aggregation sites to find and index Haskell projects. Jobs Jane Street is hiring functional programmers. Yaron Minsky [20]reminded everyone that [21]Jane Street is still hiring! Jane Street now has over 30 OCaml developers, and is actively looking to hire more in Tokyo, London and New York. PhD, postdoc, and engineering positions at HATS. CFP [22]announced the availability of 10 PhD, postdoc, and engineering positions within the HATS project (Highly Adaptable and Trustworthy Software using Formal Models), a new Integrated Project funded by the European Union, within the programme "Future and Emerging Technologies" (FET). The goal of HATS is a tool-supported framework and formal methodology for the development of long-lived and trustworthy software systems. Hypothetical Haskell job in New York. Tony Hannan [23]asked how many would be interested in applying to a hypothetical Haskell job in New York, assuming his boss can be convinced to use Haskell. Blog noise [24]Haskell news from the [25]blogosphere. * Lennart Augustsson (augustss): [26]LLVM arithmetic. * GHC / OpenSPARC Project: [27]Bootstrapping 6. * Patrick Perry: [28]New Haskell BLAS bindings!. * Clemens Fruhwirth: [29]Liskell standalone. * The GHC Team: [30]Benchmarking recent improvements in parallelism. * Galois, Inc: [31]Tech Talk: OpenTheory: Package Management for Higher Order Logic Theories. * Eric Kow (kowey): [32]fold diagram revisited?. * GHC / OpenSPARC Project: [33]Bootstrapping 5. * Lennart Augustsson (augustss): [34]LLVM. * Sebastian Fischer: [35]Monadic and Queue-Based Tree Search. * Philip Wadler: [36]Well-typed programs can't be blamed. * GHC / OpenSPARC Project: [37]Bootstrapping 4. * Manuel M T Chakravarty: [38]GPU Kernels as Data-Parallel Array Computations in Haskell.. * GHC / OpenSPARC Project: [39]Bootstrapping 3. * Tom Schrijvers: [40]Monadic Constraint Programming. * Conal Elliott: [41]Another angle on functional future values. * >>> Greg Heartsfield: [42]Cabal2doap. * Christopher Lane Hinson: [43]MaybeArrow?. * GHC / OpenSPARC Project: [44]Bootstrapping 2. * Darcs: [45]darcs 2.2.0pre2 ready for testing!. * Alson Kemp: [46]Sad about Import Cycles. * GHC / OpenSPARC Project: [47]Bootstrapping. * gamr7: [48]Accessing Recursive Haskell Data Structures from C/Python. Quotes of the Week * jml: A wise man once said, "the program isn't debugged until the last user is dead". * pumpkin: OMG I <3 RECORD SYNTAX * Olathe: > floor (1.0/0.0) 179769... But you can see that Haskell can calculate the maximum Integer. * lilac: gha! I'm drowning in the haskell number hierarchy again drdozer: magic 8-ball says 'add calls to fromIntegral' * monopoly: do not exit IO. go directly to the REPL, do not pass any parameters or continuations. * EvilTerran: [on category theory] the same place of nightmares that spawned zygohistomorphic prepromorphisms :P About the Haskell Weekly News New editions are posted to [49]the Haskell mailing list as well as to [50]the Haskell Sequence and [51]Planet Haskell. [52]RSS is also available, and headlines appear on [53]haskell.org. To help create new editions of this newsletter, please see the information on [54]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [55]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://article.gmane.org/gmane.comp.lang.haskell.cafe/50195 3. http://quantile95.com/2009/01/09/new-haskell-blas-bindings/ 4. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/blas 5. http://article.gmane.org/gmane.comp.lang.haskell.cafe/50170 6. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xhb 7. http://xcb.freedesktop.org/ 8. http://article.gmane.org/gmane.comp.lang.haskell.cafe/50169 9. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/TCache 10. http://article.gmane.org/gmane.comp.lang.haskell.cafe/50119 11. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts 12. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hlint 13. http://article.gmane.org/gmane.comp.lang.haskell.cafe/49956 14. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-trie 15. http://article.gmane.org/gmane.comp.lang.haskell.cafe/49898 16. http://wxhaskell.sourceforge.net/ 17. http://article.gmane.org/gmane.comp.lang.haskell.general/16718 18. http://blog.gregheartsfield.com/2009/01/04/cabal2doap/ 19. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cabal2doap 20. http://article.gmane.org/gmane.comp.lang.haskell.general/16741 21. http://janestreet.com/ 22. http://article.gmane.org/gmane.comp.lang.haskell.general/16736 23. http://article.gmane.org/gmane.comp.lang.haskell.cafe/50015 24. http://planet.haskell.org/ 25. http://haskell.org/haskellwiki/Blog_articles 26. http://augustss.blogspot.com/2009/01/llvm-arithmetic-so-we-want-to-compute-x.html 27. http://ghcsparc.blogspot.com/2009/01/bootstrapping-6.html 28. http://quantile95.com/2009/01/09/new-haskell-blas-bindings/ 29. http://blog.clemens.endorphin.org/2009/01/liskell-standalone.html 30. http://ghcmutterings.wordpress.com/2009/01/09/46/ 31. http://www.galois.com/blog/2009/01/08/tech-talk-opentheory-package-management-for-higher-order-logic-theories/ 32. http://koweycode.blogspot.com/2009/01/fold-diagram-revisited.html 33. http://ghcsparc.blogspot.com/2009/01/bootstrapping-5.html 34. http://augustss.blogspot.com/2009/01/llvm-llvm-low-level-virtual-machine-is.html 35. http://www-ps.informatik.uni-kiel.de/~sebf/projects/monad-vs-queue.html 36. http://wadler.blogspot.com/2009/01/well-typed-programs-cant-be-blamed.html 37. http://ghcsparc.blogspot.com/2009/01/bootstrapping-4.html 38. http://justtesting.org/post/68696876 39. http://ghcsparc.blogspot.com/2009/01/bootstrapping-3.html 40. http://tomschrijvers.blogspot.com/2009/01/monadic-constraint-programming.html 41. http://conal.net/blog/posts/another-angle-on-functional-future-values/ 42. http://blog.gregheartsfield.com/2009/01/04/cabal2doap/ 43. http://blog.downstairspeople.org/2009/01/04/maybearrow/ 44. http://ghcsparc.blogspot.com/2009/01/test-run-of-patched-ghc-6.html 45. http://blog.darcs.net/2009/01/darcs-220pre2-ready-for-testing.html 46. http://www.alsonkemp.com/haskell/sad-about-import-cycles/ 47. http://ghcsparc.blogspot.com/2009/01/building.html 48. http://gamr7.com/blog/?p=66 49. http://www.haskell.org/mailman/listinfo/haskell 50. http://sequence.complete.org/ 51. http://planet.haskell.org/ 52. http://sequence.complete.org/node/feed 53. http://haskell.org/ 54. http://haskell.org/haskellwiki/HWN 55. http://code.haskell.org/~byorgey/code/hwn/ From redcom at fedoms.com Sat Jan 10 16:40:43 2009 From: redcom at fedoms.com (=?iso-8859-15?Q?G=FCnther_Schmidt?=) Date: Sat Jan 10 16:32:10 2009 Subject: [Haskell-cafe] Looking for Haskellers on Windows In-Reply-To: <4968ED62.1040906@mail.ru> References: <4968B545.9050407@mail.ru> <4968C650.3090900@mail.ru> <4968D700.8040907@complete.org> <4968ED62.1040906@mail.ru> Message-ID: Hi Kyra, IT WORKS! Thank you very much, my application is now almost finished. It was a whole lot of fun writing this in Haskell, but the last 2 weeks where frustrating, until today. I am amazed at the possibilities Haskell gives me in wiring code together and I would not want to miss it by having to go back and do the whole app again in Smalltalk. G?nther From vigalchin at gmail.com Sat Jan 10 17:14:13 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat Jan 10 17:05:42 2009 Subject: [Haskell-cafe] Re: Issues with posix-realtime package In-Reply-To: <49688C16.8070506@libero.it> References: <5ae4f2ba0901091358j3e08366jad674d8b6ae69405@mail.gmail.com> <4967DDFD.2090105@libero.it> <5ae4f2ba0901092127p6228bb66ubf23b9b28e5f77c6@mail.gmail.com> <49688C16.8070506@libero.it> Message-ID: <5ae4f2ba0901101414m63725480ofe66069d3a8e7c04@mail.gmail.com> On Sat, Jan 10, 2009 at 5:52 AM, Manlio Perillo wrote: > Galchin, Vasili ha scritto: > >> Manlio, >> >> so compiling to native machine code works ok but if using ghci byte-code >> interpreter doesn't ..... can you supply your program please? >> >> > Right. > Can't you reproduce the problem? > > The program is very simple (I was just testing your package, since I > suggested the use of clock_gettime to Mauricio in a previous post): > > import System.Posix.Realtime.RTTime > import System.Posix.Realtime.RTDataTypes > > > main = do > time <- clockGetTime Clock_Monotonic; > print $ tvSec time > print $ tvNsec time > > > runghc rttime.hs > > > I suspect that this is a problem with shared library loading in ghci, since > the C code you use for your package, is also used by the base package (for > the Posix subsystem). > > By the way: I don't see reasons to add all that code, since it is not used. ^^^ which code? > > However, when I tried to remove all the unused code, executing the program > gave me a stack exception (maybe I have removed too many things...). > > > > One personal note: I don't like `tvSec` and `tvNsec`, I think `seconds` and > `nanoSeconds` is a better choice. > ^^^ ok .. I agree and will change. I asked others for > criticisms(constructive) when I put to hackage but didn't get any. This is > good ... > > Also, it would useful a function to compute elapsed time (maybe a general > class in base package, and a specialized instance declaration in > posix-realtime for the timespec?) > > > Vasili >> >> > > [...] > > > > Manlio > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090110/40832062/attachment-0001.htm From manlio_perillo at libero.it Sat Jan 10 17:30:32 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Sat Jan 10 17:21:59 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> <94oem4hfiqaskk4pdc5mn3d05l8p4hh6cf@4ax.com> <49676D31.109 0207@complete.org> <193gm4ldb2cichf8l3lgdbdhslhe7gifbf@4ax.com> <4968AAF4.2040108@libero.it> <59mhm496p2pjjjom5q11qcvhhshbsfotgi@4ax.com> Message-ID: <49692188.7070706@libero.it> Mauricio ha scritto: >>> POSIX realtime extensions have been developed to be high reliable. >> >> (...) However, they offer >> no guarantees on interval measurements, and the correction algorithms >> can cause the measurement of a time interval of an hour or so duration >> to be off by +/- 1 sec, especially within the first few hours after a >> cold boot. (...) > > At the start of this thread, my assumption was that > all computers had a 100% reliable tick counter. High Precision Event Timer (http://en.wikipedia.org/wiki/HPET) should be pretty reliable, but it will never be as reliable as a dedicated clock. > Well, > this shows I understand nothing about hardware. > > My problem is that the equipment I interact with is > supposed to deliver data at a constant rate. What is the rate value? How do you read the data? > Since > I don't know how much its engineers care about > patients, I wanted to be sure not to save wrong > information. You should trust the engineers, IMHO, since that is a medical equipment and should be more reliable than a PC. Read carefully the equipment specification. > It wouldn't matter if the clock is > saying we are on XVII century, as long as 10 seconds > would never be 10.1. > > But, as I learned from you, my PC is not to be > considered as a reference. Maybe the right approach > is to ask people who understand hardware if mine is > actually a valid concern. > If you can, you should ask to the equipment producer. If you are on a POSIX system, store both the time information from the equiment and from clock_gettime(CLOCK_MONOTONIC), but only trust the equipment. > Thanks, > Maur?cio > Regards Manlio From manlio_perillo at libero.it Sat Jan 10 17:37:21 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Sat Jan 10 17:29:01 2009 Subject: [Haskell-cafe] Re: Issues with posix-realtime package In-Reply-To: <5ae4f2ba0901101414m63725480ofe66069d3a8e7c04@mail.gmail.com> References: <5ae4f2ba0901091358j3e08366jad674d8b6ae69405@mail.gmail.com> <4967DDFD.2090105@libero.it> <5ae4f2ba0901092127p6228bb66ubf23b9b28e5f77c6@mail.gmail.com> <49688C16.8070506@libero.it> <5ae4f2ba0901101414m63725480ofe66069d3a8e7c04@mail.gmail.com> Message-ID: <49692321.6080308@libero.it> Galchin, Vasili ha scritto: > [...] > I suspect that this is a problem with shared library loading in > ghci, since the C code you use for your package, is also used by the > base package (for the Posix subsystem). > > By the way: I don't see reasons to add all that code, since it is > not used. > > ^^^ which code? > Code from HsUnix.h and execvpe.h. > > > One personal note: I don't like `tvSec` and `tvNsec`, I think > `seconds` and `nanoSeconds` is a better choice. > ^^^ ok .. I agree and will change. I asked others for > criticisms(constructive) when I put to hackage but didn't get any. > This is good ... > I would like to help to develope any wrappers around POSIX API. Manlio From haskell at list.mightyreason.com Sat Jan 10 18:00:13 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Sat Jan 10 17:52:10 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> <94oem4hfiqaskk4pdc5mn3d05l8p4hh6cf@4ax.com> <49676D31.109 0207@complete.org> <193gm4ldb2cichf8l3lgdbdhslhe7gifbf@4ax.com> <4968AAF4.2040108@libero.it> <59mhm496p2pjjjom5q11qcvhhshbsfotgi@4ax.com> Message-ID: Mauricio wrote: > patients, I wanted to be sure not to save wrong > information. It wouldn't matter if the clock is > saying we are on XVII century, as long as 10 seconds > would never be 10.1. > Chris (yes I am an experimental physicist) asks: What are the interval durations you need to measure? 0.1 second is very different from 1 ms or 0.1 ?s ! (1 ms is the atomic time radio signal accuracy) (0.1 ?s can be had with GPS receivers) Since they are from equipment, what is the spec? What is the error tolerance for these durations? How are these errors allowed or forbidden to accumulate? Since you say you do not trust the incoming timing then you need to be able to measure it. Do you need to monitor the timing of each and every measurement while running? Could you measure and certify the timing of the equipment before using it? Got a cheap oscilloscope? From miguelimo38 at yandex.ru Sat Jan 10 18:04:20 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Sat Jan 10 17:56:16 2009 Subject: [Haskell-cafe] Propositional logic implementation In-Reply-To: References: Message-ID: <582F11E4-162E-46B2-82D6-13E2B801C5B8@yandex.ru> Look at SYB (Data.Data, Data.Generics.*). For example, your "symbols" function can be rewritten as symbols :: Sentence -> [Symbol] symbols s = nub $ listify (const True) s "true" is not that simple, because this code is NOT boilerplate - each alternative is valuable by itself. On 10 Jan 2009, at 23:56, Andrew Wagner wrote: > All, > Is there some better way to do this? It seems like a lot of > boilerplate. Thanks! > > http://hpaste.org/13807#a1 > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From haskell at list.mightyreason.com Sat Jan 10 18:06:13 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Sat Jan 10 17:58:11 2009 Subject: [Haskell-cafe] Re: System.CPUTime and picoseconds In-Reply-To: <49690FCF.3080704@libero.it> References: <49690FCF.3080704@libero.it> Message-ID: Manlio Perillo wrote: > Hi. > > Just out of curiosity, but why Haskell 98 System.CPUTime library module > uses picoseconds instead of, say, nanoseconds? > > At least on POSIX systems, picoseconds precision is *never* specified. > I have not idea. But at a guess, I would say that 1 ns is not such a small time interval anymore. The CPU speeds are about 3 GHz, so 0.3 ns per CPU clock. Even the RAM clock in a laptop (e.g. Apple's 17" Mac Pro) is 1066 MHz, so the internal there is just under 1 ns. Whoever picked picoseconds has made it possible to talk about a single clock interval for hardware like this. -- Chris From donn at avvanta.com Sat Jan 10 18:11:41 2009 From: donn at avvanta.com (Donn Cave) Date: Sat Jan 10 18:04:56 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> <20090108221549.GA30539@hustlerturf.com> <4438705C-9069-4780-B6A9-7E928997D6EA@n-brain.net> <49676BEF.9050005@complete.org> Message-ID: <20090110231141.6B5DC93C4C@mail.avvanta.com> Quoth "John A. De Goes" : | Take a language like Ruby or Python (or Java, or C#, etc.). The vast | majority of code written in these languages does not "get down to the | C level". When I say, "vast majority", I'm referring to > 99.999%. | That's because the standard libraries provide sufficiently | comprehensive platform-agnostic abstractions to do what most people | need to do. As a result, libraries for these languages are built on | the standard libraries, and do not require native code. Maybe I haven't been paying enough attention, but I see Python and Haskell in about the same position on this, especially in light of how different they are (Haskell's FFI is a lot easier!) Plenty of Python software depends on C library modules and foreign code. The particular examples you mention - DB and UI - are great examples where it's sort of crazy to do otherwise for just the reasons you go on to list. Of the cases I myself am familiar with in these languages, LDAP is the one that seems most likely to benefit from a native implementation, as Perl does (but not Python.) The protocol is fairly simple, and the common open source C implementation makes an awkward FFI and is relatively troublesome to install and maintain. But it also represents a long legacy of hacks and features that allow it to interoperate as well as it does with other implementations that supposedly also support this same "fairly simple" protocol, a history that would be expensive and unpleasant to repeat just for the sake of a cleaner interface. The arguments you list in favor of native code are reasonable (though some of them cut both ways - in particular it's a bold assertion that bug fixes and general development are more likely in a Haskell implementation, compared to a widely used C implementation that it parallels.) But each case has its own merits, and it's perilous to generalize. It would have been absurd for Python to take the approach that Java takes (lacking the major corporate backing), and probably so also for Haskell. (Though Haskell may in the end need it for APIs that involve I/O, the way things seem to be going in GHC.) Donn From vigalchin at gmail.com Sat Jan 10 19:03:03 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat Jan 10 18:55:21 2009 Subject: [Haskell-cafe] Re: Issues with posix-realtime package In-Reply-To: <49692321.6080308@libero.it> References: <5ae4f2ba0901091358j3e08366jad674d8b6ae69405@mail.gmail.com> <4967DDFD.2090105@libero.it> <5ae4f2ba0901092127p6228bb66ubf23b9b28e5f77c6@mail.gmail.com> <49688C16.8070506@libero.it> <5ae4f2ba0901101414m63725480ofe66069d3a8e7c04@mail.gmail.com> <49692321.6080308@libero.it> Message-ID: <5ae4f2ba0901101603kc6ed063ma599d80b07eccc79@mail.gmail.com> On Sat, Jan 10, 2009 at 4:37 PM, Manlio Perillo wrote: > Galchin, Vasili ha scritto: > >> [...] >> I suspect that this is a problem with shared library loading in >> ghci, since the C code you use for your package, is also used by the >> base package (for the Posix subsystem). >> >> By the way: I don't see reasons to add all that code, since it is >> not used. >> >> ^^^ which code? >> >> > Code from HsUnix.h and execvpe.h. > > >> >> One personal note: I don't like `tvSec` and `tvNsec`, I think >> `seconds` and `nanoSeconds` is a better choice. >> ^^^ ok .. I agree and will change. I asked others for >> criticisms(constructive) when I put to hackage but didn't get any. >> This is good ... >> > > I would like to help to develope any wrappers around POSIX API. ^^^ you are suggesting to change current wrapper API? Vasili > > > > Manlio > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090110/1ea42805/attachment.htm From wagner.andrew at gmail.com Sat Jan 10 19:44:50 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Sat Jan 10 19:36:19 2009 Subject: [Haskell-cafe] Propositional logic implementation In-Reply-To: <582F11E4-162E-46B2-82D6-13E2B801C5B8@yandex.ru> References: <582F11E4-162E-46B2-82D6-13E2B801C5B8@yandex.ru> Message-ID: Nice Idea, though I don't know that I want something that extensive. I was more looking for whether there was a better way I could define the algebraic data type. On Sat, Jan 10, 2009 at 6:04 PM, Miguel Mitrofanov wrote: > Look at SYB (Data.Data, Data.Generics.*). For example, your "symbols" > function can be rewritten as > > symbols :: Sentence -> [Symbol] > symbols s = nub $ listify (const True) s > > "true" is not that simple, because this code is NOT boilerplate - each > alternative is valuable by itself. > > > On 10 Jan 2009, at 23:56, Andrew Wagner wrote: > > All, >> Is there some better way to do this? It seems like a lot of boilerplate. >> Thanks! >> >> http://hpaste.org/13807#a1 >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090110/f7c8ac5d/attachment.htm From allbery at ece.cmu.edu Sat Jan 10 20:35:55 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Jan 10 20:27:43 2009 Subject: [Haskell-cafe] Re: Monads aren't evil In-Reply-To: References: <20090108231652.24b75fe3@tritium.xx> <2f9b2d30901101145q79041fe9q9781f90b2e533499@mail.gmail.com> Message-ID: On 2009 Jan 10, at 15:19, Peter Verswyvelen wrote: > h3 x = f x <^(+)^> g x Is that an operator or Batman? (yes, I know, 3 operators) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090110/c78d0242/attachment.htm From wagner.andrew at gmail.com Sat Jan 10 20:42:54 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Sat Jan 10 20:34:16 2009 Subject: [Haskell-cafe] Re: Monads aren't evil In-Reply-To: References: <20090108231652.24b75fe3@tritium.xx> <2f9b2d30901101145q79041fe9q9781f90b2e533499@mail.gmail.com> Message-ID: Holy concatenated operators, Batman! Is that an operator or Batman? > (yes, I know, 3 operators) > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090110/c9f22418/attachment.htm From schlepptop at henning-thielemann.de Sat Jan 10 21:04:18 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Sat Jan 10 20:49:37 2009 Subject: [Haskell-cafe] ANN: Haskell BLAS bindings version 0.7 In-Reply-To: References: <56774369-38F2-4236-834B-DDC892401DDD@stanford.edu> Message-ID: <496953A2.8050607@henning-thielemann.de> Patrick Perry schrieb: > The reason I want to expose modules but hide the documentation is > because there are a lot of "unsafeX" functions I want to provide access > to, but which 99% of users don't care about. The array library does the > same thing. Alternatively, the DEPRECATED pragma may prevent programmers from using these functions too extensively. However, this may be considered abuse of this pragma. I think the Unsafe module is the cleanest solution. From schlepptop at henning-thielemann.de Sat Jan 10 21:19:03 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Sat Jan 10 21:04:23 2009 Subject: [Haskell-cafe] Syntactic Sugar (Was: Monads aren't evil) In-Reply-To: References: <20090108231652.24b75fe3@tritium.xx> Message-ID: <49695717.7090804@henning-thielemann.de> Peter Verswyvelen schrieb: > Related to this issue, I have a question here. > > I might be wrong, but it seems to me that some Haskellers don't like > writing monads (with do notation) or arrows (with proc sugar) because of > the fact they have to abandon the typical applicative syntax, which is > so close to the beautiful lambda calculus core. Or is it maybe because > some people choose monads were the less linear applicative style could > be used instead, so the choice of monads is not always appropriate. > > Haskell is full of little hardcoded syntax extensions: list notation > syntactic, list comprehensions, and even operator precedence that > reduces the need for parentheses, etc... http://www.haskell.org/haskellwiki/Syntactic_sugar/Cons From schlepptop at henning-thielemann.de Sat Jan 10 21:25:33 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Sat Jan 10 21:10:42 2009 Subject: [Haskell-cafe] Infix expressions (Was: Monads aren't evil) In-Reply-To: References: <20090108231652.24b75fe3@tritium.xx> <2f9b2d30901101145q79041fe9q9781f90b2e533499@mail.gmail.com> Message-ID: <4969589D.5080908@henning-thielemann.de> Peter Verswyvelen schrieb: > Now, for binary operators, Thomas Davie made a nice pair of combinators > on Hackage (InfixApplicative) that would allow this to become: > > h3 x = f x <^(+)^> g x http://www.haskell.org/haskellwiki/Infix_expressions From holgersiegel74 at yahoo.de Sat Jan 10 22:00:25 2009 From: holgersiegel74 at yahoo.de (Holger Siegel) Date: Sat Jan 10 21:52:15 2009 Subject: [Haskell-cafe] Propositional logic implementation In-Reply-To: References: <582F11E4-162E-46B2-82D6-13E2B801C5B8@yandex.ru> Message-ID: <200901110400.25392.holgersiegel74@yahoo.de> On Sunday 11 January 2009 01:44:50 Andrew Wagner wrote: > Nice Idea, though I don't know that I want something that extensive. I was > more looking for whether there was a better way I could define the > algebraic data type. Let's have a look at your definitions from http://hpaste.org/13807#a1 : > data Sentence = Atomic Atom | Complex Complex The distinction between atomic expressions and complex expressions seems to be merely academic: None of your functions actually distinguishes between them. Thus, I suggest that you move the constructors of type Atom and Complex to type Sentence. The only place where type Atom is used is in the following declaration: > newtype Model = Model [Atom] But a close look at function true :: Model -> Sentence -> Bool reveals that it is sufficient to make a model a list of symbols. Therefore, we modify type Model to type Model = [Symbol] If Symbol was an instance of type class Ord, we could even move from lists to sets: import qualified Data.Set as Set type Model = Set.Set Symbol Then function symbols could also return sets of symbols, allowing for a much more efficient implementation via Set.union instead of List.nub and List.++: symbols :: Sentence -> Set.Set Symbol > data Atom = T | F | Symbol Symbol deriving Eq In function symbols you need to distinguish between symbols and other values of type Atom. With your current definition, function symbol must evaluate every atom to a concrete truthvalue. We can avoid this by defining Atom as data Atom = Const Bool | Symbol Symbol deriving Eq > data Symbol = A | B | C | P | Q | R | X | Y | Z | Label String deriving Eq I don't like two things about this definition: 1) There are two kinds of symbols, but there is no clear distinction between them. Instead, String-type labels are modelled as one special case of a symbol. 2) You enumerate characters explicitly. Instead, you could use type Char for single-character symbols. If you define symbols by type Symbol = Either Char String then you have a clear distinction between single-character symbols and labels, and you also get the above-mentioned instance of typeclass Ord for free. > data Complex = Not Sentence > | Sentence :/\: Sentence > | Sentence :\/: Sentence > | Sentence :=>: Sentence > | Sentence :<=>: Sentence There are some opportunities to reduce the number of constructors in this declaration. Constructor :=>: can easily be replaced by a function (==>) :: Sentence -> Sentence -> Sentence a ==> b = Not a :/\: b You can even define true, false, negation, conjunction and disjunction in terms of a newly introduced constructor Nand [Sentence] so that false = Nand [] true = Nand [false] Operator <=> can also be expressed in terms of Nand, but that would lead to duplicated work in function symbol and function true. Thus, we keep constructor :<=>:. The resulting declarations are data Sentence = Nand [Sentence] | Sentence :<=>: Sentence | Symbol Symbol type Symbol = Either Char String type Model = Set.Set Symbol This will reduce your boilerplate code to a minimum. :) Regards, Holger From ryani.spam at gmail.com Sat Jan 10 22:08:24 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Sat Jan 10 21:59:48 2009 Subject: [Haskell-cafe] Propositional logic implementation In-Reply-To: References: <582F11E4-162E-46B2-82D6-13E2B801C5B8@yandex.ru> Message-ID: <2f9b2d30901101908x4689cc7em4b25fe7418739f69@mail.gmail.com> I like using smart constructors to replace :<=>: and :=>: a \/ b = a :\/: b a /\ b = a :/\: b a ==> b = Not a \/ b a <=> b = (a ==> b) /\ (b ==> a) Also, if you generalize Sentence a bit you get a really nice formulation of "true". See my paste at http://hpaste.org/13807#a2 -- ryan 2009/1/10 Andrew Wagner : > Nice Idea, though I don't know that I want something that extensive. I was > more looking for whether there was a better way I could define the algebraic > data type. > > On Sat, Jan 10, 2009 at 6:04 PM, Miguel Mitrofanov > wrote: >> >> Look at SYB (Data.Data, Data.Generics.*). For example, your "symbols" >> function can be rewritten as >> >> symbols :: Sentence -> [Symbol] >> symbols s = nub $ listify (const True) s >> >> "true" is not that simple, because this code is NOT boilerplate - each >> alternative is valuable by itself. >> >> On 10 Jan 2009, at 23:56, Andrew Wagner wrote: >> >>> All, >>> Is there some better way to do this? It seems like a lot of boilerplate. >>> Thanks! >>> >>> http://hpaste.org/13807#a1 >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From apfelmus at quantentunnel.de Sun Jan 11 04:44:40 2009 From: apfelmus at quantentunnel.de (Apfelmus, Heinrich) Date: Sun Jan 11 04:35:43 2009 Subject: [Haskell-cafe] Monads aren't evil? I think they are. In-Reply-To: <20090108231652.24b75fe3@tritium.xx> References: <20090108231652.24b75fe3@tritium.xx> Message-ID: Ertugrul Soeylemez wrote: > Let me tell you that usually 90% of my code is > monadic and there is really nothing wrong with that. I use especially > State monads and StateT transformers very often, because they are > convenient and are just a clean combinator frontend to what you would do > manually without them: passing state. The insistence on avoiding monads by experienced Haskellers, in particular on avoiding the IO monad, is motivated by the quest for elegance. The IO and other monads make it easy to fall back to imperative programming patterns to "get the job done". But do you really need to pass state around? Or is there a more elegant solution, an abstraction that makes everything fall into place automatically? Passing state is a valid implementation tool, but it's not a design principle. A good example is probably the HGL (Haskell Graphics Library), a small vector graphics library which once shipped with Hugs. The core is the type Graphic which represents a drawing and whose semantics are roughly Graphic = Pixel -> Color There are primitive graphics like empty :: Graphic polygon :: [Point] -> Graphic and you can combine graphics by laying them on top of each other over :: Graphic -> Graphic -> Graphic This is an elegant and pure interface for describing graphics. After having constructed a graphic, you'll also want to draw it on screen, which can be done with the function drawInWindow :: Graphic -> Window -> IO () This function is in the IO monad because it has the side-effect of changing the current window contents. But just because drawing on a screen involves IO does not mean that using it for describing graphics is a good idea. However, using IO for *implementing* the graphics type is fine type Graphics = Window -> IO () empty = \w -> return () polygon (p:ps) = \w -> moveTo p w >> mapM_ (\p -> lineTo p w) ps over g1 g2 = \w -> g1 w >> g2 w drawInWindow = id Consciously excluding monads and restricting the design space to pure functions is the basic tool of thought for finding such elegant abstractions. As Paul Hudak said in his message "A regressive view of support for imperative programming in Haskell" In my opinion one of the key principles in the design of Haskell has been the insistence on purity. It is arguably what led the Haskell designers to "discover" the monadic solution to IO, and is more generally what inspired many researchers to "discover" purely functional solutions to many seemingly imperative problems. http://article.gmane.org/gmane.comp.lang.haskell.cafe/27214 The philosophy of Haskell is that searching for purely functional solution is well worth it. Regards, H. Apfelmus From es at ertes.de Sun Jan 11 05:10:16 2009 From: es at ertes.de (Ertugrul Soeylemez) Date: Sun Jan 11 05:01:55 2009 Subject: [Haskell-cafe] Re: Monads aren't evil? I think they are. References: <20090108231652.24b75fe3@tritium.xx> Message-ID: <20090111111016.492d7dc9@tritium.xx> "Apfelmus, Heinrich" wrote: > Ertugrul Soeylemez wrote: > > > Let me tell you that usually 90% of my code is monadic and there is > > really nothing wrong with that. I use especially State monads and > > StateT transformers very often, because they are convenient and are > > just a clean combinator frontend to what you would do manually > > without them: passing state. > > The insistence on avoiding monads by experienced Haskellers, in > particular on avoiding the IO monad, is motivated by the quest for > elegance. > > The IO and other monads make it easy to fall back to imperative > programming patterns to "get the job done". [...] Often, the monadic solution _is_ the elegant solution. Please don't confuse monads with impure operations. I use the monadic properties of lists, often together with monad transformers, to find elegant solutions. As long as you're not abusing monads to program imperatively, I think, they are an excellent and elegant structure. I said that 90% of my code is monadic, not that 90% of it is in IO. I do use state monads where there is no more elegant solution than passing state around. It's simply that: you have a structure, which you modify continuously in a complex fashion, such as a neural network or an automaton. Monads are the way to go here, unless you want to do research and find a better way to express this. Personally I prefer this: somethingWithRandomsM :: (Monad m, Random a) => m a -> Something a over these: somethingWithRandoms1 :: [a] -> Something a somethingWithRandoms2 :: RandomGen g => g -> Something a Also I use monads a lot for displaying progress: lengthyComputation :: Monad m => (Progress -> m ()) -> m Result > Consciously excluding monads and restricting the design space to pure > functions is the basic tool of thought for finding such elegant > abstractions. [...] You don't need to exclude monads to restrict the design space to pure functions. Everything except IO and ST (and some related monads) is pure. As said, often monads _are_ the elegant solutions. Just look at parser monads. Greets, Ertugrul. -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/ From lennart at augustsson.net Sun Jan 11 05:23:58 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Sun Jan 11 05:15:18 2009 Subject: [Haskell-cafe] Re: System.CPUTime and picoseconds In-Reply-To: References: <49690FCF.3080704@libero.it> Message-ID: It was suggested that it should be ns, and I complained that ns would be obsolete in a while. What I really wanted was a switch to Double (and just using seconds), instead we got ps. At least ps won't get obsolete in a while. -- Lennart On Sun, Jan 11, 2009 at 12:06 AM, ChrisK wrote: > Manlio Perillo wrote: >> >> Hi. >> >> Just out of curiosity, but why Haskell 98 System.CPUTime library module >> uses picoseconds instead of, say, nanoseconds? >> >> At least on POSIX systems, picoseconds precision is *never* specified. >> > > I have not idea. But at a guess, I would say that 1 ns is not such a small > time interval anymore. The CPU speeds are about 3 GHz, so 0.3 ns per CPU > clock. Even the RAM clock in a laptop (e.g. Apple's 17" Mac Pro) is 1066 > MHz, so the internal there is just under 1 ns. > > Whoever picked picoseconds has made it possible to talk about a single clock > interval for hardware like this. > > -- > Chris > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From es at ertes.de Sun Jan 11 05:37:22 2009 From: es at ertes.de (Ertugrul Soeylemez) Date: Sun Jan 11 05:28:58 2009 Subject: [Haskell-cafe] Re: Monads aren't evil? I think they are. References: <20090108231652.24b75fe3@tritium.xx> <20090111111016.492d7dc9@tritium.xx> Message-ID: <20090111113722.3c84182b@tritium.xx> Ertugrul Soeylemez wrote: > Personally I prefer this: > > somethingWithRandomsM :: (Monad m, Random a) => m a -> Something a Of course, there is something missing here: somethingWithRandomsM :: (Monad m, Random a) => m a -> m (Something a) Sorry. Greets, Ertugrul. -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/ From jason.dusek at gmail.com Sun Jan 11 06:32:43 2009 From: jason.dusek at gmail.com (Jason Dusek) Date: Sun Jan 11 06:24:05 2009 Subject: [Haskell-cafe] Re: Monads aren't evil In-Reply-To: References: <20090108231652.24b75fe3@tritium.xx> <2f9b2d30901101145q79041fe9q9781f90b2e533499@mail.gmail.com> Message-ID: <42784f260901110332w665aaa7di403dcd3c3bb8b119@mail.gmail.com> It is really too bad we can not define the operators >_> ^_^ <_< These are significant from an internationalization standpoint; and they'd make the language so much more competitive vis-a-vis LOLCode. -- Jason Dusek 2009/1/10 Brandon S. Allbery KF8NH : > On 2009 Jan 10, at 15:19, Peter Verswyvelen wrote: > > h3 x = f x <^(+)^> g x > > Is that an operator or Batman? > (yes, I know, 3 operators) > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From the.dead.shall.rise at gmail.com Sun Jan 11 08:12:02 2009 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Sun Jan 11 08:06:25 2009 Subject: [Haskell-cafe] Declaring each instance of a typeclass to be also an instance of another typeclass Message-ID: Hi, Is it possible to write something like this: > {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} > > import Control.Monad (liftM) > > instance (Monad a) => Functor a where > fmap = liftM without having to use UndecidableInstances (and preferably, other type system extensions too)? From duncan.coutts at worc.ox.ac.uk Sun Jan 11 09:13:19 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jan 11 09:04:40 2009 Subject: [Haskell-cafe] Re: [Haskell] HaskellWiki Upgrade Aborted In-Reply-To: <4969614A.2020403@semantic.org> References: <4969524E.2010209@semantic.org> <4969614A.2020403@semantic.org> Message-ID: <1231683199.4794.67.camel@localhost> On Sat, 2009-01-10 at 19:02 -0800, Ashley Yakeley wrote: > I have given up attempting to upgrade HaskellWiki, and resumed the > site's previous normal operation. > > I wrote: > > I will also need up upgrade both PHP and MySQL. > > It turns out it would be hard to upgrade MySQL, as various things depend > on the old version: For example the gtk2hs website is using mysql and php too. I think we'd need to upgrade that to have it work with mysql-5. Perhaps gtk2hs should move to projects.haskell.org. > $ sudo rpm -U MySQL-server-community-5.1.30-0.rhel3.i386.rpm > warning: MySQL-server-community-5.1.30-0.rhel3.i386.rpm: V3 DSA > signature: NOKEY, key ID 5072e1f5 > error: Failed dependencies: > libmysqlclient.so.10 is needed by (installed) mod_auth_mysql-20030510-2.ent > libmysqlclient.so.10 is needed by (installed) perl-DBD-MySQL-2.1021-4.EL3 > libmysqlclient.so.10 is needed by (installed) php-mysql-4.3.2-48.ent > > I don't know what mod_auth_mysql and perl-DBD-MySQL are being used for, > so I don't believe I can upgrade them safely. > > The machine is running RHEL AS 3 update 9 with Linux 2.4.21. We really need to upgrade the whole thing. Not an easy job given the range of stuff being run on there by lots of different people. Duncan From alexott at gmail.com Sun Jan 11 09:37:45 2009 From: alexott at gmail.com (Alex Ott) Date: Sun Jan 11 09:29:04 2009 Subject: [Haskell-cafe] [ANN] Working with HLint from Emacs Message-ID: Hello For Emacs users it could be interesting - I wrote small module for more comfortable work with HLint from Emacs. It has same functionality as compilation-mode - navigation between errors, etc. To use it, just add following code to emacs init file: (require 'hs-lint) (defun my-haskell-mode-hook () (local-set-key "\C-cl" 'hs-lint)) (add-hook 'haskell-mode-hook 'my-haskell-mode-hook) Module is available from http://xtalk.msk.su/~ott/common/emacs/hs-lint.el -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/ http://xtalk.msk.su/~ott/ http://alexott-ru.blogspot.com/ From bugfact at gmail.com Sun Jan 11 10:03:06 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Sun Jan 11 09:54:27 2009 Subject: [Haskell-cafe] Re: System.CPUTime and picoseconds In-Reply-To: References: <49690FCF.3080704@libero.it> Message-ID: wouldn't a double become less and less precise the longer the process is running? so Integer sounds like the only datatype that could work here... and why not do it like in Windows: make two functions, one that returns the number of CPU ticks, and another that returns the frequency (number of ticks per second)... This gives you an API that works for whatever clock speed... On Sun, Jan 11, 2009 at 11:23 AM, Lennart Augustsson wrote: > It was suggested that it should be ns, and I complained that ns would > be obsolete in a while. > What I really wanted was a switch to Double (and just using seconds), > instead we got ps. > At least ps won't get obsolete in a while. > > -- Lennart > > On Sun, Jan 11, 2009 at 12:06 AM, ChrisK > wrote: > > Manlio Perillo wrote: > >> > >> Hi. > >> > >> Just out of curiosity, but why Haskell 98 System.CPUTime library module > >> uses picoseconds instead of, say, nanoseconds? > >> > >> At least on POSIX systems, picoseconds precision is *never* specified. > >> > > > > I have not idea. But at a guess, I would say that 1 ns is not such a > small > > time interval anymore. The CPU speeds are about 3 GHz, so 0.3 ns per CPU > > clock. Even the RAM clock in a laptop (e.g. Apple's 17" Mac Pro) is 1066 > > MHz, so the internal there is just under 1 ns. > > > > Whoever picked picoseconds has made it possible to talk about a single > clock > > interval for hardware like this. > > > > -- > > Chris > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090111/97f378eb/attachment.htm From noteed at gmail.com Sun Jan 11 10:22:15 2009 From: noteed at gmail.com (minh thu) Date: Sun Jan 11 10:13:34 2009 Subject: [Haskell-cafe] Re: Monads aren't evil In-Reply-To: <42784f260901110332w665aaa7di403dcd3c3bb8b119@mail.gmail.com> References: <20090108231652.24b75fe3@tritium.xx> <2f9b2d30901101145q79041fe9q9781f90b2e533499@mail.gmail.com> <42784f260901110332w665aaa7di403dcd3c3bb8b119@mail.gmail.com> Message-ID: <40a414c20901110722y7fd7a6b5g96dbacc9509b3b28@mail.gmail.com> I always thought that instead of having two classes of characters, one for variable (and function) names and the other for operators, only the first charater of the identifier could mean it's one or the others, so *vec or +point would be valid operator names and thus >_> too. And C++ could be a Data type name... Cheers, Thu 2009/1/11 Jason Dusek : > It is really too bad we can not define the operators > > >_> ^_^ <_< > > These are significant from an internationalization standpoint; > and they'd make the language so much more competitiveI > vis-a-vis LOLCode. > > -- > Jason Dusek > > > > 2009/1/10 Brandon S. Allbery KF8NH : >> On 2009 Jan 10, at 15:19, Peter Verswyvelen wrote: >> >> h3 x = f x <^(+)^> g x >> >> Is that an operator or Batman? >> (yes, I know, 3 operators) >> -- >> brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com >> system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu >> electrical and computer engineering, carnegie mellon university KF8NH >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From martijn at van.steenbergen.nl Sun Jan 11 10:28:35 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Sun Jan 11 10:19:56 2009 Subject: [Haskell-cafe] Re: Monads aren't evil In-Reply-To: <40a414c20901110722y7fd7a6b5g96dbacc9509b3b28@mail.gmail.com> References: <20090108231652.24b75fe3@tritium.xx> <2f9b2d30901101145q79041fe9q9781f90b2e533499@mail.gmail.com> <42784f260901110332w665aaa7di403dcd3c3bb8b119@mail.gmail.com> <40a414c20901110722y7fd7a6b5g96dbacc9509b3b28@mail.gmail.com> Message-ID: <496A1023.5070302@van.steenbergen.nl> minh thu wrote: > I always thought that instead of having two classes of characters, one > for variable (and function) names and the > other for operators, only the first charater of the identifier could > mean it's one or the others, > so *vec or +point would be valid operator names and thus >_> too. And > C++ could be a Data type name... No, operators have to consist entirely of punctuation, and functions entirely of alphanumerical characters. If what you said were the case, then x+y would be an identifier instead of the sum of x and y. Kind regards, Martijn. From noteed at gmail.com Sun Jan 11 10:33:56 2009 From: noteed at gmail.com (minh thu) Date: Sun Jan 11 10:25:48 2009 Subject: [Haskell-cafe] Re: Monads aren't evil In-Reply-To: <496A1023.5070302@van.steenbergen.nl> References: <20090108231652.24b75fe3@tritium.xx> <2f9b2d30901101145q79041fe9q9781f90b2e533499@mail.gmail.com> <42784f260901110332w665aaa7di403dcd3c3bb8b119@mail.gmail.com> <40a414c20901110722y7fd7a6b5g96dbacc9509b3b28@mail.gmail.com> <496A1023.5070302@van.steenbergen.nl> Message-ID: <40a414c20901110733q6ebb04c2vcb6a6739b501697@mail.gmail.com> 2009/1/11 Martijn van Steenbergen : > minh thu wrote: >> >> I always thought that instead of having two classes of characters, one >> for variable (and function) names and the >> other for operators, only the first charater of the identifier could >> mean it's one or the others, >> so *vec or +point would be valid operator names and thus >_> too. And >> C++ could be a Data type name... > > No, operators have to consist entirely of punctuation, and functions > entirely of alphanumerical characters. > > If what you said were the case, then x+y would be an identifier instead of > the sum of x and y. Indeed but what's wrong in writing x + y (with additional spaces) ? Having the possiblity to write for instance +blah instead of inventing things such as $>* is neat in my opinion (in code or for typesetting)... Cheers Thu From duncan.coutts at worc.ox.ac.uk Sun Jan 11 10:35:44 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jan 11 10:27:52 2009 Subject: [Haskell-cafe] Re: System.CPUTime and picoseconds In-Reply-To: References: <49690FCF.3080704@libero.it> Message-ID: <1231688144.4794.102.camel@localhost> On Sun, 2009-01-11 at 16:03 +0100, Peter Verswyvelen wrote: > wouldn't a double become less and less precise the longer the process > is running? > > > so Integer sounds like the only datatype that could work here... > > > and why not do it like in Windows: make two functions, one that > returns the number of CPU ticks, and another that returns the > frequency (number of ticks per second)... This gives you an API that > works for whatever clock speed... Let's assume you were joking, but just in case you were not... Clock speed is variable on all modern CPUs. In low power states some CPUs can turn off the clock completely. In some CPUs the clock speed is variable per-core and some can turn off one core without turning off all cores. Relating clock ticks to time is a minefield. Duncan From miguelimo38 at yandex.ru Sun Jan 11 11:06:54 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Sun Jan 11 10:58:25 2009 Subject: [Haskell-cafe] Re: Monads aren't evil In-Reply-To: <40a414c20901110733q6ebb04c2vcb6a6739b501697@mail.gmail.com> References: <20090108231652.24b75fe3@tritium.xx> <2f9b2d30901101145q79041fe9q9781f90b2e533499@mail.gmail.com> <42784f260901110332w665aaa7di403dcd3c3bb8b119@mail.gmail.com> <40a414c20901110722y7fd7a6b5g96dbacc9509b3b28@mail.gmail.com> <496A1023.5070302@van.steenbergen.nl> <40a414c20901110733q6ebb04c2vcb6a6739b501697@mail.gmail.com> Message-ID: > Indeed but what's wrong in writing x + y (with additional spaces) ? > Having the possiblity to write for instance +blah instead of inventing > things such as $>* is neat in my opinion (in code or for > typesetting)... I believe it was Bulat Ziganshin who once proposed parsing x + y*z + t as x + (y * z) + t and x + y * z + t as (x + y) * (z + t) From bulat.ziganshin at gmail.com Sun Jan 11 11:26:26 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Jan 11 11:18:00 2009 Subject: [Haskell-cafe] Re: Monads aren't evil In-Reply-To: References: <20090108231652.24b75fe3@tritium.xx> <2f9b2d30901101145q79041fe9q9781f90b2e533499@mail.gmail.com> <42784f260901110332w665aaa7di403dcd3c3bb8b119@mail.gmail.com> <40a414c20901110722y7fd7a6b5g96dbacc9509b3b28@mail.gmail.com> <496A1023.5070302@van.steenbergen.nl> <40a414c20901110733q6ebb04c2vcb6a6739b501697@mail.gmail.com> Message-ID: <17310105501.20090111192626@gmail.com> Hello Miguel, Sunday, January 11, 2009, 7:06:54 PM, you wrote: > I believe it was Bulat Ziganshin who once proposed parsing > x + y*z + t as x + (y * z) + t > and > x + y * z + t as (x + y) * (z + t) x+y * z+t should be here -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lennart at augustsson.net Sun Jan 11 12:42:28 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Sun Jan 11 12:33:47 2009 Subject: [Haskell-cafe] Re: Monads aren't evil In-Reply-To: <496A1023.5070302@van.steenbergen.nl> References: <20090108231652.24b75fe3@tritium.xx> <2f9b2d30901101145q79041fe9q9781f90b2e533499@mail.gmail.com> <42784f260901110332w665aaa7di403dcd3c3bb8b119@mail.gmail.com> <40a414c20901110722y7fd7a6b5g96dbacc9509b3b28@mail.gmail.com> <496A1023.5070302@van.steenbergen.nl> Message-ID: Agda has made the choice that you can have (almost) any sequence of characters in identifiers. It works fine, but forces you to use white space (which I do anyway). -- Lennart On Sun, Jan 11, 2009 at 4:28 PM, Martijn van Steenbergen wrote: > minh thu wrote: >> >> I always thought that instead of having two classes of characters, one >> for variable (and function) names and the >> other for operators, only the first charater of the identifier could >> mean it's one or the others, >> so *vec or +point would be valid operator names and thus >_> too. And >> C++ could be a Data type name... > > No, operators have to consist entirely of punctuation, and functions > entirely of alphanumerical characters. > > If what you said were the case, then x+y would be an identifier instead of > the sum of x and y. > > Kind regards, > > Martijn. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From lennart at augustsson.net Sun Jan 11 12:46:13 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Sun Jan 11 12:37:33 2009 Subject: [Haskell-cafe] Re: System.CPUTime and picoseconds In-Reply-To: References: <49690FCF.3080704@libero.it> Message-ID: A double has 53 bits in the mantissa which means that for a running time of about 24 hours you'd still have picoseconds. I doubt anyone cares about picoseconds when the running time is a day. That's why I think a Double is a good choice, it adapts to the time scale involved. -- Lennart On Sun, Jan 11, 2009 at 4:03 PM, Peter Verswyvelen wrote: > wouldn't a double become less and less precise the longer the process is > running? > so Integer sounds like the only datatype that could work here... > and why not do it like in Windows: make two functions, one that returns the > number of CPU ticks, and another that returns the frequency (number of ticks > per second)... This gives you an API that works for whatever clock speed... > > > > On Sun, Jan 11, 2009 at 11:23 AM, Lennart Augustsson > wrote: >> >> It was suggested that it should be ns, and I complained that ns would >> be obsolete in a while. >> What I really wanted was a switch to Double (and just using seconds), >> instead we got ps. >> At least ps won't get obsolete in a while. >> >> -- Lennart >> >> On Sun, Jan 11, 2009 at 12:06 AM, ChrisK >> wrote: >> > Manlio Perillo wrote: >> >> >> >> Hi. >> >> >> >> Just out of curiosity, but why Haskell 98 System.CPUTime library module >> >> uses picoseconds instead of, say, nanoseconds? >> >> >> >> At least on POSIX systems, picoseconds precision is *never* specified. >> >> >> > >> > I have not idea. But at a guess, I would say that 1 ns is not such a >> > small >> > time interval anymore. The CPU speeds are about 3 GHz, so 0.3 ns per >> > CPU >> > clock. Even the RAM clock in a laptop (e.g. Apple's 17" Mac Pro) is 1066 >> > MHz, so the internal there is just under 1 ns. >> > >> > Whoever picked picoseconds has made it possible to talk about a single >> > clock >> > interval for hardware like this. >> > >> > -- >> > Chris >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe@haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > From martijn at van.steenbergen.nl Sun Jan 11 13:04:02 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Sun Jan 11 12:55:21 2009 Subject: [Haskell-cafe] Re: Monads aren't evil In-Reply-To: References: <20090108231652.24b75fe3@tritium.xx> <2f9b2d30901101145q79041fe9q9781f90b2e533499@mail.gmail.com> <42784f260901110332w665aaa7di403dcd3c3bb8b119@mail.gmail.com> <40a414c20901110722y7fd7a6b5g96dbacc9509b3b28@mail.gmail.com> <496A1023.5070302@van.steenbergen.nl> Message-ID: <496A3492.2070507@van.steenbergen.nl> Lennart Augustsson wrote: > Agda has made the choice that you can have (almost) any sequence of > characters in identifiers. It works fine, but forces you to use white > space (which I do anyway). No _'s though, which is exactly what Jason was after. :-) Still, Agda rocks. Martijn. From agocorona at gmail.com Sun Jan 11 13:38:38 2009 From: agocorona at gmail.com (Alberto G. Corona ) Date: Sun Jan 11 13:29:59 2009 Subject: [Haskell-cafe] Re: Monads aren't evil In-Reply-To: References: <20090108231652.24b75fe3@tritium.xx> Message-ID: As a physicist, I think that programming, like any design in general, is all about making as little use of brain resources as possible at the time of solving problems and to transmit the solution to others. This is the reason why it is pervasive in all kinds of engineering the concepts of modularity, isolation, clean interfacing (for which referential transparency is part of) etc. To decompose a problem in parts each one with simple solutions and with as little uncontrolled interaction with other parts is a rule of good design simply because we can not think in nothing but around seven concepts at the same time (By the way, an evolutionary psychologist would say that the beatifulness of simplicity is related with this release of brain resources). As a matter of fact, these rules of "good" design do not apply to the design of living beings simply because the process of Natural Selection has not these limitations. that is indeed the reason because natural designs are so difficult for reverse engineering. Because such kid of human brain limitations and our lack of knowledge, design has a lot of trial and error. The danger of this is to get lost in the explosion of unfruitful alternatives due to low level issues outside of our high level problem, because the limitation of the tools we are using for it. In this sense, things like the strong type inference is superb for cutting the explosion of erroneous paths that the process of software development can generate. If designing solutions is sculpting order from chaos and against chaos, intelligent tools are the thing needed to keep us concentrated in fruitful courses of action. A physicist would say that design is to lower the entropic balance by progressively lowering the number of microstates until the only ones permitted correspond with the desired outcomes, called "solutions" and a few bugs, of course. For me, syntactic sugar is one more of this features that make haskell so great. Once we discover that a solution general enough has a correspondence with something already know, such are monads for imperative languages, then, why not make this similarity explicit ,with the do notation, in order to communicate it better with other people making use of this common knowledge?. I have to say also that, without Haskell, I never dream to have the confidence to play simultaneously with concurrence, transactions, internet incommunications, parsing and, at the time, keeping the code clean enough to understand it after a month of inactivity. This is for me the big picture that matters for real programming. 2009/1/10 Peter Verswyvelen > Related to this issue, I have a question here. > > I might be wrong, but it seems to me that some Haskellers don't like > writing monads (with do notation) or arrows (with proc sugar) because of the > fact they have to abandon the typical applicative syntax, which is so close > to the beautiful lambda calculus core. Or is it maybe because some people > choose monads were the less linear applicative style could be used instead, > so the choice of monads is not always appropriate. > > Haskell is full of little hardcoded syntax extensions: list notation > syntactic, list comprehensions, and even operator precedence that reduces > the need for parentheses, etc... > > Of course IMHO the syntactic sugar is needed, e.g. a Yampa game written > without the arrows syntax would be incomprehensible for the average > programmer. But one could claim that this syntactic sugar hides what is > really going on under the hood, so for newcomers these extensions might make > it harder. It could also feel like a hack, a failure to keep things as > simple as possible yet elegant. > > Some people I talked with like that about the Scheme/ & LISP languages: the > syntax remains ultimately close to the core, with very little hardcoded > syntactic extensions. And when one wants to add syntactic extensions, one > uses syntactic macros. > > I'm not sure what others feel about the hardcoded syntax extensions in > Haskell... > > Personally I'm not that much of a purist, I'm an old school hacker that > mainly needs to get the job done. I like the syntax extensions in Haskell > (and even C#/F# ;) because they let me write code shorter and clearer... > > On Fri, Jan 9, 2009 at 4:07 AM, Neal Alexander wrote: > >> Ertugrul Soeylemez wrote: >> >>> Hello fellow Haskellers, >>> >>> When I read questions from Haskell beginners, it somehow seems like they >>> try to avoid monads and view them as a last resort, if there is no easy >>> non-monadic way. I'm really sure that the cause for this is that most >>> tutorials deal with monads very sparingly and mostly in the context of >>> input/output. Also usually monads are associated with the do-notation, >>> which makes them appear even more special, although there is really >>> nothing special about them. >>> >>> >> Yea, i was the same way when i started learning Haskell. I understood how >> Monads worked, and what the motivation was for them, but not why i would >> want to restructure code to use them in specific instances. >> >> "Why should i care about monads when i can use Arrows or (.)" was also a >> factor. >> >> Its kinda like getting advice from an adult as a child. You have no >> particular reason to distrust the advice, but the value of it doesn't set in >> until something happens to you first hand to verify it. >> >> For me the turning point was writing some code that needed to handle >> running code locally/remotely in a transparent manner. >> >> Maybe having a list of real-world usage scenarios or exercises on the wiki >> may help. >> >> >> ______________________________ _________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090111/97108079/attachment.htm From ryani.spam at gmail.com Sun Jan 11 14:02:19 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Sun Jan 11 13:53:39 2009 Subject: [Haskell-cafe] Declaring each instance of a typeclass to be also an instance of another typeclass In-Reply-To: References: Message-ID: <2f9b2d30901111102g7485a6cv5c576abbedf7bc31@mail.gmail.com> No, but you can do this: > {-# LANGUAGE GeneralizedNewtypeDeriving #-} > import Control.Monad (liftM) > newtype Functorize m a = F { unF :: m a } deriving (Eq, Show, Monad) Insert any other type classes you care about potentially inheriting from the parent Monad into the deriving clause, like MonadPlus. Unfortunately it's not possible to derive "everything my internal type has", which makes it difficult to include things like MonadState or other multiparameter classes. > inF f = F . f . unF > instance Monad m => Functor (Functorize m) where > fmap f = inF (liftM f) -- ryan On Sun, Jan 11, 2009 at 5:12 AM, Mikhail Glushenkov wrote: > Hi, > > Is it possible to write something like this: > >> {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} >> >> import Control.Monad (liftM) >> >> instance (Monad a) => Functor a where >> fmap = liftM > > without having to use UndecidableInstances (and preferably, other type system > extensions too)? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From haskell at list.mightyreason.com Sun Jan 11 14:28:01 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Sun Jan 11 14:19:33 2009 Subject: [Haskell-cafe] Re: System.CPUTime and picoseconds In-Reply-To: References: <49690FCF.3080704@libero.it> Message-ID: <496A4841.4090700@list.mightyreason.com> An Double or Int64 are both 8 bytes and counts with picoseconds precision for 2.5 hours to 106 days. Going to 12 byte integer lets you count to 3.9 billion years (signed). Going to 16 byte integer is over 10^38 years. Lennart Augustsson wrote: > A double has 53 bits in the mantissa which means that for a running > time of about 24 hours you'd still have picoseconds. I doubt anyone > cares about picoseconds when the running time is a day. The above is an unfounded claim about the rest of humanity. > That's why I think a Double is a good choice, it adapts to the time > scale involved. Let's compute: > tTooBig :: Double > tTooBig = 2^53 > > main = do > print (tTooBig == 1+ tTooBig) The above prints True. How long does your computer have to be running before losing picosecond resolution? > tHours = tTooBig / (10^12) / 60 / 60 tHours is 2.501999792983609. My laptop battery lasts longer. Nanosecond precision is lost after 106 days. -- Chris From bugfact at gmail.com Sun Jan 11 15:41:33 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Sun Jan 11 15:32:53 2009 Subject: [Haskell-cafe] Re: System.CPUTime and picoseconds In-Reply-To: <1231688144.4794.102.camel@localhost> References: <49690FCF.3080704@libero.it> <1231688144.4794.102.camel@localhost> Message-ID: > > Let's assume you were joking, but just in case you were not... > Why this hostile tone? I didn't mean to be offensive. Unlike most people in this group, I don't have the brain of an einstein :) So sorry for my stupidity, I just tried to give some feedback... > Clock speed is variable on all modern CPUs. In low power states some > CPUs can turn off the clock completely. In some CPUs the clock speed is > variable per-core and some can turn off one core without turning off all > cores. Relating clock ticks to time is a minefield. > Yes I know that. I just meant having something that returns a number of ticks (not real CPU ticks, mea culpa) and the ticks itself. That would make it unit independent no? Anyway, this is purely theoretical, as indeed picoseconds would do for all practical purposes I guess -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090111/0f6c282b/attachment.htm From noteed at gmail.com Sun Jan 11 15:45:51 2009 From: noteed at gmail.com (minh thu) Date: Sun Jan 11 15:37:10 2009 Subject: [Haskell-cafe] how to link to external documentation with haddock ? Message-ID: <40a414c20901111245j65325bd6l53e9795025285c35@mail.gmail.com> Hi, When generating haddock documention (I use runhaskell Setup.lhs haddock), haddock warns me : "could not find link destinations for:" and lists for instance GHC.Show.Show or Data.Either.Either. Is it possible to instruct Haddock to links against http://www.haskell.org/ghc/docs/latest/html/libraries/ for those unfound destinations ? Thanks, Thu From martijn at van.steenbergen.nl Sun Jan 11 16:40:30 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Sun Jan 11 16:31:51 2009 Subject: [Haskell-cafe] Understanding type synonym families Message-ID: <496A674E.2020307@van.steenbergen.nl> Hello everybody, I think I'm finally beginning to understand how type synonym families [1] work, in the way that works best for me: running into a problem to which type synonyms offer a solution. I wrote down my train of thoughts [2] and I was hoping you could give me some feedback: are there any mistakes in my conclusions? Did I miss any obvious corollaries? Are the points I make valid? Also, I'm hoping it will be valuable to read for those wanting to understand type synonym families. Thank you in advance, Martijn. [1] http://www.haskell.org/haskellwiki/GHC/Type_families#Detailed_definition_of_type_synonym_families [2] http://martijn.van.steenbergen.nl/journal/type-synonym-families/ From duncan.coutts at worc.ox.ac.uk Sun Jan 11 16:42:17 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jan 11 16:33:37 2009 Subject: [Haskell-cafe] Re: System.CPUTime and picoseconds In-Reply-To: References: <49690FCF.3080704@libero.it> <1231688144.4794.102.camel@localhost> Message-ID: <1231710137.28590.3.camel@localhost> On Sun, 2009-01-11 at 21:41 +0100, Peter Verswyvelen wrote: > Let's assume you were joking, but just in case you were not... > > > Why this hostile tone? I didn't mean to be offensive. I'm sorry, I did not intend it to sound hostile. I mis-interpreted the "..." at the end of your sentence. Some people sometimes use this to indicate they're making a joke suggestion. > > Clock speed is variable on all modern CPUs. In low power > states some CPUs can turn off the clock completely. In some > CPUs the clock speed is variable per-core and some can turn > off one core without turning off all cores. Relating clock > ticks to time is a minefield. > > > Yes I know that. I just meant having something that returns a number > of ticks (not real CPU ticks, mea culpa) and the ticks itself. That > would make it unit independent no? I guess so. Duncan From mhenrion at gmail.com Sun Jan 11 17:00:09 2009 From: mhenrion at gmail.com (Maxime Henrion) Date: Sun Jan 11 16:51:30 2009 Subject: [Haskell-cafe] Space leak with Data.Binary and decodeFile Message-ID: <1231711209.1722.35.camel@localhost> Hello all, I've been observing a huge space leak with some code using Data.Binary that I cannot make sense of and I hope someone here can shed some light on this, so I'll try to explain my problem as clearly as possible. I qualify the space leak as huge because if I let the program run, it will soon consume the whole memory available (~3G) and finally will get killed by the system. The code I'm writing implements a search algorithm using an inverted index. This index is built from a Trie [Int] (from the bytestring-trie package) and an Array Int ByteString. The trie maps each referenced word to an integer list that is a list of indices into the array. Here is the code for the Index datatype and the obvious Binary instance: data Index = Index { entries :: Array Int ByteString , invidx :: Trie [Int } instance Binary Index where put (Index dirs idx) = put dirs >> put idx get = liftM2 get get I have no problems creating and seralizing this data structure to a file. The huge leak appears instead when I'm reading this data structure from a file and try to do something with it. This is the smallest test case I came up with that can reproduce the problem : main = do idx <- decodeFile "list.idx"; mapM_ (B.putStrLn . snd) (assocs (entries idx)) The space leak also appears when I try to touch the trie instead of the array. I've been trying tons of combinations involving adding or removing strictness annotations and seq calls in various places with no luck. I have also been adding SCC annotations and tried to profile the code. This seemed to suggest the space leak happens in the get method of the Array instance of Binary : instance (Binary i, Ix i, Binary e) => Binary (Array i e) where [...] get = do bs <- get n <- get -- read the length xs <- replicateM n get -- now the elems. return (listArray bs xs) The output of the profiler tells me that all the space gets allocated from the "replicateM n get" expression. Now for the really weird part: if I load my code in GHCi and type "main", I can observe the space leak. However, if I copy paste the definition of main instead, the code runs fine! This is the only circumstance I've seen this code work instead of eating all the RAM... I have been using GHC 6.10.1, binary 0.4.4 and bytestring-trie 0.1.2. If there's anything else that I can do to understand what's going on, I would gladfully hear about it. Please also tell me if I should provide more information. Thanks, -- Maxime Henrion From ndmitchell at gmail.com Sun Jan 11 17:05:09 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Jan 11 16:56:32 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 Message-ID: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> Hi, I am pleased to announce HLint version 1.2. HLint is a lint-like tool for Haskell that detects and suggests improvements for your code. HLint is compatible with most GHC extensions, and supports a wide variety of suggestions, and can be extended with additional user suggestions. To install: cabal update && cabal install hlint Web page: http://www-users.cs.york.ac.uk/~ndm/hlint/ Biggest new feature: List recursion suggestions. For example, running HLint over the GHC compiler now suggests things such as: Example.hs:3:1: Warning: Use foldr Found: seqList [] b = b seqList (x : xs) b = x `seq` seqList xs b Why not: seqList xs b = foldr seq b xs Example.hs:6:1: Warning: Use foldr Found: seqIds [] = () seqIds (id : ids) = seqId id `seq` seqIds ids Why not: seqIds ids = foldr (seq . seqId) () ids Example.hs:13:1: Warning: Use foldl Found: rev_app [] xs = xs rev_app (y : ys) xs = rev_app ys (y : xs) Why not: rev_app ys xs = foldl (flip (:)) xs ys HLint will automatically detect if you should have used a map, a foldr or a foldl and suggest how to change your code. In the GHC, darcs and Hoogle code bases there are no obvious map-like functions, which is a good sign :-) Changes from last time: * More GHC extensions supported - including record wild cards and fixes to a number of existing extensions. These changes are thanks to Niklas and the haskell-src-exts package. * Many infix operators are now correctly associated with the right priority. * All hints are now ignored, warnings or errors. Hopefully this should make it clearer what hints are most important. As part of this, the format for defining ignore files has changed completely - see the manual for the new format. * Lots of new hints have been added - many from users of HLint. * Many bugs have been fixed. Can any follow-up discussions please be directed to haskell-cafe@. All comments, questions, bug reports are welcome! Neil From dons at galois.com Sun Jan 11 17:26:14 2009 From: dons at galois.com (Don Stewart) Date: Sun Jan 11 17:17:20 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> Message-ID: <20090111222614.GC909@scytale.galois.com> ndmitchell: > Hi, > > I am pleased to announce HLint version 1.2. HLint is a lint-like tool > for Haskell that detects and suggests improvements for your code. > HLint is compatible with most GHC extensions, and supports a wide > variety of suggestions, and can be extended with additional user > suggestions. > > To install: cabal update && cabal install hlint > > Web page: http://www-users.cs.york.ac.uk/~ndm/hlint/ > > Biggest new feature: List recursion suggestions. For example, running > HLint over the GHC compiler now suggests things such as: Arch package, http://aur.archlinux.org/packages.php?ID=23099 Making this the 800th Haskell package on Arch. -- Don From manlio_perillo at libero.it Sun Jan 11 17:29:51 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Sun Jan 11 17:21:13 2009 Subject: [Haskell-cafe] git mirrors for GHC boot libraries Message-ID: <496A72DF.7070600@libero.it> Hi. Where can I find git mirrors for GHC boot libraries? From http://hackage.haskell.org/trac/ghc/wiki/Design/VersionControlSystem it is not clear if the mirrors are already available. Thanks Manlio Perillo From dons at galois.com Sun Jan 11 17:30:53 2009 From: dons at galois.com (Don Stewart) Date: Sun Jan 11 17:21:56 2009 Subject: [Haskell-cafe] Arch Haskell News: Jan 11 2009 Message-ID: <20090111223053.GA1296@scytale.galois.com> Arch Haskell News: Jan 11 2009 Hey all, welcome to the first Arch Haskell News of 2009. (News about Haskell on the Arch Linux platform). Arch now has 827 Haskell packages in AUR. That?s an increase of 93 new packages in the last 48 days, or 1.9 new Haskell apps and libraries a day over the holiday season. Well done everyone!. Noteworthy * lhc-0.6.20081127: ?LHC Haskell Compiler? * cabal2arch-0.4.2: ?Create Arch Linux packages from Cabal packages? * timberc-1.0.2: ?The Timber Compiler.? * haskell-x11-1.4.5: ?A binding to the X11 graphics library? * haskell-curl-1.3.2.2: ?Haskell binding to libcurl? * alex-2.3.1: ?Alex is a tool for generating lexical analysers in Haskel * haskell-bytestring-trie-0.1: ?Efficient map from strings to values.? * haskell-llvm-0.5.0.1: ?Bindings to the LLVM compiler toolkit? * tetris-0.27178: ?A 2-D clone of Tetris? * haskell-network-bytestring-0.1.1.4: ?Fast and memory efficient low-level networking? * haskell-hdbc-1.1.6: ?Haskell Database Connectivity? http://archhaskell.wordpress.com/2009/01/11/arch-haskell-news-jan-11-2009/ Other news: * llvm support, http://archhaskell.wordpress.com/2009/01/11/llvm-haskell-bindings/ * new hdbc release, http://archhaskell.wordpress.com/2009/01/11/hdbc-haskell-database-suite-updated/ * salvia, new web framework, supported http://archhaskell.wordpress.com/2009/01/11/new-haskell-web-framework-salvia-and-orchid/ Bring on 2009 and the era of ubiquitous Haskell! -- Don From lemming at henning-thielemann.de Sun Jan 11 17:44:30 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Jan 11 17:35:50 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> Message-ID: On Sun, 11 Jan 2009, Neil Mitchell wrote: > HLint will automatically detect if you should have used a map, a foldr > or a foldl and suggest how to change your code. In the GHC, darcs and > Hoogle code bases there are no obvious map-like functions, which is a > good sign :-) I found so many 'map' re-implementations in Haskell libraries, even in those, where I thought their programmers must be more experienced than me. Hm, maybe even in libraries by Neil? From ryani.spam at gmail.com Sun Jan 11 18:28:50 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Sun Jan 11 18:20:09 2009 Subject: [Haskell-cafe] Understanding type synonym families In-Reply-To: <496A674E.2020307@van.steenbergen.nl> References: <496A674E.2020307@van.steenbergen.nl> Message-ID: <2f9b2d30901111528o28e1dad6g471b0740478b3557@mail.gmail.com> >From your blog post: > Another solution is to use type synonyms to flip the parameter order > around and write > > > type StateT' m s a = StateT s m a > > That in combination with the TypeSynonymInstances extension would > allow us to write instance MonadState (StateT' m), This isn't true, actually; (StateT' m) isn't a valid instance even with TypeSynonymInstances; type synonyms must be fully applied. TypeSynonymInstances just lets you do things like > type List' x = (Int, [x]) > instance Monoid (List' x) where > mempty = (0, mempty) > mappend (a,b) (c,d) = (a + c, b ++ d) This is the same as if you wrote the "instance" line as > instance Monoid (Int, [x]) the compiler is just allowing you to put a fully applied type synonym in the instance and applying it for you before creating the instance. -- ryan On Sun, Jan 11, 2009 at 1:40 PM, Martijn van Steenbergen wrote: > Hello everybody, > > I think I'm finally beginning to understand how type synonym families [1] > work, in the way that works best for me: running into a problem to which > type synonyms offer a solution. > > I wrote down my train of thoughts [2] and I was hoping you could give me > some feedback: are there any mistakes in my conclusions? Did I miss any > obvious corollaries? Are the points I make valid? > > Also, I'm hoping it will be valuable to read for those wanting to understand > type synonym families. > > Thank you in advance, > > Martijn. > > > [1] > http://www.haskell.org/haskellwiki/GHC/Type_families#Detailed_definition_of_type_synonym_families > [2] http://martijn.van.steenbergen.nl/journal/type-synonym-families/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From lennart at augustsson.net Sun Jan 11 19:00:51 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Sun Jan 11 18:52:10 2009 Subject: [Haskell-cafe] Re: System.CPUTime and picoseconds In-Reply-To: <496A4841.4090700@list.mightyreason.com> References: <49690FCF.3080704@libero.it> <496A4841.4090700@list.mightyreason.com> Message-ID: On Sun, Jan 11, 2009 at 8:28 PM, ChrisK wrote: > An Double or Int64 are both 8 bytes and counts with picoseconds precision > for 2.5 hours to 106 days. Going to 12 byte integer lets you count to 3.9 > billion years (signed). Going to 16 byte integer is over 10^38 years. > > Lennart Augustsson wrote: >> >> A double has 53 bits in the mantissa which means that for a running >> time of about 24 hours you'd still have picoseconds. I doubt anyone >> cares about picoseconds when the running time is a day. > > The above is an unfounded claim about the rest of humanity. It's not really about humanity, but about physics. The best known clocks have a long term error of about 1e-14. If anyone claims to have made a time measurement where the accuracy exceeds the precision of a double I will just assume that this person is a liar. For counting discrete events, like clock cycles, I want something like Integer or Int64. For measuring physical quantities, like CPU time, I'll settle for Double, because we can't measure any better than this (this can of course become obsolete, but I'll accept that error). -- Lennart From lennart at augustsson.net Sun Jan 11 19:02:25 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Sun Jan 11 18:53:44 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> Message-ID: Does GHC specialize map? If it doesn't, then hand crafted version could be faster. On Sun, Jan 11, 2009 at 11:44 PM, Henning Thielemann wrote: > > On Sun, 11 Jan 2009, Neil Mitchell wrote: > >> HLint will automatically detect if you should have used a map, a foldr >> or a foldl and suggest how to change your code. In the GHC, darcs and >> Hoogle code bases there are no obvious map-like functions, which is a >> good sign :-) > > I found so many 'map' re-implementations in Haskell libraries, even in > those, where I thought their programmers must be more experienced than me. > Hm, maybe even in libraries by Neil? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From patperry at stanford.edu Sun Jan 11 20:43:36 2009 From: patperry at stanford.edu (Patrick Perry) Date: Sun Jan 11 20:34:57 2009 Subject: [Haskell-cafe] Question about touchForeignPtr Message-ID: I have the following code: IOVector n e = IOVector !ConjEnum !Int (ForeignPtr e)! (Ptr e)! Int! newtype Vector n e = IOVector n e unsafeAtVector :: Vector n e -> Int -> e unsafeAtVector (Vector (IOVector c _ f p inc)) i = let g = if c == Conj then conjugate else id in inlinePerformIO $ do e <- peekElemOff p (i*inc) io <- touchForeignPtr f let e' = g e e' `seq` io `seq` return e' {-# INLINE unsafeAtVector #-} The Ptr, 'p' is derived from the ForeignPtr, 'f'. For some offset, 'o', it is defined as: p = unsafeForeignPtrToPtr f `advancePtr` o The "touchForeignPtr" is there to keep the garbage collector from deallocating the memory before we have a chance to read 'e'. My question is the following: Is the `seq` on `io` necessary (from a safety standpoint)? Or am I just being paranoid? Thanks in advance for any help, Patrick From wren at freegeek.org Sun Jan 11 22:22:29 2009 From: wren at freegeek.org (wren ng thornton) Date: Sun Jan 11 22:13:47 2009 Subject: [Haskell-cafe] ANN: bytestring-trie 0.1.4 Message-ID: <496AB775.3010204@freegeek.org> -------------------------------------------- -- bytestring-trie 0.1.4 -------------------------------------------- Another release for efficient finite maps from (byte)strings to values. Equal parts bugfix release and real release. This upgrade is suggested for all users and is what 0.1.0 should have been. -------------------------------------------- -- Changes (since 0.1.2) -------------------------------------------- * Fixed a number of obscure bugs when "" is used as a key. * Added keys and toListBy (which generalizes toList, keys,...). Also did some optimization of toListBy so it shouldn't be as egregiously inefficient as it was before. * Added fromListL, fromListR, and fromListS to Data.Trie.Convenience along with notes about when each is more efficient than the others. * Separated Data.Trie (the main module for users) from Data.Trie.Internal (gritty details, and core implementation). Data.Trie re-exports most of Data.Trie.Internal so this is primarily a cosmetic change. The showTrie and lookupBy_ functions are no longer exported from Data.Trie however. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-trie Darcs: http://code.haskell.org/~wren/bytestring-trie/ Haddock (Darcs version): http://code.haskell.org/~wren/bytestring-trie/dist/doc/html/bytestring-trie/ -- Live well, ~wren From ashley at semantic.org Sun Jan 11 22:42:18 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Sun Jan 11 22:33:37 2009 Subject: [Haskell-cafe] Re: [Haskell] HaskellWiki Upgrade Aborted In-Reply-To: <1231683199.4794.67.camel@localhost> References: <4969524E.2010209@semantic.org> <4969614A.2020403@semantic.org> <1231683199.4794.67.camel@localhost> Message-ID: <496ABC1A.4020004@semantic.org> Duncan Coutts wrote: >> The machine is running RHEL AS 3 update 9 with Linux 2.4.21. > > We really need to upgrade the whole thing. Not an easy job given the > range of stuff being run on there by lots of different people. It might be easier to move the services to another machine, preferably running Debian 4.0 (like both monk and nun). I'm not sure how much this can be done gradually. -- Ashley Yakeley From dominic.steinitz at blueyonder.co.uk Mon Jan 12 03:28:22 2009 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Mon Jan 12 03:19:51 2009 Subject: [Haskell-cafe] Re: how to link to external documentation with haddock ? References: <40a414c20901111245j65325bd6l53e9795025285c35@mail.gmail.com> Message-ID: minh thu gmail.com> writes: http://www.haskell.org/haskellwiki/Haddock/FAQ From ndmitchell at gmail.com Mon Jan 12 03:41:03 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Jan 12 03:32:22 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> Message-ID: <404396ef0901120041n678d96fay78edb005f0059bbc@mail.gmail.com> Hi > Does GHC specialize map? If it doesn't, then hand crafted version > could be faster. GHC doesn't specialize map, and a hand-crafted one could be faster - but you then wouldn't get foldr/build fusion. In general HLint tries to make the code prettier, but sometimes you will need to deviate from its suggestions when you've profiled etc. To stop HLint warning you just create Hints.hs and include the line "ignore = LennartsSuperFastModule.mySpecialisedMap" - full details in the manual. >> I found so many 'map' re-implementations in Haskell libraries, even in >> those, where I thought their programmers must be more experienced than me. >> Hm, maybe even in libraries by Neil? I can't really be blamed for making mistakes before HLint ;-) Thanks Neil From marlowsd at gmail.com Mon Jan 12 04:21:02 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jan 12 04:12:26 2009 Subject: [Haskell-cafe] Re: concurrent haskell: thread priorities In-Reply-To: <20090109192211.GJ25701@scytale.galois.com> References: <4c44d90b0812221442p2933e84dl90c81bb2f986dd3c@mail.gmail.com> <49671A87.1040401@gmail.com> <20090109192211.GJ25701@scytale.galois.com> Message-ID: <496B0B7E.6050006@gmail.com> Don Stewart wrote: > marlowsd: >> Neal Alexander wrote: >>> Thomas DuBuisson wrote: >>>> It seems like we could get some priority based scheduling (and still >>>> be slackers) if we allow marked green threads to be strictly >>>> associated with a specific OS thread (forkChildIO?). >>>> >>>> >>>> I think you want the GHC-only GHC.Conc.forkOnIO >>>> >>> GHC.Conc.forkOnIO is helpful but doest work in this case - it doesn't >>> attach them to the same OS thread. >> But it does attach the thread to a particular "virtual CPU" in the GHC RTS >> (we call them "capabilities"), with the intention that a virtual CPU >> corresponds more or less to a real CPU core. > > Every time Simon responds on questions of parallelism and the GHC > runtime, I learn something. That indicates to me that we've got a 'bus > error' situation with how to effectively use the smp runtime. > > Simon: time for a multicore FAQ wiki page to gather this knowledge, like > we did for the performance tips? Somewhere to paste these insights? Sure, that would be great. One slight problem is that I'm still learning myself how to use parallelism effectively, and the RTS is still changing rapidly. We have a paper in the works that should serve as a good overview of the implementation, but a wiki page would be more suitable for users. If nobody else starts one, I'll try to get to it in the next few weeks. Cheers, Simon From marlowsd at gmail.com Mon Jan 12 04:24:24 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jan 12 04:15:48 2009 Subject: [Haskell-cafe] Re: concurrent haskell: thread priorities In-Reply-To: References: <4c44d90b0812221442p2933e84dl90c81bb2f986dd3c@mail.gmail.com> <49671A87.1040401@gmail.com> Message-ID: <496B0C48.80905@gmail.com> Neal Alexander wrote: > Simon Marlow wrote: >> Neal Alexander wrote: >>> Thomas DuBuisson wrote: >>>> It seems like we could get some priority based scheduling (and >>>> still >>>> be slackers) if we allow marked green threads to be strictly >>>> associated with a specific OS thread (forkChildIO?). >>>> >>>> >>>> I think you want the GHC-only GHC.Conc.forkOnIO >>>> >>> GHC.Conc.forkOnIO is helpful but doest work in this case - it doesn't >>> attach them to the same OS thread. >> >> But it does attach the thread to a particular "virtual CPU" in the GHC >> RTS (we call them "capabilities"), with the intention that a virtual >> CPU corresponds more or less to a real CPU core. >> >> Cheers, >> Simon > > Yea, but you still have the problem with FFI that uses TLS don't you? > What about having a forkOnOS version with processor affinity? Or is > there a way to "upgrade" a thread created with forkOnIO to Bound. Yes, forkOnOS would be possible (you can write it yourself using the primitives, in fact). > I have a thread with soft real-time requirements that cooperatively > yields and uses thread local state. Right now there just doesn't seem to > be any options. Right - real-time and priorities are things that we don't do at the moment, unfortunately. Cheers, Simon From kowey at darcs.net Mon Jan 12 04:44:51 2009 From: kowey at darcs.net (Eric Kow) Date: Mon Jan 12 04:36:11 2009 Subject: [Haskell-cafe] [ANNOUNCE] First release candidate of darcs 2.2. Message-ID: <20090112094451.GB22175@brighton.ac.uk> Dear Haskellers, I would like to forward this announcement on behalf of Petr Ro?kai (the current darcs Release Manager). Darcs 2.2 is scheduled for release in 2009-01-15, only three days from now! This is the first of our biannual time-based releases. We hope you'll like it, and to help us ensure that you will like it, please help us test our the release candidate. Thanks! Eric Petr's words follow: ----------------8<------------------------------------------------------------- I am pleased to announce that darcs 2.2 is coming along nicely. I would like to ask everyone to give a ride to darcs 2.2, release candidate 1. This release again comes in two flavours: 1) The source tarball, http://repos.mornfall.net/darcs/darcs-2.2.0rc1.tar.gz, which can be built using the traditional autoconf-based buildsystem. This is the fully supported version. After downloading and unpacking, you can issue: $ ./configure $ make $ ./darcs --version or # make install More detailed instructions inside the tarball (file README). 2) Cabalised source. You can either download a tarball from http://repos.mornfall.net/darcs/darcs-2.1.99.0.tar.gz and build manually (see the build instructions in README inside the tarball), or, alternatively, you can use cabal-install to obtain a copy (the release candidate is now available on hackage): $ cabal update $ cabal install darcs This should give you a darcs binary in ~/.cabal/bin -- you should probably add that to your PATH. This is a preliminary changelog since version 2.1.2 (released last November): * In interactive record, it is now possible to get a list of currently selected hunks (command 'l'). (Christian Kellermann) * It is now possible to specify --in-reply-to when using darcs send, to generate correct references in the mail header. (Pavel Shramov) * New repositories with --no-pristine-tree can no longer be created. This only has effect on legacy darcs-1 repositories. * Improvements in Windows support. (Salvatore Insalaco) * Performance improvements in `darcs repair` and robustness improvements in `darcs check`. (Petr Ro?kai) * Extensive manual and online help improvements. (Trent W. Buck) * Support for GHC 6.10. * Overhaul of the make-based build system. (Trent W. Buck) * Cabal is now supported as a build method for darcs. (Duncan Coutts, Petr Ro?kai, Gwern Branwen) * First stab at libdarcs -- when building through Cabal, all of darcs implementation is now exposed in modules. No API guarantees whatsoever. (Eric Kow) * Additions to Haddock documentation of the existing darcs modules for improved development experience. * Improvements in the testing infrastructure. (Christian Kellermann, Gwern Branwen) * Low-level optimisations in filesystem code. (Ganesh Sittampalam) * Numerous major and minor bug fixes, refactorings and cleanups by David Roundy, Eric Kow, Jason Dagit, Dmitry Kurochkin, Thorkil Naur, Salvatore Insalaco, Christian Kellerman, Florent Becker, Duncan Coutts, Reinier Lamers, Ganesh Sittampalam, Petr Ro?kai. Preliminary list of issues that have been fixed in darcs since version 2.1.2: 1223 sporadic init.sh test failure (2.1.1rc2+472) 525 amend-record => darcs patches show duplicate additions 1247 make TAGS is broken 1273 renameFile: does not exist (No such file or directory) 1165 get should print last gotten tag 1249 2.1.2 (+ 342 patches) local drive detection on Windows error 1238 wish: darcs help setpref should list all prefs 1199 Backup files darcs added after external merge 1043 pull => mergeAfterConflicting failed in geteff (2.0.2+) 1117 Whatsnew should warn on non-recorded files 1101 darcs send --cc recipient not included in success message Thanks to Thorkil Naur for compiling this list. I would like to thank all contributors -- developers, testers, bystanders -- for helping darcs get along further. It's been hard times recently for darcs, as many of you probably know. Nevertheless, we are regaining confidence in future darcs development. No way are we going to leave darcs fall by the road. I am sure that this one time, I speak for everyone in our developer and user community. Yours, Petr. -- Eric Kow PGP Key ID: 08AC04F9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090112/10dd8c95/attachment.bin From semanticphilosopher at googlemail.com Mon Jan 12 04:50:32 2009 From: semanticphilosopher at googlemail.com (Neil Davies) Date: Mon Jan 12 04:41:55 2009 Subject: [Haskell-cafe] Re: System.CPUTime and picoseconds In-Reply-To: References: <49690FCF.3080704@libero.it> <496A4841.4090700@list.mightyreason.com> Message-ID: I've found the pico second accuracy useful in working with 'rate equivalent' real time systems. Systems where the individual timings (their jitter) is not critical but the long term rate should be accurate - the extra precision helps with keeping the error accumulation under control. When you are selling something (like data bandwidth) and you are pacing the data stream on a per packet basis you definitely want any error to accumulate slowly - you are in the 10^10 events per day range here. Neil On 12 Jan 2009, at 00:00, Lennart Augustsson wrote: > On Sun, Jan 11, 2009 at 8:28 PM, ChrisK > wrote: >> An Double or Int64 are both 8 bytes and counts with picoseconds >> precision >> for 2.5 hours to 106 days. Going to 12 byte integer lets you count >> to 3.9 >> billion years (signed). Going to 16 byte integer is over 10^38 >> years. >> >> Lennart Augustsson wrote: >>> >>> A double has 53 bits in the mantissa which means that for a running >>> time of about 24 hours you'd still have picoseconds. I doubt anyone >>> cares about picoseconds when the running time is a day. >> >> The above is an unfounded claim about the rest of humanity. > > It's not really about humanity, but about physics. The best known > clocks have a long term error of about 1e-14. > If anyone claims to have made a time measurement where the accuracy > exceeds the precision of a double I will just assume that this person > is a liar. > > For counting discrete events, like clock cycles, I want something like > Integer or Int64. For measuring physical quantities, like CPU time, > I'll settle for Double, because we can't measure any better than this > (this can of course become obsolete, but I'll accept that error). > > -- Lennart > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From briqueabraque at yahoo.com Mon Jan 12 05:46:58 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Mon Jan 12 05:38:27 2009 Subject: [Haskell-cafe] Re: System.CPUTime and picoseconds In-Reply-To: References: <49690FCF.3080704@libero.it> <496A4841.4090700@list.mightyreason.com> Message-ID: Aren't Doubles evil? Integer is a nice type, Haskell filosofy compliant. Doubles are not CDoubles, IEEE, infinite precision or anything long term meaninfull. (Warning: non-expert opinion.) > I've found the pico second accuracy useful in working with 'rate > equivalent' real time systems. Systems where the individual timings > (their jitter) is not critical but the long term rate should be accurate > - the extra precision helps with keeping the error accumulation under > control. > > When you are selling something (like data bandwidth) and you are pacing > the data stream on a per packet basis you definitely want any error to > accumulate slowly - you are in the 10^10 events per day range here. > > Neil > > > On 12 Jan 2009, at 00:00, Lennart Augustsson wrote: > >> On Sun, Jan 11, 2009 at 8:28 PM, ChrisK >> wrote: >>> An Double or Int64 are both 8 bytes and counts with picoseconds >>> precision >>> for 2.5 hours to 106 days. Going to 12 byte integer lets you count >>> to 3.9 >>> billion years (signed). Going to 16 byte integer is over 10^38 years. >>> >>> Lennart Augustsson wrote: >>>> >>>> A double has 53 bits in the mantissa which means that for a running >>>> time of about 24 hours you'd still have picoseconds. I doubt anyone >>>> cares about picoseconds when the running time is a day. >>> >>> The above is an unfounded claim about the rest of humanity. >> >> It's not really about humanity, but about physics. The best known >> clocks have a long term error of about 1e-14. >> If anyone claims to have made a time measurement where the accuracy >> exceeds the precision of a double I will just assume that this person >> is a liar. >> >> For counting discrete events, like clock cycles, I want something like >> Integer or Int64. For measuring physical quantities, like CPU time, >> I'll settle for Double, because we can't measure any better than this >> (this can of course become obsolete, but I'll accept that error). >> >> -- Lennart >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe From haskell at list.mightyreason.com Mon Jan 12 05:58:16 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Mon Jan 12 05:49:36 2009 Subject: [Haskell-cafe] Re: System.CPUTime and picoseconds In-Reply-To: References: <49690FCF.3080704@libero.it> <496A4841.4090700@list.mightyreason.com> Message-ID: <496B2248.4060006@list.mightyreason.com> Neil Davies wrote: > I've found the pico second accuracy useful in working with 'rate > equivalent' real time systems. Systems where the individual timings > (their jitter) is not critical but the long term rate should be accurate > - the extra precision helps with keeping the error accumulation under > control. > > When you are selling something (like data bandwidth) and you are pacing > the data stream on a per packet basis you definitely want any error to > accumulate slowly - you are in the 10^10 events per day range here. > > Neil > Now I am posting just because I like to look at the time scales. A rate of 10^10 per Day is a period of 8.64 microseconds. If you want to slip only 1 period per year then you need a fractional accuracy of 2.74 * 10^-13. In one day this is a slip of 23.7 nanoseconds. So atomic time radio synchronization is too inaccurate. I have seen GPS receivers that claim to keep the absolute time to within 100 nanoseconds. Lennart is right that 1 picosecond accuracy is absurd compared to all the jitters and drifts in anything but an actual atomic clock in your room. But since CPUs tick faster than nanosecond the CPUTime needs better than 1 nanosecond granularity. I agree with Lennart ? I also want an Integral type; it keeps the granularity constant and avoids all the pitfalls of doing math with a Double. Out of simplicity I can see why the granularity was set to 1 picosecond as it is slightly easier to specify than 100 picosecond or 10 picosecond or 1/60 nanosecond (hmmm... arcnanosecond?). Maybe Haskell should name the "1/60 nanosecond" unit something clever and create a new Time submodule using it for April 1st. [ Base 60 is the real standard: http://en.wikipedia.org/wiki/Babylonian_mathematics has an 1800 B.C. tablet with the (sqrt 2) in base 60 as (1).(24)(51)(10) ] -- Chris From briqueabraque at yahoo.com Mon Jan 12 06:30:03 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Mon Jan 12 06:21:41 2009 Subject: [Haskell-cafe] Re: Computer time, independent of date In-Reply-To: References: <20090108115029.GA20403@gmx.de> <49661529.3030309@van.steenbergen.nl> <94oem4hfiqaskk4pdc5mn3d05l8p4hh6cf@4ax.com> <49676D31.109 0207@complete.org> <193gm4ldb2cichf8l3lgdbdhslhe7gifbf@4ax.com> <4968AAF4.2040108@libero.it> <59mhm496p2pjjjom5q11qcvhhshbsfotgi@4ax.com> Message-ID: >> patients, I wanted to be sure not to save wrong >> information. It wouldn't matter if the clock is >> saying we are on XVII century, as long as 10 seconds >> would never be 10.1. >> > What are the interval durations you need to measure? > Since they are from equipment, what is the spec? I read from serial port. When the equipment was available for testing, we measured the output to be a few thowsand bytes/second. The program is supposed to run in Windows computers at physicians offices (and their only requirement is to be able to run windows and have a serial port). Errors of 1 byte per second would be acceptable, even if they accumulate. I have no equipment specs and, right now, no equipment to test. (Yes, I know this is crazy.) So, I need to know what kind of problems I may expect, so I'm able to deal with them. Thanks, Maur?cio From rodrigo.bonifacio at uol.com.br Mon Jan 12 06:39:26 2009 From: rodrigo.bonifacio at uol.com.br (rodrigo.bonifacio) Date: Mon Jan 12 06:30:51 2009 Subject: [Haskell-cafe] Error building Sdf2Haskell Message-ID: <496b2bee5a76d_2cc3155555587eb423c@weasel2.tmail> An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090112/fde93934/attachment.htm From lemming at henning-thielemann.de Mon Jan 12 07:21:04 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jan 12 07:12:23 2009 Subject: [Haskell-cafe] version conflict on Hackage Message-ID: I repeatedly encounter the following versioning problem on Hackage: There is a package A with version 1.0. I upload a package B which imports A. Thus B is bound to A-1.0 Now a new version of A is uploaded, say 1.0.1. then I upload package C which depends both on A and B. However C is bound to the new A-1.0.1, which gives conflicts with the interface of B. All packages are sane. Both B and C work with either A-1.0 or A-1.0.1, but they must use the same version. Currently I'm forced to upload many packages with different versions, although nothing really changed. Maybe the most easiest fix to this problem is to let maintainers of a package allow to trigger re-configuration and re-compilation of a package. I would also like to flag package versions that people can safely ignore, because there was a flaw in package dependencies. On the other hand there are packages that are useful, but can no longer be compiled on Hackage, e.g. compatibility packages for older versions of GHC. From jac at informatik.uni-kiel.de Mon Jan 12 07:27:26 2009 From: jac at informatik.uni-kiel.de (Jan Christiansen) Date: Mon Jan 12 07:19:12 2009 Subject: [Haskell-cafe] Maintaining laziness In-Reply-To: References: <715BD1A7-EBEA-4B88-A11F-599DE9E27428@informatik.uni-kiel.de> Message-ID: <9158C9F5-F937-48F4-B2CF-74A1C0086835@informatik.uni-kiel.de> Hi, > Although it seems to be overkill for a single module - How about a > cabalized version on Hackage and a darcs repository? It would > simplify using and updating it. I am not sure whether this would be a good idea. The original version makes a lot of suggestions which are not satisfiable but it is not at all trivial to decide which are satisfiable and which are not. I have rewritten StrictCheck from scratch to overcome this problem. But the current implementation is not presentable right now and I have no formal prove that the criterion that I am using is correct. > Your StrictCheck is really tough! I'm currently checking my > routines from > http://hackage.haskell.org/packages/archive/utility-ht/0.0.1/doc/ > html/Data-List-HT.html > which I designed especially with laziness in mind - and I found a > lot of laziness breakers using StrictCheck! > > However now I found an example where it probably proposes > something inefficient: > > So what it proposes is essentially that one should first check the > length of the lists without looking at the contents. > [undefined,undefined] can never be a prefix of [undefined]. > However, first constructing the list spine seems to be inefficient. I know about this problem. It is mentioned in the paper about StrictCheck. I haven't worked on this right now. With respect to least-strictness I would say the tool is right. But it is probably not the kind of advise one wants. When I am sure that I can handle the other problem I will take a look at this one. Cheers, Jan From dot at dotat.at Mon Jan 12 07:55:07 2009 From: dot at dotat.at (Tony Finch) Date: Mon Jan 12 07:46:32 2009 Subject: [Haskell-cafe] Re: System.CPUTime and picoseconds In-Reply-To: <496B2248.4060006@list.mightyreason.com> References: <49690FCF.3080704@libero.it> <496A4841.4090700@list.mightyreason.com> <496B2248.4060006@list.mightyreason.com> Message-ID: On Mon, 12 Jan 2009, ChrisK wrote: > > Lennart is right that 1 picosecond accuracy is absurd compared to all > the jitters and drifts in anything but an actual atomic clock in your > room. But since CPUs tick faster than nanosecond the CPUTime needs > better than 1 nanosecond granularity. I agree with Lennart ? I also > want an Integral type; it keeps the granularity constant and avoids all > the pitfalls of doing math with a Double. Out of simplicity I can see > why the granularity was set to 1 picosecond as it is slightly easier to > specify than 100 picosecond or 10 picosecond or 1/60 nanosecond (hmmm... > arcnanosecond?). The FreeBSD kernel uses a 64+64 bit fixed point type to represent time, where the integer part is a normal Unix time_t. The fractional part is 64 bits wide in order to be able to represent multi-GHz frequencies precisely. http://phk.freebsd.dk/pubs/timecounter.pdf Tony. -- f.anthony.n.finch http://dotat.at/ TYNE DOGGER FISHER GERMAN BIGHT HUMBER: SOUTHWEST 7 TO SEVERE GALE 9 DECREASING 5 OR 6 LATER. MODERATE TO VERY ROUGH, DECREASING SLIGHT TO ROUGH LATER. OCCASIONAL RAIN. MODERATE OR GOOD. From lemming at henning-thielemann.de Mon Jan 12 08:37:39 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jan 12 08:28:58 2009 Subject: [Haskell-cafe] Maintaining laziness In-Reply-To: <9158C9F5-F937-48F4-B2CF-74A1C0086835@informatik.uni-kiel.de> References: <715BD1A7-EBEA-4B88-A11F-599DE9E27428@informatik.uni-kiel.de> <9158C9F5-F937-48F4-B2CF-74A1C0086835@informatik.uni-kiel.de> Message-ID: On Mon, 12 Jan 2009, Jan Christiansen wrote: > Hi, > >> Although it seems to be overkill for a single module - How about a >> cabalized version on Hackage and a darcs repository? It would simplify >> using and updating it. > > I am not sure whether this would be a good idea. The original version makes a > lot of suggestions which are not satisfiable but it is not at all trivial to > decide which are satisfiable and which are not. I have rewritten StrictCheck > from scratch to overcome this problem. But the current implementation is not > presentable right now and I have no formal prove that the criterion that I am > using is correct. As I said, the current version is already very useful. I have applied it to several basic functions and found a lot to improve. From rob at hoelzro.net Mon Jan 12 08:43:42 2009 From: rob at hoelzro.net (Rob Hoelz) Date: Mon Jan 12 08:35:07 2009 Subject: [Haskell-cafe] Fw: [darcs-devel] "Inferred type is less polymorphic than expected" and type witnesses Message-ID: <20090112074342.51a2f641@hoelzro.homelinux.net> Forwarding to Haskell Cafe per Eric's suggestion. Begin forwarded message: Date: Sun, 11 Jan 2009 23:01:31 -0600 From: Rob Hoelz To: darcs-devel@darcs.net Subject: [darcs-devel] "Inferred type is less polymorphic than expected" and type witnesses Hello again, Darcs users and developers, As I mentioned in my last e-mail, I'm working on http://bugs.darcs.net/issue291. It's actually gone pretty well, and I feel I'm just about finished (I've done all but sorting out the changes after leaving the editor), only I've encountered the compiler error you see in the subject of this message. This error only appears when compiling with witnesses. Here's the source for the function that it's complaining about: compare_changes_with_old (x :>: xs) (y :>: ys) = case compare_changes_with_old xs ys of nx :> ny -> if unsafeCompare x y then ((x :>: nx) :> ny) else (NilFL :> (y :>: ys)) compare_changes_with_old NilFL NilFL = (NilFL :> NilFL) compare_changes_with_old NilFL ys@(_ :>: _) = (NilFL :> ys) compare_changes_with_old x@(_ :>: _) NilFL = (NilFL :> NilFL) Now, I have two questions: 1) What exactly does this error mean, and how do I get around it? 2) What are witness types, and what are they used for? I will gladly accept links to fine manuals as answers to either question, but simple explanations would be nice. =D I thought I understood Haskell pretty well, but existentially qualified types have thrown me for a loop. Thanks much, Rob Hoelz _______________________________________________ darcs-devel mailing list (AUTOMATIC POSTINGS ONLY PLEASE!) darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel From duncan.coutts at worc.ox.ac.uk Mon Jan 12 08:54:21 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jan 12 08:46:08 2009 Subject: [Haskell-cafe] version conflict on Hackage In-Reply-To: References: Message-ID: <1231768461.28590.59.camel@localhost> On Mon, 2009-01-12 at 13:21 +0100, Henning Thielemann wrote: > I repeatedly encounter the following versioning problem on Hackage: > There is a package A with version 1.0. > I upload a package B which imports A. > Thus B is bound to A-1.0 > Now a new version of A is uploaded, say 1.0.1. > then I upload package C which depends both on A and B. > However C is bound to the new A-1.0.1, which gives conflicts with the interface of B. > All packages are sane. Both B and C work with either A-1.0 or A-1.0.1, > but they must use the same version. The package builder on hackage is broken for this reason, amongst others. > Currently I'm forced to upload many packages with different versions, > although nothing really changed. > Maybe the most easiest fix to this problem is to let maintainers of a > package allow to trigger re-configuration and re-compilation of a package. The plan with the new hackage server is that we have a smarter build client (cabal-install) that does install plans and so always installs consistent versions of packages. > I would also like to flag package versions that people can safely ignore, > because there was a flaw in package dependencies. There is a mechanism for doing this but no UI yet. > On the other hand there are packages that are useful, but can no > longer be compiled on Hackage, e.g. compatibility packages for older > versions of GHC. Right, we should leave those alone. Duncan From zara at coit.es Mon Jan 12 08:57:50 2009 From: zara at coit.es (Juan Antonio Zaratiegui Vallecillo, a.k.a. Zara) Date: Mon Jan 12 08:51:31 2009 Subject: [Haskell-cafe] Re: ANN: HLint 1.2 In-Reply-To: <404396ef0901120041n678d96fay78edb005f0059bbc@mail.gmail.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <404396ef0901120041n678d96fay78edb005f0059bbc@mail.gmail.com> Message-ID: Neil Mitchell escribi?: > Hi > >> Does GHC specialize map? If it doesn't, then hand crafted version >> could be faster. > > GHC doesn't specialize map, and a hand-crafted one could be faster - > but you then wouldn't get foldr/build fusion. In general HLint tries > to make the code prettier, but sometimes you will need to deviate from > its suggestions when you've profiled etc. To stop HLint warning you > just create Hints.hs and include the line "ignore = > LennartsSuperFastModule.mySpecialisedMap" - full details in the > manual. > I am really happy with HLint. Being relatively new to haskell world, I tend to be slow in finding ready-made solutions, or using folds fot recursive tasks. HLint 1.0 discovers `on` for me, and only for that I will be infinitely grateful. Now, if HLint 1.2 helps me with the map/fold understanding, I will be 'continuous infinitely' grateful (although real numbers are not representable!) Best regards, Zara From duncan.coutts at worc.ox.ac.uk Mon Jan 12 09:01:53 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jan 12 08:53:28 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> Message-ID: <1231768913.28590.66.camel@localhost> On Mon, 2009-01-12 at 01:02 +0100, Lennart Augustsson wrote: > Does GHC specialize map? If it doesn't, then hand crafted version > could be faster. No because the current definition are recursive and ghc cannot inline recursive functions. map :: (a -> b) -> [a] -> [b] map _ [] = [] map f (x:xs) = f x : map f xs It has to be manually transformed into a version that is not recursive at the top level: map :: (a -> b) -> [a] -> [b] map f = go where go [] = [] go (x:xs) = f x : go xs Then the map can be inlined at the call site and the 'f' inlined into the body of 'go'. Obviously this is not quite the same as specialising map since it's per use not per-function being mapped. Though specialisation would be just: mapFoo = map foo I'm not sure if you'd need {-# NOINLINE mapFoo #-} This is exactly how the ghc definitions for foldr and foldl work: foldr k z xs = go xs where go [] = z go (y:ys) = y `k` go ys foldl f z xs = lgo z xs where lgo z [] = z lgo z (x:xs) = lgo (f z x) xs Duncan From lemming at henning-thielemann.de Mon Jan 12 09:06:58 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jan 12 08:58:50 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: <1231768913.28590.66.camel@localhost> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <1231768913.28590.66.camel@localhost> Message-ID: On Mon, 12 Jan 2009, Duncan Coutts wrote: > On Mon, 2009-01-12 at 01:02 +0100, Lennart Augustsson wrote: >> Does GHC specialize map? If it doesn't, then hand crafted version >> could be faster. > > No because the current definition are recursive and ghc cannot inline > recursive functions. > > map :: (a -> b) -> [a] -> [b] > map _ [] = [] > map f (x:xs) = f x : map f xs > > It has to be manually transformed into a version that is not recursive > at the top level: > > map :: (a -> b) -> [a] -> [b] > map f = go > where > go [] = [] > go (x:xs) = f x : go xs > > Then the map can be inlined at the call site and the 'f' inlined into > the body of 'go'. Maybe HLint can make such suggestions ... From duncan.coutts at worc.ox.ac.uk Mon Jan 12 09:10:50 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jan 12 09:02:14 2009 Subject: [Haskell-cafe] Question about touchForeignPtr In-Reply-To: References: Message-ID: <1231769450.28590.75.camel@localhost> On Sun, 2009-01-11 at 17:43 -0800, Patrick Perry wrote: > The "touchForeignPtr" is there to keep the garbage collector from > deallocating the memory before we have a chance to read 'e'. My > question is the following: > Is the `seq` on `io` necessary (from a safety standpoint)? Or am I > just being paranoid? touchForeignPtr :: ForeignPtr a -> IO () There is no need to seq the returned () value. It's the side effect of touchForeignPtr that provides the guarantee that you're after. So I think you could use: ... in inlinePerformIO $ do e <- peekElemOff p (i*inc) touchForeignPtr f return $! g e By the way, in your: IOVector n e = IOVector !ConjEnum !Int (ForeignPtr e)! (Ptr e)! Int! Do the (ForeignPtr e) and the (Ptr e) point to the same thing? They appear to be related because you dereference p but touch f. It used to be the ForeignPtr was slower to dereference than a Ptr and so caching it like this could make it faster (but then requires lots of careful thought about touchForeignPtr). These days ForeignPtr is just as fast and so you can use withForeignPtr and never have to worry about touchForeignPtr. You'll notice ByteString works this way. Duncan From ndmitchell at gmail.com Mon Jan 12 09:24:15 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Jan 12 09:15:36 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <1231768913.28590.66.camel@localhost> Message-ID: <404396ef0901120624o55dcb50r5eec2b9e8825d593@mail.gmail.com> Hi >> No because the current definition are recursive and ghc cannot inline >> recursive functions. > >> map :: (a -> b) -> [a] -> [b] >> map f = go >> where >> go [] = [] >> go (x:xs) = f x : go xs >> >> Then the map can be inlined at the call site and the 'f' inlined into >> the body of 'go'. > > Maybe HLint can make such suggestions ... HLint would probably just suggest you use a supercompiler*, for which specialisation such as this is easy (http://www.cs.york.ac.uk/~ndm/supero). HLint is about making code prettier, and only in a few cases does it try for faster (mapM -> mapM_), but even there its more about avoiding a space leak. Thanks Neil * Of course, HLint (and me) should probably add the disclaimer that the chances of that working your code as it stands are fairly close to 0 - but the ideas and initial research has been started! From duncan.coutts at worc.ox.ac.uk Mon Jan 12 09:26:19 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jan 12 09:17:53 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <1231768913.28590.66.camel@localhost> Message-ID: <1231770379.28590.77.camel@localhost> On Mon, 2009-01-12 at 15:06 +0100, Henning Thielemann wrote: > > It has to be manually transformed into a version that is not recursive > > at the top level: > > > > map :: (a -> b) -> [a] -> [b] > > map f = go > > where > > go [] = [] > > go (x:xs) = f x : go xs > > > > Then the map can be inlined at the call site and the 'f' inlined into > > the body of 'go'. > > Maybe HLint can make such suggestions ... I think HLint's philosophy prefers elegant code to performance hacks. Duncan From lemming at henning-thielemann.de Mon Jan 12 09:58:27 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jan 12 09:49:53 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: <404396ef0901120624o55dcb50r5eec2b9e8825d593@mail.gmail.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <1231768913.28590.66.camel@localhost> <404396ef0901120624o55dcb50r5eec2b9e8825d593@mail.gmail.com> Message-ID: On Mon, 12 Jan 2009, Neil Mitchell wrote: > Hi > >>> No because the current definition are recursive and ghc cannot inline >>> recursive functions. >> >>> map :: (a -> b) -> [a] -> [b] >>> map f = go >>> where >>> go [] = [] >>> go (x:xs) = f x : go xs >>> >>> Then the map can be inlined at the call site and the 'f' inlined into >>> the body of 'go'. >> >> Maybe HLint can make such suggestions ... > > HLint would probably just suggest you use a supercompiler*, for which > specialisation such as this is easy > (http://www.cs.york.ac.uk/~ndm/supero). HLint is about making code > prettier, Actually, I find the 'go' variant prettier, because it clearly shows that the 'f' is not "altered" in the recursion. From jmaessen at alum.mit.edu Mon Jan 12 10:49:06 2009 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Mon Jan 12 10:40:26 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: <1231768913.28590.66.camel@localhost> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <1231768913.28590.66.camel@localhost> Message-ID: <2D150C9D-9335-4B96-B786-13A7AF12DB06@alum.mit.edu> On Jan 12, 2009, at 9:01 AM, Duncan Coutts wrote: > No because the current definition are recursive and ghc cannot inline > recursive functions. > > map :: (a -> b) -> [a] -> [b] > map _ [] = [] > map f (x:xs) = f x : map f xs > > It has to be manually transformed into a version that is not recursive > at the top level: > > map :: (a -> b) -> [a] -> [b] > map f = go > where > go [] = [] > go (x:xs) = f x : go xs > > Then the map can be inlined at the call site and the 'f' inlined into > the body of 'go'. This seems like exactly the sort of mechanical transformation that computers do quickly and accurately, and humans get wrong. Surely it wouldn't be that hard for GHC to transform self recursion in this way (possibly subject to the condition that the result be worth inlining)? [phc did this, and I think it was inherited from Lennart's program transformations.] -Jan-Willem Maessen From marlowsd at gmail.com Mon Jan 12 11:32:20 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jan 12 11:23:42 2009 Subject: [Haskell-cafe] Re: Question about touchForeignPtr In-Reply-To: References: Message-ID: <496B7094.1060309@gmail.com> Patrick Perry wrote: > > I have the following code: > > IOVector n e = IOVector !ConjEnum !Int (ForeignPtr e)! (Ptr e)! Int! > newtype Vector n e = IOVector n e > > unsafeAtVector :: Vector n e -> Int -> e > unsafeAtVector (Vector (IOVector c _ f p inc)) i = > let g = if c == Conj then conjugate else id > in inlinePerformIO $ do > e <- peekElemOff p (i*inc) > io <- touchForeignPtr f > let e' = g e > e' `seq` io `seq` return e' > {-# INLINE unsafeAtVector #-} > > > The Ptr, 'p' is derived from the ForeignPtr, 'f'. For some offset, 'o', it > is defined as: > > p = unsafeForeignPtrToPtr f `advancePtr` o > > The "touchForeignPtr" is there to keep the garbage collector from > deallocating > the memory before we have a chance to read 'e'. My question is the > following: > Is the `seq` on `io` necessary (from a safety standpoint)? Or am I just > being paranoid? You're just being paranoid - touchForeignPtr returns a (), so seqing it is a no-op. Cheers, Simon From batterseapower at hotmail.com Mon Jan 12 12:47:17 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Mon Jan 12 12:39:11 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: <2D150C9D-9335-4B96-B786-13A7AF12DB06@alum.mit.edu> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <1231768913.28590.66.camel@localhost> <2D150C9D-9335-4B96-B786-13A7AF12DB06@alum.mit.edu> Message-ID: <9d4d38820901120947l3e95f4e8gd2b133aaeb85983a@mail.gmail.com> 2009/1/12 Jan-Willem Maessen : > On Jan 12, 2009, at 9:01 AM, Duncan Coutts wrote: > >> No because the current definition are recursive and ghc cannot inline >> recursive functions. >> >> .... >> >> Then the map can be inlined at the call site and the 'f' inlined into >> the body of 'go'. > > This seems like exactly the sort of mechanical transformation that computers > do quickly and accurately, and humans get wrong. Surely it wouldn't be that > hard for GHC to transform self recursion in this way (possibly subject to > the condition that the result be worth inlining)? GHC should indeed be doing so. I'm working (on and off) to work out some suitable heuristics and put the transformation into ghc -O2. There are a few wrinkles that still need sorting out, but preliminary indications are that it decreases the runtime of our standard benchmark suite, nofib, by 12% or so. Cheers, Max From ryani.spam at gmail.com Mon Jan 12 13:05:37 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Jan 12 12:56:53 2009 Subject: [Haskell-cafe] Fw: [darcs-devel] "Inferred type is less polymorphic than expected" and type witnesses In-Reply-To: <20090112074342.51a2f641@hoelzro.homelinux.net> References: <20090112074342.51a2f641@hoelzro.homelinux.net> Message-ID: <2f9b2d30901121005p54aacc05ma632c7b6fbad07df@mail.gmail.com> Some questions first: What's the type of this function supposed to be? What's the type of unsafeCompare? How is the data type with NilFL and :>: defined? -- ryan On Mon, Jan 12, 2009 at 5:43 AM, Rob Hoelz wrote: > Forwarding to Haskell Cafe per Eric's suggestion. > > Begin forwarded message: > > Date: Sun, 11 Jan 2009 23:01:31 -0600 > From: Rob Hoelz > To: darcs-devel@darcs.net > Subject: [darcs-devel] "Inferred type is less polymorphic than > expected" and type witnesses > > > Hello again, Darcs users and developers, > > As I mentioned in my last e-mail, I'm working on > http://bugs.darcs.net/issue291. It's actually gone pretty well, and I > feel I'm just about finished (I've done all but sorting out the > changes after leaving the editor), only I've encountered the compiler > error you see in the subject of this message. This error only appears > when compiling with witnesses. Here's the source for the function > that it's complaining about: > > compare_changes_with_old (x :>: xs) (y :>: ys) = > case compare_changes_with_old xs ys of > nx :> ny -> if unsafeCompare x y > then ((x :>: nx) :> ny) > else (NilFL :> (y :>: ys)) > compare_changes_with_old NilFL NilFL = (NilFL :> NilFL) > compare_changes_with_old NilFL ys@(_ :>: _) = (NilFL :> ys) > compare_changes_with_old x@(_ :>: _) NilFL = (NilFL :> NilFL) > > Now, I have two questions: > > 1) What exactly does this error mean, and how do I get around it? > 2) What are witness types, and what are they used for? > > I will gladly accept links to fine manuals as answers to either > question, but simple explanations would be nice. =D I thought I > understood Haskell pretty well, but existentially qualified types have > thrown me for a loop. > > Thanks much, > Rob Hoelz > _______________________________________________ > darcs-devel mailing list (AUTOMATIC POSTINGS ONLY PLEASE!) > darcs-devel@darcs.net > http://lists.osuosl.org/mailman/listinfo/darcs-devel > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From rob at hoelzro.net Mon Jan 12 13:21:18 2009 From: rob at hoelzro.net (Rob Hoelz) Date: Mon Jan 12 13:19:17 2009 Subject: [Haskell-cafe] Fw: [darcs-devel] "Inferred type is less polymorphic than expected" and type witnesses In-Reply-To: <2f9b2d30901121005p54aacc05ma632c7b6fbad07df@mail.gmail.com> References: <20090112074342.51a2f641@hoelzro.homelinux.net> <2f9b2d30901121005p54aacc05ma632c7b6fbad07df@mail.gmail.com> Message-ID: <20090112122118.7a4c6079@hoelzro.homelinux.net> I should've included these when I forwarded it, but that was pre-coffee today. =P class MyEq p where unsafeCompare :: p C(a b) -> p C(c d) -> Bool -- more stuff data FL a C(x z) where (:>:) :: a C(x y) -> FL a C(y z) -> FL a C(x z) NilFL :: FL a C(x x) data (a1 :> a2) C(x y) = FORALL(z) (a1 C(x z)) :> (a2 C(z y)) infixr 1 :> -- I'm not entirely sure on this one, because type witnesses confuse me. compare_changes_with_old :: (Patchy p) => FL p C(x y) -> FL p C(x y) -> (FL p :> FL p) C(x y) C(args...) is a preprocessor macro that expands to args if Darcs is building with GADT type witnesses. FORALL(args...) expands to forall args. under the same condition. All of the definitions are available at http://darcs.net/api-doc/doc-index.html as well. Thanks, Rob "Ryan Ingram" wrote: > Some questions first: > What's the type of this function supposed to be? > What's the type of unsafeCompare? > How is the data type with NilFL and :>: defined? > > -- ryan > > On Mon, Jan 12, 2009 at 5:43 AM, Rob Hoelz wrote: > > Forwarding to Haskell Cafe per Eric's suggestion. > > > > Begin forwarded message: > > > > Date: Sun, 11 Jan 2009 23:01:31 -0600 > > From: Rob Hoelz > > To: darcs-devel@darcs.net > > Subject: [darcs-devel] "Inferred type is less polymorphic than > > expected" and type witnesses > > > > > > Hello again, Darcs users and developers, > > > > As I mentioned in my last e-mail, I'm working on > > http://bugs.darcs.net/issue291. It's actually gone pretty well, > > and I feel I'm just about finished (I've done all but sorting out > > the changes after leaving the editor), only I've encountered the > > compiler error you see in the subject of this message. This error > > only appears when compiling with witnesses. Here's the source for > > the function that it's complaining about: > > > > compare_changes_with_old (x :>: xs) (y :>: ys) = > > case compare_changes_with_old xs ys of > > nx :> ny -> if unsafeCompare x y > > then ((x :>: nx) :> ny) > > else (NilFL :> (y :>: ys)) > > compare_changes_with_old NilFL NilFL = (NilFL :> NilFL) > > compare_changes_with_old NilFL ys@(_ :>: _) = (NilFL :> ys) > > compare_changes_with_old x@(_ :>: _) NilFL = (NilFL :> NilFL) > > > > Now, I have two questions: > > > > 1) What exactly does this error mean, and how do I get around it? > > 2) What are witness types, and what are they used for? > > > > I will gladly accept links to fine manuals as answers to either > > question, but simple explanations would be nice. =D I thought I > > understood Haskell pretty well, but existentially qualified types > > have thrown me for a loop. > > > > Thanks much, > > Rob Hoelz > > _______________________________________________ > > darcs-devel mailing list (AUTOMATIC POSTINGS ONLY PLEASE!) > > darcs-devel@darcs.net > > http://lists.osuosl.org/mailman/listinfo/darcs-devel > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From dons at galois.com Mon Jan 12 13:31:21 2009 From: dons at galois.com (Don Stewart) Date: Mon Jan 12 13:22:40 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: <404396ef0901120041n678d96fay78edb005f0059bbc@mail.gmail.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <404396ef0901120041n678d96fay78edb005f0059bbc@mail.gmail.com> Message-ID: <20090112183121.GE3582@scytale.galois.com> ndmitchell: > Hi > > > Does GHC specialize map? If it doesn't, then hand crafted version > > could be faster. > > GHC doesn't specialize map, and a hand-crafted one could be faster - > but you then wouldn't get foldr/build fusion. In general HLint tries > to make the code prettier, but sometimes you will need to deviate from > its suggestions when you've profiled etc. To stop HLint warning you > just create Hints.hs and include the line "ignore = > LennartsSuperFastModule.mySpecialisedMap" - full details in the > manual. > > >> I found so many 'map' re-implementations in Haskell libraries, even in > >> those, where I thought their programmers must be more experienced than me. > >> Hm, maybe even in libraries by Neil? > > I can't really be blamed for making mistakes before HLint ;-) > But GHC tends to inline and specialise map, due to: "map" [~1] forall f xs. map f xs = build (\c n -> foldr (mapFB c f) n xs) So that, main = print (map toUpper "haskell") Yields: s :: Addr# s = "haskell"# letrec unpack_snX :: Int# -> [Char] unpack_snX = \ (x :: Int#) -> case indexCharOffAddr# s x of i { _ -> ($wtoUpper i) (: @ Char) (unpack_snX (+# x 1) '\NUL' -> [] @ Char Which looks inlined and specialised to my eyes. -- Don From dons at galois.com Mon Jan 12 13:39:47 2009 From: dons at galois.com (Don Stewart) Date: Mon Jan 12 13:30:48 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: <20090112183121.GE3582@scytale.galois.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <404396ef0901120041n678d96fay78edb005f0059bbc@mail.gmail.com> <20090112183121.GE3582@scytale.galois.com> Message-ID: <20090112183947.GF3582@scytale.galois.com> dons: > ndmitchell: > > Hi > > > > > Does GHC specialize map? If it doesn't, then hand crafted version > > > could be faster. > > > > GHC doesn't specialize map, and a hand-crafted one could be faster - > > but you then wouldn't get foldr/build fusion. In general HLint tries > > to make the code prettier, but sometimes you will need to deviate from > > its suggestions when you've profiled etc. To stop HLint warning you > > just create Hints.hs and include the line "ignore = > > LennartsSuperFastModule.mySpecialisedMap" - full details in the > > manual. > > > > >> I found so many 'map' re-implementations in Haskell libraries, even in > > >> those, where I thought their programmers must be more experienced than me. > > >> Hm, maybe even in libraries by Neil? > > > > I can't really be blamed for making mistakes before HLint ;-) > > > > But GHC tends to inline and specialise map, due to: > > "map" [~1] forall f xs. > map f xs = build (\c n -> foldr (mapFB c f) n xs) > > So that, > > main = print (map toUpper "haskell") > > Yields: > > s :: Addr# > s = "haskell"# > > letrec > unpack_snX :: Int# -> [Char] > unpack_snX = \ (x :: Int#) -> > case indexCharOffAddr# s x of i { > _ -> ($wtoUpper i) (: @ Char) (unpack_snX (+# x 1) > '\NUL' -> [] @ Char > > Which looks inlined and specialised to my eyes. > Oh, I should note the inlining only happens here since the list constant is a 'build', and map is a bulid . foldr, so we get a build/foldr fusion, and an inlined map as a result. If we just use map in isolation, no inlining: A.foo = \ (xs_ala :: [Char]) -> map @ Char @ Char toUpper xs_ala Whereas a worker/wrapper version map :: (a -> b) -> [a] -> [b] map f xs = go xs where go [] = [] go (x:xs) = f x : go xs {-# INLINE map #-} We get an inlined version: go = \ (ds_dm7 :: [Char]) -> case ds_dm7 of wild_B1 { [] -> [] @ Char; : x_all xs_aln -> : @ Char (toUpper x_all) (A.go xs_aln) } -- Don From v.dijk.bas at gmail.com Mon Jan 12 13:43:00 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Mon Jan 12 13:34:16 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: <9d4d38820901120947l3e95f4e8gd2b133aaeb85983a@mail.gmail.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <1231768913.28590.66.camel@localhost> <2D150C9D-9335-4B96-B786-13A7AF12DB06@alum.mit.edu> <9d4d38820901120947l3e95f4e8gd2b133aaeb85983a@mail.gmail.com> Message-ID: On Mon, Jan 12, 2009 at 6:47 PM, Max Bolingbroke wrote: > GHC should indeed be doing so. I'm working (on and off) to work out > some suitable heuristics and put the transformation into ghc -O2. > There are a few wrinkles that still need sorting out, but preliminary > indications are that it decreases the runtime of our standard > benchmark suite, nofib, by 12% or so. Great! In the Stream library I'm developing at http://code.haskell.org/Stream I 'closurize' (for lack of a better name) all my functions. Here are a few random examples: repeat :: a -> Stream a repeat x = repeat_x where repeat_x = x ::: repeat_x cycle :: [a] -> Stream a cycle xs = cycle_xs where cycle_xs = foldr (:::) cycle_xs xs deleteBy :: (a -> a -> Bool) -> a -> Stream a -> Stream a deleteBy eq x = deleteBy_eq_x where deleteBy_eq_x (y ::: ys) | eq x y = ys | otherwise = y ::: deleteBy_eq_x ys Closurizing the functions in Data.Stream lead to 10% to 250% speedups! Note that I follow a particular naming convention for the inner worker functions. I use the top level function name and append the 'closurized' arguments to it interspersed with underscores. regards, Bas From rodrigo.bonifacio at uol.com.br Mon Jan 12 13:43:18 2009 From: rodrigo.bonifacio at uol.com.br (rodrigo.bonifacio) Date: Mon Jan 12 13:34:40 2009 Subject: [Haskell-cafe] data, util, and lang packages Message-ID: <496b8f46d5631_2dc1155555587eb43a3@weasel8.tmail> An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090112/26e3409e/attachment.htm From jmaessen at alum.mit.edu Mon Jan 12 13:46:27 2009 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Mon Jan 12 13:38:08 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: <9d4d38820901120947l3e95f4e8gd2b133aaeb85983a@mail.gmail.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <1231768913.28590.66.camel@localhost> <2D150C9D-9335-4B96-B786-13A7AF12DB06@alum.mit.edu> <9d4d38820901120947l3e95f4e8gd2b133aaeb85983a@mail.gmail.com> Message-ID: <32FDDAD7-E430-49BE-BE62-7F451F350351@alum.mit.edu> On Jan 12, 2009, at 12:47 PM, Max Bolingbroke wrote: > 2009/1/12 Jan-Willem Maessen : >> On Jan 12, 2009, at 9:01 AM, Duncan Coutts wrote: >> >>> No because the current definition are recursive and ghc cannot >>> inline >>> recursive functions. >>> >>> .... >>> >>> Then the map can be inlined at the call site and the 'f' inlined >>> into >>> the body of 'go'. >> >> This seems like exactly the sort of mechanical transformation that >> computers >> do quickly and accurately, and humans get wrong. Surely it >> wouldn't be that >> hard for GHC to transform self recursion in this way (possibly >> subject to >> the condition that the result be worth inlining)? > > GHC should indeed be doing so. I'm working (on and off) to work out > some suitable heuristics and put the transformation into ghc -O2. > There are a few wrinkles that still need sorting out, but preliminary > indications are that it decreases the runtime of our standard > benchmark suite, nofib, by 12% or so. This is excellent news, quite apart from Don's observation that it isn't particularly relevant for map (where we are essentially using RULES to instantiate an alternative definition in terms of foldr/ build, if I understand his message rightly). Self recursion is abut so much more than map! -Jan > Cheers, > Max From dons at galois.com Mon Jan 12 13:48:19 2009 From: dons at galois.com (Don Stewart) Date: Mon Jan 12 13:39:21 2009 Subject: [Haskell-cafe] data, util, and lang packages In-Reply-To: <496b8f46d5631_2dc1155555587eb43a3@weasel8.tmail> References: <496b8f46d5631_2dc1155555587eb43a3@weasel8.tmail> Message-ID: <20090112184819.GG3582@scytale.galois.com> rodrigo.bonifacio: > Hi all, I'm trying to build a library whose configuration process requires > the data, util, and lang packages. I guess that these are *deprecated* > packages, since the library is said to be ghc 6.4.1 compliant. > > Which packages should I use instead? > > Where can I find such packages (if they are not deprecated) > > Thanks in advance. Those don't exist. They were merged into the haskell98 package several years ago. -- Don From greenrd at greenrd.org Mon Jan 12 12:06:05 2009 From: greenrd at greenrd.org (Robin Green) Date: Mon Jan 12 13:46:39 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <1231768913.28590.66.camel@localhost> <2D150C9D-9335-4B96-B786-13A7AF12DB06@alum.mit.edu> <9d4d38820901120947l3e95f4e8gd2b133aaeb85983a@mail.gmail.com> Message-ID: <20090112170605.212b6d4b@greenrd.org> On Mon, 12 Jan 2009 19:43:00 +0100 "Bas van Dijk" wrote: > On Mon, Jan 12, 2009 at 6:47 PM, Max Bolingbroke > wrote: > > GHC should indeed be doing so. I'm working (on and off) to work out > > some suitable heuristics and put the transformation into ghc -O2. > > There are a few wrinkles that still need sorting out, but > > preliminary indications are that it decreases the runtime of our > > standard benchmark suite, nofib, by 12% or so. > > Great! > > In the Stream library I'm developing at http://code.haskell.org/Stream > I 'closurize' (for lack of a better name) all my functions. Here are a > few random examples: > > repeat :: a -> Stream a > repeat x = repeat_x > where > repeat_x = x ::: repeat_x > > cycle :: [a] -> Stream a > cycle xs = cycle_xs > where > cycle_xs = foldr (:::) cycle_xs xs > > deleteBy :: (a -> a -> Bool) -> a -> Stream a -> Stream a > deleteBy eq x = deleteBy_eq_x > where > deleteBy_eq_x (y ::: ys) > | eq x y = ys > | otherwise = y ::: deleteBy_eq_x ys > > Closurizing the functions in Data.Stream lead to 10% to 250% speedups! Awesome! I tend to use Control.Monad.Fix.fix (which actually has nothing to do with monads, despite the package name) sometimes, for "closurizing" a recursive function. I am curious as to whether the "fix" style of recursive programming is likely to result in the same speedups. The fix-style equivalent to your repeat above, would be something like this: repeat x = fix $ \me -> x ::: me (I use "me" for the name of the recursive call, partly because it reminds me that it's a self-call, and partly because I find it amusing) -- Robin From patperry at stanford.edu Mon Jan 12 14:16:21 2009 From: patperry at stanford.edu (Patrick Perry) Date: Mon Jan 12 14:07:39 2009 Subject: [Haskell-cafe] Question about touchForeignPtr In-Reply-To: <1231769450.28590.75.camel@localhost> References: <1231769450.28590.75.camel@localhost> Message-ID: <68C6D835-18A6-4CFF-8CD9-90E280489679@stanford.edu> Thanks for your help, Duncan. On Jan 12, 2009, at 6:10 AM, Duncan Coutts wrote: >> Do the (ForeignPtr e) and the (Ptr e) point to the same thing? They > appear to be related because you dereference p but touch f. > > It used to be the ForeignPtr was slower to dereference than a Ptr > and so > caching it like this could make it faster (but then requires lots of > careful thought about touchForeignPtr). These days ForeignPtr is > just as > fast and so you can use withForeignPtr and never have to worry about > touchForeignPtr. You'll notice ByteString works this way. Often they point to the same thing, but not always. If they pointed to the same thing, I wouldn't store p separately, but often p has a nonzero offset from f. You either have to store the offset or cache the pointer. I found that it was both faster and simpler to cache p rather than the offset. Patrick From lemming at henning-thielemann.de Mon Jan 12 14:21:38 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jan 12 14:12:56 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: <20090112170605.212b6d4b@greenrd.org> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <1231768913.28590.66.camel@localhost> <2D150C9D-9335-4B96-B786-13A7AF12DB06@alum.mit.edu> <9d4d38820901120947l3e95f4e8gd2b133aaeb85983a@mail.gmail.com> <20090112170605.212b6d4b@greenrd.org> Message-ID: On Mon, 12 Jan 2009, Robin Green wrote: > I tend to use Control.Monad.Fix.fix (which actually has nothing to do > with monads, despite the package name) That's why it is also available from Data.Function now: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Function.html From v.dijk.bas at gmail.com Mon Jan 12 14:23:19 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Mon Jan 12 14:14:36 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: <20090112170605.212b6d4b@greenrd.org> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <1231768913.28590.66.camel@localhost> <2D150C9D-9335-4B96-B786-13A7AF12DB06@alum.mit.edu> <9d4d38820901120947l3e95f4e8gd2b133aaeb85983a@mail.gmail.com> <20090112170605.212b6d4b@greenrd.org> Message-ID: On Mon, Jan 12, 2009 at 6:06 PM, Robin Green wrote: > The fix-style equivalent to your repeat above, would be something like > this: > > repeat x = fix $ \me -> x ::: me Interesting. Your repeat and mine are compiled to the same code: Data.Stream.repeat :: forall a_aVi. a_aVi -> Data.Stream.Stream a_aVi Data.Stream.repeat = \ (@ a_a2lT) (x_aZ6 :: a_a2lT) -> letrec { repeat_x_s50K :: Data.Stream.Stream a_a2lT repeat_x_s50K = Data.Stream.::: @ a_a2lT x_aZ6 repeat_x_s50K; } in repeat_x_s50K Bas From bugfact at gmail.com Mon Jan 12 14:27:45 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Mon Jan 12 14:19:02 2009 Subject: [Haskell-cafe] Generalized partial application (again) Message-ID: Please correct me if I'm wrong in any of the reasoning below. Haskell provides the ability the perform partial application on the rightmost arguments. I learned from some pretty smart guys that partial application cannot be emulated with lambas, because they behave differently operationally, e.g. e = trace "e" op = (+) a1 = let f = (op (e 1)) in (f 10, f 100) a2 = let f = (\x -> op (e 1) x) in (f 10, f 100) a1 and a2 are operationally not the same: a1 will evaluate (e 1) once, a2 will evaluate it twice. However, Haskell also allows to partially apply the second argument of binary functions (using sections) b1 = let f = (`op` (e 1)) in (f 10, f 100) b2 = let f = (\x -> (e 1) `op` x) in (f 10, f 100) Again, b1 evaluates (e 1) once, b2 twice. b1 is actually the same as c1 = let f = ((flip op) (e 1)) in (f 10, f 100) So for ternary functions we could write more permutations of flip: flip3_12 f a1 a2 a3 = f a2 a1 a3 flip3_13 f a1 a2 a3 = f a3 a2 a1 flip3_23 f a1 a2 a3 = f a1 a3 a2 And use these to partially apply any argument e1 x = trace "e1" x e2 x = trace "e2" x op2 :: Int -> Int -> Int -> Int op2 x y z = x+10*y+100*z z1 = let f = (flip3_12 op2) (e1 1) (e2 2) in (f 3, f 4) z2 = let f = (flip3_13 op2) (e1 1) (e2 2) in (f 3, f 4) z3 = let f = (flip3_23 op2) (e1 1) (e2 2) in (f 3, f 4) This could be extended to N-ary functions. Haskell doesn't give any special syntactic support for this, but it surely is possible. Am I missing something here? Is there any easier way to perform "generalized partial application"? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090112/bcd216ad/attachment.htm From dons at galois.com Mon Jan 12 14:30:18 2009 From: dons at galois.com (Don Stewart) Date: Mon Jan 12 14:21:37 2009 Subject: [Haskell-cafe] ANN: bytestring-trie 0.1.4 In-Reply-To: <496AB775.3010204@freegeek.org> References: <496AB775.3010204@freegeek.org> Message-ID: <20090112193018.GI3582@scytale.galois.com> Do you have any benchmarks comparing dictionaries against Map ByteString Int, or Map String Int? -- Don wren: > -------------------------------------------- > -- bytestring-trie 0.1.4 > -------------------------------------------- > > Another release for efficient finite maps from (byte)strings to values. > Equal parts bugfix release and real release. This upgrade is suggested > for all users and is what 0.1.0 should have been. > > > -------------------------------------------- > -- Changes (since 0.1.2) > -------------------------------------------- > > * Fixed a number of obscure bugs when "" is used as a key. > > * Added keys and toListBy (which generalizes toList, keys,...). Also did > some optimization of toListBy so it shouldn't be as egregiously > inefficient as it was before. > > * Added fromListL, fromListR, and fromListS to Data.Trie.Convenience > along with notes about when each is more efficient than the others. > > * Separated Data.Trie (the main module for users) from > Data.Trie.Internal (gritty details, and core implementation). Data.Trie > re-exports most of Data.Trie.Internal so this is primarily a cosmetic > change. The showTrie and lookupBy_ functions are no longer exported from > Data.Trie however. > > > -------------------------------------------- > -- Links > -------------------------------------------- > > Homepage: > http://code.haskell.org/~wren/ > > Hackage: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-trie > > Darcs: > http://code.haskell.org/~wren/bytestring-trie/ > > Haddock (Darcs version): > > http://code.haskell.org/~wren/bytestring-trie/dist/doc/html/bytestring-trie/ > > -- > Live well, > ~wren > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From felipe.lessa at gmail.com Mon Jan 12 14:33:11 2009 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Mon Jan 12 14:24:27 2009 Subject: [Haskell-cafe] Generalized partial application (again) In-Reply-To: References: Message-ID: How about using "let"s? 2009/1/12 Peter Verswyvelen : > e = trace "e" > op = (+) > a1 = let f = (op (e 1)) in (f 10, f 100) > a2 = let f = (\x -> op (e 1) x) in (f 10, f 100) > a1 and a2 are operationally not the same: a1 will evaluate (e 1) once, a2 a3 = let f = (let y = e 1 in (\x -> op y x)) in (f 10, f 100) > e1 x = trace "e1" x > e2 x = trace "e2" x > op2 :: Int -> Int -> Int -> Int > op2 x y z = x+10*y+100*z > z1 = let f = (flip3_12 op2) (e1 1) (e2 2) in (f 3, f 4) > z2 = let f = (flip3_13 op2) (e1 1) (e2 2) in (f 3, f 4) > z3 = let f = (flip3_23 op2) (e1 1) (e2 2) in (f 3, f 4) z1' = let f = (let y1 = e1 1; y2 = e2 2 in (\x -> op2 y2 y1 x)) in (f 3, f 4) -- Felipe. From bugfact at gmail.com Mon Jan 12 14:44:06 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Mon Jan 12 14:35:57 2009 Subject: [Haskell-cafe] Generalized partial application (again) In-Reply-To: References: Message-ID: On Mon, Jan 12, 2009 at 8:33 PM, Felipe Lessa wrote: > > z1' = let f = (let y1 = e1 1; y2 = e2 2 in (\x -> op2 y2 y1 x)) in (f 3, f > 4) oooh! sweet! I didn't think of that. many thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090112/63524882/attachment.htm From andrewcoppin at btinternet.com Mon Jan 12 14:56:03 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon Jan 12 14:50:53 2009 Subject: [Haskell-cafe] unfoldr [ANN: HLint 1.2] In-Reply-To: <404396ef0901120033x3aca958btc3b7f35c02be29cf@mail.gmail.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <496A70D2.5020809@btinternet.com> <404396ef0901120033x3aca958btc3b7f35c02be29cf@mail.gmail.com> Message-ID: <496BA053.6020003@btinternet.com> Neil Mitchell wrote: > Hi Andrew, > > >>> HLint will automatically detect if you should have used a map, a foldr >>> or a foldl and suggest how to change your code. In the GHC, darcs and >>> Hoogle code bases there are no obvious map-like functions, which is a >>> good sign :-) >>> >>> >> ...What an intriguing idea. Clearly I'm going to have to play with this >> sometime soon. >> >> Does it suggest unfoldr too? >> > > No, but it could do in the future - I never use unfold's in my code, > so am not really familiar with them. But I will look into them, do you > have any examples where it should suggest unfoldr so I can play with > them? > Off the top of my head, try this: convert b 0 = [] convert b n = n `mod` b : convert b (n `div` b) (Takes a number and yields the radix-B representation of it. Backwards.) convert b = unfoldr (\n -> if n > 0 then Just (n `mod` b, n `div` b) else Nothing) It's also useful for converting a data structure into a list: heap_to_list = unfoldr (\h -> if heap_empty h then Nothing else Just (heap_top h, heap_delete_top h)) Those are the major uses I'm aware of. I'm sure somebody else will think of others. (IIRC, unstream is implemented as an unfold...?) From lemming at henning-thielemann.de Mon Jan 12 15:01:14 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jan 12 14:52:30 2009 Subject: [Haskell-cafe] Re: [Haskell] HaskellWiki Upgrade Aborted In-Reply-To: <1231683199.4794.67.camel@localhost> References: <4969524E.2010209@semantic.org> <4969614A.2020403@semantic.org> <1231683199.4794.67.camel@localhost> Message-ID: On Sun, 11 Jan 2009, Duncan Coutts wrote: > We really need to upgrade the whole thing. Not an easy job given the > range of stuff being run on there by lots of different people. Btw. is there a simple way to download all the Wiki content? From lemming at henning-thielemann.de Mon Jan 12 15:04:35 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jan 12 14:55:52 2009 Subject: [Haskell-cafe] unfoldr [ANN: HLint 1.2] In-Reply-To: <496BA053.6020003@btinternet.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <496A70D2.5020809@btinternet.com> <404396ef0901120033x3aca958btc3b7f35c02be29cf@mail.gmail.com> <496BA053.6020003@btinternet.com> Message-ID: On Mon, 12 Jan 2009, Andrew Coppin wrote: > Off the top of my head, try this: > > convert b 0 = [] > convert b n = n `mod` b : convert b (n `div` b) > > (Takes a number and yields the radix-B representation of it. Backwards.) > > convert b = unfoldr (\n -> if n > 0 then Just (n `mod` b, n `div` b) else Nothing) I have the nice function 'toMaybe' which simplifies this to: unfoldr (\n -> toMaybe (n>0) (n `mod` b, n `div` b)) Maybe HLint can also suggest non-base functions? ;-) http://hackage.haskell.org/packages/archive/utility-ht/0.0.2/doc/html/Data-Maybe-HT.html From schlepptop at henning-thielemann.de Mon Jan 12 15:25:28 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon Jan 12 15:10:29 2009 Subject: [Haskell-cafe] Monads aren't evil? I think they are. In-Reply-To: References: <20090108231652.24b75fe3@tritium.xx> Message-ID: <496BA738.4010409@henning-thielemann.de> Apfelmus, Heinrich schrieb: > Ertugrul Soeylemez wrote: >> Let me tell you that usually 90% of my code is >> monadic and there is really nothing wrong with that. I use especially >> State monads and StateT transformers very often, because they are >> convenient and are just a clean combinator frontend to what you would do >> manually without them: passing state. > > The insistence on avoiding monads by experienced Haskellers, in > particular on avoiding the IO monad, is motivated by the quest for elegance. > > The IO and other monads make it easy to fall back to imperative > programming patterns to "get the job done". But do you really need to > pass state around? Or is there a more elegant solution, an abstraction > that makes everything fall into place automatically? Passing state is a > valid implementation tool, but it's not a design principle. I collected some hints, on how to avoid at least the IO monad: http://www.haskell.org/haskellwiki/Avoiding_IO From pbeadling at mail2web.com Mon Jan 12 15:20:19 2009 From: pbeadling at mail2web.com (Phil) Date: Mon Jan 12 15:11:59 2009 Subject: [Haskell-cafe] Multiple State Monads Message-ID: Hi, I?ve been reading the Monads aren?t evil posts with interest ? I?m a 2nd week Haskell newbie and I?m doing my best to use them where (I hope) it is appropriate. Typically I?m writing my code out without using Monads (normally using list recursion), and then when I get them working, I delve into the Monad world.... This has been going well so far with a bit of help from you guys, but I?ve hit a snag. In the code below I?m using a state Monad (getEvolution), but unlike simpler cases I?m passing around two items of state, and one of these states is also ultimately a result ? although I don?t care about the result until I reach an end state. My implementation is a bit ugly to say the least and clearly I?m forcing round pegs into square holes here ? reading a bit online I get the impression that I can solve the two-state issue using Monad Transformers, by wrapping a StateT around a regular State object (or even two StateT Monads around an Identity Monad??). I think I understand the theory here, but any attempt to implement it leads to a horrible mess that typically doesn?t compile. The other problem of having a state that is also a result, I?m sure what to do about this. Was wondering if anyone could give me a push in the right direction ? how can I rework my state monad so that it looks less wildly. Many thanks, Phil. mcSimulate :: Double -> Double -> Word64 -> [Double] mcSimulate startStock endTime seedForSeed = expiryStock : mcSimulate startStock endTime newSeedForSeed where expiryStock = evalState ( do replicateM_ (truncate(endTime/timeStep)-1) getEvolution; getEvolution ) $ (startStock,ranq1Init seedForSeed) newSeedForSeed = seedForSeed + 246524 discount :: Double -> Double -> Double -> Double discount stock r t = stock * exp (-r)*t payOff :: Double -> Double -> Double payOff strike stock | (stock - strike) > 0 = stock - strike | otherwise = 0 -- Monad Implementation -- Yuk! evolveUnderlying :: (Double, Word64) -> ( Double, (Double, Word64) ) evolveUnderlying (stock, state) = ( newStock, ( newStock, newState ) ) where newState = ranq1Increment state newStock = stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep + ( vol*sqrt(timeStep)*normalFromRngState(state) ) ) getEvolution :: State (Double, Word64) Double getEvolution = State evolveUnderlying -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090112/e7c79810/attachment.htm From schlepptop at henning-thielemann.de Mon Jan 12 15:28:48 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon Jan 12 15:13:45 2009 Subject: [Haskell-cafe] Re: Monads aren't evil? I think they are. In-Reply-To: <20090111111016.492d7dc9@tritium.xx> References: <20090108231652.24b75fe3@tritium.xx> <20090111111016.492d7dc9@tritium.xx> Message-ID: <496BA800.90707@henning-thielemann.de> Ertugrul Soeylemez schrieb: > "Apfelmus, Heinrich" wrote: > >> The insistence on avoiding monads by experienced Haskellers, in >> particular on avoiding the IO monad, is motivated by the quest for >> elegance. >> >> The IO and other monads make it easy to fall back to imperative >> programming patterns to "get the job done". [...] > > Often, the monadic solution _is_ the elegant solution. Please don't > confuse monads with impure operations. I use the monadic properties of > lists, often together with monad transformers, to find elegant > solutions. As long as you're not abusing monads to program > imperatively, I think, they are an excellent and elegant structure. I have seen several libraries where all functions of a monad have the monadic result (), e.g. Binary.Put and other writing functions. This is a clear indicator, that the Monad instance is artificial and was only chosen because of the 'do' notation. From duncan.coutts at worc.ox.ac.uk Mon Jan 12 15:45:38 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jan 12 15:36:55 2009 Subject: [Haskell-cafe] haskell-platform mailing list Message-ID: <1231793138.28590.103.camel@localhost> Hi all, If you are interested in helping out with the haskell platform project then we invite you to subscribe to the haskell-platform mailing list. http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform This mailing list is for discussing practical stuff. We expect to discuss policy questions on the libraries mailing list. Issues like which packages to pick, what package QA standards to use etc would be discussed on the libraries mailing list. Those issues are for the community as a whole. Building and coordinating the actual releases will be done via the haskell-platform mailing list. Duncan From noteed at gmail.com Mon Jan 12 15:49:50 2009 From: noteed at gmail.com (minh thu) Date: Mon Jan 12 15:41:08 2009 Subject: [Haskell-cafe] Multiple State Monads In-Reply-To: References: Message-ID: <40a414c20901121249l39606ee5x88e4b6abeab39550@mail.gmail.com> 2009/1/12 Phil : > Hi, > > I've been reading the Monads aren't evil posts with interest ? I'm a 2nd > week Haskell newbie and I'm doing my best to use them where (I hope) it is > appropriate. Typically I'm writing my code out without using Monads > (normally using list recursion), and then when I get them working, I delve > into the Monad world.... This has been going well so far with a bit of help > from you guys, but I've hit a snag. > > In the code below I'm using a state Monad (getEvolution), but unlike simpler > cases I'm passing around two items of state, and one of these states is also > ultimately a result ? although I don't care about the result until I reach > an end state. My implementation is a bit ugly to say the least and clearly > I'm forcing round pegs into square holes here ? reading a bit online I get > the impression that I can solve the two-state issue using Monad > Transformers, by wrapping a StateT around a regular State object (or even > two StateT Monads around an Identity Monad??). I think I understand the > theory here, but any attempt to implement it leads to a horrible mess that > typically doesn't compile. The other problem of having a state that is also > a result, I'm sure what to do about this. > > Was wondering if anyone could give me a push in the right direction ? how > can I rework my state monad so that it looks less wildly. > > Many thanks, > > Phil. > > mcSimulate :: Double -> Double -> Word64 -> [Double] > mcSimulate startStock endTime seedForSeed = expiryStock : mcSimulate > startStock endTime newSeedForSeed > where > expiryStock = evalState ( do replicateM_ (truncate(endTime/timeStep)-1) > getEvolution; getEvolution ) > $ (startStock,ranq1Init seedForSeed) > newSeedForSeed = seedForSeed + 246524 > > discount :: Double -> Double -> Double -> Double > discount stock r t = stock * exp (-r)*t > > payOff :: Double -> Double -> Double > payOff strike stock | (stock - strike) > 0 = stock - strike > | otherwise = 0 > > -- Monad Implementation > > -- Yuk! > evolveUnderlying :: (Double, Word64) -> ( Double, (Double, Word64) ) > evolveUnderlying (stock, state) = ( newStock, ( newStock, newState ) ) > where > newState = ranq1Increment state > newStock = stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep + ( > vol*sqrt(timeStep)*normalFromRngState(state) ) ) > > getEvolution :: State (Double, Word64) Double > getEvolution = State evolveUnderlying Hi, the evolveUnderlying can simply manipulate the state, so you can do evolveUnderlying -- state (not your state, but the tuple) changes here r <- gets fst -- query the state for the first element of the tuple return r -- simply return what you want Note that if you want to combine your state and the stock, you simply end with a new kind of state : the tuple (thus, no need to compose two State) Note also, since evolveUnderlying only manipulates the internal state of the State monad, it returns (). Depending on how you want to structure your code, you can also use execState instead of evalState : it returns the state on which you can use fst. hope it helps, Thu From ryani.spam at gmail.com Mon Jan 12 15:58:52 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Jan 12 15:50:08 2009 Subject: [Haskell-cafe] Fw: [darcs-devel] "Inferred type is less polymorphic than expected" and type witnesses In-Reply-To: <20090112122118.7a4c6079@hoelzro.homelinux.net> References: <20090112074342.51a2f641@hoelzro.homelinux.net> <2f9b2d30901121005p54aacc05ma632c7b6fbad07df@mail.gmail.com> <20090112122118.7a4c6079@hoelzro.homelinux.net> Message-ID: <2f9b2d30901121258n7c2c39cbs5a566d3a84d44565@mail.gmail.com> Here's a minimal bit of code that gives you the error: > data FL p x z where > ConsFL :: p x y -> FL p y z -> FL p x z > NilFL :: FL p x x > data GTE a1 a2 x z where > GTE :: a1 x y -> a2 y z -> GTE a1 a2 x z > ccwo (ConsFL x xs) (ConsFL y ys) = > case ccwo xs ys of > GTE nx ny -> undefined However, your problem goes further than this; if we add the NilFL cases, you *need* to understand the type of ccwo and qualify it with a type signature, or else you get the "GADT pattern match in non-rigid context" error. The reason it doesn't show up in this first case is that ConsFL isn't using all the powers of GADTs; it can be represented with just existential types. So, FL p represents an element of the transitive closure of p over types; that is, if you have ab :: P A B ac :: P A C bd :: P B D cd :: P C D then you can get the following FLs: NilFL :: FL P x x -- for any x ConsFL ab NilFL :: FL P A B ConsFL ac NilFL :: FL P A C ConsFL bd NilFL :: FL P B D ConsFL cd NilFL :: FL P C D abd = ConsFL ab (ConsFL bd NilFL) :: FL P A D acd = ConsFL ac (ConsFL cd NilFL) :: FL P A D Note the two separate constructions of FL P A D. This means your suggested type for ccwo can't work; consider "ccwo abd acd". The existentially held type in the first list is "B", and in the second list is "C". So, what do you expect compare_changes_with_old to do in this "diamond" case? I think if you understand that, you'll be able to figure out a working definition. -- ryan On Mon, Jan 12, 2009 at 10:21 AM, Rob Hoelz wrote: > I should've included these when I forwarded it, but that was pre-coffee > today. =P > > class MyEq p where > unsafeCompare :: p C(a b) -> p C(c d) -> Bool > -- more stuff > > data FL a C(x z) where > (:>:) :: a C(x y) -> FL a C(y z) -> FL a C(x z) > NilFL :: FL a C(x x) > > data (a1 :> a2) C(x y) = FORALL(z) (a1 C(x z)) :> (a2 C(z y)) > infixr 1 :> > > -- I'm not entirely sure on this one, because type witnesses confuse me. > compare_changes_with_old :: (Patchy p) => > FL p C(x y) > -> FL p C(x y) > -> (FL p :> FL p) C(x y) > > C(args...) is a preprocessor macro that expands to args if Darcs is > building with GADT type witnesses. FORALL(args...) expands to forall > args. under the same condition. > > All of the definitions are available at > http://darcs.net/api-doc/doc-index.html as well. > > Thanks, > Rob > > "Ryan Ingram" wrote: > >> Some questions first: >> What's the type of this function supposed to be? >> What's the type of unsafeCompare? >> How is the data type with NilFL and :>: defined? >> >> -- ryan >> >> On Mon, Jan 12, 2009 at 5:43 AM, Rob Hoelz wrote: >> > Forwarding to Haskell Cafe per Eric's suggestion. >> > >> > Begin forwarded message: >> > >> > Date: Sun, 11 Jan 2009 23:01:31 -0600 >> > From: Rob Hoelz >> > To: darcs-devel@darcs.net >> > Subject: [darcs-devel] "Inferred type is less polymorphic than >> > expected" and type witnesses >> > >> > >> > Hello again, Darcs users and developers, >> > >> > As I mentioned in my last e-mail, I'm working on >> > http://bugs.darcs.net/issue291. It's actually gone pretty well, >> > and I feel I'm just about finished (I've done all but sorting out >> > the changes after leaving the editor), only I've encountered the >> > compiler error you see in the subject of this message. This error >> > only appears when compiling with witnesses. Here's the source for >> > the function that it's complaining about: >> > >> > compare_changes_with_old (x :>: xs) (y :>: ys) = >> > case compare_changes_with_old xs ys of >> > nx :> ny -> if unsafeCompare x y >> > then ((x :>: nx) :> ny) >> > else (NilFL :> (y :>: ys)) >> > compare_changes_with_old NilFL NilFL = (NilFL :> NilFL) >> > compare_changes_with_old NilFL ys@(_ :>: _) = (NilFL :> ys) >> > compare_changes_with_old x@(_ :>: _) NilFL = (NilFL :> NilFL) >> > >> > Now, I have two questions: >> > >> > 1) What exactly does this error mean, and how do I get around it? >> > 2) What are witness types, and what are they used for? >> > >> > I will gladly accept links to fine manuals as answers to either >> > question, but simple explanations would be nice. =D I thought I >> > understood Haskell pretty well, but existentially qualified types >> > have thrown me for a loop. >> > >> > Thanks much, >> > Rob Hoelz >> > _______________________________________________ >> > darcs-devel mailing list (AUTOMATIC POSTINGS ONLY PLEASE!) >> > darcs-devel@darcs.net >> > http://lists.osuosl.org/mailman/listinfo/darcs-devel >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe@haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > From d at domob.eu Mon Jan 12 16:16:14 2009 From: d at domob.eu (Daniel Kraft) Date: Mon Jan 12 16:03:44 2009 Subject: [Haskell-cafe] Data analysis with Haskell Message-ID: Hi all, I'm going to start a project where I'll have to do some data analysis (statistics about product orders) based on database entries; it will mostly be some very basic stuff like grouping by certain rules and finding averages as well as summing up and such. It will however be more than what can be done directly in the database using SQL, so there will be some processing in my program. I'm thinking about trying to do this in Haskell (because I like this language a lot); however, it is surely not my most proficient language and I tried to do some number crunching (real one that time) before in Haskell where I had to deal with some 4 million integer lists, and this failed; the program took a lot more memory than would have been necessary and ran for several minutes (kept swapping all the time, too). A rewrite in Fortran did give the result in 6s and didn't run out of space. This was probably my fault at that time, because I surely did something completely wrong for the Haskell style. However, I fear I could run into problems like that in the new project, too. So I want to ask for your opinions, do you think Haskell is the right language to do data analysis of this kind? And do you think it is hard for still beginner Haskell programmer to get this right so Haskell does not use up a lot of memory for thunks or list-overhead or things like that? And finally, are there database bindings for Haskell I could use for the queries? Thanks a lot! Daniel From dons at galois.com Mon Jan 12 16:18:02 2009 From: dons at galois.com (Don Stewart) Date: Mon Jan 12 16:09:05 2009 Subject: [Haskell-cafe] Data analysis with Haskell In-Reply-To: References: Message-ID: <20090112211802.GM3582@scytale.galois.com> d: > Hi all, > > I'm going to start a project where I'll have to do some data analysis > (statistics about product orders) based on database entries; it will > mostly be some very basic stuff like grouping by certain rules and > finding averages as well as summing up and such. It will however be > more than what can be done directly in the database using SQL, so there > will be some processing in my program. > > I'm thinking about trying to do this in Haskell (because I like this > language a lot); however, it is surely not my most proficient language > and I tried to do some number crunching (real one that time) before in > Haskell where I had to deal with some 4 million integer lists, and this > failed; the program took a lot more memory than would have been > necessary and ran for several minutes (kept swapping all the time, too). > A rewrite in Fortran did give the result in 6s and didn't run out of > space. **Don't use lists when you mean to use arrays** E.g. multiple two 4M element arrays, map over the result and sum that. import Data.Array.Vector main = print . sumU . mapU (+7) $ zipWithU (*) (enumFromToU 1 (4000000 :: Int)) (enumFromToU 2 (4000001 :: Int)) Compile it: $ ghc -O2 -fvia-C -optc-O3 -funbox-strict-fields --make $ time ./A 2886605259654448384 ./A 0.03s user 0.00s system 97% cpu 0.034 total Not the end of the world at all. > This was probably my fault at that time, because I surely did something > completely wrong for the Haskell style. However, I fear I could run > into problems like that in the new project, too. So I want to ask for > your opinions, do you think Haskell is the right language to do data You want to compile Haskell DB queries into SQL? > analysis of this kind? And do you think it is hard for still beginner > Haskell programmer to get this right so Haskell does not use up a lot of > memory for thunks or list-overhead or things like that? And finally, > are there database bindings for Haskell I could use for the queries? There are lots of database bindings. Very popular ones are HDBC and Takusen. Check on hackage.haskell.org -- Donnn From ahunter at cs.hmc.edu Mon Jan 12 16:41:03 2009 From: ahunter at cs.hmc.edu (Andrew Hunter) Date: Mon Jan 12 16:32:19 2009 Subject: [Haskell-cafe] Re: [Haskell] ANN: ghci-haskeline 0.1 In-Reply-To: <6d74b0d20901121257q19b953cft2c8dc54b98809ef5@mail.gmail.com> References: <6d74b0d20901121257q19b953cft2c8dc54b98809ef5@mail.gmail.com> Message-ID: <20090112214103.GW13626@knuth.cs.hmc.edu> On Mon, Jan 12, 2009 at 12:57:57PM -0800, Judah Jacobson wrote: > I'm pleased to announce the first release of ghci-haskeline. This > package uses the GHC API to reimplement ghci with the Haskeline > library as a backend. Haskeline is a library for line input in > command-line programs, similar to readline or editline, which is > written in Haskell and thus (hopefully) more easily integrated into > other Haskell programs. > Perhaps this has already been discussed at length, in which case I apologize but, well, why provide line input editing at all? A number of languages/programs (off the top of my head: sml, most Schemes) don't; the standard method to get line editing is rlwrap. And this works (in my limited experience) quite well. The disadvantage as I see it of using editline or Haskeline or whatever is that it's going to be sutbly different than other methods; presumably, people won't like the changes in behavior. It seems to me that from a UNIX-y separation of concern view, the right thing to do (as many languages have chosen) is to /not/ provide line editing, and just let the user do that with any number of convenient tools that focus on getting/that/ right (like rlwrap.) Is there a reason we've not taken that approach? Thanks, AHH From haskell at list.mightyreason.com Mon Jan 12 17:11:19 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Mon Jan 12 17:02:44 2009 Subject: [Haskell-cafe] Re: [Haskell] ANN: ghci-haskeline 0.1 In-Reply-To: <20090112214103.GW13626@knuth.cs.hmc.edu> References: <6d74b0d20901121257q19b953cft2c8dc54b98809ef5@mail.gmail.com> <20090112214103.GW13626@knuth.cs.hmc.edu> Message-ID: Haskeline is designed to remove the readline dependency, because Windows does not have readline. So rlwrap is useless there. Andrew Hunter wrote: > On Mon, Jan 12, 2009 at 12:57:57PM -0800, Judah Jacobson wrote: >> I'm pleased to announce the first release of ghci-haskeline. This >> package uses the GHC API to reimplement ghci with the Haskeline >> library as a backend. Haskeline is a library for line input in >> command-line programs, similar to readline or editline, which is >> written in Haskell and thus (hopefully) more easily integrated into >> other Haskell programs. >> > > Perhaps this has already been discussed at length, in which case I > apologize but, well, why provide line input editing at all? > > A number of languages/programs (off the top of my head: sml, most > Schemes) don't; the standard method to get line editing is rlwrap. > And this works (in my limited experience) quite well. The > disadvantage as I see it of using editline or Haskeline or whatever is > that it's going to be sutbly different than other methods; presumably, > people won't like the changes in behavior. > > It seems to me that from a UNIX-y separation of concern view, the > right thing to do (as many languages have chosen) is to /not/ provide > line editing, and just let the user do that with any number of > convenient tools that focus on getting/that/ right (like rlwrap.) Is > there a reason we've not taken that approach? > > Thanks, > AHH From roma at ro-che.info Mon Jan 12 17:12:06 2009 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon Jan 12 17:03:31 2009 Subject: [Haskell-cafe] Re: [Haskell] ANN: ghci-haskeline 0.1 In-Reply-To: <20090112214103.GW13626@knuth.cs.hmc.edu> References: <6d74b0d20901121257q19b953cft2c8dc54b98809ef5@mail.gmail.com> <20090112214103.GW13626@knuth.cs.hmc.edu> Message-ID: <20090112221206.GA6451@flit> * Andrew Hunter [2009-01-12 13:41:03-0800] > On Mon, Jan 12, 2009 at 12:57:57PM -0800, Judah Jacobson wrote: > > I'm pleased to announce the first release of ghci-haskeline. This > > package uses the GHC API to reimplement ghci with the Haskeline > > library as a backend. Haskeline is a library for line input in > > command-line programs, similar to readline or editline, which is > > written in Haskell and thus (hopefully) more easily integrated into > > other Haskell programs. > > > > Perhaps this has already been discussed at length, in which case I > apologize but, well, why provide line input editing at all? > > A number of languages/programs (off the top of my head: sml, most > Schemes) don't; the standard method to get line editing is rlwrap. > And this works (in my limited experience) quite well. The > disadvantage as I see it of using editline or Haskeline or whatever is > that it's going to be sutbly different than other methods; presumably, > people won't like the changes in behavior. > > It seems to me that from a UNIX-y separation of concern view, the > right thing to do (as many languages have chosen) is to /not/ provide > line editing, and just let the user do that with any number of > convenient tools that focus on getting/that/ right (like rlwrap.) Is > there a reason we've not taken that approach? For example, ghci does more intelligent completion than rlwrap probably can do: X -> no matches :m X -> XMonad -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain From rodrigo.bonifacio at uol.com.br Mon Jan 12 17:24:47 2009 From: rodrigo.bonifacio at uol.com.br (rodrigo.bonifacio) Date: Mon Jan 12 17:16:06 2009 Subject: [Haskell-cafe] A pattern type signature cannot bind scoped type variables `t' Message-ID: <496bc32f52f74_3f7c155555587eb411b0@weasel1.tmail> An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090112/83179153/attachment.htm From ahunter at cs.hmc.edu Mon Jan 12 17:28:51 2009 From: ahunter at cs.hmc.edu (Andrew Hunter) Date: Mon Jan 12 17:20:07 2009 Subject: [Haskell-cafe] Re: [Haskell] ANN: ghci-haskeline 0.1 In-Reply-To: References: <6d74b0d20901121257q19b953cft2c8dc54b98809ef5@mail.gmail.com> <20090112214103.GW13626@knuth.cs.hmc.edu> Message-ID: <20090112222851.GX13626@knuth.cs.hmc.edu> On Mon, Jan 12, 2009 at 10:11:19PM +0000, ChrisK wrote: > Haskeline is designed to remove the readline dependency, because Windows > does not have readline. So rlwrap is useless there. > Ah, I hadn't considered Windows support--that makes sense. Thanks, that answers my questions. AHH From derek.a.elkins at gmail.com Mon Jan 12 17:56:33 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Mon Jan 12 17:47:56 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <1231768913.28590.66.camel@localhost> <2D150C9D-9335-4B96-B786-13A7AF12DB06@alum.mit.edu> <9d4d38820901120947l3e95f4e8gd2b133aaeb85983a@mail.gmail.com> Message-ID: <1231800993.26426.1.camel@derek-laptop> On Mon, 2009-01-12 at 19:43 +0100, Bas van Dijk wrote: > On Mon, Jan 12, 2009 at 6:47 PM, Max Bolingbroke > wrote: > > GHC should indeed be doing so. I'm working (on and off) to work out > > some suitable heuristics and put the transformation into ghc -O2. > > There are a few wrinkles that still need sorting out, but preliminary > > indications are that it decreases the runtime of our standard > > benchmark suite, nofib, by 12% or so. > > Great! > > In the Stream library I'm developing at http://code.haskell.org/Stream > I 'closurize' (for lack of a better name) One name for this transformation (or one very closely related to it) is lambda-dropping which was chosen to contrast to the better known transformation, lambda lifting. From haskell at list.mightyreason.com Mon Jan 12 17:58:19 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Mon Jan 12 17:49:49 2009 Subject: [Haskell-cafe] Re: System.CPUTime and picoseconds In-Reply-To: References: <49690FCF.3080704@libero.it> <496A4841.4090700@list.mightyreason.com> <496B2248.4060006@list.mightyreason.com> Message-ID: Tony Finch wrote: > The FreeBSD kernel uses a 64+64 bit fixed point type to represent time, > where the integer part is a normal Unix time_t. The fractional part is > 64 bits wide in order to be able to represent multi-GHz frequencies > precisely. "multi-GHz" being a euphemism for 18.45*10^9 GHz, over 18 billion GHz. I just read through that. The granularity is 2^-64 seconds, or 5.4*^-20 seconds? That is 54 nano-pico-seconds. I can see needing better than nanosecond, and going to milli-nanoseconds like Haskell, but to jump close to pico-nano-seconds? That skips right past micro-nano-seconds and nano-nano-seconds. That's 20 million times more resolution than Haskell's picoseconds. My that was fun to write. It looks like an excellent performance hack for OS kernels. 64-bits make for simple register and cache access, the compiled code is small and quick, etc. As a portable API it is far too complicated to use. Not in the least because only FreeBSD probably has that API. Note that at 10^-20 seconds the general relativistic shift due to altitude will matter over less than the thickness of a closed laptop. Defining "now" that accurately has meaning localized to less then your computer's size. The warranty for the bottom of your screen will expire sooner than that of the top. Only stock traders and relativistic particles care about time intervals that short. "FreeBSD ? designed for the interstellar craft to tomorrow" Hmm...The W and Z bosons decay the fastest with 10^-25 second lifetimes, the shortest known lifetimes that I can find. The fundamental Planck scale, the shortest amount of time in today's physics, is 5.4*10^-44 seconds. So with 80 more bits FreeBSD would be at the fundamental limit. Of course the conversion then depends on the values of h, c, and G. Now that would also be a good April Fool's joke proposal. -- Chris From derek.a.elkins at gmail.com Mon Jan 12 17:59:25 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Mon Jan 12 17:50:49 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <1231768913.28590.66.camel@localhost> <2D150C9D-9335-4B96-B786-13A7AF12DB06@alum.mit.edu> <9d4d38820901120947l3e95f4e8gd2b133aaeb85983a@mail.gmail.com> <20090112170605.212b6d4b@greenrd.org> Message-ID: <1231801165.26426.5.camel@derek-laptop> On Mon, 2009-01-12 at 20:23 +0100, Bas van Dijk wrote: > On Mon, Jan 12, 2009 at 6:06 PM, Robin Green wrote: > > The fix-style equivalent to your repeat above, would be something like > > this: > > > > repeat x = fix $ \me -> x ::: me > > Interesting. The definition of fix is small and non-recursive, in particular it is: fix f = let x = f x in x When inlined, which it -will- be if optimizations are enabled, fix (x:::) is -identical- to your definition of repeat. From bugfact at gmail.com Mon Jan 12 18:09:54 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Mon Jan 12 18:01:10 2009 Subject: [Haskell-cafe] Gtk2Hs on Windows for GHC 6.10.1 Message-ID: Gtk2Hs 0.9.13 has an annoying bug on Windows that makes it impossible to run via GHCi. So to see if the latest development version works better, I tried to build it on Windows using GHC 6.10.1, but I failed to do so with both MSYS and Cygwin. Does anybody know how to build it on Windows? Thanks, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/211de6a0/attachment.htm From flippa at flippac.org Mon Jan 12 18:23:32 2009 From: flippa at flippac.org (Philippa Cowderoy) Date: Mon Jan 12 18:14:51 2009 Subject: [Haskell-cafe] Monads aren't evil? I think they are. In-Reply-To: References: <20090108231652.24b75fe3@tritium.xx> Message-ID: <1231802612.24774.42.camel@flippa-eee> On Sun, 2009-01-11 at 10:44 +0100, Apfelmus, Heinrich wrote: > Ertugrul Soeylemez wrote: > > Let me tell you that usually 90% of my code is > > monadic and there is really nothing wrong with that. I use especially > > State monads and StateT transformers very often, because they are > > convenient and are just a clean combinator frontend to what you would do > > manually without them: passing state. > > The insistence on avoiding monads by experienced Haskellers, in > particular on avoiding the IO monad, is motivated by the quest for elegance. > By some experienced Haskellers. Others pile them on where they feel it's appropriate, though avoiding IO where possible is still a good principle. I often find that less is essentially stateful than it looks. However, I also find that as I decompose tasks - especially if I'm willing to 'de-fuse' things - then state-like dataflows crop up again in places where they had been eliminated. Especially if I want to eg instrument or quietly abstract some code. Spotting particular sub-cases like Reader and Writer is a gain, of course! > A good example is probably the HGL (Haskell Graphics Library), a small > vector graphics library which once shipped with Hugs. The core is the type > > Graphic > > which represents a drawing and whose semantics are roughly > > Graphic = Pixel -> Color > After having constructed a graphic, you'll also want to draw it on > screen, which can be done with the function > > drawInWindow :: Graphic -> Window -> IO () > Note that there are two different things going on here. The principle of building up 'programs' in pure code to execute via IO is good - though ironically enough, plenty of combinator libraries for such tasks form monads themselves. Finding the right domain for DSL programs is also important, but this is not necessarily as neatly functional. If you start with a deep embedding rather than a shallow one then this isn't much of a problem even if you find your first attempt was fatally flawed - the DSL code's just another piece of data. -- Philippa Cowderoy From lrpalmer at gmail.com Mon Jan 12 18:34:10 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Jan 12 18:25:26 2009 Subject: [Haskell-cafe] Data analysis with Haskell In-Reply-To: References: Message-ID: <7ca3f0160901121534v5a60580av3a6f2e374b105d1a@mail.gmail.com> On Mon, Jan 12, 2009 at 2:16 PM, Daniel Kraft wrote: > This was probably my fault at that time, because I surely did something > completely wrong for the Haskell style. However, I fear I could run into > problems like that in the new project, too. So I want to ask for your > opinions, do you think Haskell is the right language to do data analysis of > this kind? And do you think it is hard for still beginner Haskell > programmer to get this right so Haskell does not use up a lot of memory for > thunks or list-overhead or things like that? Haskell's memory performance *can* be quite subtle. Here's my opinion though: avoiding a language is a terrible way to learn it. If you want to learn Haskell, do your project in Haskell. Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090112/6372c42e/attachment.htm From duncan.coutts at worc.ox.ac.uk Mon Jan 12 18:35:13 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jan 12 18:26:29 2009 Subject: [Haskell-cafe] Gtk2Hs on Windows for GHC 6.10.1 In-Reply-To: References: Message-ID: <1231803313.28590.130.camel@localhost> On Tue, 2009-01-13 at 00:09 +0100, Peter Verswyvelen wrote: > Gtk2Hs 0.9.13 has an annoying bug on Windows that makes it impossible > to run via GHCi. > > > So to see if the latest development version works better, I tried to > build it on Windows using GHC 6.10.1, but I failed to do so with both > MSYS and Cygwin. > > > Does anybody know how to build it on Windows? If the instructions on the gtk2hs website do not help: http://haskell.org/gtk2hs/archives/category/faqs/ http://haskell.org/gtk2hs/archives/2005/06/24/building-from-source-on-windows/ then the best place to ask is on the gtk2hs users mailing list: http://haskell.org/gtk2hs/development/#mailing_lists Duncan From greenrd at greenrd.org Mon Jan 12 16:48:08 2009 From: greenrd at greenrd.org (Robin Green) Date: Mon Jan 12 18:28:40 2009 Subject: [Haskell-cafe] unfoldr [ANN: HLint 1.2] In-Reply-To: References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <496A70D2.5020809@btinternet.com> <404396ef0901120033x3aca958btc3b7f35c02be29cf@mail.gmail.com> <496BA053.6020003@btinternet.com> Message-ID: <20090112214808.170b457d@greenrd.org> On Mon, 12 Jan 2009 21:04:35 +0100 (CET) Henning Thielemann wrote: > > On Mon, 12 Jan 2009, Andrew Coppin wrote: > > > Off the top of my head, try this: > > > > convert b 0 = [] > > convert b n = n `mod` b : convert b (n `div` b) > > > > (Takes a number and yields the radix-B representation of it. > > Backwards.) > > > > convert b = unfoldr (\n -> if n > 0 then Just (n `mod` b, n `div` > > b) else Nothing) > > I have the nice function 'toMaybe' which simplifies this to: > unfoldr (\n -> toMaybe (n>0) (n `mod` b, n `div` b)) I would use the more general idiom: unfoldr (\n -> guard (n > 0) >> return (n `mod` b, n `div` b)) -- Robin From bugfact at gmail.com Mon Jan 12 18:46:42 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Mon Jan 12 18:37:58 2009 Subject: [Haskell-cafe] Re: System.CPUTime and picoseconds In-Reply-To: <496B2248.4060006@list.mightyreason.com> References: <49690FCF.3080704@libero.it> <496A4841.4090700@list.mightyreason.com> <496B2248.4060006@list.mightyreason.com> Message-ID: I just tried getCPUTime on Windows and it seems to tick really slow, about 10 times per second or so. Actually it changes every 15600100000 picoseconds, so about 15600 microseconds, which is indeed the interval at which Windows updates its "tick" count. So anyway a lot of room to go to the picosecond resolution :) But, is this intended behavior? How does it perform on Linux? Should it behave the same on all platforms? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/99fdd987/attachment.htm From jgoerzen at complete.org Mon Jan 12 19:19:59 2009 From: jgoerzen at complete.org (John Goerzen) Date: Mon Jan 12 19:11:17 2009 Subject: [Haskell-cafe] Looking for Haskellers on Windows In-Reply-To: <4968B2CC.30302@btinternet.com> References: <887509072.20090110171802@gmail.com> <4968B2CC.30302@btinternet.com> Message-ID: <496BDE2F.7020607@complete.org> Andrew Coppin wrote: > G?nther Schmidt wrote: >> Hi Bulat, >> >> I do :), but I was amazed that there was no response to a post with, >> what I thought, would be a rather common problem for an application >> developer. That post was about writing to an MS-Access database via >> HDBC-ODBC, which fails. When I then asked the HDBC maintainer himself >> it turned out that he doesn't use Windows either and thus can't help. >> >> Thus my cry for help explicitly to Haskellers on Windows. > > If you managed to get HDBC-ODBC to compile on Windows in the first > place, you got further than me... Can you describe exactly what the problem you're having is? > > It's a pitty that Windows receives so little support, but I guess if > nobody has a Windows box to test with, there's not much you can do about it. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From sdh33 at cornell.edu Mon Jan 12 19:56:30 2009 From: sdh33 at cornell.edu (Stephen Hicks) Date: Mon Jan 12 19:47:44 2009 Subject: [Haskell-cafe] Functions with generic return types Message-ID: <50b5ae760901121656v44d98358t2fd1d08e3dc6fcf6@mail.gmail.com> Hi, I'm trying to write a small module for conveniently writing functions that can return any of a finite number of types. That is, I'd like to be able to write something like foo :: StringOrInt t => String -> IO t This is pretty easy to do if I hard-code the classes as above, but I run into difficulties making it more general. In particular, it's convenient to use incoherent instances so that I can insert the polymorphism at whatever level I choose (see the third instance declaration below, as well as the function foo). But when I try to make this work for monads, it fails - that is, my function bar (below) always prints both "str" and "int" because I can't make it lazy enough - in order to get even a thunk in the non-monadic type, it seems like the side effect has to happen (unsafeInterleaveIO + seq would sort of fix this here, but not generally), whereas the type alone should be sufficient in selecting which monad needs to be evaluated. I'm having a hard time explaining this abstractly, but I think the following concrete code explains pretty clearly what I'm trying to do, and I would appreciate any comments or suggestions for either a better way to go about this, or something already written that achieves something similar? Thanks, steve ==== {-# LANGUAGE TypeSynonymInstances, MultiParamTypeClasses, FlexibleInstances, FlexibleContexts, IncoherentInstances #-} class Pick c a where pick :: c -> a instance Pick (a,b) a where pick = fst instance Pick (a,b) b where pick = snd instance Pick (a,b) c => Pick (d -> a, d -> b) (d -> c) where pick (a,b) d = pick (a d,b d) -- This instance definition is broken... instance (Monad m,Pick (a,b) c) => Pick (m a,m b) (m c) where pick (ma,mb) = do { a <- ma; b <- mb; return $ pick (a,b) } foo :: Pick (String,Int) t => String -> t foo = pick (id :: String -> String, length :: String -> Int) toStr :: String -> IO String toStr s = putStrLn "str" >> return s toInt :: String -> IO Int toInt s = putStrLn "int" >> return (length s) bar :: Pick (String,Int) t => String -> IO t bar = pick (toStr,toInt) From pbeadling at mail2web.com Mon Jan 12 20:34:57 2009 From: pbeadling at mail2web.com (Phil) Date: Mon Jan 12 20:26:49 2009 Subject: [Haskell-cafe] Multiple State Monads In-Reply-To: <40a414c20901121249l39606ee5x88e4b6abeab39550@mail.gmail.com> Message-ID: Thanks Minh - I've updated my code as you suggested. This looks better than my first attempt! Is it possible to clean this up any more? I find: ( (), (Double, Word64) ) a bit odd syntactically, although I understand this is just to fit the type to the State c'tor so that we don't have to write our own Monad longhand. I guess given that (), as I understand, is just like 'void' in C, it should not affect program performance, and the fact that I'm using replicateM_ means that the result is being ignored for all but my last iteration. As an exercise I assume I could have approached the problem using the StateT transformer, although for the purposes below carrying two states in a tuple is probably clearer and more performant? Thanks again, Phil. mcSimulate :: Double -> Double -> Word64 -> [Double] mcSimulate startStock endTime seedForSeed = fst expiryStock : mcSimulate startStock endTime newSeedForSeed where expiryStock = execState ( do replicateM_ (truncate(endTime/timeStep)-1) getEvolution; getEvolution ) $ (startStock,ranq1Init seedForSeed) newSeedForSeed = seedForSeed + 246524 -- Monad Implementation evolveUnderlying :: (Double, Word64) -> ( (), (Double, Word64) ) evolveUnderlying (stock, state) = ( (), ( newStock, newState ) ) where newState = ranq1Increment state newStock = stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep + ( vol*sqrt(timeStep)*normalFromRngState(state) ) ) getEvolution :: State (Double, Word64) () getEvolution = State evolveUnderlying On 12/01/2009 20:49, "minh thu" wrote: > 2009/1/12 Phil : >> Hi, >> >> I've been reading the Monads aren't evil posts with interest ? I'm a 2nd >> week Haskell newbie and I'm doing my best to use them where (I hope) it is >> appropriate. Typically I'm writing my code out without using Monads >> (normally using list recursion), and then when I get them working, I delve >> into the Monad world.... This has been going well so far with a bit of help >> from you guys, but I've hit a snag. >> >> In the code below I'm using a state Monad (getEvolution), but unlike simpler >> cases I'm passing around two items of state, and one of these states is also >> ultimately a result ? although I don't care about the result until I reach >> an end state. My implementation is a bit ugly to say the least and clearly >> I'm forcing round pegs into square holes here ? reading a bit online I get >> the impression that I can solve the two-state issue using Monad >> Transformers, by wrapping a StateT around a regular State object (or even >> two StateT Monads around an Identity Monad??). I think I understand the >> theory here, but any attempt to implement it leads to a horrible mess that >> typically doesn't compile. The other problem of having a state that is also >> a result, I'm sure what to do about this. >> >> Was wondering if anyone could give me a push in the right direction ? how >> can I rework my state monad so that it looks less wildly. >> >> Many thanks, >> >> Phil. >> >> mcSimulate :: Double -> Double -> Word64 -> [Double] >> mcSimulate startStock endTime seedForSeed = expiryStock : mcSimulate >> startStock endTime newSeedForSeed >> where >> expiryStock = evalState ( do replicateM_ (truncate(endTime/timeStep)-1) >> getEvolution; getEvolution ) >> $ (startStock,ranq1Init seedForSeed) >> newSeedForSeed = seedForSeed + 246524 >> >> discount :: Double -> Double -> Double -> Double >> discount stock r t = stock * exp (-r)*t >> >> payOff :: Double -> Double -> Double >> payOff strike stock | (stock - strike) > 0 = stock - strike >> | otherwise = 0 >> >> -- Monad Implementation >> >> -- Yuk! >> evolveUnderlying :: (Double, Word64) -> ( Double, (Double, Word64) ) >> evolveUnderlying (stock, state) = ( newStock, ( newStock, newState ) ) >> where >> newState = ranq1Increment state >> newStock = stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep + ( >> vol*sqrt(timeStep)*normalFromRngState(state) ) ) >> >> getEvolution :: State (Double, Word64) Double >> getEvolution = State evolveUnderlying > > Hi, > > the evolveUnderlying can simply manipulate the state, so you can > > do evolveUnderlying -- state (not your state, but the tuple) changes here > r <- gets fst -- query the state for the first element of the tuple > return r -- simply return what you want > > Note that if you want to combine your state and the stock, you simply end > with a new kind of state : the tuple (thus, no need to compose two State) > > Note also, since evolveUnderlying only manipulates the internal state of the > State monad, it returns (). > > Depending on how you want to structure your code, you can also use execState > instead of evalState : it returns the state on which you can use fst. > > hope it helps, > Thu From lrpalmer at gmail.com Mon Jan 12 21:48:05 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Jan 12 21:39:21 2009 Subject: [Haskell-cafe] Functions with generic return types In-Reply-To: <50b5ae760901121656v44d98358t2fd1d08e3dc6fcf6@mail.gmail.com> References: <50b5ae760901121656v44d98358t2fd1d08e3dc6fcf6@mail.gmail.com> Message-ID: <7ca3f0160901121848u446ed4aalf5153abfddacb950@mail.gmail.com> On Mon, Jan 12, 2009 at 5:56 PM, Stephen Hicks wrote: > -- This instance definition is broken... > instance (Monad m,Pick (a,b) c) => Pick (m a,m b) (m c) where > pick (ma,mb) = do { a <- ma; b <- mb; return $ pick (a,b) } First, and I know these types of comments are generally unwanted, but I recommend you *not do this*. You are only making pain for yourself later. Haskell is not good at this type of ad-hoc polymorphism (partially because it does not play well with inference). I.e. whyever you think you need this machinery, I suggest you spend some time rethinking why this is really necessary. Okay, now to explain this instance. An instance Pick (a,b) c is just a function (a,b) -> c. So this instance reduces to the possibility of writing a function: monadify :: ((a,b) -> c) -> ((m a, m b) -> m c) Which is only implementable by executing both actions m a and m b (because you need both an a and a b to pass to c). Consider what would happen if a pick function looked at the contents of its argument? e.g. maybe someone writes: instance Pick (Int,Int) Int where pick (x,y) = min x y Then you would have to know the actual values to decide what to return, thus both actions must be executed. One thing I always like to do when I'm writing typeclasses is write the proof term library first (i.e. explicit dictionary passing) and then start turning those into typeclasses. This practice helps to weed out impossible ideas (eg. if you can't do what you want by explicitly passing dictionaries, how is the compiler going to infer the dictionaries for you?), and also to make more transparent what terms are being constructed. As an example, you might start: type PickD a b = a -> b leftTuple :: PickD (a,b) a leftTuple = fst rightTuple :: PickD (a,b) b rightTuple = snd func :: PickD (a,b) c -> PickD (d -> a, d -> b) (d -> c) func p (f,g) x = p (f x, g x) ... And do this for each of your proposed instances. Then do an example use case, using these functions explicitly, and try to envisage an algorithm which might pick the functions for you. Then it will be much more obvious if it is possible to typeclassify these, and if so, how. Luke > > foo :: Pick (String,Int) t => String -> t > foo = pick (id :: String -> String, length :: String -> Int) > > toStr :: String -> IO String > toStr s = putStrLn "str" >> return s > toInt :: String -> IO Int > toInt s = putStrLn "int" >> return (length s) > > bar :: Pick (String,Int) t => String -> IO t > bar = pick (toStr,toInt) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090112/3872bd40/attachment.htm From lrpalmer at gmail.com Mon Jan 12 21:55:13 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Jan 12 21:46:28 2009 Subject: [Haskell-cafe] Multiple State Monads In-Reply-To: References: <40a414c20901121249l39606ee5x88e4b6abeab39550@mail.gmail.com> Message-ID: <7ca3f0160901121855h1f4f1d2dqcf77c1e0d20bdbb6@mail.gmail.com> On Mon, Jan 12, 2009 at 6:34 PM, Phil wrote: > -- Monad Implementation > > evolveUnderlying :: (Double, Word64) -> ( (), (Double, Word64) ) > evolveUnderlying (stock, state) = ( (), ( newStock, newState ) ) > where > newState = ranq1Increment state > newStock = stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep + ( > vol*sqrt(timeStep)*normalFromRngState(state) ) ) > How about: evolveUnderlying :: (Double, Word64) -> (Double, Word64) evolveUnderlying (stock, state) = (newStock, newState) where ... getEvolution = modify evolveUnderlying Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090112/022569dd/attachment.htm From dave at zednenem.com Mon Jan 12 22:13:33 2009 From: dave at zednenem.com (David Menendez) Date: Mon Jan 12 22:04:47 2009 Subject: [Haskell-cafe] Multiple State Monads In-Reply-To: References: <40a414c20901121249l39606ee5x88e4b6abeab39550@mail.gmail.com> Message-ID: <49a77b7a0901121913y75bcc3c3uadcb7e76b1fdb1a8@mail.gmail.com> On Mon, Jan 12, 2009 at 8:34 PM, Phil wrote: > Thanks Minh - I've updated my code as you suggested. This looks better than > my first attempt! > > Is it possible to clean this up any more? I find: > > ( (), (Double, Word64) ) > > a bit odd syntactically, although I understand this is just to fit the type > to the State c'tor so that we don't have to write our own Monad longhand. If you have a function which transforms the state, you can lift it into the state monad using "modify". > evolveUnderlying :: (Double, Word64) -> (Double, Word64) > evolveUnderlying (stock, state) = ( newStock, newState ) > where > newState = ranq1Increment state > newStock = stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep + ( > vol*sqrt(timeStep)*normalFromRngState(state) ) ) > > getEvolution :: State (Double, Word64) () > getEvolution = modify evolveUnderlying Now, I don't know the full context of what you're doing, but the example you posted isn't really gaining anything from the state monad. Specifically, execState (replicateM_ n (modify f)) = execState (modify f >> modify f >> ... >> modify f) = execState (modify (f . f . ... . f)) = f . f . ... . f So you could just write something along these lines, > mcSimulate :: Double -> Double -> Word64 -> [Double] > mcSimulate startStock endTime seedForSeed = fst expiryStock : mcSimulate > startStock endTime newSeedForSeed > where > expiryStock = iterate evolveUnderlying (startStock, ranq1Init seedForSeed) !! truncate (endTime/timeStep) > newSeedForSeed = seedForSeed + 246524 Coming back to your original question, it is possible to work with nested state monad transformers. The trick is to use "lift" to make sure you are working with the appropriate state. get :: StateT s1 (State s2) s1 put :: s1 -> StateT s1 (State s2) () lift get :: StateT s1 (State s2) s2 lift put :: s2 -> StateT s1 (State s2) () A more general piece of advice is to try breaking things into smaller pieces. For example: getRanq1 :: MonadState Word64 m => m Word64 getRanq1 = do seed <- get put (ranq1Increment seed) return seed getEvolution :: StateT Double (State Word64) () getEvolution = do seed <- lift getRanq1 modify $ \stock -> stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep + ( vol*sqrt(timeStep)*normalFromRngState(seed) ) ) -- Dave Menendez From bauertim at eecs.orst.edu Mon Jan 12 22:14:36 2009 From: bauertim at eecs.orst.edu (Tim Bauer) Date: Mon Jan 12 22:05:51 2009 Subject: [Haskell-cafe] type error using ghc 6.10.1, not in previous versions Message-ID: <496C071C.90503@eecs.orst.edu> Hi all. Under I have some old code that broke under ghc 6.10.1. Under (6.6.1), 6.8.1 (and I think 6.8.2), this compiles. import Prelude hiding(catch) import Control.Concurrent import Control.Exception(catch,throw,evaluate) async :: IO a -> IO (MVar a) async ioa = do mVar <- newEmptyMVar forkIO $ catch (ioa >>= putMVar mVar) (putMVar mVar . throw) return mVar Under 6.10. I now get a type error. TypeError.hs:13:55: Ambiguous type variable `e' in the constraint: `GHC.Exception.Exception e' arising from a use of `throw' at TypeError.hs:13:55-59 Probable fix: add a type signature that fixes these type variable(s) Prelude> :t catch catch :: IO a -> (IOError -> IO a) -> IO a Prelude> :t Control.Exception.catch Control.Exception.catch :: (GHC.Exception.Exception e) => IO a -> (e -> IO a) -> IO a What changed that causes this to break between 6.8 and 6.10? In fact, I don't even see the type error (the message is of little help). The function throw returns an `a', so it should unify with the required type for the handler. I tried simplifying the problematic line to: forkIO $ catch (ioa >>= putMVar mVar) (error "boom") (error "boom") should also unify with anything. Can anyone suggest other things I can try and perhaps what is going on? Thanks, - Tim From sigbjorn.finne at gmail.com Mon Jan 12 23:04:19 2009 From: sigbjorn.finne at gmail.com (Sigbjorn Finne) Date: Mon Jan 12 22:55:47 2009 Subject: [Haskell-cafe] ANN: json-0.4.1 Message-ID: <496C12C3.4020500@gmail.com> Hi, a new release of the 'json' package is now available via hackage, version 0.4.1 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/json [no claims that it represents rocket science, but a number of downstream codebases depend on this package for their operation, hence the announcement here.] New in this release is a generic JSON encoder contributed by Lennart Augustsson (Text.JSON.Generic ; thanks Lennart!) along with a number of other, smaller changes (including changes to the default encoding for constructors and prelude types - no longer down-cased; see release notes for more.) Enjoy --sigbjorn From wren at freegeek.org Tue Jan 13 00:00:45 2009 From: wren at freegeek.org (wren ng thornton) Date: Mon Jan 12 23:52:00 2009 Subject: [Haskell-cafe] ANN: bytestring-trie 0.1.4 In-Reply-To: <20090112193018.GI3582@scytale.galois.com> References: <496AB775.3010204@freegeek.org> <20090112193018.GI3582@scytale.galois.com> Message-ID: <496C1FFD.1070109@freegeek.org> Don Stewart wrote: > Do you have any benchmarks comparing dictionaries against Map ByteString > Int, or Map String Int? I haven't personally run them, but Mark Wotton has compared [(ByteString,Int)] vs (Map ByteString Int) vs (Trie Int) version 0.1.1 or 0.1.2 and using data from /usr/share/dict/words: 9:22 ~/projects/current/MapBench % ghc --make Test.hs ../../Microbench.hs && ./Test [1 of 2] Compiling Microbench ( ../../Microbench.hs, ../../Microbench.o ) [2 of 2] Compiling Main ( Test.hs, Test.o ) Linking Test ... * alist lookup: 160.641ns per iteration / 6225.07 per second. * map lookup: 0.881ns per iteration / 1135623.22 per second. * Trie lookup: 0.243ns per iteration / 4116930.41 per second. The benchmarking code requires hacking microbench to use Integers instead of Ints, to avoid counter overflow. I haven't yet worked the benchmarking code into the Darcs repo, but it's available to those interested. I'll add it to the repo soon. The cost of inserting elements is higher for Trie than Map (I don't have the numbers). One possible reason for this is that the generic alterBy doesn't know whether it's inserting or deleting, so it uses smart constructors along the spine which adds the cost of consistency checks. I've planned to add a dedicated implementation for insertBy (or modifyBy, or some such name) in order to test this hypothesis. The cost of merging is still unknown, but big-endian patricia trees have better asymptotic complexity than the balanced trees used by Map, so Trie is probably better there too. Another improvement in the works is a smarter algorithm for splitting strings. Once it's in place, this should speed up all three of the main algorithms. -- Live well, ~wren From anishmuttreja at gmail.com Tue Jan 13 01:56:43 2009 From: anishmuttreja at gmail.com (Anish Muttreja) Date: Tue Jan 13 01:48:04 2009 Subject: [Haskell-cafe] type error using ghc 6.10.1, not in previous versions In-Reply-To: <496C071C.90503@eecs.orst.edu> References: <496C071C.90503@eecs.orst.edu> Message-ID: <20090113065643.GA22979@raven> On Mon, Jan 12, 2009 at 07:14:36PM -0800, Tim Bauer wrote: > Hi all. Under I have some old code that broke under ghc 6.10.1. > Under (6.6.1), 6.8.1 (and I think 6.8.2), this compiles. > > import Prelude hiding(catch) > import Control.Concurrent > import Control.Exception(catch,throw,evaluate) > > async :: IO a -> IO (MVar a) > async ioa = do > mVar <- newEmptyMVar > forkIO $ catch (ioa >>= putMVar mVar) (putMVar mVar . throw) > return mVar > > > Under 6.10. I now get a type error. > > TypeError.hs:13:55: > Ambiguous type variable `e' in the constraint: > `GHC.Exception.Exception e' > arising from a use of `throw' at TypeError.hs:13:55-59 > Probable fix: add a type signature that fixes these type variable(s) > > Prelude> :t catch > catch :: IO a -> (IOError -> IO a) -> IO a > Prelude> :t Control.Exception.catch > Control.Exception.catch :: (GHC.Exception.Exception e) => > IO a -> (e -> IO a) -> IO a > > What changed that causes this to break between 6.8 and 6.10? > In fact, I don't even see the type error (the message is > of little help). The function throw returns an `a', so it > should unify with the required type for the handler. > Hi Tim, There were messages about this on the list before, I believe. >From ghc 6.10.1 release notes, what changed is this "Control.Exception now uses extensible exceptions. The old style of exceptions are still available in Control.OldException, but we expect to remove them in a future release. " http://www.haskell.org/ghc/docs/6.10.1/html/users_guide/release-6-10-1.html Providing a type signature for the argument of throw ought to fix it. forkIO $ catch (ioa >>= putMVar mVar) (\e -> (putMVar mVar . throw) (e :: IOException) ) I don't really understand what extensible exceptions are, just that providing a type signature makes the compiler happy. This www.haskell.org/~simonmar/papers/ext-exceptions.pdf might provide the explanation. Hope that helps. Anish > I tried simplifying the problematic line to: > forkIO $ catch (ioa >>= putMVar mVar) (error "boom") > (error "boom") should also unify with anything. > > Can anyone suggest other things I can try and perhaps what > is going on? > Thanks, > - Tim > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From jac at informatik.uni-kiel.de Tue Jan 13 03:24:06 2009 From: jac at informatik.uni-kiel.de (Jan Christiansen) Date: Tue Jan 13 03:15:49 2009 Subject: [Haskell-cafe] Maintaining laziness In-Reply-To: References: <715BD1A7-EBEA-4B88-A11F-599DE9E27428@informatik.uni-kiel.de> <9158C9F5-F937-48F4-B2CF-74A1C0086835@informatik.uni-kiel.de> Message-ID: <60B73B62-9342-4972-AE32-F220B6E9B53E@informatik.uni-kiel.de> Hi, Am 12.01.2009 um 14:37 schrieb Henning Thielemann: > > On Mon, 12 Jan 2009, Jan Christiansen wrote: >> I am not sure whether this would be a good idea. The original >> version makes a lot of suggestions which are not satisfiable but >> it is not at all trivial to decide which are satisfiable and which >> are not. I have rewritten StrictCheck from scratch to overcome >> this problem. But the current implementation is not presentable >> right now and I have no formal prove that the criterion that I am >> using is correct. > > As I said, the current version is already very useful. I have > applied it to several basic functions and found a lot to improve. OK, I am sorry for my negative attitude. I just have had some negative experiences where the tool made suggestions, I implemented them and afterwards the tool made complains about another case. In fact it was not possible to fulfil both cases at all. But it was very difficult to detect these cases. I would be very interested in functions that can be improved with respect to non-strictness as test cases for my work. Cheers Jan From ndmitchell at gmail.com Tue Jan 13 04:30:30 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jan 13 04:21:45 2009 Subject: [Haskell-cafe] unfoldr [ANN: HLint 1.2] In-Reply-To: References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <496A70D2.5020809@btinternet.com> <404396ef0901120033x3aca958btc3b7f35c02be29cf@mail.gmail.com> <496BA053.6020003@btinternet.com> Message-ID: <404396ef0901130130o2211ff63ya2515ae44a037695@mail.gmail.com> Hi >> convert b 0 = [] >> convert b n = n `mod` b : convert b (n `div` b) >> >> convert b = unfoldr (\n -> if n > 0 then Just (n `mod` b, n `div` b) else >> Nothing) To my untrained eyes the second looks more complex... It can't be implemented in the HLint list recursion functions I've got at the moment since they first search for a pattern-match on []/(:) on the left to start the process, but maybe one day. > I have the nice function 'toMaybe' which simplifies this to: > unfoldr (\n -> toMaybe (n>0) (n `mod` b, n `div` b)) > > Maybe HLint can also suggest non-base functions? ;-) Yes, sure - but not by default. See http://code.google.com/p/ndmitchell/issues/detail?id=126 The idea is that if someone wants to maintain a separate Hints file, say HackageHints.hs, then an individual user can decide to add import HackageHints to their Hints.hs and use the additional hints, which may require arbitrary Haskell libraries. Thanks Neil From haskell at list.mightyreason.com Tue Jan 13 05:16:32 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Tue Jan 13 05:08:00 2009 Subject: [Haskell-cafe] Re: Monads aren't evil? I think they are. In-Reply-To: <496BA800.90707@henning-thielemann.de> References: <20090108231652.24b75fe3@tritium.xx> <20090111111016.492d7dc9@tritium.xx> <496BA800.90707@henning-thielemann.de> Message-ID: <496C6A00.2010001@list.mightyreason.com> Henning Thielemann wrote: > I have seen several libraries where all functions of a monad have the > monadic result (), e.g. Binary.Put and other writing functions. This is > a clear indicator, that the Monad instance is artificial and was only > chosen because of the 'do' notation. I completely disagree with that example. The Put monad is, mainly, a specialized State monad. The internal state being the current fixed-size bytestring memory buffer that has been allocated and is being filled. The monad make the execution sequential so that there is only one memory buffer being filled at a time. In Put, when one memory buffer has been filled it allocates the next one to create a Lazy Bytestring. This is not to say that all M () are really monads, but just that Put () is. -- Chris From ross at soi.city.ac.uk Tue Jan 13 05:45:39 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Jan 13 05:37:02 2009 Subject: [Haskell-cafe] Re: Monads aren't evil? I think they are. In-Reply-To: <496C6A00.2010001@list.mightyreason.com> References: <20090108231652.24b75fe3@tritium.xx> <20090111111016.492d7dc9@tritium.xx> <496BA800.90707@henning-thielemann.de> <496C6A00.2010001@list.mightyreason.com> Message-ID: <20090113104539.GA3380@soi.city.ac.uk> On Tue, Jan 13, 2009 at 10:16:32AM +0000, ChrisK wrote: > Henning Thielemann wrote: >> I have seen several libraries where all functions of a monad have the >> monadic result (), e.g. Binary.Put and other writing functions. This is >> a clear indicator, that the Monad instance is artificial and was only >> chosen because of the 'do' notation. > > I completely disagree with that example. > The Put monad is, mainly, a specialized State monad. > The internal state being the current fixed-size bytestring memory buffer > that has been allocated and is being filled. > The monad make the execution sequential so that there is only one memory > buffer being filled at a time. No, Put is a specialized Writer monad. The sequencing is imposed by the mappend operation of the Builder monoid. The monadic interface is indeed there just to access do notation. And Henning's general point also holds: a monad that is always applied to () is just a monoid. From manlio_perillo at libero.it Tue Jan 13 06:04:43 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Tue Jan 13 05:55:59 2009 Subject: [Haskell-cafe] errno handling in concurrent haskell Message-ID: <496C754B.7000300@libero.it> Hi. I have some doubts about errno handling in a Concurrent Haskell program. Let's suppose that GHC non threaded runtime is used, so that each Haskell thread is bound to an OS thread. Let's suppose there are two threads running (`A` and `B`). Thread `A` calls a function `f`, that, in turn, calls via FFI a C function `c_f`. Function `c_f` fails, settings errno; however the GHC scheduler suspends execution of thread `A` and switch to thread `B`, before the current value of errno is read. Now, let's suppose thread `B` calls a function `g`, that, in turn, calls via FFI a C function `c_g`. Function `c_g`, too, fails, setting errno. Is this possible? P.S.: I have found this is C.Foreign.Error.hs, in base package (not the latest version): throwErrnoIfRetry :: (a -> Bool) -> String -> IO a -> IO a throwErrnoIfRetry pred loc f = do res <- f if pred res then do err <- getErrno if err == eINTR then throwErrnoIfRetry pred loc f else throwErrno loc else return res This function calls getErrno two times. Is this safe? Why the throwErrno function does not accept errno as parameter? Thanks Manlio Perillo From manlio_perillo at libero.it Tue Jan 13 06:09:22 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Tue Jan 13 06:00:37 2009 Subject: [Haskell-cafe] Re: Issues with posix-realtime package In-Reply-To: <5ae4f2ba0901101603kc6ed063ma599d80b07eccc79@mail.gmail.com> References: <5ae4f2ba0901091358j3e08366jad674d8b6ae69405@mail.gmail.com> <4967DDFD.2090105@libero.it> <5ae4f2ba0901092127p6228bb66ubf23b9b28e5f77c6@mail.gmail.com> <49688C16.8070506@libero.it> <5ae4f2ba0901101414m63725480ofe66069d3a8e7c04@mail.gmail.com> <49692321.6080308@libero.it> <5ae4f2ba0901101603kc6ed063ma599d80b07eccc79@mail.gmail.com> Message-ID: <496C7662.20508@libero.it> Galchin, Vasili ha scritto: > [...] > I would like to help to develope any wrappers around POSIX API. > > > ^^^ you are suggesting to change current wrapper API? > No, but I don't understand why to link code that seems to be not used. P.S.: is the problem I have reported riproducible? I'm on Linux Debian Lenny. Manlio Perillo From greenspan.levi at googlemail.com Tue Jan 13 07:16:46 2009 From: greenspan.levi at googlemail.com (Levi Greenspan) Date: Tue Jan 13 07:08:01 2009 Subject: [Haskell-cafe] Slow Text.JSON parser Message-ID: <3e62d4360901130416x78e37771od30311ca5abea69f@mail.gmail.com> Dear list members, I tried Text.JSON from hackage and did an initial test to see how well it performs. I created a single JSON file of roughly 6 MB containing a single JSON array with 30906 JSON objects and used the following code to parse it: module Main where import System.IO import Data.Time.Clock import System.Environment import Text.Printf import Text.JSON parse s = do start <- getCurrentTime let !len = decode s end <- getCurrentTime print len printf "Elapsed time = %s\n" (show $ diffUTCTime end start) where decode s = case decodeStrict s of Ok (JSArray a) -> length a _ -> -1 main = do file <- getArgs >>= return . head withFile file ReadMode (\h -> hGetContents h >>= parse) The outcome was something like: 30906 Elapsed time = 2.902755s on my 2GHz core 2 duo. Another Java-based JSON parser (Jackson: http://www.cowtowncoder.com/hatchery/jackson/index.html) gives me: 30906 Elapsed time = 480 ms Now I wonder why Text.JSON is so slow in comparison and what can be done about it. Any ideas? Or is the test case invalid? Thanks, Levi ----------------------------------- The Java code for the Jackson test is: import org.codehaus.jackson.JsonParser; import org.codehaus.jackson.JsonFactory; import org.codehaus.jackson.map.JsonTypeMapper; import org.codehaus.jackson.map.JsonNode; import java.io.File; class Test { public static void main(String[] args) throws Exception { final long start = System.currentTimeMillis(); final JsonTypeMapper mapper = new JsonTypeMapper(); final JsonParser parser = new JsonFactory().createJsonParser(new File(args[0])); final JsonNode root = mapper.read(parser); final long end = System.currentTimeMillis(); System.out.println(root.size()); System.out.println(String.format("Elapsed time = %d ms", end - start)); } } From marlowsd at gmail.com Tue Jan 13 07:24:17 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jan 13 07:15:36 2009 Subject: [Haskell-cafe] Re: ANN: HLint 1.2 In-Reply-To: <9d4d38820901120947l3e95f4e8gd2b133aaeb85983a@mail.gmail.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <1231768913.28590.66.camel@localhost> <2D150C9D-9335-4B96-B786-13A7AF12DB06@alum.mit.edu> <9d4d38820901120947l3e95f4e8gd2b133aaeb85983a@mail.gmail.com> Message-ID: <496C87F1.40103@gmail.com> Max Bolingbroke wrote: > 2009/1/12 Jan-Willem Maessen : >> On Jan 12, 2009, at 9:01 AM, Duncan Coutts wrote: >> >>> No because the current definition are recursive and ghc cannot inline >>> recursive functions. >>> >>> .... >>> >>> Then the map can be inlined at the call site and the 'f' inlined into >>> the body of 'go'. >> This seems like exactly the sort of mechanical transformation that computers >> do quickly and accurately, and humans get wrong. Surely it wouldn't be that >> hard for GHC to transform self recursion in this way (possibly subject to >> the condition that the result be worth inlining)? > > GHC should indeed be doing so. I'm working (on and off) to work out > some suitable heuristics and put the transformation into ghc -O2. > There are a few wrinkles that still need sorting out, but preliminary > indications are that it decreases the runtime of our standard > benchmark suite, nofib, by 12% or so. !!! That's a surprising result - have you looked closely at the places where the transformation is having a big effect to see what's going on? Cheers, Simon From marlowsd at gmail.com Tue Jan 13 07:49:32 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jan 13 07:40:51 2009 Subject: [Haskell-cafe] Re: errno handling in concurrent haskell In-Reply-To: <496C754B.7000300@libero.it> References: <496C754B.7000300@libero.it> Message-ID: <496C8DDC.7020005@gmail.com> Manlio Perillo wrote: > I have some doubts about errno handling in a Concurrent Haskell program. > > Let's suppose that GHC non threaded runtime is used, so that each > Haskell thread is bound to an OS thread. > > Let's suppose there are two threads running (`A` and `B`). > Thread `A` calls a function `f`, that, in turn, calls via FFI a C > function `c_f`. > > Function `c_f` fails, settings errno; however the GHC scheduler suspends > execution of thread `A` and switch to thread `B`, before the current > value of errno is read. > > Now, let's suppose thread `B` calls a function `g`, that, in turn, calls > via FFI a C function `c_g`. > Function `c_g`, too, fails, setting errno. > > > Is this possible? It's safe, we save the value of errno when a Haskell thread is descheduled, and restore it when it is scheduled again. We do the same on Windows for GetLastError(). > P.S.: > I have found this is C.Foreign.Error.hs, in base package (not the latest > version): > > throwErrnoIfRetry :: (a -> Bool) -> String -> IO a -> IO a > throwErrnoIfRetry pred loc f = > do > res <- f > if pred res > then do > err <- getErrno > if err == eINTR > then throwErrnoIfRetry pred loc f > else throwErrno loc > else return res > > This function calls getErrno two times. > Is this safe? yes > Why the throwErrno function does not accept errno as parameter? because it reads the global errno. Cheers, Simon From gale at sefer.org Tue Jan 13 08:45:02 2009 From: gale at sefer.org (Yitzchak Gale) Date: Tue Jan 13 08:36:16 2009 Subject: [Haskell-cafe] unfoldr [ANN: HLint 1.2] In-Reply-To: <496BA053.6020003@btinternet.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <496A70D2.5020809@btinternet.com> <404396ef0901120033x3aca958btc3b7f35c02be29cf@mail.gmail.com> <496BA053.6020003@btinternet.com> Message-ID: <2608b8a80901130545i35754bddg596e3172c7c22971@mail.gmail.com> Andrew Coppin wrote: >>> Does it suggest unfoldr too? I think Neil's idea to have this customizable is a good one. It's often a matter of taste. I would rarely want to use unfoldr, and I wouldn't want HList to bother me about it. Instead, I prefer to use iterate for both of Andrew's examples: > convert b 0 = [] > convert b n = n `mod` b : convert b (n `div` b) > > convert b = unfoldr (\n -> if n > 0 then Just (n `mod` b, n `div` b) else > Nothing) convert b = map (`mod` b) . takeWhile (> 0) . iterate (`div` b) > heap_to_list = unfoldr (\h -> if heap_empty h then Nothing else Just > (heap_top h, heap_delete_top h)) heap_to_list = map heap_top . takeWhile (not . heap_empty) . iterate heap_delete_top Here is one case where I actually do use unfoldr: -- Mine free-form user input for occurrences of a data type readMany = unfoldr $ listToMaybe . concatMap reads . tails ghci> readMany "The numbers are 3, 7, and 42." :: [Int] [3,7,42] But I don't believe HLint should be expected to come up with something like that. It's quite rare. Regards, Yitz From ketil at malde.org Tue Jan 13 08:48:29 2009 From: ketil at malde.org (Ketil Malde) Date: Tue Jan 13 08:39:47 2009 Subject: [Haskell-cafe] Slow Text.JSON parser In-Reply-To: <3e62d4360901130416x78e37771od30311ca5abea69f@mail.gmail.com> (Levi Greenspan's message of "Tue\, 13 Jan 2009 13\:16\:46 +0100") References: <3e62d4360901130416x78e37771od30311ca5abea69f@mail.gmail.com> Message-ID: <87d4er5nbm.fsf@malde.org> "Levi Greenspan" writes: > Now I wonder why Text.JSON is so slow in comparison and what can be > done about it. Any ideas? Or is the test case invalid? I haven't used JSON, but at first glance, I'd blame String IO. Can't you decode from ByteString? -k -- If I haven't seen further, it is by standing in the footprints of giants From briqueabraque at yahoo.com Tue Jan 13 09:03:26 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Tue Jan 13 08:54:50 2009 Subject: [Haskell-cafe] Re: [Haskell] ANN: ghci-haskeline 0.1 In-Reply-To: <20090112222851.GX13626@knuth.cs.hmc.edu> References: <6d74b0d20901121257q19b953cft2c8dc54b98809ef5@mail.gmail.com> <20090112214103.GW13626@knuth.cs.hmc.edu> <20090112222851.GX13626@knuth.cs.hmc.edu> Message-ID: >> Haskeline is designed to remove the readline dependency, because Windows >> does not have readline. So rlwrap is useless there. >> > > Ah, I hadn't considered Windows support--that makes sense. Thanks, > that answers my questions. > > AHH One nice thing would be to write something like rlwrap that would work everywhere Haskell does. Even more sofisticated behavior could come from some comunication from the api, using standard OS facilities (like a file with an updated list of completions, or something more clever). (For those interested: rlwrap is available in cygwin. It used to work very well on old ghci, when line editing wasn't available.) Best, Maur?cio From batterseapower at hotmail.com Tue Jan 13 09:21:58 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Tue Jan 13 09:13:11 2009 Subject: [Haskell-cafe] Re: ANN: HLint 1.2 In-Reply-To: <496C87F1.40103@gmail.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <1231768913.28590.66.camel@localhost> <2D150C9D-9335-4B96-B786-13A7AF12DB06@alum.mit.edu> <9d4d38820901120947l3e95f4e8gd2b133aaeb85983a@mail.gmail.com> <496C87F1.40103@gmail.com> Message-ID: <9d4d38820901130621w2446cea1t6871ce676b3301b8@mail.gmail.com> 2009/1/13 Simon Marlow : >> GHC should indeed be doing so. I'm working (on and off) to work out >> some suitable heuristics and put the transformation into ghc -O2. >> There are a few wrinkles that still need sorting out, but preliminary >> indications are that it decreases the runtime of our standard >> benchmark suite, nofib, by 12% or so. > > !!! > > That's a surprising result - have you looked closely at the places where the > transformation is having a big effect to see what's going on? Yes, it is rather better than I expected :-) The main gains seem to come from specialising higher-order functions on particular arguments, like we saw earlier in this thread. There seem to be a number of suitable functions in the standard library that aren't written in static-argument-transformed (SATed) style. Another gain comes from the nofib program "atom", which has a function a lot like this: f x y z = (x, y, z) : f x y z Once this is SATed it becomes a much better function: f = let f' = (x, y, z) : f' in f' Which decreases runtime of atom by 97% :-) The catch is that things written in this style can actually be worse than their lambda-lifted brethren. This happens for 3 main reasons: 1) SATed functions tend to have case liberation applied to them instead of constructor specialisation. Case liberation kind of sucks in comparison to constructor specialisation, so bad things happen (increased allocations and code size) 2) Carrying around a single variable in the SAT closure just adds indirection to the generated code with no benefits, so it's better to remove that indirection (by lambda lifting) just before going to STG - but be careful not to change the unfolding! 3) More SATing means more expressions are loop invariant. This is usually a good thing, but if you float a loop-invariant out of a "cold branch" of a recursive function (a branch that is actually only entered once dynamically) then you end up eagerly allocating a closure for the loop-invariant thing which may never be entered. This is sort of a bug in our current float-out pass. Like I said, I'm working on improving the situation with 1 and 2, which need to be resolved to iron out some of the bad cases in nofib. I need to find time to take a look at this though. Cheers, Max From manlio_perillo at libero.it Tue Jan 13 09:28:28 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Tue Jan 13 09:19:48 2009 Subject: [Haskell-cafe] Re: errno handling in concurrent haskell In-Reply-To: <496C8DDC.7020005@gmail.com> References: <496C754B.7000300@libero.it> <496C8DDC.7020005@gmail.com> Message-ID: <496CA50C.9050104@libero.it> Simon Marlow ha scritto: > Manlio Perillo wrote: > >> I have some doubts about errno handling in a Concurrent Haskell program. >> >> Let's suppose that GHC non threaded runtime is used, so that each >> Haskell thread is bound to an OS thread. >> >> Let's suppose there are two threads running (`A` and `B`). >> Thread `A` calls a function `f`, that, in turn, calls via FFI a C >> function `c_f`. >> >> Function `c_f` fails, settings errno; however the GHC scheduler >> suspends execution of thread `A` and switch to thread `B`, before the >> current value of errno is read. >> >> Now, let's suppose thread `B` calls a function `g`, that, in turn, >> calls via FFI a C function `c_g`. >> Function `c_g`, too, fails, setting errno. >> >> >> Is this possible? > > It's safe, we save the value of errno when a Haskell thread is > descheduled, and restore it when it is scheduled again. We do the same > on Windows for GetLastError(). > Thanks. I was just replying to the message, after having read the code of the scheduler. Manlio Perillo From RafaelGCPP.Linux at gmail.com Tue Jan 13 09:56:55 2009 From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto) Date: Tue Jan 13 09:48:10 2009 Subject: [Haskell-cafe] The problem with Monads... Message-ID: <351ff25e0901130656k530348afj6633048d206d7f74@mail.gmail.com> Last night I was thinking on what makes monads so hard to take, and came to a conclusion: the lack of a guided tour on the implemented monads. Let's take the Writer monad documentation: all it says is: Inspired by the paper "Functional Programming with Overloading and Higher-Order Polymorphism", Mark P Jones (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html) Advanced School of Functional Programming, 1995. SO WHAT? The best approach is the Part II of the "All About Monads" tutorial. There you have the almost ideal approach, except that the examples are just thrown there, with no step-by-step explanation. Of course one could copy, paste and run it, but this gives pretty much a "is it right?' feeling. Questions like "if a Reader is an application, why don't use a regular function instead?" or "what bind means for a State monad?". I will try to work on a "Part II" extended version on my vacations... maybe a WikiMonad... or MonadPedia... :-) After all, it is my duty as a haskell noob to write another monad tutorial! :D Cheers! -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/ea8edc07/attachment.htm From dons at galois.com Tue Jan 13 10:00:50 2009 From: dons at galois.com (Don Stewart) Date: Tue Jan 13 09:51:49 2009 Subject: [Haskell-cafe] Slow Text.JSON parser In-Reply-To: <87d4er5nbm.fsf@malde.org> References: <3e62d4360901130416x78e37771od30311ca5abea69f@mail.gmail.com> <87d4er5nbm.fsf@malde.org> Message-ID: <20090113150050.GB6422@scytale.galois.com> ketil: > "Levi Greenspan" writes: > > > Now I wonder why Text.JSON is so slow in comparison and what can be > > done about it. Any ideas? Or is the test case invalid? > > I haven't used JSON, but at first glance, I'd blame String IO. Can't > you decode from ByteString? > Text.JSON was never optimised for performance. It was designed for small JSON objects. For things above 1M I'd suggest using Data.Binary (or a quick JSON encoding over bytestrings). Shouldn't be too hard to prepare. -- Don From judah.jacobson at gmail.com Tue Jan 13 10:02:31 2009 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Tue Jan 13 09:53:45 2009 Subject: [Haskell-cafe] Re: [Haskell] ANN: ghci-haskeline 0.1 In-Reply-To: References: <6d74b0d20901121257q19b953cft2c8dc54b98809ef5@mail.gmail.com> <20090112214103.GW13626@knuth.cs.hmc.edu> <20090112222851.GX13626@knuth.cs.hmc.edu> Message-ID: <6d74b0d20901130702w219bc3d3r951c610651666614@mail.gmail.com> On Tue, Jan 13, 2009 at 6:03 AM, Mauricio wrote: >>> Haskeline is designed to remove the readline dependency, because Windows >>> does not have readline. So rlwrap is useless there. >>> >> >> Ah, I hadn't considered Windows support--that makes sense. Thanks, >> that answers my questions. >> >> AHH > > One nice thing would be to write something like rlwrap > that would work everywhere Haskell does. Even more > sofisticated behavior could come from some comunication > from the api, using standard OS facilities (like a file > with an updated list of completions, or something more > clever). > > (For those interested: rlwrap is available in cygwin. > It used to work very well on old ghci, when line > editing wasn't available.) This does sound useful; the main difficulty is that when a program has stdin piped from another process it may behaved differently. For example, ghci uses block buffering and doesn't print its prompt when stdin doesn't appear to be a terminal. The solution on POSIX is probably to use some sort of pseudo-terminal support; I don't know what the right thing to do on Windows is. The following post discusses those issues in a little more detail: http://www.haskell.org/pipermail/haskell-cafe/2008-May/042342.html -Judah From regis.saint-paul at create-net.org Tue Jan 13 10:33:26 2009 From: regis.saint-paul at create-net.org (Regis Saint-Paul) Date: Tue Jan 13 10:24:56 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) Message-ID: <027A7D7FCDF44376AC625F076AD23870@createnet.org> Hi, I?ve seen many times the monad topic coming around on the cafe and plentiful tutorials on monads have been published. However, as a complete Haskell newbie coming from OOP, I felt monads were not particularly difficult to grasp, and very exciting to work with. During my experiments with Haskell so far, the main problems I kept bumping into were not related to the language but to its libraries: their compilation and installation. Unfortunately, this topic has not received nearly as much attention. I was unable to find a comprehensive tutorial on how to deal with the variety of problems I get when trying to install Hackage packages. This turned out to be (and still is) THE main source of wasted time and headaches. And worse, unlike type problems, these are not interesting ones to solve. Thus, as a beginner, the package management is what is really getting in the way of switching to Haskell--not the language. Even books like Real World Haskell (otherwise excellent) ignore entirely the topic. Cabal and Cabal-install are clearly wonderful applications that make installing most packages very straightforward. Unfortunately, whenever this "standard" method for package installation fails (or when it is not available as with, e.g., gtk2hs), I find myself in complete disarray. Below are some of the questions and issues I faced regarding package management: - For a number of packages, cabal-install gets stuck and has to be killed. I assume this is due to some difficulties in solving the dependencies and it is fine, not all can be automated and cabal-install is not responsible for poor packages. But the question then becomes what to do from there? Is their some method to solve dependencies? How should we proceed to "debug" a package installation? How do gurus deal with that? (maybe some less known command line arguments? Or ways to figure out the problem and work out its solution (cabal-install is silent in such case)? In particular, how to know why did cabal get stuck in the first place? - Some packages on Hackage are reported as not building successfully with GHC6.10 (e.g., encoding) while others do not build with 6.8 (e.g., salvia) and the later might depend on the former...What is one supposed to do in such case? For example, is it an appropriate way to proceed to compile a package with one version of GHC and then use the compiled package with another version of GHC? Is it safe? What could possibly go wrong? If it is the right way to go, how should we setup the two GHC versions? For instance, should we have a shared package configuration file and choose through the path which GHC is used or is there nicer way to set this up? ? - Taking for example the "encoding" package on Hackage. Last time I tried, the log was saying it fails to build on GHC 6.10, however, looking inside this Hackage log, I could see a successful compilation using "preferred versions". So it looks as if the thing can be compiled somehow. What should one do with this information? If cabal manages to compile it using this method on Hackage, then isn't cabal install just doing it on my disk? Is it possible through some command line? Is it possible manually (without cabal-install) and, if so, how? (I tried to copy-past the build instruction as it appeared on the log...that somehow compiled, but then, I failed to figure out how to install...) ?? - I?m primarily a windows user and lots of my initial struggles probably came from that. After many difficulties, I figured out that installing MinGW and MSys was *THE* way to get a bit more of the things working. First, a lot of time would be saved by just saying clearly on the GHC download page that MinGW and MSys are mandatory installation (or even package that with GHC for the windows distribution if license allows, who cares the extra few Mb). Even if that is not technically exact, i.e., even if ghci and many trivial command line programs can work without, MSys and MinGW turn out to be quiet necessary whenever trying to install anything producing side effect. Making it plain that these two are necessary would real come has a great time savers for newbie like me on windows (personal opinion of course). Or, if another path exists to go without these two, I'd be very glad to learn. Besides, even these tools basic installation is not enough, you need automake and various things of the like. That makes me wonder if the most precious skill for programming with Haskell would not be a strong C/C++ programming background. ? - In face of the difficulties with windows, I switched to Linux. While some things worked better, there were still lots of difficulties with package compilation. For instance, it is very difficult to figure out which Linux packages of a given distribution are needed for compiling this or that package. Again, gtk2hs is epitome here: which C development packages are needed to compile it is obscure at best (cairo, codeview, etc...). I ended up querying the Debian package management with any keyword found after running gtk2hs and randomly installing all the dev packages...And when gtk2hs finally compiled, it failed to install anyway. As of today, I?ve never been able to compile even the dumbest demo using gtk2hs whether on linux or on windows and whether using ghc 6.8.3 or 6.10.1. On windows, the automated setup install worked but did not allow me to compile with codeview and I still do not know how to add codeview to the install packages. Trust that I tried hard and read the docs thoroughly. Gtk2hs is just on of many examples; I had problems under Linux also with, e.g., Happs, yi, database things, etc. and figured out that the situation was roughly identical to windows with MSys and MinGW. So Linux appears not to be the right solution here. Maybe it's just that Linux users are more experienced with the GNU C/C++ libraries...but it won't help a windows user to switch to Linux since this knowledge can't be built out of thin air. - Would there be some binary version of cabal targeting various OSs? I believe the Haskell platform project is about that. But without waiting for a fair and objective selection of the packages (it seems to be the current status of the project), I?d be happy working with some authoritative bundle produced by a Haskell guru and would trust his subjective choices (who am I to question these choices anyway). Or even an image (e.g., virtual box or Xen) of a fully setup development environment since there are so many dependencies involved in, e.g., simply compiling GHC... Now, one might argue that these are not Haskell problems, that they are normal when dealing with non-mature packages. So let me explain why I've been trying hard to install these packages: As a beginner with no experience with emacs, I tried to find some IDE-like environment which would, at least, save me from manually reloading files in ghci or help me browse the source files. Following the Haskellwiki advice, that led to trying out Yi, Leksah, eclipsefp, or a Visual Studio extension. To this date, NOT ANY SINGLE ONE of these worked, be it on Linux or Windows. I had to resort to learning emacs which seems the only sensible choice available today. I am particularly unskilled, no question here. But, would a charitable soul take the pain of writing a comprehensive package management tutorial instead of a monad one, (s)he would have my deepest gratitude :) Apologies for the long mail. -Regis P.S. People on #haskell are wonderful. They helped me solve many issues. Unfortunately, solving specific instances of problem did not contribute much to a deeper understanding of the internal working. I find myself randomly trying things without knowing which would work or why; Hence this plea for a tutorial. From jonathanccast at fastmail.fm Tue Jan 13 10:51:00 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Tue Jan 13 10:42:18 2009 Subject: [Haskell-cafe] The problem with Monads... In-Reply-To: <351ff25e0901130656k530348afj6633048d206d7f74@mail.gmail.com> References: <351ff25e0901130656k530348afj6633048d206d7f74@mail.gmail.com> Message-ID: <1231861860.17950.1.camel@jonathans-macbook> On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira Pinto wrote: > > Last night I was thinking on what makes monads so hard to take, and > came to a conclusion: the lack of a guided tour on the implemented > monads. ... > Inspired by the paper "Functional Programming with Overloading and > Higher-Order Polymorphism", > Mark P Jones > (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html) > Advanced School of Functional Programming, 1995. > > SO WHAT? So have you read Jones' paper? Or do you have a *concrete* explanation of how it differs from your desired `guided tour'? jcc From bugfact at gmail.com Tue Jan 13 10:54:08 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Tue Jan 13 10:45:22 2009 Subject: [Haskell-cafe] Real World Haskell: confusion Message-ID: On page 102: "partial function application is named currying" I thought "currying" or "to curry" means converting f :: (a,b) ->c into g :: a -> b -> c by applying "curry" (mmm, are Asian people good at Haskell? :-) g = curry f -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/839f6127/attachment.htm From ekirpichov at gmail.com Tue Jan 13 11:05:19 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Tue Jan 13 10:56:33 2009 Subject: [Haskell-cafe] Real World Haskell: confusion In-Reply-To: References: Message-ID: <5e0214850901130805h638625d1ge647a7fb278fc7e@mail.gmail.com> The term 'currying' means both of these things: - Converting an uncurried function to a 'curriable' one - Partially applying a 'curriable' function 2009/1/13 Peter Verswyvelen : > On page 102: "partial function application is named currying" > > > > I thought "currying" or "to curry" means converting > > > > f :: (a,b) ->c > > > > into > > > > g :: a -> b -> c > > > > by applying "curry" (mmm, are Asian people good at Haskell? :-) > > > g = curry f > > > > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From es at ertes.de Tue Jan 13 11:07:50 2009 From: es at ertes.de (Ertugrul Soeylemez) Date: Tue Jan 13 10:59:13 2009 Subject: [Haskell-cafe] Re: The problem with Monads... References: <351ff25e0901130656k530348afj6633048d206d7f74@mail.gmail.com> <1231861860.17950.1.camel@jonathans-macbook> Message-ID: <20090113170750.0b837f8a@tritium.xx> Jonathan Cast wrote: > On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira Pinto > wrote: > > > Inspired by the paper "Functional Programming with Overloading and > > Higher-Order Polymorphism", > > Mark P Jones > > (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html) > > Advanced School of Functional Programming, 1995. > > > > SO WHAT? > > So have you read Jones' paper? Or do you have a *concrete* > explanation of how it differs from your desired `guided tour'? I agree with Rafael here. The standard library documentation is insufficient. Pointing to nothing else than a paper is about the same as "RTFM", especially being "inspired" by a paper, there is really almost no information in the documentation. I wouldn't expect from an average programmer to read a whole paper to understand an everyday-use monad. Especially for newcomers to the purely functional world, even reading the introduction of a paper may well take an hour, which can be tiring and frustrating. There should be some basic information about the monad at least at the end of the documentation, as well as some well-thought usage examples. Greets, Ertugrul. -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/ From RafaelGCPP.Linux at gmail.com Tue Jan 13 11:09:01 2009 From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto) Date: Tue Jan 13 11:00:17 2009 Subject: [Haskell-cafe] The problem with Monads... In-Reply-To: <1231861860.17950.1.camel@jonathans-macbook> References: <351ff25e0901130656k530348afj6633048d206d7f74@mail.gmail.com> <1231861860.17950.1.camel@jonathans-macbook> Message-ID: <351ff25e0901130809x22f5131dx60fede4bcf38b779@mail.gmail.com> Yes, I've read it twice, and it is a nice explanation that "yes, the reader monad is an application and is a monad". How do I use it? Why not the function itself? How would the plumbing work in a real world example? BTW, the article is really great as an brief introduction to monad transformers. For the whole concept of monads, my all time favorite is "The Haskell Programmer's Guide to the IO Monad" by Stefan Klinger. Chapters 14 to 19 of "Real World Haskell" also have a good introduction on the usage of the monads, but it lacks other monads, like the RWS or the Continuation... See, that is my point. The mathematical concept of monads is very palatable. The idea that monads are either patterns or structures to hide computations in sequence is also very easy to see. But how do we use them? Why should I use a Writer monad when I can use a (a,w) tuple? On Tue, Jan 13, 2009 at 13:51, Jonathan Cast wrote: > On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira Pinto > wrote: > > > > Last night I was thinking on what makes monads so hard to take, and > > came to a conclusion: the lack of a guided tour on the implemented > > monads. > > ... > > > Inspired by the paper "Functional Programming with Overloading and > > Higher-Order Polymorphism", > > Mark P Jones > > (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html > ) > > Advanced School of Functional Programming, 1995. > > > > SO WHAT? > > So have you read Jones' paper? Or do you have a *concrete* explanation > of how it differs from your desired `guided tour'? > > jcc > > > -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/3d4e09d1/attachment-0001.htm From bugfact at gmail.com Tue Jan 13 11:17:37 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Tue Jan 13 11:08:57 2009 Subject: [Haskell-cafe] Real World Haskell: confusion In-Reply-To: <5e0214850901130805h638625d1ge647a7fb278fc7e@mail.gmail.com> References: <5e0214850901130805h638625d1ge647a7fb278fc7e@mail.gmail.com> Message-ID: Ah. That explains my confusion. But isn't that ambiguous terminology? There must be some reason for it to be that way? On Tue, Jan 13, 2009 at 5:05 PM, Eugene Kirpichov wrote: > The term 'currying' means both of these things: > - Converting an uncurried function to a 'curriable' one > - Partially applying a 'curriable' function > > 2009/1/13 Peter Verswyvelen : > > On page 102: "partial function application is named currying" > > > > > > > > I thought "currying" or "to curry" means converting > > > > > > > > f :: (a,b) ->c > > > > > > > > into > > > > > > > > g :: a -> b -> c > > > > > > > > by applying "curry" (mmm, are Asian people good at Haskell? :-) > > > > > > g = curry f > > > > > > > > > > > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/36c220f0/attachment.htm From jamiiecb at googlemail.com Tue Jan 13 11:21:40 2009 From: jamiiecb at googlemail.com (Jamie Brandon) Date: Tue Jan 13 11:12:54 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <027A7D7FCDF44376AC625F076AD23870@createnet.org> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> Message-ID: <10ed1a750901130821m9b3e8fev2528a0877ebf6be1@mail.gmail.com> I agree completely. There is not nearly enough documentation on packaging in haskell and too many hackage packages are broken or do not install. I know several people are working on improving this but they seem do be doing so rather quietly. Could someone briefly outline what improvements are planned and what stage the current work is at? I remember seeing some demos at anglohaskell during the summer but nothing since. Jamie On Tue, Jan 13, 2009 at 3:33 PM, Regis Saint-Paul wrote: > Hi, > > I've seen many times the monad topic coming around on the cafe and plentiful > tutorials on monads have been published. However, as a complete Haskell > newbie coming from OOP, I felt monads were not particularly difficult to > grasp, and very exciting to work with. > > During my experiments with Haskell so far, the main problems I kept bumping > into were not related to the language but to its libraries: their > compilation and installation. Unfortunately, this topic has not received > nearly as much attention. I was unable to find a comprehensive tutorial on > how to deal with the variety of problems I get when trying to install > Hackage packages. This turned out to be (and still is) THE main source of > wasted time and headaches. And worse, unlike type problems, these are not > interesting ones to solve. > > Thus, as a beginner, the package management is what is really getting in the > way of switching to Haskell--not the language. Even books like Real World > Haskell (otherwise excellent) ignore entirely the topic. Cabal and > Cabal-install are clearly wonderful applications that make installing most > packages very straightforward. Unfortunately, whenever this "standard" > method for package installation fails (or when it is not available as with, > e.g., gtk2hs), I find myself in complete disarray. > > Below are some of the questions and issues I faced regarding package > management: > > - For a number of packages, cabal-install gets stuck and has to be killed. I > assume this is due to some difficulties in solving the dependencies and it > is fine, not all can be automated and cabal-install is not responsible for > poor packages. But the question then becomes what to do from there? Is their > some method to solve dependencies? How should we proceed to "debug" a > package installation? How do gurus deal with that? (maybe some less known > command line arguments? Or ways to figure out the problem and work out its > solution (cabal-install is silent in such case)? In particular, how to know > why did cabal get stuck in the first place? > > - Some packages on Hackage are reported as not building successfully with > GHC6.10 (e.g., encoding) while others do not build with 6.8 (e.g., salvia) > and the later might depend on the former...What is one supposed to do in > such case? For example, is it an appropriate way to proceed to compile a > package with one version of GHC and then use the compiled package with > another version of GHC? Is it safe? What could possibly go wrong? If it is > the right way to go, how should we setup the two GHC versions? For instance, > should we have a shared package configuration file and choose through the > path which GHC is used or is there nicer way to set this up? > > - Taking for example the "encoding" package on Hackage. Last time I tried, > the log was saying it fails to build on GHC 6.10, however, looking inside > this Hackage log, I could see a successful compilation using "preferred > versions". So it looks as if the thing can be compiled somehow. What should > one do with this information? If cabal manages to compile it using this > method on Hackage, then isn't cabal install just doing it on my disk? Is it > possible through some command line? Is it possible manually (without > cabal-install) and, if so, how? (I tried to copy-past the build instruction > as it appeared on the log...that somehow compiled, but then, I failed to > figure out how to install...) > > - I'm primarily a windows user and lots of my initial struggles probably > came from that. After many difficulties, I figured out that installing MinGW > and MSys was *THE* way to get a bit more of the things working. First, a lot > of time would be saved by just saying clearly on the GHC download page that > MinGW and MSys are mandatory installation (or even package that with GHC for > the windows distribution if license allows, who cares the extra few Mb). > Even if that is not technically exact, i.e., even if ghci and many trivial > command line programs can work without, MSys and MinGW turn out to be quiet > necessary whenever trying to install anything producing side effect. Making > it plain that these two are necessary would real come has a great time > savers for newbie like me on windows (personal opinion of course). Or, if > another path exists to go without these two, I'd be very glad to learn. > Besides, even these tools basic installation is not enough, you need > automake and various things of the like. That makes me wonder if the most > precious skill for programming with Haskell would not be a strong C/C++ > programming background. > > - In face of the difficulties with windows, I switched to Linux. While some > things worked better, there were still lots of difficulties with package > compilation. For instance, it is very difficult to figure out which Linux > packages of a given distribution are needed for compiling this or that > package. Again, gtk2hs is epitome here: which C development packages are > needed to compile it is obscure at best (cairo, codeview, etc...). I ended > up querying the Debian package management with any keyword found after > running gtk2hs and randomly installing all the dev packages...And when > gtk2hs finally compiled, it failed to install anyway. As of today, I've > never been able to compile even the dumbest demo using gtk2hs whether on > linux or on windows and whether using ghc 6.8.3 or 6.10.1. On windows, the > automated setup install worked but did not allow me to compile with codeview > and I still do not know how to add codeview to the install packages. Trust > that I tried hard and read the docs thoroughly. Gtk2hs is just on of many > examples; I had problems under Linux also with, e.g., Happs, yi, database > things, etc. and figured out that the situation was roughly identical to > windows with MSys and MinGW. So Linux appears not to be the right solution > here. Maybe it's just that Linux users are more experienced with the GNU > C/C++ libraries...but it won't help a windows user to switch to Linux since > this knowledge can't be built out of thin air. > > - Would there be some binary version of cabal targeting various OSs? I > believe the Haskell platform project is about that. But without waiting for > a fair and objective selection of the packages (it seems to be the current > status of the project), I'd be happy working with some authoritative bundle > produced by a Haskell guru and would trust his subjective choices (who am I > to question these choices anyway). Or even an image (e.g., virtual box or > Xen) of a fully setup development environment since there are so many > dependencies involved in, e.g., simply compiling GHC... > > Now, one might argue that these are not Haskell problems, that they are > normal when dealing with non-mature packages. So let me explain why I've > been trying hard to install these packages: > > As a beginner with no experience with emacs, I tried to find some IDE-like > environment which would, at least, save me from manually reloading files in > ghci or help me browse the source files. Following the Haskellwiki advice, > that led to trying out Yi, Leksah, eclipsefp, or a Visual Studio extension. > To this date, NOT ANY SINGLE ONE of these worked, be it on Linux or Windows. > I had to resort to learning emacs which seems the only sensible choice > available today. > > I am particularly unskilled, no question here. But, would a charitable soul > take the pain of writing a comprehensive package management tutorial instead > of a monad one, (s)he would have my deepest gratitude :) > > Apologies for the long mail. > > -Regis > > P.S. People on #haskell are wonderful. They helped me solve many issues. > Unfortunately, solving specific instances of problem did not contribute much > to a deeper understanding of the internal working. I find myself randomly > trying things without knowing which would work or why; Hence this plea for a > tutorial. > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ganesh.sittampalam at credit-suisse.com Tue Jan 13 11:22:24 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Tue Jan 13 11:15:45 2009 Subject: [Haskell-cafe] The problem with Monads... In-Reply-To: <1231861860.17950.1.camel@jonathans-macbook> References: <351ff25e0901130656k530348afj6633048d206d7f74@mail.gmail.com> <1231861860.17950.1.camel@jonathans-macbook> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B4DCAE8@ELON17P32001A.csfb.cs-group.com> Jonathan Cast wrote: > On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira > Pinto wrote: >> >> Inspired by the paper "Functional Programming with Overloading and >> Higher-Order Polymorphism", Mark P Jones >> (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html) >> Advanced School of Functional Programming, 1995. >> >> SO WHAT? > > So have you read Jones' paper? Or do you have a *concrete* > explanation of how it differs from your desired `guided tour'? To give a specific example, a few weeks ago I wanted an explanation of the 'pass' function and couldn't find it in that paper. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From gtener at gmail.com Tue Jan 13 11:33:17 2009 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Tue Jan 13 11:24:31 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <027A7D7FCDF44376AC625F076AD23870@createnet.org> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> Message-ID: <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> My experience from using GHC under Windows XP is very similar. Many packages (especially those involving bindings to C packages) are at least painful to build. Regarding encoding package: it compiles fine for me: C:\Documents and Settings\Metharius>cabal install encoding Resolving dependencies... Downloading encoding-0.4.1... Configuring encoding-0.4.1... Preprocessing library encoding-0.4.1... Building encoding-0.4.1... [ 1 of 37] Compiling Data.Encoding.Helper.Template ( Data\Encoding\Helper\Template.hs, dist\build\Data\Encoding\Helper\Template.o ) [ 2 of 37] Compiling Data.Encoding.GB18030Data ( Data\Encoding\GB18030Data.hs, dist\build\Data\Encoding\GB18030Data.o ) [ 3 of 37] Compiling Data.Encoding.Base ( Data\Encoding\Base.hs, dist\build\Data\Encoding\Base.o ) [ 4 of 37] Compiling Data.Encoding.GB18030 ( Data\Encoding\GB18030.hs, dist\build\Data\Encoding\GB18030.o ) [ 5 of 37] Compiling Data.Encoding.KOI8U ( Data\Encoding\KOI8U.hs, dist\build\Data\Encoding\KOI8U.o ) [ 6 of 37] Compiling Data.Encoding.KOI8R ( Data\Encoding\KOI8R.hs, dist\build\Data\Encoding\KOI8R.o ) [ 7 of 37] Compiling Data.Encoding.CP1258 ( Data\Encoding\CP1258.hs, dist\build\Data\Encoding\CP1258.o ) Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package regex-base-0.72.0.2 ... linking ... done. Loading package regex-posix-0.72.0.3 ... linking ... done. Loading package regex-compat-0.71.0.1 ... linking ... done. Loading package base-3.0.3.0 ... linking ... done. [ 8 of 37] Compiling Data.Encoding.CP1257 ( Data\Encoding\CP1257.hs, dist\build\Data\Encoding\CP1257.o ) [ 9 of 37] Compiling Data.Encoding.CP1256 ( Data\Encoding\CP1256.hs, dist\build\Data\Encoding\CP1256.o ) [10 of 37] Compiling Data.Encoding.CP1255 ( Data\Encoding\CP1255.hs, dist\build\Data\Encoding\CP1255.o ) [11 of 37] Compiling Data.Encoding.CP1254 ( Data\Encoding\CP1254.hs, dist\build\Data\Encoding\CP1254.o ) [12 of 37] Compiling Data.Encoding.CP1253 ( Data\Encoding\CP1253.hs, dist\build\Data\Encoding\CP1253.o ) [13 of 37] Compiling Data.Encoding.CP1252 ( Data\Encoding\CP1252.hs, dist\build\Data\Encoding\CP1252.o ) [14 of 37] Compiling Data.Encoding.CP1251 ( Data\Encoding\CP1251.hs, dist\build\Data\Encoding\CP1251.o ) [15 of 37] Compiling Data.Encoding.CP1250 ( Data\Encoding\CP1250.hs, dist\build\Data\Encoding\CP1250.o ) [16 of 37] Compiling Data.Encoding.BootString ( Data\Encoding\BootString.hs, dist\build\Data\Encoding\BootString.o ) [17 of 37] Compiling Data.Encoding.ISO885916 ( Data\Encoding\ISO885916.hs, dist\build\Data\Encoding\ISO885916.o ) [18 of 37] Compiling Data.Encoding.ISO885915 ( Data\Encoding\ISO885915.hs, dist\build\Data\Encoding\ISO885915.o ) [19 of 37] Compiling Data.Encoding.ISO885914 ( Data\Encoding\ISO885914.hs, dist\build\Data\Encoding\ISO885914.o ) [20 of 37] Compiling Data.Encoding.ISO885913 ( Data\Encoding\ISO885913.hs, dist\build\Data\Encoding\ISO885913.o ) [21 of 37] Compiling Data.Encoding.ISO885911 ( Data\Encoding\ISO885911.hs, dist\build\Data\Encoding\ISO885911.o ) [22 of 37] Compiling Data.Encoding.ISO885910 ( Data\Encoding\ISO885910.hs, dist\build\Data\Encoding\ISO885910.o ) [23 of 37] Compiling Data.Encoding.ISO88599 ( Data\Encoding\ISO88599.hs, dist\build\Data\Encoding\ISO88599.o ) [24 of 37] Compiling Data.Encoding.ISO88598 ( Data\Encoding\ISO88598.hs, dist\build\Data\Encoding\ISO88598.o ) [25 of 37] Compiling Data.Encoding.ISO88597 ( Data\Encoding\ISO88597.hs, dist\build\Data\Encoding\ISO88597.o ) [26 of 37] Compiling Data.Encoding.ISO88596 ( Data\Encoding\ISO88596.hs, dist\build\Data\Encoding\ISO88596.o ) [27 of 37] Compiling Data.Encoding.ISO88595 ( Data\Encoding\ISO88595.hs, dist\build\Data\Encoding\ISO88595.o ) [28 of 37] Compiling Data.Encoding.ISO88594 ( Data\Encoding\ISO88594.hs, dist\build\Data\Encoding\ISO88594.o ) [29 of 37] Compiling Data.Encoding.ISO88593 ( Data\Encoding\ISO88593.hs, dist\build\Data\Encoding\ISO88593.o ) [30 of 37] Compiling Data.Encoding.ISO88592 ( Data\Encoding\ISO88592.hs, dist\build\Data\Encoding\ISO88592.o ) [31 of 37] Compiling Data.Encoding.ISO88591 ( Data\Encoding\ISO88591.hs, dist\build\Data\Encoding\ISO88591.o ) [32 of 37] Compiling Data.Encoding.UTF32 ( Data\Encoding\UTF32.hs, dist\build\Data\Encoding\UTF32.o ) [33 of 37] Compiling Data.Encoding.UTF16 ( Data\Encoding\UTF16.hs, dist\build\Data\Encoding\UTF16.o ) [34 of 37] Compiling Data.Encoding.UTF8 ( Data\Encoding\UTF8.hs, dist\build\Data\Encoding\UTF8.o ) [35 of 37] Compiling Data.Encoding.ASCII ( Data\Encoding\ASCII.hs, dist\build\Data\Encoding\ASCII.o ) [36 of 37] Compiling Data.Encoding ( Data\Encoding.hs, dist\build\Data\Encoding.o ) [37 of 37] Compiling System.IO.Encoding ( System\IO\Encoding.hs, dist\build\System\IO\Encoding.o ) C:\ghc\ghc-6.10.1\bin\ar.exe: creating dist\build\libHSencoding-0.4.1.a Installing library in C:\Program Files\Haskell\encoding-0.4.1\ghc-6.10.1 Registering encoding-0.4.1... Reading package info from "dist\\installed-pkg-config" ... done. Writing new package config file... done. In any case, passing -v option should be helpful for debugging. All best Christopher Skrz?tnicki On Tue, Jan 13, 2009 at 16:33, Regis Saint-Paul wrote: > Hi, > > I've seen many times the monad topic coming around on the cafe and plentiful > tutorials on monads have been published. However, as a complete Haskell > newbie coming from OOP, I felt monads were not particularly difficult to > grasp, and very exciting to work with. > > During my experiments with Haskell so far, the main problems I kept bumping > into were not related to the language but to its libraries: their > compilation and installation. Unfortunately, this topic has not received > nearly as much attention. I was unable to find a comprehensive tutorial on > how to deal with the variety of problems I get when trying to install > Hackage packages. This turned out to be (and still is) THE main source of > wasted time and headaches. And worse, unlike type problems, these are not > interesting ones to solve. > > Thus, as a beginner, the package management is what is really getting in the > way of switching to Haskell--not the language. Even books like Real World > Haskell (otherwise excellent) ignore entirely the topic. Cabal and > Cabal-install are clearly wonderful applications that make installing most > packages very straightforward. Unfortunately, whenever this "standard" > method for package installation fails (or when it is not available as with, > e.g., gtk2hs), I find myself in complete disarray. > > Below are some of the questions and issues I faced regarding package > management: > > - For a number of packages, cabal-install gets stuck and has to be killed. I > assume this is due to some difficulties in solving the dependencies and it > is fine, not all can be automated and cabal-install is not responsible for > poor packages. But the question then becomes what to do from there? Is their > some method to solve dependencies? How should we proceed to "debug" a > package installation? How do gurus deal with that? (maybe some less known > command line arguments? Or ways to figure out the problem and work out its > solution (cabal-install is silent in such case)? In particular, how to know > why did cabal get stuck in the first place? > > - Some packages on Hackage are reported as not building successfully with > GHC6.10 (e.g., encoding) while others do not build with 6.8 (e.g., salvia) > and the later might depend on the former...What is one supposed to do in > such case? For example, is it an appropriate way to proceed to compile a > package with one version of GHC and then use the compiled package with > another version of GHC? Is it safe? What could possibly go wrong? If it is > the right way to go, how should we setup the two GHC versions? For instance, > should we have a shared package configuration file and choose through the > path which GHC is used or is there nicer way to set this up? > > - Taking for example the "encoding" package on Hackage. Last time I tried, > the log was saying it fails to build on GHC 6.10, however, looking inside > this Hackage log, I could see a successful compilation using "preferred > versions". So it looks as if the thing can be compiled somehow. What should > one do with this information? If cabal manages to compile it using this > method on Hackage, then isn't cabal install just doing it on my disk? Is it > possible through some command line? Is it possible manually (without > cabal-install) and, if so, how? (I tried to copy-past the build instruction > as it appeared on the log...that somehow compiled, but then, I failed to > figure out how to install...) > > - I'm primarily a windows user and lots of my initial struggles probably > came from that. After many difficulties, I figured out that installing MinGW > and MSys was *THE* way to get a bit more of the things working. First, a lot > of time would be saved by just saying clearly on the GHC download page that > MinGW and MSys are mandatory installation (or even package that with GHC for > the windows distribution if license allows, who cares the extra few Mb). > Even if that is not technically exact, i.e., even if ghci and many trivial > command line programs can work without, MSys and MinGW turn out to be quiet > necessary whenever trying to install anything producing side effect. Making > it plain that these two are necessary would real come has a great time > savers for newbie like me on windows (personal opinion of course). Or, if > another path exists to go without these two, I'd be very glad to learn. > Besides, even these tools basic installation is not enough, you need > automake and various things of the like. That makes me wonder if the most > precious skill for programming with Haskell would not be a strong C/C++ > programming background. > > - In face of the difficulties with windows, I switched to Linux. While some > things worked better, there were still lots of difficulties with package > compilation. For instance, it is very difficult to figure out which Linux > packages of a given distribution are needed for compiling this or that > package. Again, gtk2hs is epitome here: which C development packages are > needed to compile it is obscure at best (cairo, codeview, etc...). I ended > up querying the Debian package management with any keyword found after > running gtk2hs and randomly installing all the dev packages...And when > gtk2hs finally compiled, it failed to install anyway. As of today, I've > never been able to compile even the dumbest demo using gtk2hs whether on > linux or on windows and whether using ghc 6.8.3 or 6.10.1. On windows, the > automated setup install worked but did not allow me to compile with codeview > and I still do not know how to add codeview to the install packages. Trust > that I tried hard and read the docs thoroughly. Gtk2hs is just on of many > examples; I had problems under Linux also with, e.g., Happs, yi, database > things, etc. and figured out that the situation was roughly identical to > windows with MSys and MinGW. So Linux appears not to be the right solution > here. Maybe it's just that Linux users are more experienced with the GNU > C/C++ libraries...but it won't help a windows user to switch to Linux since > this knowledge can't be built out of thin air. > > - Would there be some binary version of cabal targeting various OSs? I > believe the Haskell platform project is about that. But without waiting for > a fair and objective selection of the packages (it seems to be the current > status of the project), I'd be happy working with some authoritative bundle > produced by a Haskell guru and would trust his subjective choices (who am I > to question these choices anyway). Or even an image (e.g., virtual box or > Xen) of a fully setup development environment since there are so many > dependencies involved in, e.g., simply compiling GHC... > > Now, one might argue that these are not Haskell problems, that they are > normal when dealing with non-mature packages. So let me explain why I've > been trying hard to install these packages: > > As a beginner with no experience with emacs, I tried to find some IDE-like > environment which would, at least, save me from manually reloading files in > ghci or help me browse the source files. Following the Haskellwiki advice, > that led to trying out Yi, Leksah, eclipsefp, or a Visual Studio extension. > To this date, NOT ANY SINGLE ONE of these worked, be it on Linux or Windows. > I had to resort to learning emacs which seems the only sensible choice > available today. > > I am particularly unskilled, no question here. But, would a charitable soul > take the pain of writing a comprehensive package management tutorial instead > of a monad one, (s)he would have my deepest gratitude :) > > Apologies for the long mail. > > -Regis > > P.S. People on #haskell are wonderful. They helped me solve many issues. > Unfortunately, solving specific instances of problem did not contribute much > to a deeper understanding of the internal working. I find myself randomly > trying things without knowing which would work or why; Hence this plea for a > tutorial. > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dons at galois.com Tue Jan 13 12:13:36 2009 From: dons at galois.com (Don Stewart) Date: Tue Jan 13 12:04:36 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <10ed1a750901130821m9b3e8fev2528a0877ebf6be1@mail.gmail.com> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <10ed1a750901130821m9b3e8fev2528a0877ebf6be1@mail.gmail.com> Message-ID: <20090113171336.GD6699@scytale.galois.com> Well, the number one thing is to use Cabal and the cabal-install tool. That is the simplest way to avoid headaches. Regarding libraries in general, the platform project is underway, aiming to bless a set of stable, "batteries included" packages, saving duplicated work determining which, say, json library to use. -- Don jamiiecb: > I agree completely. There is not nearly enough documentation on > packaging in haskell and too many hackage packages are broken or do > not install. I know several people are working on improving this but > they seem do be doing so rather quietly. Could someone briefly outline > what improvements are planned and what stage the current work is at? I > remember seeing some demos at anglohaskell during the summer but > nothing since. > > Jamie > > On Tue, Jan 13, 2009 at 3:33 PM, Regis Saint-Paul > wrote: > > Hi, > > > > I've seen many times the monad topic coming around on the cafe and plentiful > > tutorials on monads have been published. However, as a complete Haskell > > newbie coming from OOP, I felt monads were not particularly difficult to > > grasp, and very exciting to work with. > > > > During my experiments with Haskell so far, the main problems I kept bumping > > into were not related to the language but to its libraries: their > > compilation and installation. Unfortunately, this topic has not received > > nearly as much attention. I was unable to find a comprehensive tutorial on > > how to deal with the variety of problems I get when trying to install > > Hackage packages. This turned out to be (and still is) THE main source of > > wasted time and headaches. And worse, unlike type problems, these are not > > interesting ones to solve. > > > > Thus, as a beginner, the package management is what is really getting in the > > way of switching to Haskell--not the language. Even books like Real World > > Haskell (otherwise excellent) ignore entirely the topic. Cabal and > > Cabal-install are clearly wonderful applications that make installing most > > packages very straightforward. Unfortunately, whenever this "standard" > > method for package installation fails (or when it is not available as with, > > e.g., gtk2hs), I find myself in complete disarray. > > > > Below are some of the questions and issues I faced regarding package > > management: > > > > - For a number of packages, cabal-install gets stuck and has to be killed. I > > assume this is due to some difficulties in solving the dependencies and it > > is fine, not all can be automated and cabal-install is not responsible for > > poor packages. But the question then becomes what to do from there? Is their > > some method to solve dependencies? How should we proceed to "debug" a > > package installation? How do gurus deal with that? (maybe some less known > > command line arguments? Or ways to figure out the problem and work out its > > solution (cabal-install is silent in such case)? In particular, how to know > > why did cabal get stuck in the first place? > > > > - Some packages on Hackage are reported as not building successfully with > > GHC6.10 (e.g., encoding) while others do not build with 6.8 (e.g., salvia) > > and the later might depend on the former...What is one supposed to do in > > such case? For example, is it an appropriate way to proceed to compile a > > package with one version of GHC and then use the compiled package with > > another version of GHC? Is it safe? What could possibly go wrong? If it is > > the right way to go, how should we setup the two GHC versions? For instance, > > should we have a shared package configuration file and choose through the > > path which GHC is used or is there nicer way to set this up? > > > > - Taking for example the "encoding" package on Hackage. Last time I tried, > > the log was saying it fails to build on GHC 6.10, however, looking inside > > this Hackage log, I could see a successful compilation using "preferred > > versions". So it looks as if the thing can be compiled somehow. What should > > one do with this information? If cabal manages to compile it using this > > method on Hackage, then isn't cabal install just doing it on my disk? Is it > > possible through some command line? Is it possible manually (without > > cabal-install) and, if so, how? (I tried to copy-past the build instruction > > as it appeared on the log...that somehow compiled, but then, I failed to > > figure out how to install...) > > > > - I'm primarily a windows user and lots of my initial struggles probably > > came from that. After many difficulties, I figured out that installing MinGW > > and MSys was *THE* way to get a bit more of the things working. First, a lot > > of time would be saved by just saying clearly on the GHC download page that > > MinGW and MSys are mandatory installation (or even package that with GHC for > > the windows distribution if license allows, who cares the extra few Mb). > > Even if that is not technically exact, i.e., even if ghci and many trivial > > command line programs can work without, MSys and MinGW turn out to be quiet > > necessary whenever trying to install anything producing side effect. Making > > it plain that these two are necessary would real come has a great time > > savers for newbie like me on windows (personal opinion of course). Or, if > > another path exists to go without these two, I'd be very glad to learn. > > Besides, even these tools basic installation is not enough, you need > > automake and various things of the like. That makes me wonder if the most > > precious skill for programming with Haskell would not be a strong C/C++ > > programming background. > > > > - In face of the difficulties with windows, I switched to Linux. While some > > things worked better, there were still lots of difficulties with package > > compilation. For instance, it is very difficult to figure out which Linux > > packages of a given distribution are needed for compiling this or that > > package. Again, gtk2hs is epitome here: which C development packages are > > needed to compile it is obscure at best (cairo, codeview, etc...). I ended > > up querying the Debian package management with any keyword found after > > running gtk2hs and randomly installing all the dev packages...And when > > gtk2hs finally compiled, it failed to install anyway. As of today, I've > > never been able to compile even the dumbest demo using gtk2hs whether on > > linux or on windows and whether using ghc 6.8.3 or 6.10.1. On windows, the > > automated setup install worked but did not allow me to compile with codeview > > and I still do not know how to add codeview to the install packages. Trust > > that I tried hard and read the docs thoroughly. Gtk2hs is just on of many > > examples; I had problems under Linux also with, e.g., Happs, yi, database > > things, etc. and figured out that the situation was roughly identical to > > windows with MSys and MinGW. So Linux appears not to be the right solution > > here. Maybe it's just that Linux users are more experienced with the GNU > > C/C++ libraries...but it won't help a windows user to switch to Linux since > > this knowledge can't be built out of thin air. > > > > - Would there be some binary version of cabal targeting various OSs? I > > believe the Haskell platform project is about that. But without waiting for > > a fair and objective selection of the packages (it seems to be the current > > status of the project), I'd be happy working with some authoritative bundle > > produced by a Haskell guru and would trust his subjective choices (who am I > > to question these choices anyway). Or even an image (e.g., virtual box or > > Xen) of a fully setup development environment since there are so many > > dependencies involved in, e.g., simply compiling GHC... > > > > Now, one might argue that these are not Haskell problems, that they are > > normal when dealing with non-mature packages. So let me explain why I've > > been trying hard to install these packages: > > > > As a beginner with no experience with emacs, I tried to find some IDE-like > > environment which would, at least, save me from manually reloading files in > > ghci or help me browse the source files. Following the Haskellwiki advice, > > that led to trying out Yi, Leksah, eclipsefp, or a Visual Studio extension. > > To this date, NOT ANY SINGLE ONE of these worked, be it on Linux or Windows. > > I had to resort to learning emacs which seems the only sensible choice > > available today. > > > > I am particularly unskilled, no question here. But, would a charitable soul > > take the pain of writing a comprehensive package management tutorial instead > > of a monad one, (s)he would have my deepest gratitude :) > > > > Apologies for the long mail. > > > > -Regis > > > > P.S. People on #haskell are wonderful. They helped me solve many issues. > > Unfortunately, solving specific instances of problem did not contribute much > > to a deeper understanding of the internal working. I find myself randomly > > trying things without knowing which would work or why; Hence this plea for a > > tutorial. > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From derek.a.elkins at gmail.com Tue Jan 13 12:27:19 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Jan 13 12:18:39 2009 Subject: [Haskell-cafe] The problem with Monads... In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B4DCAE8@ELON17P32001A.csfb.cs-group.com> References: <351ff25e0901130656k530348afj6633048d206d7f74@mail.gmail.com> <1231861860.17950.1.camel@jonathans-macbook> <16442B752A06A74AB4D9F9A5FF076E4B4DCAE8@ELON17P32001A.csfb.cs-group.com> Message-ID: <1231867639.3917.9.camel@derek-laptop> On Tue, 2009-01-13 at 16:22 +0000, Sittampalam, Ganesh wrote: > Jonathan Cast wrote: > > On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira > > Pinto wrote: > >> > >> Inspired by the paper "Functional Programming with Overloading and > >> Higher-Order Polymorphism", Mark P Jones > >> (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html) > >> Advanced School of Functional Programming, 1995. > >> > >> SO WHAT? > > > > So have you read Jones' paper? Or do you have a *concrete* > > explanation of how it differs from your desired `guided tour'? > > To give a specific example, a few weeks ago I wanted an explanation of > the 'pass' function and couldn't find it in that paper. > > Ganesh Several years ago I documented all the (basic) monads in the mtl on the (old) wiki. http://web.archive.org/web/20030927210146/haskell.org/hawiki/MonadTemplateLibrary In particular, http://web.archive.org/web/20030907203223/haskell.org/hawiki/MonadWriter To respond to the essential point of Rafael's initial claim, Wadler's papers "The Essence of Functional Programming" and/or "Monads for Functional Programming" have exactly what he wants. These are the papers that I recommend to anyone who is learning about monads. http://homepages.inf.ed.ac.uk/wadler/topics/monads.html Please, we do not need the 101st monad tutorial when there was an adequate one made almost two decades ago. While I'm not saying that this is the case here, I suspect that many people don't read those papers because 1) they haven't heard of them and 2) they are "papers" and thus couldn't possibly be readable and understandable (which also partially causes (1) as people just don't think to look for papers at all.) From bugfact at gmail.com Tue Jan 13 12:43:25 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Tue Jan 13 12:34:40 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <20090113171336.GD6699@scytale.galois.com> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <10ed1a750901130821m9b3e8fev2528a0877ebf6be1@mail.gmail.com> <20090113171336.GD6699@scytale.galois.com> Message-ID: What could be done is letting the community rate the quality of the modules for each platform? Maybe with user comments? Like amazon.com (so we hackazon.org ;-) And using lambdas instead of stars for giving the rating :) On Tue, Jan 13, 2009 at 6:13 PM, Don Stewart wrote: > > Well, the number one thing is to use Cabal and the cabal-install tool. > That is the simplest way to avoid headaches. > > Regarding libraries in general, the platform project is underway, aiming > to bless a set of stable, "batteries included" packages, saving > duplicated work determining which, say, json library to use. > > -- Don > > > jamiiecb: > > I agree completely. There is not nearly enough documentation on > > packaging in haskell and too many hackage packages are broken or do > > not install. I know several people are working on improving this but > > they seem do be doing so rather quietly. Could someone briefly outline > > what improvements are planned and what stage the current work is at? I > > remember seeing some demos at anglohaskell during the summer but > > nothing since. > > > > Jamie > > > > On Tue, Jan 13, 2009 at 3:33 PM, Regis Saint-Paul > > wrote: > > > Hi, > > > > > > I've seen many times the monad topic coming around on the cafe and > plentiful > > > tutorials on monads have been published. However, as a complete Haskell > > > newbie coming from OOP, I felt monads were not particularly difficult > to > > > grasp, and very exciting to work with. > > > > > > During my experiments with Haskell so far, the main problems I kept > bumping > > > into were not related to the language but to its libraries: their > > > compilation and installation. Unfortunately, this topic has not > received > > > nearly as much attention. I was unable to find a comprehensive tutorial > on > > > how to deal with the variety of problems I get when trying to install > > > Hackage packages. This turned out to be (and still is) THE main source > of > > > wasted time and headaches. And worse, unlike type problems, these are > not > > > interesting ones to solve. > > > > > > Thus, as a beginner, the package management is what is really getting > in the > > > way of switching to Haskell--not the language. Even books like Real > World > > > Haskell (otherwise excellent) ignore entirely the topic. Cabal and > > > Cabal-install are clearly wonderful applications that make installing > most > > > packages very straightforward. Unfortunately, whenever this "standard" > > > method for package installation fails (or when it is not available as > with, > > > e.g., gtk2hs), I find myself in complete disarray. > > > > > > Below are some of the questions and issues I faced regarding package > > > management: > > > > > > - For a number of packages, cabal-install gets stuck and has to be > killed. I > > > assume this is due to some difficulties in solving the dependencies and > it > > > is fine, not all can be automated and cabal-install is not responsible > for > > > poor packages. But the question then becomes what to do from there? Is > their > > > some method to solve dependencies? How should we proceed to "debug" a > > > package installation? How do gurus deal with that? (maybe some less > known > > > command line arguments? Or ways to figure out the problem and work out > its > > > solution (cabal-install is silent in such case)? In particular, how to > know > > > why did cabal get stuck in the first place? > > > > > > - Some packages on Hackage are reported as not building successfully > with > > > GHC6.10 (e.g., encoding) while others do not build with 6.8 (e.g., > salvia) > > > and the later might depend on the former...What is one supposed to do > in > > > such case? For example, is it an appropriate way to proceed to compile > a > > > package with one version of GHC and then use the compiled package with > > > another version of GHC? Is it safe? What could possibly go wrong? If it > is > > > the right way to go, how should we setup the two GHC versions? For > instance, > > > should we have a shared package configuration file and choose through > the > > > path which GHC is used or is there nicer way to set this up? > > > > > > - Taking for example the "encoding" package on Hackage. Last time I > tried, > > > the log was saying it fails to build on GHC 6.10, however, looking > inside > > > this Hackage log, I could see a successful compilation using "preferred > > > versions". So it looks as if the thing can be compiled somehow. What > should > > > one do with this information? If cabal manages to compile it using this > > > method on Hackage, then isn't cabal install just doing it on my disk? > Is it > > > possible through some command line? Is it possible manually (without > > > cabal-install) and, if so, how? (I tried to copy-past the build > instruction > > > as it appeared on the log...that somehow compiled, but then, I failed > to > > > figure out how to install...) > > > > > > - I'm primarily a windows user and lots of my initial struggles > probably > > > came from that. After many difficulties, I figured out that installing > MinGW > > > and MSys was *THE* way to get a bit more of the things working. First, > a lot > > > of time would be saved by just saying clearly on the GHC download page > that > > > MinGW and MSys are mandatory installation (or even package that with > GHC for > > > the windows distribution if license allows, who cares the extra few > Mb). > > > Even if that is not technically exact, i.e., even if ghci and many > trivial > > > command line programs can work without, MSys and MinGW turn out to be > quiet > > > necessary whenever trying to install anything producing side effect. > Making > > > it plain that these two are necessary would real come has a great time > > > savers for newbie like me on windows (personal opinion of course). Or, > if > > > another path exists to go without these two, I'd be very glad to learn. > > > Besides, even these tools basic installation is not enough, you need > > > automake and various things of the like. That makes me wonder if the > most > > > precious skill for programming with Haskell would not be a strong C/C++ > > > programming background. > > > > > > - In face of the difficulties with windows, I switched to Linux. While > some > > > things worked better, there were still lots of difficulties with > package > > > compilation. For instance, it is very difficult to figure out which > Linux > > > packages of a given distribution are needed for compiling this or that > > > package. Again, gtk2hs is epitome here: which C development packages > are > > > needed to compile it is obscure at best (cairo, codeview, etc...). I > ended > > > up querying the Debian package management with any keyword found after > > > running gtk2hs and randomly installing all the dev packages...And when > > > gtk2hs finally compiled, it failed to install anyway. As of today, I've > > > never been able to compile even the dumbest demo using gtk2hs whether > on > > > linux or on windows and whether using ghc 6.8.3 or 6.10.1. On windows, > the > > > automated setup install worked but did not allow me to compile with > codeview > > > and I still do not know how to add codeview to the install packages. > Trust > > > that I tried hard and read the docs thoroughly. Gtk2hs is just on of > many > > > examples; I had problems under Linux also with, e.g., Happs, yi, > database > > > things, etc. and figured out that the situation was roughly identical > to > > > windows with MSys and MinGW. So Linux appears not to be the right > solution > > > here. Maybe it's just that Linux users are more experienced with the > GNU > > > C/C++ libraries...but it won't help a windows user to switch to Linux > since > > > this knowledge can't be built out of thin air. > > > > > > - Would there be some binary version of cabal targeting various OSs? I > > > believe the Haskell platform project is about that. But without waiting > for > > > a fair and objective selection of the packages (it seems to be the > current > > > status of the project), I'd be happy working with some authoritative > bundle > > > produced by a Haskell guru and would trust his subjective choices (who > am I > > > to question these choices anyway). Or even an image (e.g., virtual box > or > > > Xen) of a fully setup development environment since there are so many > > > dependencies involved in, e.g., simply compiling GHC... > > > > > > Now, one might argue that these are not Haskell problems, that they are > > > normal when dealing with non-mature packages. So let me explain why > I've > > > been trying hard to install these packages: > > > > > > As a beginner with no experience with emacs, I tried to find some > IDE-like > > > environment which would, at least, save me from manually reloading > files in > > > ghci or help me browse the source files. Following the Haskellwiki > advice, > > > that led to trying out Yi, Leksah, eclipsefp, or a Visual Studio > extension. > > > To this date, NOT ANY SINGLE ONE of these worked, be it on Linux or > Windows. > > > I had to resort to learning emacs which seems the only sensible choice > > > available today. > > > > > > I am particularly unskilled, no question here. But, would a charitable > soul > > > take the pain of writing a comprehensive package management tutorial > instead > > > of a monad one, (s)he would have my deepest gratitude :) > > > > > > Apologies for the long mail. > > > > > > -Regis > > > > > > P.S. People on #haskell are wonderful. They helped me solve many > issues. > > > Unfortunately, solving specific instances of problem did not contribute > much > > > to a deeper understanding of the internal working. I find myself > randomly > > > trying things without knowing which would work or why; Hence this plea > for a > > > tutorial. > > > > > > > > > > > > _______________________________________________ > > > Haskell-Cafe mailing list > > > Haskell-Cafe@haskell.org > > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/d9be6180/attachment.htm From dpiponi at gmail.com Tue Jan 13 12:44:19 2009 From: dpiponi at gmail.com (Dan Piponi) Date: Tue Jan 13 12:35:32 2009 Subject: [Haskell-cafe] Real World Haskell: confusion In-Reply-To: References: Message-ID: <625b74080901130944p40851761i5e938c9164100ea1@mail.gmail.com> 2009/1/13 Peter Verswyvelen : > On page 102: "partial function application is named currying" > I thought "currying" or "to curry" means converting > f :: (a,b) ->c Confusion over these terms is commonplace. See, for example, the discussion here: http://lambda-the-ultimate.org/node/2266 -- Dan From derek.a.elkins at gmail.com Tue Jan 13 12:46:35 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Jan 13 12:37:53 2009 Subject: [Haskell-cafe] Real World Haskell: confusion In-Reply-To: References: <5e0214850901130805h638625d1ge647a7fb278fc7e@mail.gmail.com> Message-ID: <1231868795.3917.25.camel@derek-laptop> No, it means exactly what you said it means. People abuse it to mean the second sense. Those people are wrong and there is already a term for that second sense, namely "partial application." I really wish people would stop conflating these terms*, all it does is create confusion. To Eugene: The suggested meaning of "curriable", namely "able to be curried," does not make sense. curry takes an uncurried function to a curried form. * A related annoyance is people who talk about languages "supporting currying and/or partial application." Unless one means that the language supports higher order functions at all by that, it doesn't make any sense. Haskell has no "support" for currying or partial application. The fact that most functions are in curried form in Haskell is merely a convention (with, admittedly strong -social- ramifications.) The only way one could say Haskell "supports" currying is that it has a lightweight notation for nested lambdas. On Tue, 2009-01-13 at 17:17 +0100, Peter Verswyvelen wrote: > Ah. That explains my confusion. But isn't that ambiguous terminology? > There must be some reason for it to be that way? > > On Tue, Jan 13, 2009 at 5:05 PM, Eugene Kirpichov > wrote: > The term 'currying' means both of these things: > - Converting an uncurried function to a 'curriable' one > - Partially applying a 'curriable' function > > 2009/1/13 Peter Verswyvelen : > > > On page 102: "partial function application is named > currying" > > > > > > > > I thought "currying" or "to curry" means converting > > > > > > > > f :: (a,b) ->c > > > > > > > > into > > > > > > > > g :: a -> b -> c > > > > > > > > by applying "curry" (mmm, are Asian people good at > Haskell? :-) > > > > > > g = curry f > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From wagner.andrew at gmail.com Tue Jan 13 12:48:09 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Tue Jan 13 12:39:25 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <10ed1a750901130821m9b3e8fev2528a0877ebf6be1@mail.gmail.com> <20090113171336.GD6699@scytale.galois.com> Message-ID: Wow, totally ++ this idea! 2009/1/13 Peter Verswyvelen > What could be done is letting the community rate the quality of the modules > for each platform? Maybe with user comments? Like amazon.com (so we > hackazon.org ;-) And using lambdas instead of stars for giving the rating > :) > > > On Tue, Jan 13, 2009 at 6:13 PM, Don Stewart wrote: > >> >> Well, the number one thing is to use Cabal and the cabal-install tool. >> That is the simplest way to avoid headaches. >> >> Regarding libraries in general, the platform project is underway, aiming >> to bless a set of stable, "batteries included" packages, saving >> duplicated work determining which, say, json library to use. >> >> -- Don >> >> >> jamiiecb: >> > I agree completely. There is not nearly enough documentation on >> > packaging in haskell and too many hackage packages are broken or do >> > not install. I know several people are working on improving this but >> > they seem do be doing so rather quietly. Could someone briefly outline >> > what improvements are planned and what stage the current work is at? I >> > remember seeing some demos at anglohaskell during the summer but >> > nothing since. >> > >> > Jamie >> > >> > On Tue, Jan 13, 2009 at 3:33 PM, Regis Saint-Paul >> > wrote: >> > > Hi, >> > > >> > > I've seen many times the monad topic coming around on the cafe and >> plentiful >> > > tutorials on monads have been published. However, as a complete >> Haskell >> > > newbie coming from OOP, I felt monads were not particularly difficult >> to >> > > grasp, and very exciting to work with. >> > > >> > > During my experiments with Haskell so far, the main problems I kept >> bumping >> > > into were not related to the language but to its libraries: their >> > > compilation and installation. Unfortunately, this topic has not >> received >> > > nearly as much attention. I was unable to find a comprehensive >> tutorial on >> > > how to deal with the variety of problems I get when trying to install >> > > Hackage packages. This turned out to be (and still is) THE main source >> of >> > > wasted time and headaches. And worse, unlike type problems, these are >> not >> > > interesting ones to solve. >> > > >> > > Thus, as a beginner, the package management is what is really getting >> in the >> > > way of switching to Haskell--not the language. Even books like Real >> World >> > > Haskell (otherwise excellent) ignore entirely the topic. Cabal and >> > > Cabal-install are clearly wonderful applications that make installing >> most >> > > packages very straightforward. Unfortunately, whenever this "standard" >> > > method for package installation fails (or when it is not available as >> with, >> > > e.g., gtk2hs), I find myself in complete disarray. >> > > >> > > Below are some of the questions and issues I faced regarding package >> > > management: >> > > >> > > - For a number of packages, cabal-install gets stuck and has to be >> killed. I >> > > assume this is due to some difficulties in solving the dependencies >> and it >> > > is fine, not all can be automated and cabal-install is not responsible >> for >> > > poor packages. But the question then becomes what to do from there? Is >> their >> > > some method to solve dependencies? How should we proceed to "debug" a >> > > package installation? How do gurus deal with that? (maybe some less >> known >> > > command line arguments? Or ways to figure out the problem and work out >> its >> > > solution (cabal-install is silent in such case)? In particular, how to >> know >> > > why did cabal get stuck in the first place? >> > > >> > > - Some packages on Hackage are reported as not building successfully >> with >> > > GHC6.10 (e.g., encoding) while others do not build with 6.8 (e.g., >> salvia) >> > > and the later might depend on the former...What is one supposed to do >> in >> > > such case? For example, is it an appropriate way to proceed to compile >> a >> > > package with one version of GHC and then use the compiled package with >> > > another version of GHC? Is it safe? What could possibly go wrong? If >> it is >> > > the right way to go, how should we setup the two GHC versions? For >> instance, >> > > should we have a shared package configuration file and choose through >> the >> > > path which GHC is used or is there nicer way to set this up? >> > > >> > > - Taking for example the "encoding" package on Hackage. Last time I >> tried, >> > > the log was saying it fails to build on GHC 6.10, however, looking >> inside >> > > this Hackage log, I could see a successful compilation using >> "preferred >> > > versions". So it looks as if the thing can be compiled somehow. What >> should >> > > one do with this information? If cabal manages to compile it using >> this >> > > method on Hackage, then isn't cabal install just doing it on my disk? >> Is it >> > > possible through some command line? Is it possible manually (without >> > > cabal-install) and, if so, how? (I tried to copy-past the build >> instruction >> > > as it appeared on the log...that somehow compiled, but then, I failed >> to >> > > figure out how to install...) >> > > >> > > - I'm primarily a windows user and lots of my initial struggles >> probably >> > > came from that. After many difficulties, I figured out that installing >> MinGW >> > > and MSys was *THE* way to get a bit more of the things working. First, >> a lot >> > > of time would be saved by just saying clearly on the GHC download page >> that >> > > MinGW and MSys are mandatory installation (or even package that with >> GHC for >> > > the windows distribution if license allows, who cares the extra few >> Mb). >> > > Even if that is not technically exact, i.e., even if ghci and many >> trivial >> > > command line programs can work without, MSys and MinGW turn out to be >> quiet >> > > necessary whenever trying to install anything producing side effect. >> Making >> > > it plain that these two are necessary would real come has a great time >> > > savers for newbie like me on windows (personal opinion of course). Or, >> if >> > > another path exists to go without these two, I'd be very glad to >> learn. >> > > Besides, even these tools basic installation is not enough, you need >> > > automake and various things of the like. That makes me wonder if the >> most >> > > precious skill for programming with Haskell would not be a strong >> C/C++ >> > > programming background. >> > > >> > > - In face of the difficulties with windows, I switched to Linux. While >> some >> > > things worked better, there were still lots of difficulties with >> package >> > > compilation. For instance, it is very difficult to figure out which >> Linux >> > > packages of a given distribution are needed for compiling this or that >> > > package. Again, gtk2hs is epitome here: which C development packages >> are >> > > needed to compile it is obscure at best (cairo, codeview, etc...). I >> ended >> > > up querying the Debian package management with any keyword found after >> > > running gtk2hs and randomly installing all the dev packages...And when >> > > gtk2hs finally compiled, it failed to install anyway. As of today, >> I've >> > > never been able to compile even the dumbest demo using gtk2hs whether >> on >> > > linux or on windows and whether using ghc 6.8.3 or 6.10.1. On windows, >> the >> > > automated setup install worked but did not allow me to compile with >> codeview >> > > and I still do not know how to add codeview to the install packages. >> Trust >> > > that I tried hard and read the docs thoroughly. Gtk2hs is just on of >> many >> > > examples; I had problems under Linux also with, e.g., Happs, yi, >> database >> > > things, etc. and figured out that the situation was roughly identical >> to >> > > windows with MSys and MinGW. So Linux appears not to be the right >> solution >> > > here. Maybe it's just that Linux users are more experienced with the >> GNU >> > > C/C++ libraries...but it won't help a windows user to switch to Linux >> since >> > > this knowledge can't be built out of thin air. >> > > >> > > - Would there be some binary version of cabal targeting various OSs? I >> > > believe the Haskell platform project is about that. But without >> waiting for >> > > a fair and objective selection of the packages (it seems to be the >> current >> > > status of the project), I'd be happy working with some authoritative >> bundle >> > > produced by a Haskell guru and would trust his subjective choices (who >> am I >> > > to question these choices anyway). Or even an image (e.g., virtual box >> or >> > > Xen) of a fully setup development environment since there are so many >> > > dependencies involved in, e.g., simply compiling GHC... >> > > >> > > Now, one might argue that these are not Haskell problems, that they >> are >> > > normal when dealing with non-mature packages. So let me explain why >> I've >> > > been trying hard to install these packages: >> > > >> > > As a beginner with no experience with emacs, I tried to find some >> IDE-like >> > > environment which would, at least, save me from manually reloading >> files in >> > > ghci or help me browse the source files. Following the Haskellwiki >> advice, >> > > that led to trying out Yi, Leksah, eclipsefp, or a Visual Studio >> extension. >> > > To this date, NOT ANY SINGLE ONE of these worked, be it on Linux or >> Windows. >> > > I had to resort to learning emacs which seems the only sensible choice >> > > available today. >> > > >> > > I am particularly unskilled, no question here. But, would a charitable >> soul >> > > take the pain of writing a comprehensive package management tutorial >> instead >> > > of a monad one, (s)he would have my deepest gratitude :) >> > > >> > > Apologies for the long mail. >> > > >> > > -Regis >> > > >> > > P.S. People on #haskell are wonderful. They helped me solve many >> issues. >> > > Unfortunately, solving specific instances of problem did not >> contribute much >> > > to a deeper understanding of the internal working. I find myself >> randomly >> > > trying things without knowing which would work or why; Hence this plea >> for a >> > > tutorial. >> > > >> > > >> > > >> > > _______________________________________________ >> > > Haskell-Cafe mailing list >> > > Haskell-Cafe@haskell.org >> > > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe@haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/33b28164/attachment-0001.htm From briqueabraque at yahoo.com Tue Jan 13 12:55:47 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Tue Jan 13 12:47:12 2009 Subject: [Haskell-cafe] Re: real haskell difficulties (at least for me) In-Reply-To: <10ed1a750901130821m9b3e8fev2528a0877ebf6be1@mail.gmail.com> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <10ed1a750901130821m9b3e8fev2528a0877ebf6be1@mail.gmail.com> Message-ID: There's a 'stability' field on cabal description files. Maybe it could appear after the name on the main listing. Or, all packages marked as 'Stable' at that field could get a beautifull color. > I agree completely. There is not nearly enough documentation on > packaging in haskell and too many hackage packages are broken or do > not install. I know several people are working on improving this but > they seem do be doing so rather quietly. Could someone briefly outline > what improvements are planned and what stage the current work is at? I > remember seeing some demos at anglohaskell during the summer but > nothing since. > > Jamie > > On Tue, Jan 13, 2009 at 3:33 PM, Regis Saint-Paul > wrote: >> Hi, >> >> I've seen many times the monad topic coming around on the cafe and plentiful >> tutorials on monads have been published. However, as a complete Haskell >> newbie coming from OOP, I felt monads were not particularly difficult to >> grasp, and very exciting to work with. >> >> During my experiments with Haskell so far, the main problems I kept bumping >> into were not related to the language but to its libraries: their >> compilation and installation. Unfortunately, this topic has not received >> nearly as much attention. I was unable to find a comprehensive tutorial on >> how to deal with the variety of problems I get when trying to install >> Hackage packages. This turned out to be (and still is) THE main source of >> wasted time and headaches. And worse, unlike type problems, these are not >> interesting ones to solve. >> >> Thus, as a beginner, the package management is what is really getting in the >> way of switching to Haskell--not the language. Even books like Real World >> Haskell (otherwise excellent) ignore entirely the topic. Cabal and >> Cabal-install are clearly wonderful applications that make installing most >> packages very straightforward. Unfortunately, whenever this "standard" >> method for package installation fails (or when it is not available as with, >> e.g., gtk2hs), I find myself in complete disarray. >> >> Below are some of the questions and issues I faced regarding package >> management: >> >> - For a number of packages, cabal-install gets stuck and has to be killed. I >> assume this is due to some difficulties in solving the dependencies and it >> is fine, not all can be automated and cabal-install is not responsible for >> poor packages. But the question then becomes what to do from there? Is their >> some method to solve dependencies? How should we proceed to "debug" a >> package installation? How do gurus deal with that? (maybe some less known >> command line arguments? Or ways to figure out the problem and work out its >> solution (cabal-install is silent in such case)? In particular, how to know >> why did cabal get stuck in the first place? >> >> - Some packages on Hackage are reported as not building successfully with >> GHC6.10 (e.g., encoding) while others do not build with 6.8 (e.g., salvia) >> and the later might depend on the former...What is one supposed to do in >> such case? For example, is it an appropriate way to proceed to compile a >> package with one version of GHC and then use the compiled package with >> another version of GHC? Is it safe? What could possibly go wrong? If it is >> the right way to go, how should we setup the two GHC versions? For instance, >> should we have a shared package configuration file and choose through the >> path which GHC is used or is there nicer way to set this up? >> >> - Taking for example the "encoding" package on Hackage. Last time I tried, >> the log was saying it fails to build on GHC 6.10, however, looking inside >> this Hackage log, I could see a successful compilation using "preferred >> versions". So it looks as if the thing can be compiled somehow. What should >> one do with this information? If cabal manages to compile it using this >> method on Hackage, then isn't cabal install just doing it on my disk? Is it >> possible through some command line? Is it possible manually (without >> cabal-install) and, if so, how? (I tried to copy-past the build instruction >> as it appeared on the log...that somehow compiled, but then, I failed to >> figure out how to install...) >> >> - I'm primarily a windows user and lots of my initial struggles probably >> came from that. After many difficulties, I figured out that installing MinGW >> and MSys was *THE* way to get a bit more of the things working. First, a lot >> of time would be saved by just saying clearly on the GHC download page that >> MinGW and MSys are mandatory installation (or even package that with GHC for >> the windows distribution if license allows, who cares the extra few Mb). >> Even if that is not technically exact, i.e., even if ghci and many trivial >> command line programs can work without, MSys and MinGW turn out to be quiet >> necessary whenever trying to install anything producing side effect. Making >> it plain that these two are necessary would real come has a great time >> savers for newbie like me on windows (personal opinion of course). Or, if >> another path exists to go without these two, I'd be very glad to learn. >> Besides, even these tools basic installation is not enough, you need >> automake and various things of the like. That makes me wonder if the most >> precious skill for programming with Haskell would not be a strong C/C++ >> programming background. >> >> - In face of the difficulties with windows, I switched to Linux. While some >> things worked better, there were still lots of difficulties with package >> compilation. For instance, it is very difficult to figure out which Linux >> packages of a given distribution are needed for compiling this or that >> package. Again, gtk2hs is epitome here: which C development packages are >> needed to compile it is obscure at best (cairo, codeview, etc...). I ended >> up querying the Debian package management with any keyword found after >> running gtk2hs and randomly installing all the dev packages...And when >> gtk2hs finally compiled, it failed to install anyway. As of today, I've >> never been able to compile even the dumbest demo using gtk2hs whether on >> linux or on windows and whether using ghc 6.8.3 or 6.10.1. On windows, the >> automated setup install worked but did not allow me to compile with codeview >> and I still do not know how to add codeview to the install packages. Trust >> that I tried hard and read the docs thoroughly. Gtk2hs is just on of many >> examples; I had problems under Linux also with, e.g., Happs, yi, database >> things, etc. and figured out that the situation was roughly identical to >> windows with MSys and MinGW. So Linux appears not to be the right solution >> here. Maybe it's just that Linux users are more experienced with the GNU >> C/C++ libraries...but it won't help a windows user to switch to Linux since >> this knowledge can't be built out of thin air. >> >> - Would there be some binary version of cabal targeting various OSs? I >> believe the Haskell platform project is about that. But without waiting for >> a fair and objective selection of the packages (it seems to be the current >> status of the project), I'd be happy working with some authoritative bundle >> produced by a Haskell guru and would trust his subjective choices (who am I >> to question these choices anyway). Or even an image (e.g., virtual box or >> Xen) of a fully setup development environment since there are so many >> dependencies involved in, e.g., simply compiling GHC... >> >> Now, one might argue that these are not Haskell problems, that they are >> normal when dealing with non-mature packages. So let me explain why I've >> been trying hard to install these packages: >> >> As a beginner with no experience with emacs, I tried to find some IDE-like >> environment which would, at least, save me from manually reloading files in >> ghci or help me browse the source files. Following the Haskellwiki advice, >> that led to trying out Yi, Leksah, eclipsefp, or a Visual Studio extension. >> To this date, NOT ANY SINGLE ONE of these worked, be it on Linux or Windows. >> I had to resort to learning emacs which seems the only sensible choice >> available today. >> >> I am particularly unskilled, no question here. But, would a charitable soul >> take the pain of writing a comprehensive package management tutorial instead >> of a monad one, (s)he would have my deepest gratitude :) >> >> Apologies for the long mail. >> >> -Regis >> >> P.S. People on #haskell are wonderful. They helped me solve many issues. >> Unfortunately, solving specific instances of problem did not contribute much >> to a deeper understanding of the internal working. I find myself randomly >> trying things without knowing which would work or why; Hence this plea for a >> tutorial. >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> From andrewcoppin at btinternet.com Tue Jan 13 13:13:20 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Tue Jan 13 13:10:39 2009 Subject: [Haskell-cafe] unfoldr [ANN: HLint 1.2] In-Reply-To: <20090112214808.170b457d@greenrd.org> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <496A70D2.5020809@btinternet.com> <404396ef0901120033x3aca958btc3b7f35c02be29cf@mail.gmail.com> <496BA053.6020003@btinternet.com> <20090112214808.170b457d@greenrd.org> Message-ID: <496CD9C0.7060904@btinternet.com> Robin Green wrote: > On Mon, 12 Jan 2009 21:04:35 +0100 (CET) > Henning Thielemann wrote: > > >> On Mon, 12 Jan 2009, Andrew Coppin wrote: >> >> >>> convert b = unfoldr (\n -> if n > 0 then Just (n `mod` b, n `div` >>> b) else Nothing) >>> >> I have the nice function 'toMaybe' which simplifies this to: >> unfoldr (\n -> toMaybe (n>0) (n `mod` b, n `div` b)) >> > > I would use the more general idiom: > > unfoldr (\n -> guard (n > 0) >> return (n `mod` b, n `div` b) One of the wonderful things about Haskell is that almost any time anybody posts code, at least one person will think up an alternative but equivilent way of achieving the same goal - sometimes by radically different steps. Maybe we should have a name for this effect? From newsham at lava.net Tue Jan 13 13:21:09 2009 From: newsham at lava.net (Tim Newsham) Date: Tue Jan 13 13:12:41 2009 Subject: [Haskell-cafe] Re: Monads aren't evil? I think they are. In-Reply-To: <496BA800.90707@henning-thielemann.de> References: <20090108231652.24b75fe3@tritium.xx> <20090111111016.492d7dc9@tritium.xx> <496BA800.90707@henning-thielemann.de> Message-ID: > I have seen several libraries where all functions of a monad have the > monadic result (), e.g. Binary.Put and other writing functions. This is > a clear indicator, that the Monad instance is artificial and was only > chosen because of the 'do' notation. Maybe that was the initial reason, but I've actually found the Binary.Put.PutM (where Put = PutM ()) to be useful. Sometimes your putter does need to propogate a result... Tim Newsham http://www.thenewsh.com/~newsham/ From gour at mail.inet.hr Tue Jan 13 13:29:34 2009 From: gour at mail.inet.hr (Gour) Date: Tue Jan 13 13:20:33 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety References: <87eizkra83.fsf@nitai.hr> <20090108030656.GA4430@complete.org> <87hc48zv9g.fsf@nitai.hr> <49676DEC.9070208@complete.org> Message-ID: <87tz83vz3l.fsf@nitai.hr> >>>>> "John" == John Goerzen writes: John> That's great. Even better if accompanied by a patch ;-) Heh, one of the things which prevents me advancing with my own Haskell project is lack of enough skills to provide bindings for one C-lib and here I see the same pattern...It looks I have to cross it over :-) >> I'll e.g. open ticket for BLOB support :-D John> Of course :-) I did it - have you seen the notice about problems with HDBC-forums? John> Yes, I'm quite aware of that. Just not *my* particular ones ;-) OK. I'll try to, at least, come with some concrete proposal... Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/b1dfbe3f/attachment.bin From gour at mail.inet.hr Tue Jan 13 13:30:48 2009 From: gour at mail.inet.hr (Gour) Date: Tue Jan 13 13:26:16 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety References: <87eizkra83.fsf@nitai.hr> Message-ID: <87prirvz1j.fsf@nitai.hr> >>>>> "Mauricio" == Mauricio writes: Mauricio> I've been doing a lot of low level sqlite3 lately (it's going Mauricio> to be on a hackage package as soon as I finish my current Mauricio> work). Have you done any work with BLOBs? Mauricio> As long as I clearly isolate and test the marshalling of my Mauricio> data to SQL and back, my (personal, probably different from Mauricio> yours) experience using just sqlite3_exec has never got me Mauricio> into trouble. Thank you for your input. Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/5aa5080a/attachment.bin From RafaelGCPP.Linux at gmail.com Tue Jan 13 13:35:57 2009 From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto) Date: Tue Jan 13 13:27:56 2009 Subject: [Haskell-cafe] The problem with Monads... In-Reply-To: <1231867639.3917.9.camel@derek-laptop> References: <351ff25e0901130656k530348afj6633048d206d7f74@mail.gmail.com> <1231861860.17950.1.camel@jonathans-macbook> <16442B752A06A74AB4D9F9A5FF076E4B4DCAE8@ELON17P32001A.csfb.cs-group.com> <1231867639.3917.9.camel@derek-laptop> Message-ID: <351ff25e0901131035r16bdd19did9cce96e70d4352c@mail.gmail.com> I didn't knew Wadler's papers (I save all papers I read into a external USB HD, so I can read them later!), and at a first glance it is really good. Then again, instead of creating another "monad tutorial", what about a Haskell monads reference guide, and some worked examples? Some of this work could even be attached to the library documentation. Regards Rafael On Tue, Jan 13, 2009 at 15:27, Derek Elkins wrote: > On Tue, 2009-01-13 at 16:22 +0000, Sittampalam, Ganesh wrote: > > Jonathan Cast wrote: > > > On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira > > > Pinto wrote: > > >> > > >> Inspired by the paper "Functional Programming with Overloading and > > >> Higher-Order Polymorphism", Mark P Jones > > >> (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html > ) > > >> Advanced School of Functional Programming, 1995. > > >> > > >> SO WHAT? > > > > > > So have you read Jones' paper? Or do you have a *concrete* > > > explanation of how it differs from your desired `guided tour'? > > > > To give a specific example, a few weeks ago I wanted an explanation of > > the 'pass' function and couldn't find it in that paper. > > > > Ganesh > > Several years ago I documented all the (basic) monads in the mtl on the > (old) wiki. > > http://web.archive.org/web/20030927210146/haskell.org/hawiki/MonadTemplateLibrary > In particular, > http://web.archive.org/web/20030907203223/haskell.org/hawiki/MonadWriter > > > To respond to the essential point of Rafael's initial claim, Wadler's > papers "The Essence of Functional Programming" and/or "Monads for > Functional Programming" have exactly what he wants. These are the > papers that I recommend to anyone who is learning about monads. > http://homepages.inf.ed.ac.uk/wadler/topics/monads.html > > Please, we do not need the 101st monad tutorial when there was an > adequate one made almost two decades ago. While I'm not saying that > this is the case here, I suspect that many people don't read those > papers because 1) they haven't heard of them and 2) they are "papers" > and thus couldn't possibly be readable and understandable (which also > partially causes (1) as people just don't think to look for papers at > all.) > > -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/d07b0868/attachment.htm From jgoerzen at complete.org Tue Jan 13 13:37:45 2009 From: jgoerzen at complete.org (John Goerzen) Date: Tue Jan 13 13:28:59 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety In-Reply-To: <87tz83vz3l.fsf@nitai.hr> References: <87eizkra83.fsf@nitai.hr> <20090108030656.GA4430@complete.org> <87hc48zv9g.fsf@nitai.hr> <49676DEC.9070208@complete.org> <87tz83vz3l.fsf@nitai.hr> Message-ID: <496CDF79.3030205@complete.org> Gour wrote: >>>>>> "John" == John Goerzen writes: > > John> That's great. Even better if accompanied by a patch ;-) > > Heh, one of the things which prevents me advancing with my own Haskell > project is lack of enough skills to provide bindings for one C-lib and > here I see the same pattern...It looks I have to cross it over :-) > >>> I'll e.g. open ticket for BLOB support :-D > > John> Of course :-) > > I did it - have you seen the notice about problems with HDBC-forums? Yes. I am thoroughly displeased with Ruby on Rails at the moment. It is less maintainable than a network of DOS boxes. There are a host of mysterious crashes in Redmine at the moment -- including one where pulling up the page for one specific bug (but none others) crashes the server. I could upgrade Redmine, but that requires a Ruby stack that is partly newer than what's in Debian, and the upgrade for that process appears to succeed, but then fails in mysterious ways at the end. To anyone annoyed with Haskell's library install process: you have no idea how good you have it unless you've tried Ruby and rails. -- John From manlio_perillo at libero.it Tue Jan 13 13:50:17 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Tue Jan 13 13:41:53 2009 Subject: [Haskell-cafe] Re: [Haskell] ANN: ghci-haskeline 0.1 In-Reply-To: <6d74b0d20901130702w219bc3d3r951c610651666614@mail.gmail.com> References: <6d74b0d20901121257q19b953cft2c8dc54b98809ef5@mail.gmail.com> <20090112214103.GW13626@knuth.cs.hmc.edu> <20090112222851.GX13626@knuth.cs.hmc.edu> <6d74b0d20901130702w219bc3d3r951c610651666614@mail.gmail.com> Message-ID: <496CE269.7010003@libero.it> Judah Jacobson ha scritto: > [...] >> >> (For those interested: rlwrap is available in cygwin. >> It used to work very well on old ghci, when line >> editing wasn't available.) > > This does sound useful; the main difficulty is that when a program has > stdin piped from another process it may behaved differently. For > example, ghci uses block buffering and doesn't print its prompt when > stdin doesn't appear to be a terminal. The solution on POSIX is > probably to use some sort of pseudo-terminal support; I don't know > what the right thing to do on Windows is. > On Windows you can create a Console object: http://msdn.microsoft.com/en-us/library/ms682087.aspx Regards Manlio Perillo From colinpauladams at googlemail.com Tue Jan 13 13:57:09 2009 From: colinpauladams at googlemail.com (Colin Adams) Date: Tue Jan 13 13:48:22 2009 Subject: [Haskell-cafe] unfoldr [ANN: HLint 1.2] In-Reply-To: <496CD9C0.7060904@btinternet.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <496A70D2.5020809@btinternet.com> <404396ef0901120033x3aca958btc3b7f35c02be29cf@mail.gmail.com> <496BA053.6020003@btinternet.com> <20090112214808.170b457d@greenrd.org> <496CD9C0.7060904@btinternet.com> Message-ID: <1afdeaec0901131057p24f83fa2y577a41f74ab3edd5@mail.gmail.com> 2009/1/13 Andrew Coppin : > One of the wonderful things about Haskell is that almost any time anybody > posts code, at least one person will think up an alternative but equivilent > way of achieving the same goal - sometimes by radically different steps. > > Maybe we should have a name for this effect? Confusion. From phercek at gmail.com Tue Jan 13 14:27:24 2009 From: phercek at gmail.com (Peter Hercek) Date: Tue Jan 13 14:18:47 2009 Subject: [Haskell-cafe] Re: Arch Haskell News: Jan 11 2009 In-Reply-To: <20090111223053.GA1296@scytale.galois.com> References: <20090111223053.GA1296@scytale.galois.com> Message-ID: Hi, Any idea why ghc 6.10.1 is still in Testing repository on archlinux? Peter. Don Stewart wrote: > Arch Haskell News: Jan 11 2009 <--cut--> From jgoerzen at complete.org Tue Jan 13 14:43:05 2009 From: jgoerzen at complete.org (John Goerzen) Date: Tue Jan 13 14:34:22 2009 Subject: [Haskell-cafe] unfoldr [ANN: HLint 1.2] In-Reply-To: <1afdeaec0901131057p24f83fa2y577a41f74ab3edd5@mail.gmail.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <496A70D2.5020809@btinternet.com> <404396ef0901120033x3aca958btc3b7f35c02be29cf@mail.gmail.com> <496BA053.6020003@btinternet.com> <20090112214808.170b457d@greenrd.org> <496CD9C0.7060904@btinternet.com> <1afdeaec0901131057p24f83fa2y577a41f74ab3edd5@mail.gmail.com> Message-ID: <496CEEC9.2070403@complete.org> Colin Adams wrote: > 2009/1/13 Andrew Coppin : > >> One of the wonderful things about Haskell is that almost any time anybody >> posts code, at least one person will think up an alternative but equivilent >> way of achieving the same goal - sometimes by radically different steps. >> >> Maybe we should have a name for this effect? > > Confusion. Ah, so Haskell is completely reducible to Perl then? ;-) From alexott at gmail.com Tue Jan 13 14:47:49 2009 From: alexott at gmail.com (Alex Ott) Date: Tue Jan 13 14:39:35 2009 Subject: [Haskell-cafe] ANN: json-0.4.1 In-Reply-To: <496C12C3.4020500@gmail.com> (Sigbjorn Finne's message of "Mon, 12 Jan 2009 20:04:19 -0800") References: <496C12C3.4020500@gmail.com> Message-ID: Hello >>>>> "SF" == Sigbjorn Finne writes: SF> Hi, a new release of the 'json' package is now available via hackage, SF> version 0.4.1 SF> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/json I tried to upgrade it via cabal on mac os x & linux (both use ghc 6.10.1) and it fails with Building json-0.4.1... Text/JSON/Generic.hs:33:7: Could not find module `Data.Generics': it was found in multiple packages: base-3.0.3.0 syb cabal: Error: some packages failed to install: json-0.4.1 failed during the building phase. The exception was: exit: ExitFailure 1 -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/ http://xtalk.msk.su/~ott/ http://alexott-ru.blogspot.com/ From dmehrtash at gmail.com Tue Jan 13 14:49:31 2009 From: dmehrtash at gmail.com (Daryoush Mehrtash) Date: Tue Jan 13 14:40:44 2009 Subject: [Haskell-cafe] Adding Authentication and Authorization to a service implemented in Haskell Message-ID: I am trying to figure out a clean way to add authentication and authorization in a webservice. The services of the web services are implemented as Haskell functions. The request to the service contains the user authentication information. I want to authenticate the user by verifying his authentication informaton, assign him roles, and then based on the roles decide on the functions and data that he can have access too. Is there a clean way to do this in Haskell? Thanks Daryoush -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/8ceb9f87/attachment.htm From briqueabraque at yahoo.com Tue Jan 13 14:50:56 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Tue Jan 13 14:42:28 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety In-Reply-To: <87prirvz1j.fsf@nitai.hr> References: <87eizkra83.fsf@nitai.hr> <87prirvz1j.fsf@nitai.hr> Message-ID: > Mauricio> I've been doing a lot of low level sqlite3 lately (it's going > Mauricio> to be on a hackage package as soon as I finish my current > Mauricio> work). > > Have you done any work with BLOBs? > No. Only sqlite3_exec with INSERT, SELECT stuff, and saving everything that needs structure in pseudo-xml strings. Not that efficient, but easy to change to blobs when everything is ready and tested. Maur?cio From v.dijk.bas at gmail.com Tue Jan 13 14:58:22 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Tue Jan 13 14:49:35 2009 Subject: [Haskell-cafe] ANN: json-0.4.1 In-Reply-To: References: <496C12C3.4020500@gmail.com> Message-ID: On Tue, Jan 13, 2009 at 8:47 PM, Alex Ott wrote: > Hello > >>>>>> "SF" == Sigbjorn Finne writes: > SF> Hi, a new release of the 'json' package is now available via hackage, > SF> version 0.4.1 > > SF> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/json > > I tried to upgrade it via cabal on mac os x & linux (both use ghc 6.10.1) > and it fails with > > Building json-0.4.1... > > Text/JSON/Generic.hs:33:7: > Could not find module `Data.Generics': > it was found in multiple packages: base-3.0.3.0 syb > cabal: Error: some packages failed to install: > json-0.4.1 failed during the building phase. The exception was: > exit: ExitFailure 1 The standard solution for this is to add a cabal flag that controls wether to depend on base-4 or base-3: ------------------------------------------------------ flag small_base description: Choose the new smaller, split-up base package. Library if flag(small_base) Build-Depends: base == 4.*, syb CPP-Options: -DBASE_4 else Build-Depends: base == 3.* ------------------------------------------------------ And use some CPP in your modules like this: ------------------------------------------------------ {-# LANGUAGE CPP #-} #ifdef BASE_4 import Data.Data (Data) #else import Data.Generics (Data) #endif ------------------------------------------------------ See for example how I do it in http://code.haskell.org/Stream regards, Bas From gour at mail.inet.hr Tue Jan 13 15:02:25 2009 From: gour at mail.inet.hr (Gour) Date: Tue Jan 13 14:53:26 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety References: <87eizkra83.fsf@nitai.hr> <20090108030656.GA4430@complete.org> <87hc48zv9g.fsf@nitai.hr> <49676DEC.9070208@complete.org> <87tz83vz3l.fsf@nitai.hr> <496CDF79.3030205@complete.org> Message-ID: <87eiz77z5a.fsf@nitai.hr> >>>>> "John" == John Goerzen writes: John> Yes. I am thoroughly displeased with Ruby on Rails at the moment. John> It is less maintainable than a network of DOS boxes. There are a John> host of mysterious crashes in Redmine at the moment -- including John> one where pulling up the page for one specific bug (but none John> others) crashes the server. I liked the look of Redmine when trying it out, but after installing RoR, I quickly forgot it and put Roundup on one server. Now, while still waiting if something will come out of DarcForge, I'll use LP. John> To anyone annoyed with Haskell's library install process: you have John> no idea how good you have it unless you've tried Ruby and rails. I can understand you hoping you will find a better solution in the future. Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/6dc67e57/attachment.bin From gour at mail.inet.hr Tue Jan 13 15:08:43 2009 From: gour at mail.inet.hr (Gour) Date: Tue Jan 13 14:59:48 2009 Subject: [Haskell-cafe] Re: [ANN] Working with HLint from Emacs References: Message-ID: <878wpf7yus.fsf@nitai.hr> >>>>> "Alex" == Alex Ott writes: Alex> Hello For Emacs users it could be interesting - I wrote small Alex> module for more comfortable work with HLint from Emacs. It has Alex> same functionality as compilation-mode - navigation between Alex> errors, etc. Thank you for it. Alex> Module is available from Alex> http://xtalk.msk.su/~ott/common/emacs/hs-lint.el Module is not under some dvcs? Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/be3ebedf/attachment.bin From gour at mail.inet.hr Tue Jan 13 15:15:33 2009 From: gour at mail.inet.hr (Gour) Date: Tue Jan 13 15:06:30 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety References: <87eizkra83.fsf@nitai.hr> <495F6C07.5050006@henning-thielemann.de> <871vvkqyao.fsf@nitai.hr> Message-ID: <874p037yje.fsf@nitai.hr> >>>>> "Johannes" == Johannes Waldmann writes: Johannes> see Johannes> http://article.gmane.org/gmane.comp.lang.haskell.libraries/10490 Thanks. Is it just a 'fix' or HSQL will be properly maintained as well? Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/a46f5493/attachment.bin From gour at mail.inet.hr Tue Jan 13 15:17:30 2009 From: gour at mail.inet.hr (Gour) Date: Tue Jan 13 15:11:17 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety References: <87eizkra83.fsf@nitai.hr> <87prirvz1j.fsf@nitai.hr> Message-ID: <87zlhv6jvp.fsf@nitai.hr> >>>>> "Mauricio" == Mauricio writes: Mauricio> No. Only sqlite3_exec with INSERT, SELECT stuff, Mauricio> and saving everything that needs structure in pseudo-xml Mauricio> strings. Not that efficient, but easy to change to blobs when Mauricio> everything is ready and tested. I see...I'm thinking to maybe store only paths for bigger BLOBs, but still there is need to store smaller (thumbnails pics) ones... Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/61fcf8ff/attachment.bin From mle+cl at mega-nerd.com Tue Jan 13 15:58:37 2009 From: mle+cl at mega-nerd.com (Erik de Castro Lopo) Date: Tue Jan 13 15:49:53 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <20090113171336.GD6699@scytale.galois.com> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <10ed1a750901130821m9b3e8fev2528a0877ebf6be1@mail.gmail.com> <20090113171336.GD6699@scytale.galois.com> Message-ID: <20090114075837.f78b3a56.mle+cl@mega-nerd.com> Don Stewart wrote: > Well, the number one thing is to use Cabal and the cabal-install tool. > That is the simplest way to avoid headaches. I'm sure cabal works very well for many people, but for anyone who has used Debian based distributions for some time, cabal really does seem like a backward step. For instance, I regularly develop on 6 machines; personal laptop, home desktop, 2 work desktops and 2 work build machines. At work, the main output of my development work is Debian packages (which get installed on hundreds of machines), and the Debian packages I create have build depends on whatever compilers and libraries are required to build them. We also have a build bot that runs nightly in a clean chroot for each package so that build depends can be verified to be correct. However, if I install compilers or libraries using cabal there is no package to build depend on, breaking a system which currently works very, very well for all the code we build in C, C++ and Ocaml. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "Arguing that Java is better than C++ is like arguing that grasshoppers taste better than tree bark." -- Thant Tessman From porges at porg.es Tue Jan 13 16:28:41 2009 From: porges at porg.es (George Pollard) Date: Tue Jan 13 16:20:12 2009 Subject: [Haskell-cafe] unfoldr [ANN: HLint 1.2] In-Reply-To: <20090112214808.170b457d@greenrd.org> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <496A70D2.5020809@btinternet.com> <404396ef0901120033x3aca958btc3b7f35c02be29cf@mail.gmail.com> <496BA053.6020003@btinternet.com> <20090112214808.170b457d@greenrd.org> Message-ID: <1231882121.7180.9.camel@porges-laptop> On Mon, 2009-01-12 at 21:48 +0000, Robin Green wrote: > > > convert b = unfoldr (\n -> if n > 0 then Just (n `mod` b, n `div` > > > b) else Nothing) > > > > I have the nice function 'toMaybe' which simplifies this to: > > unfoldr (\n -> toMaybe (n>0) (n `mod` b, n `div` b)) > > I would use the more general idiom: > > unfoldr (\n -> guard (n > 0) >> return (n `mod` b, n `div` b)) I have the equivalent in my ?useful functions?: > ifM p x = if p then return x else mzero -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/ef0d9c48/attachment.bin From hjgtuyl at chello.nl Tue Jan 13 16:57:55 2009 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Tue Jan 13 16:49:11 2009 Subject: [Haskell-beginners] Re: [Haskell-cafe] The problem with Monads... In-Reply-To: <351ff25e0901131035r16bdd19did9cce96e70d4352c@mail.gmail.com> References: <351ff25e0901130656k530348afj6633048d206d7f74@mail.gmail.com> <1231861860.17950.1.camel@jonathans-macbook> <16442B752A06A74AB4D9F9A5FF076E4B4DCAE8@ELON17P32001A.csfb.cs-group.com> <1231867639.3917.9.camel@derek-laptop> <351ff25e0901131035r16bdd19did9cce96e70d4352c@mail.gmail.com> Message-ID: On Tue, 13 Jan 2009 19:35:57 +0100, Rafael Gustavo da Cunha Pereira Pinto wrote: > I didn't knew Wadler's papers (I save all papers I read into a external > USB > HD, so I can read them later!), and at a first glance it is really good. > > > Then again, instead of creating another "monad tutorial", what about a > Haskell monads reference guide, and some worked examples? > > Some of this work could even be attached to the library documentation. > > Regards > > Rafael > I have written a reference manual for the basic Haskell monad functions, "A Tour of the Haskell Monad functions". It contains a lot of examples. You can find it at: http://members.chello.nl/hjgtuyl/tourdemonad.html As far as I know, there is no reference guide for advanced monads, like the Reader, Writer and State monads. -- Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- From dons at galois.com Tue Jan 13 17:08:19 2009 From: dons at galois.com (Don Stewart) Date: Tue Jan 13 16:59:15 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <20090114075837.f78b3a56.mle+cl@mega-nerd.com> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <10ed1a750901130821m9b3e8fev2528a0877ebf6be1@mail.gmail.com> <20090113171336.GD6699@scytale.galois.com> <20090114075837.f78b3a56.mle+cl@mega-nerd.com> Message-ID: <20090113220819.GC7815@scytale.galois.com> mle+cl: > Don Stewart wrote: > > > Well, the number one thing is to use Cabal and the cabal-install tool. > > That is the simplest way to avoid headaches. > > I'm sure cabal works very well for many people, but for anyone who > has used Debian based distributions for some time, cabal really > does seem like a backward step. > > For instance, I regularly develop on 6 machines; personal laptop, > home desktop, 2 work desktops and 2 work build machines. > > At work, the main output of my development work is Debian packages > (which get installed on hundreds of machines), and the Debian packages > I create have build depends on whatever compilers and libraries are > required to build them. We also have a build bot that runs nightly > in a clean chroot for each package so that build depends can be > verified to be correct. > > However, if I install compilers or libraries using cabal there is > no package to build depend on, breaking a system which currently > works very, very well for all the code we build in C, C++ and > Ocaml. I encourage *strongly* the Debian community to package up hackage packages natively, as we have done on Gentoo and Arch. (This can be automated, in fact, see cabal2arch). cabal-install will work on any system. If you have particular distro requirements, consider distro-specific package tools. -- Don From byorgey at seas.upenn.edu Tue Jan 13 17:09:19 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Tue Jan 13 17:00:32 2009 Subject: [Haskell-cafe] ANN: split-0.1.1 (doc bugfix; new functions wordsBy and linesBy) Message-ID: <20090113220919.GB1232@seas.upenn.edu> Version 0.1.1 of the split library is now on Hackage, which provides a wide range of strategies and a unified combinator framework for splitting lists with respect to some sort of delimiter. This version: * fixes a couple Haddock bugs that were preventing the documentation from building on Hackage, and * adds two new convenience functions suggested by Neil Mitchell, wordsBy and linesBy, such that words === wordsBy isSpace lines === linesBy (=='\n'). Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/split darcs: http://code.haskell.org/~byorgey/code/split -Brent From waldmann at imn.htwk-leipzig.de Tue Jan 13 17:11:31 2009 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Tue Jan 13 17:02:51 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety References: <87eizkra83.fsf@nitai.hr> <495F6C07.5050006@henning-thielemann.de> <871vvkqyao.fsf@nitai.hr> <874p037yje.fsf@nitai.hr> Message-ID: > Johannes> http://article.gmane.org/gmane.comp.lang.haskell.libraries/10490 > Is it just a 'fix' or HSQL will be properly maintained as well? Just a fix for Setup.hs and *.cabal, and no changes to the real code (w.r.t. version -1.7 presently available from hackage) J.W. From vigalchin at gmail.com Tue Jan 13 17:12:31 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Tue Jan 13 17:03:43 2009 Subject: [Haskell-cafe] ByteString intercalate semantics?? Message-ID: <5ae4f2ba0901131412s368b098fp49442114b99c6e5f@mail.gmail.com> Hello, From Hoogle (my friend) .... *intercalate* :: ByteString-> [ ByteString] -> ByteString Source *O(n)* The intercalatefunction takes a ByteStringand a list of ByteStrings and concatenates the list after interspersing the first argument between each element of the list. So intercalate doesn't do a simple concatenation? Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/3b106067/attachment.htm From magnus at therning.org Tue Jan 13 17:14:03 2009 From: magnus at therning.org (Magnus Therning) Date: Tue Jan 13 17:05:27 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <20090113220819.GC7815@scytale.galois.com> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <10ed1a750901130821m9b3e8fev2528a0877ebf6be1@mail.gmail.com> <20090113171336.GD6699@scytale.galois.com> <20090114075837.f78b3a56.mle+cl@mega-nerd.com> <20090113220819.GC7815@scytale.galois.com> Message-ID: <496D122B.9060403@therning.org> Don Stewart wrote: > mle+cl: >> Don Stewart wrote: >> >>> Well, the number one thing is to use Cabal and the cabal-install tool. >>> That is the simplest way to avoid headaches. >> I'm sure cabal works very well for many people, but for anyone who >> has used Debian based distributions for some time, cabal really >> does seem like a backward step. >> >> For instance, I regularly develop on 6 machines; personal laptop, >> home desktop, 2 work desktops and 2 work build machines. >> >> At work, the main output of my development work is Debian packages >> (which get installed on hundreds of machines), and the Debian packages >> I create have build depends on whatever compilers and libraries are >> required to build them. We also have a build bot that runs nightly >> in a clean chroot for each package so that build depends can be >> verified to be correct. >> >> However, if I install compilers or libraries using cabal there is >> no package to build depend on, breaking a system which currently >> works very, very well for all the code we build in C, C++ and >> Ocaml. > > I encourage *strongly* the Debian community to package up hackage > packages natively, as we have done on Gentoo and Arch. > > (This can be automated, in fact, see cabal2arch). > > cabal-install will work on any system. If you have particular distro > requirements, consider distro-specific package tools. Get on the debian-haskell list to discuss this! I've looked into it myself, but got stuck on a severely outdated haddock package. That won't be fixed until GHC 6.10 makes it into experimental or unstable :-( /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?org http://therning.org/magnus Haskell is an even 'redder' pill than Lisp or Scheme. -- PaulPotts -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/0bb99d4b/signature.bin From dons at galois.com Tue Jan 13 17:17:49 2009 From: dons at galois.com (Don Stewart) Date: Tue Jan 13 17:08:47 2009 Subject: [Haskell-cafe] ByteString intercalate semantics?? In-Reply-To: <5ae4f2ba0901131412s368b098fp49442114b99c6e5f@mail.gmail.com> References: <5ae4f2ba0901131412s368b098fp49442114b99c6e5f@mail.gmail.com> Message-ID: <20090113221749.GD7815@scytale.galois.com> vigalchin: > Hello, > > From Hoogle (my friend) .... > > intercalate :: [1]ByteString -> [[2]ByteString] -> [3]ByteString [4]Source > O(n) The [5]intercalate function takes a [6]ByteString and a list of > [7]ByteStrings and concatenates the list after interspersing the first > argument between each element of the list. > So intercalate doesn't do a simple concatenation? FWIW. concat . intersperse x == intercalate x -- Don From ketil at malde.org Tue Jan 13 17:26:49 2009 From: ketil at malde.org (Ketil Malde) Date: Tue Jan 13 17:17:29 2009 Subject: [Haskell-cafe] unfoldr [ANN: HLint 1.2] In-Reply-To: <1afdeaec0901131057p24f83fa2y577a41f74ab3edd5@mail.gmail.com> (Colin Adams's message of "Tue\, 13 Jan 2009 18\:57\:09 +0000") References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <496A70D2.5020809@btinternet.com> <404396ef0901120033x3aca958btc3b7f35c02be29cf@mail.gmail.com> <496BA053.6020003@btinternet.com> <20090112214808.170b457d@greenrd.org> <496CD9C0.7060904@btinternet.com> <1afdeaec0901131057p24f83fa2y577a41f74ab3edd5@mail.gmail.com> Message-ID: <877i4y6dw6.fsf@malde.org> "Colin Adams" writes: >> One of the wonderful things about Haskell is that almost any time anybody >> posts code, at least one person will think up an alternative but equivilent >> way of achieving the same goal - sometimes by radically different steps. >> Maybe we should have a name for this effect? > Confusion. Golfusion? -k -- If I haven't seen further, it is by standing in the footprints of giants From pbeadling at mail2web.com Tue Jan 13 17:29:02 2009 From: pbeadling at mail2web.com (Phil) Date: Tue Jan 13 17:24:12 2009 Subject: [Haskell-cafe] Multiple State Monads In-Reply-To: <49a77b7a0901121913y75bcc3c3uadcb7e76b1fdb1a8@mail.gmail.com> Message-ID: Many thanks for the replies. Using 'modify' cleans the syntax up nicely. With regard to using 'iterate' as shown by David here: >> mcSimulate :: Double -> Double -> Word64 -> [Double] >> mcSimulate startStock endTime seedForSeed = fst expiryStock : mcSimulate >> startStock endTime newSeedForSeed >> where >> expiryStock = iterate evolveUnderlying (startStock, ranq1Init seedForSeed) >> !! truncate (endTime/timeStep) >> newSeedForSeed = seedForSeed + 246524 My only concern with using this method is - Will 'iterate' not create a full list of type [Double] and then take the final position once the list has been fully realized? For my application this would be undesirable as the list may be millions of items long, and you only ever care about the last iteration (It's a crude Monte Carlo simulator to give it some context). If Haskell is smart enough to look ahead and see as we only need the last element as it is creating the list, therefore garbage collecting earlier items then this would work fine - by I'm guessing that is a step to far for the compiler? I had originally implemented this similar to the above (although I didn't know about the 'iterate' keyword - which makes things tidier - a useful tip!), I moved to using the state monad and replicateM_ for the first truncate(endTime/timeStep)-1 elements so that everything but the last result is thrown away, and a final bind to getEvolution would return the result. Now that the code has been modified so that no result is passed back, using modify and execState, this can be simplified to "replicateM_ truncate(endTime/timeStep)" with no final bind needed. I've tried this and it works fine. The key reason for using the Monad was to tell Haskell to discard all but the current state. If I'm wrong about please let me know, as I don't want to be guilty of overcomplicating my algorithm, and more importantly it means I'm not yet totally grasping the power of Haskell! Thanks again, Phil. On 13/01/2009 03:13, "David Menendez" wrote: > On Mon, Jan 12, 2009 at 8:34 PM, Phil wrote: >> Thanks Minh - I've updated my code as you suggested. This looks better than >> my first attempt! >> >> Is it possible to clean this up any more? I find: >> >> ( (), (Double, Word64) ) >> >> a bit odd syntactically, although I understand this is just to fit the type >> to the State c'tor so that we don't have to write our own Monad longhand. > > If you have a function which transforms the state, you can lift it > into the state monad using "modify". > >> evolveUnderlying :: (Double, Word64) -> (Double, Word64) >> evolveUnderlying (stock, state) = ( newStock, newState ) >> where >> newState = ranq1Increment state >> newStock = stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep + ( >> vol*sqrt(timeStep)*normalFromRngState(state) ) ) >> >> getEvolution :: State (Double, Word64) () >> getEvolution = modify evolveUnderlying > > Now, I don't know the full context of what you're doing, but the > example you posted isn't really gaining anything from the state monad. > Specifically, > > execState (replicateM_ n (modify f)) > = execState (modify f >> modify f >> ... >> modify f) > = execState (modify (f . f . ... . f)) > = f . f . ... . f > > So you could just write something along these lines, > >> mcSimulate :: Double -> Double -> Word64 -> [Double] >> mcSimulate startStock endTime seedForSeed = fst expiryStock : mcSimulate >> startStock endTime newSeedForSeed >> where >> expiryStock = iterate evolveUnderlying (startStock, ranq1Init seedForSeed) >> !! truncate (endTime/timeStep) >> newSeedForSeed = seedForSeed + 246524 > > > Coming back to your original question, it is possible to work with > nested state monad transformers. The trick is to use "lift" to make > sure you are working with the appropriate state. > > get :: StateT s1 (State s2) s1 > put :: s1 -> StateT s1 (State s2) () > > lift get :: StateT s1 (State s2) s2 > lift put :: s2 -> StateT s1 (State s2) () > > A more general piece of advice is to try breaking things into smaller > pieces. For example: > > getRanq1 :: MonadState Word64 m => m Word64 > getRanq1 = do > seed <- get > put (ranq1Increment seed) > return seed > > getEvolution :: StateT Double (State Word64) () > getEvolution = do > seed <- lift getRanq1 > modify $ \stock -> stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep > + ( vol*sqrt(timeStep)*normalFromRngState(seed) ) ) > From lrpalmer at gmail.com Tue Jan 13 17:51:09 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Jan 13 17:42:21 2009 Subject: [Haskell-cafe] Re: Monads aren't evil? I think they are. In-Reply-To: References: <20090108231652.24b75fe3@tritium.xx> <20090111111016.492d7dc9@tritium.xx> <496BA800.90707@henning-thielemann.de> Message-ID: <7ca3f0160901131451k79bc6a6oc27bfb5dff276079@mail.gmail.com> On Tue, Jan 13, 2009 at 11:21 AM, Tim Newsham wrote: > I have seen several libraries where all functions of a monad have the >> monadic result (), e.g. Binary.Put and other writing functions. This is >> a clear indicator, that the Monad instance is artificial and was only >> chosen because of the 'do' notation. >> > > Maybe that was the initial reason, but I've actually found the > Binary.Put.PutM (where Put = PutM ()) to be useful. Sometimes > your putter does need to propogate a result... But that's the whole point of Writer! Take a monoid, make it into a monad. Put as a monad is silly. Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/f633c3fe/attachment.htm From jgoerzen at complete.org Tue Jan 13 17:51:34 2009 From: jgoerzen at complete.org (John Goerzen) Date: Tue Jan 13 17:42:48 2009 Subject: [Haskell-cafe] Request for help testing HDBC-postgresql Message-ID: <496D1AF6.8050901@complete.org> Hi folks, I've pushed to the Git repo a bunch of new code for HDBC-postgresql. Specifically, it: 1) Removes autoconf in favor of Duncan's Setup.lhs that should work on all combinations of GHC 6.8, GHC 6.10, POSIX, and Windows 2) Adds support for UTF-8 encoding of strings 3) Adds support for translation of dates/times into a PostgreSQL format I would appreciate people testing it on GHC 6.8, 6.10, and Windows before I upload it to hackage. Please reply with thumbs up/thumbs down. Get it with: git clone git://git.complete.org/hdbc-postgresql Thanks! - John From manlio_perillo at libero.it Tue Jan 13 17:54:53 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Tue Jan 13 17:46:11 2009 Subject: [Haskell-cafe] walking a directory tree efficiently Message-ID: <496D1BBD.8060101@libero.it> Hi. During a tentative (quite unsuccessfull) to convert a simple Python script that prints on stdout a directory and all its subdirectory [1] in a good Haskell (mostly to start to do real practice with the language), I came across this blog post: http://blog.moertel.com/articles/2007/03/28/directory-tree-printing-in-haskell-part-three-lazy-i-o Since recently I read about alternatives to lazy IO (like iteratee), I'm curious to know if a flexible, efficient and safe alternative exists, for the task of display a directory tree. [1] http://paste.pocoo.org/show/99523/ Thanks Manlio perillo From duncan.coutts at worc.ox.ac.uk Tue Jan 13 18:05:50 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 13 17:57:05 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <027A7D7FCDF44376AC625F076AD23870@createnet.org> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> Message-ID: <1231887950.28590.235.camel@localhost> On Tue, 2009-01-13 at 16:33 +0100, Regis Saint-Paul wrote: > Hi, > > I?ve seen many times the monad topic coming around on the cafe and plentiful > tutorials on monads have been published. However, as a complete Haskell > newbie coming from OOP, I felt monads were not particularly difficult to > grasp, and very exciting to work with. > > During my experiments with Haskell so far, the main problems I kept bumping > into were not related to the language but to its libraries: their > compilation and installation. Unfortunately, this topic has not received > nearly as much attention. I was unable to find a comprehensive tutorial on > how to deal with the variety of problems I get when trying to install > Hackage packages. This turned out to be (and still is) THE main source of > wasted time and headaches. And worse, unlike type problems, these are not > interesting ones to solve. You're right, we've only been actively working on this for the last couple years. The tools are not yet as good as we would like them to be. Unfortunately as you say the problem does not interest a lot of people. So it is "good enough" for lots of people and we do not have quite enough people working on the package infrastructure to make it really great as quickly as we'd like. Of course it's not for lack of ideas or suggestions, we've got a huge TODO list! :-) Let me add a plug for our resources for new Cabal hackers: http://hackage.haskell.org/trac/hackage/ There's a source code guide, an "easy ticket" list, a link to the development mailing list and instructions on how to get the code. New hackers are most welcome! :-) > Thus, as a beginner, the package management is what is really getting in the > way of switching to Haskell--not the language. Even books like Real World > Haskell (otherwise excellent) ignore entirely the topic. In fairness I think it does mention Cabal and cabal-install. But it does not go into a lot of detail I admit. At the time they were writing that cabal-install had only just got to the stage of being usable (the authors had to slightly make a guess as to whether this "cabal-install" thing was going to become popular). It's still pretty young software. > Cabal and Cabal-install are clearly wonderful applications that make > installing most packages very straightforward. Phew! That's a big improvement. It used to be universally hard to install packages, and there were many fewer packages around because they used to be so hard to make. > Unfortunately, whenever this "standard" method for package > installation fails (or when it is not available as with, e.g., > gtk2hs), I find myself in complete disarray. Yes, that is a serious problem. > Below are some of the questions and issues I faced regarding package > management: > > - For a number of packages, cabal-install gets stuck and has to be killed. Assuming you are using the latest version (0.6.0) this should never happen. If it does please report bugs with details on how to reproduce the problem. I'm the maintainer of Cabal so email me or add tickets in our bug tracker: http://hackage.haskell.org/trac/hackage/ If it gets stuck building the package then that's a slightly different issue. Either way, more information would help in diagnosing what is going on. It is certainly not expected behaviour. > I assume this is due to some difficulties in solving the dependencies and it > is fine, not all can be automated and cabal-install is not responsible for > poor packages. But the question then becomes what to do from there? Is their > some method to solve dependencies? How should we proceed to "debug" a > package installation? How do gurus deal with that? (maybe some less known > command line arguments? Or ways to figure out the problem and work out its > solution (cabal-install is silent in such case)? In particular, how to know > why did cabal get stuck in the first place? cabal install --dry-run -v This produces quite a bit of information about what the dependency resolver is doing, especially in the latest version. I've not had the situation where it sometimes fails to terminate. The only infinite loop bug it has ever had (as far as I am aware) is when cabal-install version 0.5.x is used with ghc-6.10. In that case it always fails to terminate, it does not matter what package. So like I said, if you are getting non-termination in the solver we need more details. What does happen sometimes is that the solver cannont find a solution. In this case you can look at the error message and perhaps the output of --dry-run -v and try adding constraints to give it some help on what versions of packages to pick, for example: cabal install --dry-run -v 'foo < 2' 'bar == 1.2.0' > - Some packages on Hackage are reported as not building successfully with > GHC6.10 (e.g., encoding) while others do not build with 6.8 (e.g., salvia) > and the later might depend on the former...What is one supposed to do in > such case? Note that the hackage build results are not very accurate at the moment. They can fail for a number of reasons that would not prevent you from making it work on your own machine. If the package really does not build with the version of ghc you have then either try a different version of the package (in the case that the latest one works with ghv 6.10 but you want to use ghc 6.8). You may of course find packages that need patching before they will work with 6.10. In such cases if you cannot patch them yourself then email the maintainer and tell them that you would like to use it with 6.10. There are still quite a few of these about. > For example, is it an appropriate way to proceed to compile a > package with one version of GHC and then use the compiled package with > another version of GHC? Is it safe? What could possibly go wrong? It will not work. For one thing it would be hard to try and get into that situation since the package databases are different for each ghc version. If you managed to hack it anyway then ghc will detect that you used a different version to build the other package and refuse to compile against it. > If it is the right way to go, how should we setup the two GHC > versions? For instance,should we have a shared package configuration > file and choose through the path which GHC is used or is there nicer > way to set this up? It is perfectly possible to have multiple versions of ghc installed. I've got 4 versions. Each has an independent set of libraries however. By default ghc installs into a versioned lib directory and the binaries are versioned too, so 'ghc' on the $PATH will refer to the ghc version you installed most recently and use ghc-x.y for specific versions. > - Taking for example the "encoding" package on Hackage. Last time I tried, > the log was saying it fails to build on GHC 6.10, however, looking inside > this Hackage log, I could see a successful compilation using "preferred > versions". So it looks as if the thing can be compiled somehow. What should > one do with this information? cabal-install uses it automatically, at least if you're using the latest version (0.6.0). > If cabal manages to compile it using this method on Hackage, then > isn't cabal install just doing it on my disk? Yes. > Is it possible through some command line? Is it possible manually > (without cabal-install) and, if so, how? (I tried to copy-past the > build instruction as it appeared on the log...that somehow compiled, > but then, I failed to figure out how to install...) It sounds like you're using an older version. It works fine for me here using cabal-install-0.6.0. > - I?m primarily a windows user and lots of my initial struggles probably > came from that. After many difficulties, I figured out that installing MinGW > and MSys was *THE* way to get a bit more of the things working. First, a lot > of time would be saved by just saying clearly on the GHC download page that > MinGW and MSys are mandatory installation (or even package that with GHC for > the windows distribution if license allows, who cares the extra few Mb). > Even if that is not technically exact, i.e., even if ghci and many trivial > command line programs can work without, MSys and MinGW turn out to be quiet > necessary whenever trying to install anything producing side effect. They should only be needed for packages that use ./configure scripts. Perhaps that applies to all the ones you were trying. > Making it plain that these two are necessary would real come has a > great time savers for newbie like me on windows (personal opinion of > course). Or, if another path exists to go without these two, I'd be > very glad to learn. Besides, even these tools basic installation is > not enough, you need automake and various things of the like. That > makes me wonder if the most precious skill for programming with > Haskell would not be a strong C/C++ programming background. These should not be necessary unless you are modifying packages that use ./configure scripts. Just to build them it is not necessary. To be honest I've never got autoconf or automake to work on MinGW/MSYS. I always generate the tarballs on linux and build them on windows (eg for building the gtk2hs windows installers) > - In face of the difficulties with windows, I switched to Linux. While some > things worked better, there were still lots of difficulties with package > compilation. For instance, it is very difficult to figure out which Linux > packages of a given distribution are needed for compiling this or that > package. Again, gtk2hs is epitome here: which C development packages are > needed to compile it is obscure at best (cairo, codeview, etc...). I ended > up querying the Debian package management with any keyword found after > running gtk2hs and randomly installing all the dev packages... That's a reasonable strategy. Or using native gtk2hs packages if they are available for your system (I think the debian gtk2hs packages are a bit older than the current gtk2hs release but probably still usable.) > And when gtk2hs finally compiled, it failed to install anyway. As of > today, I?ve never been able to compile even the dumbest demo using > gtk2hs whether on linux or on windows and whether using ghc 6.8.3 or > 6.10.1. The released version should work with ghc-6.8.x. Perhaps ask for help on the gtk2hs-users mailing list. The last release came out before ghc-6.10 and do not work with it. The development version works with 6.10 and we're expecting a new release any time. > On windows, the automated setup install worked but did not allow me to > compile with codeview and I still do not know how to add codeview to > the install packages. No, the windows installer does not include the sourceview package because it requires many many more C libraries and we decided it was not worth it for most users. Again feel free to ask on the gtk2hs-users list. If people do want it and don't mind the bigger download then it's doable. > Trust that I tried hard and read the docs thoroughly. Gtk2hs is just > on of many examples; I had problems under Linux also with, e.g., > Happs, yi, database things, etc. and figured out that the situation > was roughly identical to windows with MSys and MinGW. So Linux appears > not to be the right solution here. Maybe it's just that Linux users > are more experienced with the GNU C/C++ libraries...but it won't help > a windows user to switch to Linux since this knowledge can't be built > out of thin air. Partly it is familiarity and partly it is the fact that hackage is a 'live' collection of the latest version of everything. It is not a packaged collection of stuff that has been tested together. So there really are many packages that will be hard to get to work with whatever versions of other things you've got. It's a situation we are trying to improve by improved reporting and information on the hackage website. We're also building a "haskell platform" which is a collection of packages that have been tested together on several different operating systems. > - Would there be some binary version of cabal targeting various OSs? I > believe the Haskell platform project is about that. Yes exactly. > But without waiting for a fair and objective selection of the packages > (it seems to be the current status of the project), I?d be happy > working with some authoritative bundle produced by a Haskell guru and > would trust his subjective choices (who am I to question these choices > anyway). Or even an image (e.g., virtual box or Xen) of a fully setup > development environment since there are so many dependencies involved > in, e.g., simply compiling GHC... It sounds like you're describing the platform project. Hopefully that will not be too long a wait. > Now, one might argue that these are not Haskell problems, that they are > normal when dealing with non-mature packages. So let me explain why I've > been trying hard to install these packages: > > As a beginner with no experience with emacs, I tried to find some IDE-like > environment which would, at least, save me from manually reloading files in > ghci or help me browse the source files. Following the Haskellwiki advice, > that led to trying out Yi, Leksah, eclipsefp, or a Visual Studio extension. > To this date, NOT ANY SINGLE ONE of these worked, be it on Linux or Windows. > I had to resort to learning emacs which seems the only sensible choice > available today. No, none of them are mature. Most people are using ordinary editors with Haskell modes and manually reloading files in ghci. > I am particularly unskilled, no question here. But, would a charitable soul > take the pain of writing a comprehensive package management tutorial instead > of a monad one, (s)he would have my deepest gratitude :) Yes if we could find someone to help us improve the documentation for using cabal that would be brilliant. We've got a lot of information in the cabal user guide but I get the feeling it is not very accessible. Also it does not cover hackage. Personally I find it very hard to document broken stuff. I prefer to spend that time fixing things. I realise that's not very helpful. As I said, we could do with some help in this area. > Apologies for the long mail. Thanks for the feedback. It makes it clear how much work we have yet to do to make this process smoother for new users. > P.S. People on #haskell are wonderful. They helped me solve many issues. > Unfortunately, solving specific instances of problem did not contribute much > to a deeper understanding of the internal working. I find myself randomly > trying things without knowing which would work or why; Hence this plea for a > tutorial. From benjovi at gmx.net Tue Jan 13 18:07:02 2009 From: benjovi at gmx.net (Benedikt Huber) Date: Tue Jan 13 17:58:19 2009 Subject: [Haskell-cafe] Re: The problem with Monads... In-Reply-To: <351ff25e0901130809x22f5131dx60fede4bcf38b779@mail.gmail.com> References: <351ff25e0901130656k530348afj6633048d206d7f74@mail.gmail.com> <1231861860.17950.1.camel@jonathans-macbook> <351ff25e0901130809x22f5131dx60fede4bcf38b779@mail.gmail.com> Message-ID: <496D1E96.40500@gmx.net> Rafael Gustavo da Cunha Pereira Pinto schrieb: > Yes, I've read it twice, and it is a nice explanation that "yes, the > reader monad is an application and is a monad". How do I use it? Why not > the function itself? How would the plumbing work in a real world example? Hi Rafael, First of all, I agree that the documentation for mtl should be improved. Especially Control.Monad.RWS and Control.Monad.List really need some more information. The documentation for the Reader and Identity monad are quite detailled though. They seem to be "inspired" by http://www.haskell.org/all_about_monads/, which also has documentation on Writer and Cont. Control.Monad.List is a good example for the lack of documentation: There is a single sentence at the beginning > "The List monad." and then one declaration > newtype ListT m a = ListT { runListT :: m [a] } while the important information is hidden as one of many instance declarations: > Monad m => Functor (ListT m) > Monad m => MonadPlus (ListT m) Btw, the quality of the examples in Control.Monad.Reader is debutable. From Example 1: > -- The Reader monad, which implements this complicated check. > calc_isCountCorrect :: Reader Bindings Bool > calc_isCountCorrect = do > count <- asks (lookupVar "count") > bindings <- ask > return (count == (Map.size bindings)) I think it is wrong (or weird at least) to call the function a 'Reader monad'; the name 'calc_isCountCorrect' is horrible too (because of the calc_ prefix), Finally, implementing > isCountCorrect :: Bindings -> Bool > isCountCorrect bs = (bs Map.! "count") == Map.size bs using the Reader monad will convince everybody _not_ to use it. A suggestion: If license permits it, short versions of the articles on all_about_monads would make a great documentation for mtl (except for RWS and List, which are missing). benedikt > > BTW, the article is really great as an brief introduction to monad > transformers. For the whole concept of monads, my all time favorite is > "The Haskell Programmer's Guide to the IO Monad" by Stefan Klinger. > > Chapters 14 to 19 of "Real World Haskell" also have a good introduction > on the usage of the monads, but it lacks other monads, like the RWS or > the Continuation... > > See, that is my point. The mathematical concept of monads is very > palatable. The idea that monads are either patterns or structures to > hide computations in sequence is also very easy to see. But how do we > use them? > Why should I use a Writer monad when I can use a (a,w) tuple? > > > > On Tue, Jan 13, 2009 at 13:51, Jonathan Cast > wrote: > > On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira Pinto > wrote: > > > > Last night I was thinking on what makes monads so hard to take, and > > came to a conclusion: the lack of a guided tour on the implemented > > monads. > > ... > > > Inspired by the paper "Functional Programming with Overloading and > > Higher-Order Polymorphism", > > Mark P Jones > > (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html > ) > > Advanced School of Functional Programming, 1995. > > > > SO WHAT? > > So have you read Jones' paper? Or do you have a *concrete* explanation > of how it differs from your desired `guided tour'? > > jcc > > > > > > -- > Rafael Gustavo da Cunha Pereira Pinto > Electronic Engineer, MSc. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From duncan.coutts at worc.ox.ac.uk Tue Jan 13 18:10:48 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 13 18:02:00 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <10ed1a750901130821m9b3e8fev2528a0877ebf6be1@mail.gmail.com> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <10ed1a750901130821m9b3e8fev2528a0877ebf6be1@mail.gmail.com> Message-ID: <1231888248.28590.241.camel@localhost> On Tue, 2009-01-13 at 16:21 +0000, Jamie Brandon wrote: > I agree completely. There is not nearly enough documentation on > packaging in haskell and too many hackage packages are broken or do > not install. I know several people are working on improving this but > they seem do be doing so rather quietly. Could someone briefly outline > what improvements are planned and what stage the current work is at? I > remember seeing some demos at anglohaskell during the summer but > nothing since. If you are talking about the new hackage server then the code is here: http://code.haskell.org/hackage-server/ It should work though it is not feature complete. Patches gratefully accepted. The build reporting should work with the current cabal-install, though again it needs some polishing. Nothing especially difficult, it's primarily a lack of developer time. We've got too many "high priority" TODO items. We are spread too thin across the projects: Cabal, cabal-install, hackage-server, haskell-platform. More helpers are required. Your Haskell needs you! Sign up today! http://hackage.haskell.org/trac/hackage/#StartingpointsfornewCabalhackers Duncan From duncan.coutts at worc.ox.ac.uk Tue Jan 13 18:20:50 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 13 18:12:02 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <10ed1a750901130821m9b3e8fev2528a0877ebf6be1@mail.gmail.com> <20090113171336.GD6699@scytale.galois.com> Message-ID: <1231888850.28590.251.camel@localhost> On Tue, 2009-01-13 at 18:43 +0100, Peter Verswyvelen wrote: > What could be done is letting the community rate the quality of the > modules for each platform? Maybe with user comments? Like amazon.com > (so we hackazon.org ;-) And using lambdas instead of stars for giving > the rating :) On Tue, 2009-01-13 at 15:55 -0200, Mauricio wrote: > There's a 'stability' field on cabal description files. Maybe > it could appear after the name on the main listing. Or, all > packages marked as 'Stable' at that field could get a beautifull > color. My main problem with these mechanisms is that they require a lot of manual work and there is no way to ensure the information is accurate or authoritative. If what we want to know is "does the package build" then we should build it and find out. We should build it on a 100 different platform combinations and combine the information. That's what we're trying to do with the new haskage-server and cabal-install. Lack of developer time is hampering progress. The stability field is almost useless. There is no agreement on what it means and most packages lack it. If what we want to know is "is this version of the package API compatible with this one" then we should follow the package versioning policy. We should let packages opt-in to the policy and if they op-in we should enforce it. That gives us real information and real guarantees. Similar comments apply for test suites and code coverage. Automation and collection of useful information. What human comments are great for however is describing the quality of the API, how well it composes, how good the documentation is, how easy it is to understand and use. That kind of information can only be gleaned through use. I don't know if a star/lambda rating system would be very helpful. There are only a few similar packages in each category (even for xml and databases). Once we eliminate the ones that clearly do not build (using the automatically collected info) then there will only be the comments for two or three packages to review. That's not that much and star rating probably do not provide a very good summary to help in that decision. Automation! Automation! Automation! (Oh and more hackers to help us with these vial community infrastructure projects) Duncan From lrpalmer at gmail.com Tue Jan 13 18:24:49 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Jan 13 18:16:02 2009 Subject: [Haskell-cafe] Multiple State Monads In-Reply-To: References: <49a77b7a0901121913y75bcc3c3uadcb7e76b1fdb1a8@mail.gmail.com> Message-ID: <7ca3f0160901131524s7f67d59fvcb3280c9419cad09@mail.gmail.com> On Tue, Jan 13, 2009 at 3:29 PM, Phil wrote: > My only concern with using this method is - Will 'iterate' not create a > full > list of type [Double] and then take the final position once the list has > been fully realized? For my application this would be undesirable as the > list may be millions of items long, and you only ever care about the last > iteration (It's a crude Monte Carlo simulator to give it some context). If > Haskell is smart enough to look ahead and see as we only need the last > element as it is creating the list, therefore garbage collecting earlier > items then this would work fine - by I'm guessing that is a step to far for > the compiler? No, doing this type of thing is very typical Haskell, and the garbage collector *will* incrementally throw away early elements of the list. > I had originally implemented this similar to the above (although I didn't > know about the 'iterate' keyword FWIW, iterate is just a function, not a keyword. Could just be terminology mismatch. So, while the garbage collector will do the right thing, for a list millions of elements long, I suspect you will get stack overflows and/or bad memory performance because the computation is too lazy. One solution is to use a stricter version of !!, which evaluates elements of the list as it whizzes by them. Because the function you're iterating is strict to begin with, you do not lose performance by doing this: strictIdx :: Int -> [a] -> a strictIdx _ [] = error "empty list" strictIdx 0 (x:xs) = x strictIdx n (x:xs) = x `seq` strictIdx (n-1) xs (Note that I flipped the arguments, to an order that is nicer for currying) The reason is that iterate f x0 constructs a list like this: [ x0, f x0, f (f x0), f (f (f x0)), ... ] But shares the intermediate elements, so if we were to evaluate the first f x0 to, say, 42, then the thunks are overwritten and become: [ x0, 42, f 42, f (f 42), ... ] So iterate f x0 !! 1000000 is f (f (f (f ( ... a million times ... f x0)))), which will be a stack overflow because of each of the calls. What strictIdx does is to evaluate each element as it traverses it, so that each call is only one function deep, then we move on to the next one. This is the laziness abstraction leaking. Intuition about it develops with time and experience. It would be great if this leak could be patched by some brilliant theorist somewhere. Luke - which makes things tidier - a useful > tip!), I moved to using the state monad and replicateM_ for the first > truncate(endTime/timeStep)-1 elements so that everything but the last > result > is thrown away, and a final bind to getEvolution would return the result. > > Now that the code has been modified so that no result is passed back, using > modify and execState, this can be simplified to "replicateM_ > truncate(endTime/timeStep)" with no final bind needed. I've tried this and > it works fine. > > The key reason for using the Monad was to tell Haskell to discard all but > the current state. If I'm wrong about please let me know, as I don't want > to be guilty of overcomplicating my algorithm, and more importantly it > means > I'm not yet totally grasping the power of Haskell! > > Thanks again, > > Phil. > > > > > On 13/01/2009 03:13, "David Menendez" wrote: > > > On Mon, Jan 12, 2009 at 8:34 PM, Phil wrote: > >> Thanks Minh - I've updated my code as you suggested. This looks better > than > >> my first attempt! > >> > >> Is it possible to clean this up any more? I find: > >> > >> ( (), (Double, Word64) ) > >> > >> a bit odd syntactically, although I understand this is just to fit the > type > >> to the State c'tor so that we don't have to write our own Monad > longhand. > > > > If you have a function which transforms the state, you can lift it > > into the state monad using "modify". > > > >> evolveUnderlying :: (Double, Word64) -> (Double, Word64) > >> evolveUnderlying (stock, state) = ( newStock, newState ) > >> where > >> newState = ranq1Increment state > >> newStock = stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep + ( > >> vol*sqrt(timeStep)*normalFromRngState(state) ) ) > >> > >> getEvolution :: State (Double, Word64) () > >> getEvolution = modify evolveUnderlying > > > > Now, I don't know the full context of what you're doing, but the > > example you posted isn't really gaining anything from the state monad. > > Specifically, > > > > execState (replicateM_ n (modify f)) > > = execState (modify f >> modify f >> ... >> modify f) > > = execState (modify (f . f . ... . f)) > > = f . f . ... . f > > > > So you could just write something along these lines, > > > >> mcSimulate :: Double -> Double -> Word64 -> [Double] > >> mcSimulate startStock endTime seedForSeed = fst expiryStock : mcSimulate > >> startStock endTime newSeedForSeed > >> where > >> expiryStock = iterate evolveUnderlying (startStock, ranq1Init > seedForSeed) > >> !! truncate (endTime/timeStep) > >> newSeedForSeed = seedForSeed + 246524 > > > > > > Coming back to your original question, it is possible to work with > > nested state monad transformers. The trick is to use "lift" to make > > sure you are working with the appropriate state. > > > > get :: StateT s1 (State s2) s1 > > put :: s1 -> StateT s1 (State s2) () > > > > lift get :: StateT s1 (State s2) s2 > > lift put :: s2 -> StateT s1 (State s2) () > > > > A more general piece of advice is to try breaking things into smaller > > pieces. For example: > > > > getRanq1 :: MonadState Word64 m => m Word64 > > getRanq1 = do > > seed <- get > > put (ranq1Increment seed) > > return seed > > > > getEvolution :: StateT Double (State Word64) () > > getEvolution = do > > seed <- lift getRanq1 > > modify $ \stock -> stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep > > + ( vol*sqrt(timeStep)*normalFromRngState(seed) ) ) > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/816f3627/attachment.htm From dons at galois.com Tue Jan 13 18:27:08 2009 From: dons at galois.com (Don Stewart) Date: Tue Jan 13 18:18:05 2009 Subject: [Haskell-cafe] walking a directory tree efficiently In-Reply-To: <496D1BBD.8060101@libero.it> References: <496D1BBD.8060101@libero.it> Message-ID: <20090113232708.GE7815@scytale.galois.com> manlio_perillo: > Hi. > > During a tentative (quite unsuccessfull) to convert a simple Python > script that prints on stdout a directory and all its subdirectory [1] in > a good Haskell (mostly to start to do real practice with the language), > I came across this blog post: > http://blog.moertel.com/articles/2007/03/28/directory-tree-printing-in-haskell-part-three-lazy-i-o > > > Since recently I read about alternatives to lazy IO (like iteratee), I'm > curious to know if a flexible, efficient and safe alternative exists, > for the task of display a directory tree. > > > [1] http://paste.pocoo.org/show/99523/ > If you can do it with strict IO in Python, do the same thing in Haskell with System.IO.Strict. It should be mechanical to translate Python programs directly into naive IO-based Haskell using strict IO. Boring, but mechanical. There's no iteratee/fold-based IO system yet. -- Don From duncan.coutts at worc.ox.ac.uk Tue Jan 13 18:27:58 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 13 18:19:10 2009 Subject: [Haskell-cafe] ANN: json-0.4.1 In-Reply-To: References: <496C12C3.4020500@gmail.com> Message-ID: <1231889278.28590.256.camel@localhost> On Tue, 2009-01-13 at 20:58 +0100, Bas van Dijk wrote: > > Could not find module `Data.Generics': > > it was found in multiple packages: base-3.0.3.0 syb > > cabal: Error: some packages failed to install: > > json-0.4.1 failed during the building phase. The exception was: > > exit: ExitFailure 1 > > The standard solution for this is to add a cabal flag that controls > wether to depend on base-4 or base-3: Note that in future it will be even easier. As of Cabal-1.6 (which comes with ghc-6.10 but works with older versions too) you can use CPP macros: > #if MIN_VERSION_base(4,0,0) > import Data.Data (Data) > #else > import Data.Generics (Data) > #endif and not have to do anything in the .cabal file. Of course this does not really help you for base 3 / 4 because the only point of doing that is to preserve compatibility with ghc-6.8 and out-of-the-box ghc-6.8 comes with an older Cabal version and we generally cannot expect all users to upgrade their Cabal version. Duncan From sjoerd at w3future.com Tue Jan 13 18:39:45 2009 From: sjoerd at w3future.com (Sjoerd Visscher) Date: Tue Jan 13 18:31:05 2009 Subject: [Haskell-cafe] Slow Text.JSON parser In-Reply-To: <20090113150050.GB6422@scytale.galois.com> References: <3e62d4360901130416x78e37771od30311ca5abea69f@mail.gmail.com> <87d4er5nbm.fsf@malde.org> <20090113150050.GB6422@scytale.galois.com> Message-ID: <1691A507-AFBA-417A-8A84-0C5F5B06BCAB@w3future.com> JSON is a UNICODE format, like any modern format is today. ByteStrings are not going to work. If everybody starts yelling "ByteString" every time String performance is an issue, I don't see how Haskell is ever going to be a "real world programming language". On Jan 13, 2009, at 4:00 PM, Don Stewart wrote: > ketil: >> "Levi Greenspan" writes: >> >>> Now I wonder why Text.JSON is so slow in comparison and what can be >>> done about it. Any ideas? Or is the test case invalid? >> >> I haven't used JSON, but at first glance, I'd blame String IO. Can't >> you decode from ByteString? >> > > Text.JSON was never optimised for performance. It was designed for > small > JSON objects. For things above 1M I'd suggest using Data.Binary (or a > quick JSON encoding over bytestrings). Shouldn't be too hard to > prepare. > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sjoerd Visscher sjoerd@w3future.com From porges at porg.es Tue Jan 13 18:39:54 2009 From: porges at porg.es (George Pollard) Date: Tue Jan 13 18:31:18 2009 Subject: [Haskell-cafe] Real World Haskell: confusion In-Reply-To: <1231868795.3917.25.camel@derek-laptop> References: <5e0214850901130805h638625d1ge647a7fb278fc7e@mail.gmail.com> <1231868795.3917.25.camel@derek-laptop> Message-ID: <1231889994.7180.12.camel@porges-laptop> On Tue, 2009-01-13 at 11:46 -0600, Derek Elkins wrote: > No, it means exactly what you said it means. People abuse it to mean > the second sense. Those people are wrong and there is already a term > for that second sense, namely "partial application." I really wish > people would stop conflating these terms*, all it does is create > confusion. > > To Eugene: The suggested meaning of "curriable", namely "able to be > curried," does not make sense. curry takes an uncurried function to a > curried form. > > * A related annoyance is people who talk about languages "supporting > currying and/or partial application." Unless one means that the > language supports higher order functions at all by that, it doesn't make > any sense. Haskell has no "support" for currying or partial > application. The fact that most functions are in curried form in > Haskell is merely a convention (with, admittedly strong -social- > ramifications.) The only way one could say Haskell "supports" currying > is that it has a lightweight notation for nested lambdas. I?d almost say that there is no such thing as partial application in Haskell. Since every: > f ? a ? b ? c is really: > f ? a ? (b ? c) there are no multiple arguments to be applied ?partially?, only a function ?f? that takes one argument and gives you another, anonymous, function. - George -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/5e741326/attachment.bin From dons at galois.com Tue Jan 13 18:42:15 2009 From: dons at galois.com (Don Stewart) Date: Tue Jan 13 18:33:12 2009 Subject: [Haskell-cafe] Slow Text.JSON parser In-Reply-To: <1691A507-AFBA-417A-8A84-0C5F5B06BCAB@w3future.com> References: <3e62d4360901130416x78e37771od30311ca5abea69f@mail.gmail.com> <87d4er5nbm.fsf@malde.org> <20090113150050.GB6422@scytale.galois.com> <1691A507-AFBA-417A-8A84-0C5F5B06BCAB@w3future.com> Message-ID: <20090113234215.GF7815@scytale.galois.com> utf8-string allows one to decode utf8 from bytestrings. It was built so that we could decode utf8 strings at work from bytestrings :) http://hackage.haskell.org/packages/archive/utf8-string/0.3.3/doc/html/Data-ByteString-UTF8.html Enjoy! Libraries win every day of the week. -- Don sjoerd: > JSON is a UNICODE format, like any modern format is today. ByteStrings > are not going to work. > > If everybody starts yelling "ByteString" every time String performance > is an issue, I don't see how Haskell is ever going to be a "real world > programming language". > > On Jan 13, 2009, at 4:00 PM, Don Stewart wrote: > > >ketil: > >>"Levi Greenspan" writes: > >> > >>>Now I wonder why Text.JSON is so slow in comparison and what can be > >>>done about it. Any ideas? Or is the test case invalid? > >> > >>I haven't used JSON, but at first glance, I'd blame String IO. Can't > >>you decode from ByteString? > >> > > > >Text.JSON was never optimised for performance. It was designed for > >small > >JSON objects. For things above 1M I'd suggest using Data.Binary (or a > >quick JSON encoding over bytestrings). Shouldn't be too hard to > >prepare. > > > >-- Don > >_______________________________________________ > >Haskell-Cafe mailing list > >Haskell-Cafe@haskell.org > >http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- > Sjoerd Visscher > sjoerd@w3future.com > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From lrpalmer at gmail.com Tue Jan 13 18:42:37 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Jan 13 18:33:50 2009 Subject: [Haskell-cafe] Slow Text.JSON parser In-Reply-To: <1691A507-AFBA-417A-8A84-0C5F5B06BCAB@w3future.com> References: <3e62d4360901130416x78e37771od30311ca5abea69f@mail.gmail.com> <87d4er5nbm.fsf@malde.org> <20090113150050.GB6422@scytale.galois.com> <1691A507-AFBA-417A-8A84-0C5F5B06BCAB@w3future.com> Message-ID: <7ca3f0160901131542j36d0d455je8dee9ca9aec7f7e@mail.gmail.com> On Tue, Jan 13, 2009 at 4:39 PM, Sjoerd Visscher wrote: > JSON is a UNICODE format, like any modern format is today. ByteStrings are > not going to work. I don't understand this statement. Why can one not make a parser from ByteStrings that can decode UTF-8? Luke > > > If everybody starts yelling "ByteString" every time String performance is > an issue, I don't see how Haskell is ever going to be a "real world > programming language". > > > On Jan 13, 2009, at 4:00 PM, Don Stewart wrote: > > ketil: >> >>> "Levi Greenspan" writes: >>> >>> Now I wonder why Text.JSON is so slow in comparison and what can be >>>> done about it. Any ideas? Or is the test case invalid? >>>> >>> >>> I haven't used JSON, but at first glance, I'd blame String IO. Can't >>> you decode from ByteString? >>> >>> >> Text.JSON was never optimised for performance. It was designed for small >> JSON objects. For things above 1M I'd suggest using Data.Binary (or a >> quick JSON encoding over bytestrings). Shouldn't be too hard to prepare. >> >> -- Don >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > -- > Sjoerd Visscher > sjoerd@w3future.com > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/eea70dec/attachment.htm From sjoerd at w3future.com Tue Jan 13 18:54:21 2009 From: sjoerd at w3future.com (Sjoerd Visscher) Date: Tue Jan 13 18:45:45 2009 Subject: [Haskell-cafe] Slow Text.JSON parser In-Reply-To: <7ca3f0160901131542j36d0d455je8dee9ca9aec7f7e@mail.gmail.com> References: <3e62d4360901130416x78e37771od30311ca5abea69f@mail.gmail.com> <87d4er5nbm.fsf@malde.org> <20090113150050.GB6422@scytale.galois.com> <1691A507-AFBA-417A-8A84-0C5F5B06BCAB@w3future.com> <7ca3f0160901131542j36d0d455je8dee9ca9aec7f7e@mail.gmail.com> Message-ID: <97CFFA0B-3B6A-4967-802B-EF93BE12393E@w3future.com> It is not impossible, but a lot of work. And if you want to do it correctly you would have to support UTF-16 (BE of LE) and UTF-32 (BE of LE) as well. You can't expect someone to start writing utf encoders and decoders every time he needs a fast parser. Sjoerd On Jan 14, 2009, at 12:42 AM, Luke Palmer wrote: > On Tue, Jan 13, 2009 at 4:39 PM, Sjoerd Visscher > wrote: > JSON is a UNICODE format, like any modern format is today. > ByteStrings are not going to work. > > I don't understand this statement. Why can one not make a parser > from ByteStrings that can decode UTF-8? > > Luke > > > > If everybody starts yelling "ByteString" every time String > performance is an issue, I don't see how Haskell is ever going to be > a "real world programming language". > > > On Jan 13, 2009, at 4:00 PM, Don Stewart wrote: > > ketil: > "Levi Greenspan" writes: > > Now I wonder why Text.JSON is so slow in comparison and what can be > done about it. Any ideas? Or is the test case invalid? > > I haven't used JSON, but at first glance, I'd blame String IO. Can't > you decode from ByteString? > > > Text.JSON was never optimised for performance. It was designed for > small > JSON objects. For things above 1M I'd suggest using Data.Binary (or a > quick JSON encoding over bytestrings). Shouldn't be too hard to > prepare. > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- > Sjoerd Visscher > sjoerd@w3future.com > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Sjoerd Visscher sjoerd@w3future.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/0a9d320b/attachment.htm From ryani.spam at gmail.com Tue Jan 13 19:03:48 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Jan 13 18:55:00 2009 Subject: [Haskell-cafe] Adding Authentication and Authorization to a service implemented in Haskell In-Reply-To: References: Message-ID: <2f9b2d30901131603q4bd75435rffdc0732fde1cdd@mail.gmail.com> At ICFP this year there was a fun presentation about this subject. The paper & library are available from: http://www.cs.chalmers.se/~russo/seclib.htm -- ryan 2009/1/13 Daryoush Mehrtash : > I am trying to figure out a clean way to add authentication and > authorization in a webservice. The services of the web services are > implemented as Haskell functions. The request to the service contains the > user authentication information. I want to authenticate the user by > verifying his authentication informaton, assign him roles, and then based on > the roles decide on the functions and data that he can have access too. Is > there a clean way to do this in Haskell? > > > Thanks > > Daryoush > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From bugfact at gmail.com Tue Jan 13 19:04:18 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Tue Jan 13 18:55:32 2009 Subject: [Haskell-cafe] Real World Haskell: confusion In-Reply-To: <1231889994.7180.12.camel@porges-laptop> References: <5e0214850901130805h638625d1ge647a7fb278fc7e@mail.gmail.com> <1231868795.3917.25.camel@derek-laptop> <1231889994.7180.12.camel@porges-laptop> Message-ID: > I'd almost say that there is no such thing as partial application in > Haskell. Since every: > > > f ¡Ë a ¡ú b ¡ú c > > is really: > > > f ¡Ë a ¡ú (b ¡ú c) > > there are no multiple arguments to be applied 'partially', only a > function 'f' that takes one argument and gives you another, anonymous, > function. > Mmm. And since tuples are just one syntactic sugared kind of ADTs, maybe Haskell doesn't have real currying either? ;-) Because really any kind of ADT could be curried in a sense no? Unless we really think of tuples as a handy anonymous kind of ADT that gets special treatment, e.g. because it is the only way to return multiple values from a function in Haskell (without having to declare a new type as must be done in C#, C++ etc?) Which is probably the case... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/b91fb284/attachment.htm From dan.doel at gmail.com Tue Jan 13 19:19:38 2009 From: dan.doel at gmail.com (Dan Doel) Date: Tue Jan 13 19:10:53 2009 Subject: [Haskell-cafe] Re: Monads aren't evil? I think they are. In-Reply-To: <7ca3f0160901131451k79bc6a6oc27bfb5dff276079@mail.gmail.com> References: <20090108231652.24b75fe3@tritium.xx> <7ca3f0160901131451k79bc6a6oc27bfb5dff276079@mail.gmail.com> Message-ID: <200901131919.38691.dan.doel@gmail.com> On Tuesday 13 January 2009 5:51:09 pm Luke Palmer wrote: > On Tue, Jan 13, 2009 at 11:21 AM, Tim Newsham wrote: > > I have seen several libraries where all functions of a monad have the > > > >> monadic result (), e.g. Binary.Put and other writing functions. This is > >> a clear indicator, that the Monad instance is artificial and was only > >> chosen because of the 'do' notation. > > > > Maybe that was the initial reason, but I've actually found the > > Binary.Put.PutM (where Put = PutM ()) to be useful. Sometimes > > your putter does need to propogate a result... > > But that's the whole point of Writer! Take a monoid, make it into a monad. > Put as a monad is silly. You mean it should be Writer instead? When GHC starts optimizing (Writer Builder) as well as it optimizes PutM, then that will be a cogent argument. Until then, one might argue that it misses "the whole point of Put". -- Dan From anton at appsolutions.com Tue Jan 13 19:23:32 2009 From: anton at appsolutions.com (Anton van Straaten) Date: Tue Jan 13 19:14:45 2009 Subject: [Haskell-cafe] Real World Haskell: confusion In-Reply-To: <1231868795.3917.25.camel@derek-laptop> References: <5e0214850901130805h638625d1ge647a7fb278fc7e@mail.gmail.com> <1231868795.3917.25.camel@derek-laptop> Message-ID: <496D3084.9000003@appsolutions.com> Derek Elkins wrote: > No, it means exactly what you said it means. People abuse it to mean > the second sense. Those people are wrong and there is already a term > for that second sense, namely "partial application." I really wish > people would stop conflating these terms*, all it does is create > confusion. +1 > * A related annoyance is people who talk about languages "supporting > currying and/or partial application." Unless one means that the > language supports higher order functions at all by that, it doesn't make > any sense. Haskell has no "support" for currying or partial > application. The fact that most functions are in curried form in > Haskell is merely a convention (with, admittedly strong -social- > ramifications.) The only way one could say Haskell "supports" currying > is that it has a lightweight notation for nested lambdas. Compared to most other languages, that lightweight notation makes enough of a difference that it's reasonable to say that Haskell "supports currying and partial application". E.g., in Haskell: f x y z = ... Haskell without the above notation: f x = \y -> \z -> ... Javascript, to underscore the point: function f(x) { return function (y) { return function (z) { ... } } } "Standard" Scheme: (define (f x) (lambda (y) (lambda (z) ...))) Scheme with a common macro to "support currying": (define (((f x) y) z) ...) That's just the function definition side. On the application side, Haskell has a lightweight notation for application in general, i.e. you write "f a b c" instead of e.g. "f(a)(b)(c)" in C-like syntaxes or "(((f a) b) c)" in Lisp-like syntaxes. Together, these two sugary treats make it quite a bit more convenient and practical to use currying and partial application in Haskell (and ML, etc.), and this translates to *much* more use in practice. Anton From lrpalmer at gmail.com Tue Jan 13 19:27:10 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Jan 13 19:18:23 2009 Subject: [Haskell-cafe] Re: Monads aren't evil? I think they are. In-Reply-To: <200901131919.38691.dan.doel@gmail.com> References: <20090108231652.24b75fe3@tritium.xx> <7ca3f0160901131451k79bc6a6oc27bfb5dff276079@mail.gmail.com> <200901131919.38691.dan.doel@gmail.com> Message-ID: <7ca3f0160901131627w252d496dy29d7e2c88f348e42@mail.gmail.com> On Tue, Jan 13, 2009 at 5:19 PM, Dan Doel wrote: > On Tuesday 13 January 2009 5:51:09 pm Luke Palmer wrote: > > On Tue, Jan 13, 2009 at 11:21 AM, Tim Newsham wrote: > > > I have seen several libraries where all functions of a monad have the > > > > > >> monadic result (), e.g. Binary.Put and other writing functions. This > is > > >> a clear indicator, that the Monad instance is artificial and was only > > >> chosen because of the 'do' notation. > > > > > > Maybe that was the initial reason, but I've actually found the > > > Binary.Put.PutM (where Put = PutM ()) to be useful. Sometimes > > > your putter does need to propogate a result... > > > > But that's the whole point of Writer! Take a monoid, make it into a > monad. > > Put as a monad is silly. > > You mean it should be Writer instead? Or rather, PutM should not exist (or be exposed), and Put should just be a monoid. > When GHC starts optimizing (Writer Builder) as well as it optimizes PutM, > then > that will be a cogent argument. Until then, one might argue that it misses > "the whole point of Put". Well it can still serve as an optimization over bytestrings using whatever trickery it uses (I am assuming here -- I am not familiar with its trickery), the same way DList is an optimization over List. It's just that its monadiness is superfluous. Surely PutM and Writer Put have almost the same performance?! (I am worried if not -- if not, can you give an indication why?) Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/54dcf707/attachment.htm From dan.doel at gmail.com Tue Jan 13 19:44:17 2009 From: dan.doel at gmail.com (Dan Doel) Date: Tue Jan 13 19:35:32 2009 Subject: [Haskell-cafe] Re: Monads aren't evil? I think they are. In-Reply-To: <7ca3f0160901131627w252d496dy29d7e2c88f348e42@mail.gmail.com> References: <20090108231652.24b75fe3@tritium.xx> <200901131919.38691.dan.doel@gmail.com> <7ca3f0160901131627w252d496dy29d7e2c88f348e42@mail.gmail.com> Message-ID: <200901131944.18449.dan.doel@gmail.com> On Tuesday 13 January 2009 7:27:10 pm Luke Palmer wrote: > > When GHC starts optimizing (Writer Builder) as well as it optimizes PutM, > > then > > that will be a cogent argument. Until then, one might argue that it > > misses "the whole point of Put". > > Well it can still serve as an optimization over bytestrings using whatever > trickery it uses (I am assuming here -- I am not familiar with its > trickery), the same way DList is an optimization over List. It's just that > its monadiness is superfluous. > > Surely PutM and Writer Put have almost the same performance?! (I am > worried if not -- if not, can you give an indication why?) The underlying monoid is Builder. The point of PutM is to be a version of Writer that's specialized to the Builder monoid for maximum performance. It looks like: data PairS a = PairS a {-# UNPACK #-} !Builder newtype PutM a = Put { unPut :: PairS a } I'm not sure why it's split up like that. Anyhow, the strict, unpacked Builder gets optimized better than Writer Builder. Even if you change Writer to: data Writer w a = Writer a !w it still won't match up, because polymorphic components don't get unpacked and such. That's, for instance, why Data.Sequence uses a specialized version of the finger tree type, instead of using the general version in Data.FingerTree. Only exposing Put as a monoid is kind of redundant. You might as well work straight with Builder. -- Dan From pbeadling at mail2web.com Tue Jan 13 19:45:58 2009 From: pbeadling at mail2web.com (Phil) Date: Tue Jan 13 19:39:17 2009 Subject: [Haskell-cafe] Multiple State Monads In-Reply-To: <7ca3f0160901131524s7f67d59fvcb3280c9419cad09@mail.gmail.com> Message-ID: Ahh, I see ? so using the State monad is arguably overcomplicating this. This is very helpful. The use of ?keyword? was just an unfortunate use of terminology ? my bad. Very useful explanation about the laziness resulting in stack overflows too ? when I crank up the numbers I have been seeing this, I had been temporarily ignoring the issue and just increasing the stack size at runtime, but I suspected something was awry. One last question on this function: In the definition: mcSimulate :: Double -> Double -> Word64 -> [Double] mcSimulate startStock endTime seedForSeed = fst expiryStock : mcSimulate startStock endTime newSeedForSeed It is abundantly clear that the startStock and endTime are just being passed around from call to call unchanged ? that is their value is constant throughout the the simulation. For the purposes here when I?m only passing 2 ?constants? around it doesn?t strike me as too odd, but my list of ?constants? is likely to grow as I bolt more functionality onto this. For readability, I understand that I can create new types to encapsulate complex data types into a single type , but I can?t help thinking that passing say 9 or 10 ?constants? around and around like this ?feels wrong?. If I sit back and think about it, it doesn?t strike me as implausible that the compiler will recognize what I?m doing and optimize this out for me, and what I?m doing is thinking about the whole think like a C++ programmer (which I traditionally am) would. However before I allayed my own concerns I wanted to check that in the Haskell world passing around lots of parameters isn?t a bad thing ? that is, I?m not missing a trick here to make my code more readable or more importantly more performant. Thanks again, Phil. On 13/01/2009 23:24, "Luke Palmer" wrote: > On Tue, Jan 13, 2009 at 3:29 PM, Phil wrote: >> My only concern with using this method is - Will 'iterate' not create a full >> list of type [Double] and then take the final position once the list has >> been fully realized? For my application this would be undesirable as the >> list may be millions of items long, and you only ever care about the last >> iteration (It's a crude Monte Carlo simulator to give it some context). If >> Haskell is smart enough to look ahead and see as we only need the last >> element as it is creating the list, therefore garbage collecting earlier >> items then this would work fine - by I'm guessing that is a step to far for >> the compiler? > > No, doing this type of thing is very typical Haskell, and the garbage > collector will incrementally throw away early elements of the list. > >> >> I had originally implemented this similar to the above (although I didn't >> know about the 'iterate' keyword > > FWIW, iterate is just a function, not a keyword. Could just be terminology > mismatch. > > So, while the garbage collector will do the right thing, for a list millions > of elements long, I suspect you will get stack overflows and/or bad memory > performance because the computation is too lazy. One solution is to use a > stricter version of !!, which evaluates elements of the list as it whizzes by > them. Because the function you're iterating is strict to begin with, you do > not lose performance by doing this: > > strictIdx :: Int -> [a] -> a > strictIdx _ [] = error "empty list" > strictIdx 0 (x:xs) = x > strictIdx n (x:xs) = x `seq` strictIdx (n-1) xs > > (Note that I flipped the arguments, to an order that is nicer for currying) > > The reason is that iterate f x0 constructs a list like this: > > [ x0, f x0, f (f x0), f (f (f x0)), ... ] > > But shares the intermediate elements, so if we were to evaluate the first f x0 > to, say, 42, then the thunks are overwritten and become: > > [ x0, 42, f 42, f (f 42), ... ] > > So iterate f x0 !! 1000000 is f (f (f (f ( ... a million times ... f x0)))), > which will be a stack overflow because of each of the calls. What strictIdx > does is to evaluate each element as it traverses it, so that each call is only > one function deep, then we move on to the next one. > > This is the laziness abstraction leaking. Intuition about it develops with > time and experience. It would be great if this leak could be patched by some > brilliant theorist somewhere. > > Luke > >> - which makes things tidier - a useful >> tip!), I moved to using the state monad and replicateM_ for the first >> truncate(endTime/timeStep)-1 elements so that everything but the last result >> is thrown away, and a final bind to getEvolution would return the result. >> >> Now that the code has been modified so that no result is passed back, using >> modify and execState, this can be simplified to "replicateM_ >> truncate(endTime/timeStep)" with no final bind needed. I've tried this and >> it works fine. >> >> The key reason for using the Monad was to tell Haskell to discard all but >> the current state. If I'm wrong about please let me know, as I don't want >> to be guilty of overcomplicating my algorithm, and more importantly it means >> I'm not yet totally grasping the power of Haskell! >> >> Thanks again, >> >> Phil. >> >> >> >> >> On 13/01/2009 03:13, "David Menendez" wrote: >> >>> > On Mon, Jan 12, 2009 at 8:34 PM, Phil wrote: >>>> >> Thanks Minh - I've updated my code as you suggested. This looks better >>>> than >>>> >> my first attempt! >>>> >> >>>> >> Is it possible to clean this up any more? I find: >>>> >> >>>> >> ( (), (Double, Word64) ) >>>> >> >>>> >> a bit odd syntactically, although I understand this is just to fit the >>>> type >>>> >> to the State c'tor so that we don't have to write our own Monad >>>> longhand. >>> > >>> > If you have a function which transforms the state, you can lift it >>> > into the state monad using "modify". >>> > >>>> >> evolveUnderlying :: (Double, Word64) -> (Double, Word64) >>>> >> evolveUnderlying (stock, state) = ( newStock, newState ) >>>> >> where >>>> >> newState = ranq1Increment state >>>> >> newStock = stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep + ( >>>> >> vol*sqrt(timeStep)*normalFromRngState(state) ) ) >>>> >> >>>> >> getEvolution :: State (Double, Word64) () >>>> >> getEvolution = modify evolveUnderlying >>> > >>> > Now, I don't know the full context of what you're doing, but the >>> > example you posted isn't really gaining anything from the state monad. >>> > Specifically, >>> > >>> > execState (replicateM_ n (modify f)) >>> > = execState (modify f >> modify f >> ... >> modify f) >>> > = execState (modify (f . f . ... . f)) >>> > = f . f . ... . f >>> > >>> > So you could just write something along these lines, >>> > >>>> >> mcSimulate :: Double -> Double -> Word64 -> [Double] >>>> >> mcSimulate startStock endTime seedForSeed = fst expiryStock : mcSimulate >>>> >> startStock endTime newSeedForSeed >>>> >> where >>>> >> expiryStock = iterate evolveUnderlying (startStock, ranq1Init >>>> seedForSeed) >>>> >> !! truncate (endTime/timeStep) >>>> >> newSeedForSeed = seedForSeed + 246524 >>> > >>> > >>> > Coming back to your original question, it is possible to work with >>> > nested state monad transformers. The trick is to use "lift" to make >>> > sure you are working with the appropriate state. >>> > >>> > get :: StateT s1 (State s2) s1 >>> > put :: s1 -> StateT s1 (State s2) () >>> > >>> > lift get :: StateT s1 (State s2) s2 >>> > lift put :: s2 -> StateT s1 (State s2) () >>> > >>> > A more general piece of advice is to try breaking things into smaller >>> > pieces. For example: >>> > >>> > getRanq1 :: MonadState Word64 m => m Word64 >>> > getRanq1 = do >>> > seed <- get >>> > put (ranq1Increment seed) >>> > return seed >>> > >>> > getEvolution :: StateT Double (State Word64) () >>> > getEvolution = do >>> > seed <- lift getRanq1 >>> > modify $ \stock -> stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep >>> > + ( vol*sqrt(timeStep)*normalFromRngState(seed) ) ) >>> > >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/899b5784/attachment.htm From duncan.coutts at worc.ox.ac.uk Tue Jan 13 19:54:44 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 13 19:45:56 2009 Subject: [Haskell-cafe] Re: Monads aren't evil? I think they are. In-Reply-To: <200901131919.38691.dan.doel@gmail.com> References: <20090108231652.24b75fe3@tritium.xx> <7ca3f0160901131451k79bc6a6oc27bfb5dff276079@mail.gmail.com> <200901131919.38691.dan.doel@gmail.com> Message-ID: <1231894484.28590.270.camel@localhost> On Tue, 2009-01-13 at 19:19 -0500, Dan Doel wrote: > On Tuesday 13 January 2009 5:51:09 pm Luke Palmer wrote: > > On Tue, Jan 13, 2009 at 11:21 AM, Tim Newsham wrote: > > > I have seen several libraries where all functions of a monad have the > > > > > >> monadic result (), e.g. Binary.Put and other writing functions. This is > > >> a clear indicator, that the Monad instance is artificial and was only > > >> chosen because of the 'do' notation. > > > > > > Maybe that was the initial reason, but I've actually found the > > > Binary.Put.PutM (where Put = PutM ()) to be useful. Sometimes > > > your putter does need to propogate a result... > > > > But that's the whole point of Writer! Take a monoid, make it into a monad. > > Put as a monad is silly. > > You mean it should be Writer instead? > > When GHC starts optimizing (Writer Builder) as well as it optimizes PutM, then > that will be a cogent argument. In that case it's a cogent argument now. :-) You may be interested to note that PutM really is implemented as a writer monad over the Builder monoid: -- | The PutM type. A Writer monad over the efficient Builder monoid. newtype PutM a = Put { unPut :: PairS a } data PairS a = PairS a {-# UNPACK #-}!Builder -- | Put merely lifts Builder into a Writer monad, applied to (). type Put = PutM () > Until then, one might argue that it misses "the whole point of Put". Back when we were first writing the binary library, Ross converted our original Put to be a monoid called Builder with Put left as a Writer. GHC optimises it perfectly, we checked. The reason we provide Put as well as Builder is purely for symmetry with code written using Get. Also `mappend` is not so pretty. Another argument for redefining (++) == mappend :-) Get doesn't need to be a Monad either, it only needs to be an applicative functor. Indeed the rules to eliminate adjacent bounds checks only fire if it is used in this way (using >> also works). Duncan From ross at soi.city.ac.uk Tue Jan 13 19:55:40 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Jan 13 19:46:57 2009 Subject: [Haskell-cafe] Re: Monads aren't evil? I think they are. In-Reply-To: <200901131944.18449.dan.doel@gmail.com> References: <20090108231652.24b75fe3@tritium.xx> <200901131919.38691.dan.doel@gmail.com> <7ca3f0160901131627w252d496dy29d7e2c88f348e42@mail.gmail.com> <200901131944.18449.dan.doel@gmail.com> Message-ID: <20090114005540.GA16357@soi.city.ac.uk> On Tue, Jan 13, 2009 at 07:44:17PM -0500, Dan Doel wrote: > On Tuesday 13 January 2009 7:27:10 pm Luke Palmer wrote: > > Surely PutM and Writer Put have almost the same performance?! (I am > > worried if not -- if not, can you give an indication why?) > > The underlying monoid is Builder. The point of PutM is to be > a version of Writer that's specialized to the Builder monoid for > maximum performance. It looks like: > > data PairS a = PairS a {-# UNPACK #-} !Builder > > newtype PutM a = Put { unPut :: PairS a } > > I'm not sure why it's split up like that. Anyhow, the strict, unpacked > Builder gets optimized better than Writer Builder. But the only reason you want this monad optimized is so that you can use it in do-notation. Otherwise you'd just use Builder directly. From dave at zednenem.com Tue Jan 13 19:56:53 2009 From: dave at zednenem.com (David Menendez) Date: Tue Jan 13 19:48:05 2009 Subject: [Haskell-cafe] Multiple State Monads In-Reply-To: References: <49a77b7a0901121913y75bcc3c3uadcb7e76b1fdb1a8@mail.gmail.com> Message-ID: <49a77b7a0901131656o2dde4f35n144b5d6796f39dad@mail.gmail.com> On Tue, Jan 13, 2009 at 5:29 PM, Phil wrote: > Many thanks for the replies. > > Using 'modify' cleans the syntax up nicely. > > With regard to using 'iterate' as shown by David here: > >>> mcSimulate :: Double -> Double -> Word64 -> [Double] >>> mcSimulate startStock endTime seedForSeed = fst expiryStock : mcSimulate >>> startStock endTime newSeedForSeed >>> where >>> expiryStock = iterate evolveUnderlying (startStock, ranq1Init seedForSeed) >>> !! truncate (endTime/timeStep) >>> newSeedForSeed = seedForSeed + 246524 > > My only concern with using this method is - Will 'iterate' not create a full > list of type [Double] and then take the final position once the list has > been fully realized? iterate creates the elements of the list as they are requested, and !! will discard everything until it hits the answer it wants. That being said, it's not the best way to repeatedly apply a function, as Luke pointed out. A better way would probably be something like this, applyNTimes :: Int -> (a -> a) -> a -> a applyNTimes n f a | n <= 0 = a | otherwise = applyNTimes (n-1) $! f a That ($!) is there to make sure "f a" gets evaluated before calling applyNTimes again. > The key reason for using the Monad was to tell Haskell to discard all but > the current state. If I'm wrong about please let me know, as I don't want > to be guilty of overcomplicating my algorithm, and more importantly it means > I'm not yet totally grasping the power of Haskell! I'm not entirely sure what you mean by "discard all but the current state", but Haskell implementations are pretty good about discarding values that are no longer needed. That being said, here's one way I might implement your algorithm. It's a sketch, and I haven't tested it, but the general idea should be clear. mcSimulate stock endTime seed = map (evolve n stock) $ iterate (+246524) seed where n = truncate (endTime / timeStep) evolve :: Int -> Double -> Word64 -> Double evolve n stock seed | n <= 0 = stock | otherwise = evolve (n-1) (evolveStock stock seed) (ranq1Increment seed) evolveStock :: Double -> Word64 -> Double evolveStock stock seed = stock * exp (a + b * normalFromRngState seed) where a = (ir - 0.5 * vol * vol) * timeStep b = vol * sqrt timeStep -- Dave Menendez From duncan.coutts at worc.ox.ac.uk Tue Jan 13 19:58:48 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 13 19:50:00 2009 Subject: [Haskell-cafe] Re: Monads aren't evil? I think they are. In-Reply-To: <200901131944.18449.dan.doel@gmail.com> References: <20090108231652.24b75fe3@tritium.xx> <200901131919.38691.dan.doel@gmail.com> <7ca3f0160901131627w252d496dy29d7e2c88f348e42@mail.gmail.com> <200901131944.18449.dan.doel@gmail.com> Message-ID: <1231894728.28590.275.camel@localhost> On Tue, 2009-01-13 at 19:44 -0500, Dan Doel wrote: > On Tuesday 13 January 2009 7:27:10 pm Luke Palmer wrote: > > > When GHC starts optimizing (Writer Builder) as well as it optimizes PutM, > > > then > > > that will be a cogent argument. Until then, one might argue that it > > > misses "the whole point of Put". > > > > Well it can still serve as an optimization over bytestrings using whatever > > trickery it uses (I am assuming here -- I am not familiar with its > > trickery), the same way DList is an optimization over List. It's just that > > its monadiness is superfluous. > > > > Surely PutM and Writer Put have almost the same performance?! (I am > > worried if not -- if not, can you give an indication why?) > > The underlying monoid is Builder. The point of PutM is to be a version of > Writer that's specialized to the Builder monoid for maximum performance. It > looks like: > > data PairS a = PairS a {-# UNPACK #-} !Builder > > newtype PutM a = Put { unPut :: PairS a } > > I'm not sure why it's split up like that. Anyhow, the strict, unpacked Builder > gets optimized better than Writer Builder. Oops, I walked into this conversation without reading enough context. Sorry, I see what you mean now. Yes, it's specialised to get decent performance. As you say, the lifted (,) in the Writer would get in the way otherwise. There's an interesting project in optimising parametrised monads and stacks of monad transformers. Duncan From lrpalmer at gmail.com Tue Jan 13 20:08:35 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Jan 13 19:59:48 2009 Subject: [Haskell-cafe] Multiple State Monads In-Reply-To: References: <7ca3f0160901131524s7f67d59fvcb3280c9419cad09@mail.gmail.com> Message-ID: <7ca3f0160901131708p4211c1eay34a0dfdb3d8177e@mail.gmail.com> On Tue, Jan 13, 2009 at 5:45 PM, Phil wrote: > mcSimulate :: Double -> Double -> Word64 -> [Dou > ble] > mcSimulate startStock endTime seedForSeed = fst expiryStock : mcSimulate > startStock endTime newSeedForSeed > > It is abundantly clear that the startStock and endTime are just being > passed around from call to call unchanged ? that is their value is constant > throughout the the simulation. For the purposes here when I'm only passing > 2 'constants' around it doesn't strike me as too odd, but my list of > 'constants' is likely to grow as I bolt more functionality onto this. For > readability, I understand that I can create new types to encapsulate complex > data types into a single type , but I can't help thinking that passing say 9 > or 10 'constants' around and around like this 'feels wrong'. If I sit back > and think about it, it doesn't strike me as implausible that the compiler > will recognize what I'm doing and optimize this out for me, and what I'm > doing is thinking about the whole think like a C++ programmer (which I > traditionally am) would. > You can factor out constants in a couple ways. If you are just passing constants between a recursive call to the same function, you can factor out the recursive bit into a separate function: something param1 param2 = go where go = ... param1 ... param2 ... etc ... go ... etc = ... Where go takes only the parameters that change, and the rest is handled by its enclosing scope. You might buy a little performance this way too, depending on the compiler's cleverness (I'm not sure how it optimizes these things). If you are passing around many constants between functions, first package them all up in a record data type: data Params = Params { parmFoo :: Int, parmBar :: Double, ... } At this point it is pretty easy just to pass a Parms object around. If you really hate the explicit style, though, you can throw your computation into a Reader Parms (Reader is the monad precisely for this: adding a constant parameter to every function), and then use eg. asks parmFoo to get parameters out. And if none of those strike your fancy, you can look into GHC's "implicit arguments" extension. But that seems to be in the process of a phase out by the community (nothing explicit, it's just that nobody is using them anymore). Luke > > > However before I allayed my own concerns I wanted to check that in the > Haskell world passing around lots of parameters isn't a bad thing ? that is, > I'm not missing a trick here to make my code more readable or more > importantly more performant. > > Thanks again, > > Phil. > > > On 13/01/2009 23:24, "Luke Palmer" wrote: > > On Tue, Jan 13, 2009 at 3:29 PM, Phil wrote: > > My only concern with using this method is - Will 'iterate' not create a > full > list of type [Double] and then take the final position once the list has > been fully realized? For my application this would be undesirable as the > list may be millions of items long, and you only ever care about the last > iteration (It's a crude Monte Carlo simulator to give it some context). If > Haskell is smart enough to look ahead and see as we only need the last > element as it is creating the list, therefore garbage collecting earlier > items then this would work fine - by I'm guessing that is a step to far for > the compiler? > > > No, doing this type of thing is very typical Haskell, and the garbage > collector *will* incrementally throw away early elements of the list. > > > I had originally implemented this similar to the above (although I didn't > know about the 'iterate' keyword > > > FWIW, iterate is just a function, not a keyword. Could just be terminology > mismatch. > > So, while the garbage collector will do the right thing, for a list > millions of elements long, I suspect you will get stack overflows and/or bad > memory performance because the computation is too lazy. One solution is to > use a stricter version of !!, which evaluates elements of the list as it > whizzes by them. Because the function you're iterating is strict to begin > with, you do not lose performance by doing this: > > strictIdx :: Int -> [a] -> a > strictIdx _ [] = error "empty list" > strictIdx 0 (x:xs) = x > strictIdx n (x:xs) = x `seq` strictIdx (n-1) xs > > (Note that I flipped the arguments, to an order that is nicer for currying) > > The reason is that iterate f x0 constructs a list like this: > > [ x0, f x0, f (f x0), f (f (f x0)), ... ] > > But shares the intermediate elements, so if we were to evaluate the first f > x0 to, say, 42, then the thunks are overwritten and become: > > [ x0, 42, f 42, f (f 42), ... ] > > So iterate f x0 !! 1000000 is f (f (f (f ( ... a million times ... f > x0)))), which will be a stack overflow because of each of the calls. What > strictIdx does is to evaluate each element as it traverses it, so that each > call is only one function deep, then we move on to the next one. > > This is the laziness abstraction leaking. Intuition about it develops with > time and experience. It would be great if this leak could be patched by > some brilliant theorist somewhere. > > Luke > > - which makes things tidier - a useful > tip!), I moved to using the state monad and replicateM_ for the first > truncate(endTime/timeStep)-1 elements so that everything but the last > result > is thrown away, and a final bind to getEvolution would return the result. > > Now that the code has been modified so that no result is passed back, using > modify and execState, this can be simplified to "replicateM_ > truncate(endTime/timeStep)" with no final bind needed. I've tried this and > it works fine. > > The key reason for using the Monad was to tell Haskell to discard all but > the current state. If I'm wrong about please let me know, as I don't want > to be guilty of overcomplicating my algorithm, and more importantly it > means > I'm not yet totally grasping the power of Haskell! > > Thanks again, > > Phil. > > > > > On 13/01/2009 03:13, "David Menendez" wrote: > > > On Mon, Jan 12, 2009 at 8:34 PM, Phil wrote: > >> Thanks Minh - I've updated my code as you suggested. This looks better > than > >> my first attempt! > >> > >> Is it possible to clean this up any more? I find: > >> > >> ( (), (Double, Word64) ) > >> > >> a bit odd syntactically, although I understand this is just to fit the > type > >> to the State c'tor so that we don't have to write our own Monad > longhand. > > > > If you have a function which transforms the state, you can lift it > > into the state monad using "modify". > > > >> evolveUnderlying :: (Double, Word64) -> (Double, Word64) > >> evolveUnderlying (stock, state) = ( newStock, newState ) > >> where > >> newState = ranq1Increment state > >> newStock = stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep + ( > >> vol*sqrt(timeStep)*normalFromRngState(state) ) ) > >> > >> getEvolution :: State (Double, Word64) () > >> getEvolution = modify evolveUnderlying > > > > Now, I don't know the full context of what you're doing, but the > > example you posted isn't really gaining anything from the state monad. > > Specifically, > > > > execState (replicateM_ n (modify f)) > > = execState (modify f >> modify f >> ... >> modify f) > > = execState (modify (f . f . ... . f)) > > = f . f . ... . f > > > > So you could just write something along these lines, > > > >> mcSimulate :: Double -> Double -> Word64 -> [Double] > >> mcSimulate startStock endTime seedForSeed = fst expiryStock : mcSimulate > >> startStock endTime newSeedForSeed > >> where > >> expiryStock = iterate evolveUnderlying (startStock, ranq1Init > seedForSeed) > >> !! truncate (endTime/timeStep) > >> newSeedForSeed = seedForSeed + 246524 > > > > > > Coming back to your original question, it is possible to work with > > nested state monad transformers. The trick is to use "lift" to make > > sure you are working with the appropriate state. > > > > get :: StateT s1 (State s2) s1 > > put :: s1 -> StateT s1 (State s2) () > > > > lift get :: StateT s1 (State s2) s2 > > lift put :: s2 -> StateT s1 (State s2) () > > > > A more general piece of advice is to try breaking things into smaller > > pieces. For example: > > > > getRanq1 :: MonadState Word64 m => m Word64 > > getRanq1 = do > > seed <- get > > put (ranq1Increment seed) > > return seed > > > > getEvolution :: StateT Double (State Word64) () > > getEvolution = do > > seed <- lift getRanq1 > > modify $ \stock -> stock * exp ( ( ir - (0.5*(vol*vol)) )*timeStep > > + ( vol*sqrt(timeStep)*normalFromRngState(seed) ) ) > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/043a7fb9/attachment.htm From tphyahoo at gmail.com Tue Jan 13 20:49:05 2009 From: tphyahoo at gmail.com (Thomas Hartman) Date: Tue Jan 13 20:40:18 2009 Subject: [Haskell-cafe] walking a directory tree efficiently In-Reply-To: <20090113232708.GE7815@scytale.galois.com> References: <496D1BBD.8060101@libero.it> <20090113232708.GE7815@scytale.galois.com> Message-ID: <910ddf450901131749p6a46d7edsa04d8392c09ee456@mail.gmail.com> > There's no iteratee/fold-based IO system yet. What about http://sites.google.com/site/haskell/notes/lazy-io-considered-harmful-way-to-go-left-fold-enumerator ? It's not on hackage, but at least it's public domain. Oleg, of course. 2009/1/13 Don Stewart : > manlio_perillo: >> Hi. >> >> During a tentative (quite unsuccessfull) to convert a simple Python >> script that prints on stdout a directory and all its subdirectory [1] in >> a good Haskell (mostly to start to do real practice with the language), >> I came across this blog post: >> http://blog.moertel.com/articles/2007/03/28/directory-tree-printing-in-haskell-part-three-lazy-i-o >> >> >> Since recently I read about alternatives to lazy IO (like iteratee), I'm >> curious to know if a flexible, efficient and safe alternative exists, >> for the task of display a directory tree. >> >> >> [1] http://paste.pocoo.org/show/99523/ >> > > If you can do it with strict IO in Python, do the same thing in Haskell > with System.IO.Strict. It should be mechanical to translate Python > programs directly into naive IO-based Haskell using strict IO. Boring, > but mechanical. > > There's no iteratee/fold-based IO system yet. > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From wren at freegeek.org Tue Jan 13 21:03:19 2009 From: wren at freegeek.org (wren ng thornton) Date: Tue Jan 13 20:54:32 2009 Subject: [Haskell-cafe] Real World Haskell: confusion In-Reply-To: <496D3084.9000003@appsolutions.com> References: <5e0214850901130805h638625d1ge647a7fb278fc7e@mail.gmail.com> <1231868795.3917.25.camel@derek-laptop> <496D3084.9000003@appsolutions.com> Message-ID: <496D47E7.10507@freegeek.org> Anton van Straaten wrote: > Derek Elkins wrote: > > * A related annoyance is people who talk about languages "supporting > > currying and/or partial application." Unless one means that the > > language supports higher order functions at all by that, it doesn't make > > any sense. Haskell has no "support" for currying or partial > > application. The fact that most functions are in curried form in > > Haskell is merely a convention (with, admittedly strong -social- > > ramifications.) The only way one could say Haskell "supports" currying > > is that it has a lightweight notation for nested lambdas. > > Compared to most other languages, that lightweight notation makes enough > of a difference that it's reasonable to say that Haskell "supports > currying and partial application". > [...] > Together, these two sugary treats make it quite a bit more convenient > and practical to use currying and partial application in Haskell (and > ML, etc.), and this translates to *much* more use in practice. The lightweight syntax for definition and application helps tremendously. But another thing that helps a lot is that GHC is smart enough to make it efficient. OCaml also has fairly lightweight syntax compared to Java and Scheme, but the community is strongly focused on performance and they tend to get riled up about when and when-not to use it. Whereas Haskell nurtures a community that says "let the compiler do the ugly things", which is backed by excellent compiler writers. This perspective difference can also be seen in the let/letrec distinction vs letting the compiler figure it out. -- Live well, ~wren From jan.h.xie at gmail.com Tue Jan 13 21:19:22 2009 From: jan.h.xie at gmail.com (Xie Hanjian) Date: Tue Jan 13 21:10:45 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety In-Reply-To: <496CDF79.3030205@complete.org> References: <87eizkra83.fsf@nitai.hr> <20090108030656.GA4430@complete.org> <87hc48zv9g.fsf@nitai.hr> <49676DEC.9070208@complete.org> <87tz83vz3l.fsf@nitai.hr> <496CDF79.3030205@complete.org> Message-ID: <20090114021922.GA22414@aiur> * John Goerzen [2009-01-13 12:37:45 -0600]: > Gour wrote: > >>>>>> "John" == John Goerzen writes: > > > > John> That's great. Even better if accompanied by a patch ;-) > > > > Heh, one of the things which prevents me advancing with my own Haskell > > project is lack of enough skills to provide bindings for one C-lib and > > here I see the same pattern...It looks I have to cross it over :-) > > > >>> I'll e.g. open ticket for BLOB support :-D > > > > John> Of course :-) > > > > I did it - have you seen the notice about problems with HDBC-forums? > > Yes. I am thoroughly displeased with Ruby on Rails at the moment. It > is less maintainable than a network of DOS boxes. There are a host of > mysterious crashes in Redmine at the moment -- including one where > pulling up the page for one specific bug (but none others) crashes the > server. > > I could upgrade Redmine, but that requires a Ruby stack that is partly > newer than what's in Debian, and the upgrade for that process appears to > succeed, but then fails in mysterious ways at the end. Redmine requires only ruby 1.8.6 and rails 2.1.2, which are both stable releases, so I think an upgrade of your ruby stack is very reasonable. > > To anyone annoyed with Haskell's library install process: you have no > idea how good you have it unless you've tried Ruby and rails. Disagree. Rubygems is fairly easy to use. At lease, I can guess how to uninstall a package by trying 'gem uninstall foobar', but failed by trying 'cabal uninstall/remove foobar' :-) Jan > > -- John > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- jan=callcc{|jan|jan};jan.call(jan) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/8a3d8ac7/attachment.bin From vigalchin at gmail.com Tue Jan 13 21:22:55 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Tue Jan 13 21:14:07 2009 Subject: [Haskell-cafe] posting newspaper article? Message-ID: <5ae4f2ba0901131822n1d6a1ccbtfbc474f1cdb47da8@mail.gmail.com> Hello, I don't want to risk the ire of the Haskell Cafe community. Is there a moderator? I want to post an editorial by the Big Blue CEO which seems to me to be very interesting vis-a-vis the FPL community and Haskell in general. I have an online subscription and can post to stimulate discussion. ???? Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/80ec5d63/attachment-0001.htm From jgoerzen at complete.org Tue Jan 13 21:53:40 2009 From: jgoerzen at complete.org (John Goerzen) Date: Tue Jan 13 21:45:00 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety In-Reply-To: <20090114021922.GA22414@aiur> References: <87eizkra83.fsf@nitai.hr> <20090108030656.GA4430@complete.org> <87hc48zv9g.fsf@nitai.hr> <49676DEC.9070208@complete.org> <87tz83vz3l.fsf@nitai.hr> <496CDF79.3030205@complete.org> <20090114021922.GA22414@aiur> Message-ID: <496D53B4.7060205@complete.org> Xie Hanjian wrote: > * John Goerzen [2009-01-13 12:37:45 -0600]: > > Redmine requires only ruby 1.8.6 and rails 2.1.2, which are both stable > releases, so I think an upgrade of your ruby stack is very reasonable. It also requires a newer version of rake than is in Debian. Not a problem as such, but you start working with gem install commands (and their friends), and eventually find that after spending 30 minutes installing/upgrading stuff, it bombs at the very end saying that some component needed a newer version of something than is available, and it can't install that component, so it's left the server hosed -- too new to run the old version, not ready to accept the new. Great. It ought to have checked the dependencies *before* messing with my system. And it ought not to have failed mysteriously anyhow. >> To anyone annoyed with Haskell's library install process: you have no >> idea how good you have it unless you've tried Ruby and rails. > > Disagree. Rubygems is fairly easy to use. At lease, I can guess how to It is completely poorly documented on how to gem install something when you don't have root. The gem(1) manpage is a joke. The online help doesn't help much either. Turns out there is a magic combination of undocumented environment variables and documented command-line options that does it. Or at least, I *thought* it does it. The other problem about Rails is that code and data are inseparably mixed. It will be just about impossible to install a rails app as a Debian package because it needs write access to its install directory, and this stuff is not easily configured to use /usr and /etc as appropriate. Anyhow, this is a Haskell list, so I'm not going to rant any more about this here. I can give you details off-list if you like. It's touched a nerve lately. -- John From allbery at ece.cmu.edu Tue Jan 13 22:43:48 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Jan 13 22:35:02 2009 Subject: [Haskell-cafe] Slow Text.JSON parser In-Reply-To: <97CFFA0B-3B6A-4967-802B-EF93BE12393E@w3future.com> References: <3e62d4360901130416x78e37771od30311ca5abea69f@mail.gmail.com> <87d4er5nbm.fsf@malde.org> <20090113150050.GB6422@scytale.galois.com> <1691A507-AFBA-417A-8A84-0C5F5B06BCAB@w3future.com> <7ca3f0160901131542j36d0d455je8dee9ca9aec7f7e@mail.gmail.com> <97CFFA0B-3B6A-4967-802B-EF93BE12393E@w3future.com> Message-ID: <56073450-3F70-477F-A4F9-0E9CE776AA02@ece.cmu.edu> On 2009 Jan 13, at 18:54, Sjoerd Visscher wrote: > It is not impossible, but a lot of work. And if you want to do it > correctly you would have to support UTF-16 (BE of LE) and UTF-32 (BE > of LE) as well. You can't expect someone to start writing utf > encoders and decoders every time he needs a fast parser. ...whereas making a linked list of Word32 run quickly is trivial? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/62a41a88/attachment.htm From derek.a.elkins at gmail.com Tue Jan 13 22:54:30 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Jan 13 22:45:47 2009 Subject: [Haskell-cafe] Real World Haskell: confusion In-Reply-To: <1231889994.7180.12.camel@porges-laptop> References: <5e0214850901130805h638625d1ge647a7fb278fc7e@mail.gmail.com> <1231868795.3917.25.camel@derek-laptop> <1231889994.7180.12.camel@porges-laptop> Message-ID: <1231905270.3917.28.camel@derek-laptop> On Wed, 2009-01-14 at 12:39 +1300, George Pollard wrote: > On Tue, 2009-01-13 at 11:46 -0600, Derek Elkins wrote: > > No, it means exactly what you said it means. People abuse it to mean > > the second sense. Those people are wrong and there is already a term > > for that second sense, namely "partial application." I really wish > > people would stop conflating these terms*, all it does is create > > confusion. > > > > To Eugene: The suggested meaning of "curriable", namely "able to be > > curried," does not make sense. curry takes an uncurried function to a > > curried form. > > > > * A related annoyance is people who talk about languages "supporting > > currying and/or partial application." Unless one means that the > > language supports higher order functions at all by that, it doesn't make > > any sense. Haskell has no "support" for currying or partial > > application. The fact that most functions are in curried form in > > Haskell is merely a convention (with, admittedly strong -social- > > ramifications.) The only way one could say Haskell "supports" currying > > is that it has a lightweight notation for nested lambdas. > > I?d almost say that there is no such thing as partial application in > Haskell. Since every: > > > f ? a ? b ? c > > is really: > > > f ? a ? (b ? c) > > there are no multiple arguments to be applied ?partially?, only a > function ?f? that takes one argument and gives you another, anonymous, > function. Dan Piponi linked an LtU thread where I discussed exactly this issue. A slighly more direct link: http://lambda-the-ultimate.org/node/2266#comment-33620 In Haskell there is arguably a slight semantic difference, but, yes, there's not a big difference between application and partial application (in Haskell.) From vigalchin at gmail.com Tue Jan 13 23:07:05 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Tue Jan 13 22:58:17 2009 Subject: [Haskell-cafe] Re: Issues with posix-realtime package In-Reply-To: <496C7662.20508@libero.it> References: <5ae4f2ba0901091358j3e08366jad674d8b6ae69405@mail.gmail.com> <4967DDFD.2090105@libero.it> <5ae4f2ba0901092127p6228bb66ubf23b9b28e5f77c6@mail.gmail.com> <49688C16.8070506@libero.it> <5ae4f2ba0901101414m63725480ofe66069d3a8e7c04@mail.gmail.com> <49692321.6080308@libero.it> <5ae4f2ba0901101603kc6ed063ma599d80b07eccc79@mail.gmail.com> <496C7662.20508@libero.it> Message-ID: <5ae4f2ba0901132007y674e73d0v4f8738976725db9a@mail.gmail.com> Hi Manlio, Are you now talking about code in Code from HsUnix.h and execvpe.h? Vasili On Tue, Jan 13, 2009 at 5:09 AM, Manlio Perillo wrote: > Galchin, Vasili ha scritto: > >> [...] >> I would like to help to develope any wrappers around POSIX API. >> >> >> ^^^ you are suggesting to change current wrapper API? >> >> > No, but I don't understand why to link code that seems to be not used. > > P.S.: is the problem I have reported riproducible? > > I'm on Linux Debian Lenny. > > > > Manlio Perillo > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/b7ab7c5f/attachment.htm From derek.a.elkins at gmail.com Tue Jan 13 23:24:26 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Jan 13 23:15:43 2009 Subject: [Haskell-cafe] Real World Haskell: confusion In-Reply-To: <496D3084.9000003@appsolutions.com> References: <5e0214850901130805h638625d1ge647a7fb278fc7e@mail.gmail.com> <1231868795.3917.25.camel@derek-laptop> <496D3084.9000003@appsolutions.com> Message-ID: <1231907066.3917.45.camel@derek-laptop> On Tue, 2009-01-13 at 19:23 -0500, Anton van Straaten wrote: > Derek Elkins wrote: > > No, it means exactly what you said it means. People abuse it to mean > > the second sense. Those people are wrong and there is already a term > > for that second sense, namely "partial application." I really wish > > people would stop conflating these terms*, all it does is create > > confusion. > > +1 > > > * A related annoyance is people who talk about languages "supporting > > currying and/or partial application." Unless one means that the > > language supports higher order functions at all by that, it doesn't make > > any sense. Haskell has no "support" for currying or partial > > application. The fact that most functions are in curried form in > > Haskell is merely a convention (with, admittedly strong -social- > > ramifications.) The only way one could say Haskell "supports" currying > > is that it has a lightweight notation for nested lambdas. > > Compared to most other languages, that lightweight notation makes enough > of a difference that it's reasonable to say that Haskell "supports > currying and partial application". > > E.g., in Haskell: > > f x y z = ... > > Haskell without the above notation: > > f x = \y -> \z -> ... This would be adequately lightweight for me, especially in a language that was impure. > > Javascript, to underscore the point: > > function f(x) { return function (y) { return function (z) { ... } } } This is what my javascript looks like. I guess I could implement some curry functions and write: curry3(function(x,y,z) { ... }) > > "Standard" Scheme: > > (define (f x) (lambda (y) (lambda (z) ...))) > > Scheme with a common macro to "support currying": > > (define (((f x) y) z) ...) > > That's just the function definition side. On the application side, > Haskell has a lightweight notation for application in general, i.e. you > write "f a b c" instead of e.g. "f(a)(b)(c)" in C-like syntaxes or > "(((f a) b) c)" in Lisp-like syntaxes. > > Together, these two sugary treats make it quite a bit more convenient > and practical to use currying and partial application in Haskell (and > ML, etc.), and this translates to *much* more use in practice. > > Anton I consider the notation "f(a)(b)(c)", both lightweight and ideal syntax for C-style languages. You really, really don't want it to look too much like normal application in those languages as the "f(a)" part in the above term can have significant side-effects, and otherwise it's almost as minimal as Haskell* which is the most minimal possible. I will agree that many languages have an extremely verbose syntax for lambda abstraction. A lightweight syntax for lambdas is very handy. A good example of this is Smalltalk's blocks which makes using HOFs for all control structures reasonable. (Smalltalk then messes things up as far as currying is concerned by having a verbose application syntax.) Can't account for poor tastes on the part of language designers, though some are getting hint including Javascript's designers. Examples: C#2.0: delegate(int x) { return delegate (int y) { return x + y; }; } C#3.0: x => y => x+y -- A lighter weight syntax for lambda than even Haskell! JS1.7: function(x) { return function(y) { return x + y } } JS1.8: function(x) function(y) x+y * In many cases, equally minimal: f(x+1)(2*x)(x+y) Javascript or Haskell? From sigbjorn.finne at gmail.com Tue Jan 13 23:31:04 2009 From: sigbjorn.finne at gmail.com (Sigbjorn Finne) Date: Tue Jan 13 23:22:19 2009 Subject: [Haskell-cafe] ANN: json-0.4.1 In-Reply-To: References: <496C12C3.4020500@gmail.com> Message-ID: <496D6A88.2050205@gmail.com> Thanks Bas for the helpful & clear advice. While I'm not on top of it yet why some installs of 6.10.1 experience this build failure, but others don't, I've put together an updated .cabal file + source dist that I hope gets at it. It's available from http://www.galois.com/~sof/json-0.4.1.tar.gz I've pointed Alex at this bundle earlier, but if others that have run into the same problem could test using above bits and see if that fixes it, that'd be great. If cool, I'll upload the bits to hackage. My apologies if this is breaking people's cabal builds at the moment. cheers --sigbjorn On 1/13/2009 11:58, Bas van Dijk wrote: > On Tue, Jan 13, 2009 at 8:47 PM, Alex Ott wrote: > >> Hello >> >> >>>>>>> "SF" == Sigbjorn Finne writes: >>>>>>> >> SF> Hi, a new release of the 'json' package is now available via hackage, >> SF> version 0.4.1 >> >> SF> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/json >> >> I tried to upgrade it via cabal on mac os x & linux (both use ghc 6.10.1) >> and it fails with >> >> Building json-0.4.1... >> >> Text/JSON/Generic.hs:33:7: >> Could not find module `Data.Generics': >> it was found in multiple packages: base-3.0.3.0 syb >> cabal: Error: some packages failed to install: >> json-0.4.1 failed during the building phase. The exception was: >> exit: ExitFailure 1 >> > > The standard solution for this is to add a cabal flag that controls > wether to depend on base-4 or base-3: > > ------------------------------------------------------ > flag small_base > description: Choose the new smaller, split-up base package. > > Library > if flag(small_base) > Build-Depends: base == 4.*, syb > CPP-Options: -DBASE_4 > else > Build-Depends: base == 3.* > ------------------------------------------------------ > > And use some CPP in your modules like this: > > ------------------------------------------------------ > {-# LANGUAGE CPP #-} > > #ifdef BASE_4 > import Data.Data (Data) > #else > import Data.Generics (Data) > #endif > ------------------------------------------------------ > > See for example how I do it in http://code.haskell.org/Stream > > regards, > > Bas From allbery at ece.cmu.edu Tue Jan 13 23:32:04 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Jan 13 23:23:21 2009 Subject: [Haskell-cafe] Slow Text.JSON parser In-Reply-To: <56073450-3F70-477F-A4F9-0E9CE776AA02@ece.cmu.edu> References: <3e62d4360901130416x78e37771od30311ca5abea69f@mail.gmail.com> <87d4er5nbm.fsf@malde.org> <20090113150050.GB6422@scytale.galois.com> <1691A507-AFBA-417A-8A84-0C5F5B06BCAB@w3future.com> <7ca3f0160901131542j36d0d455je8dee9ca9aec7f7e@mail.gmail.com> <97CFFA0B-3B6A-4967-802B-EF93BE12393E@w3future.com> <56073450-3F70-477F-A4F9-0E9CE776AA02@ece.cmu.edu> Message-ID: <1135C093-48DC-42F9-8C26-915618A06783@ece.cmu.edu> On 2009 Jan 13, at 22:43, Brandon S. Allbery KF8NH wrote: > On 2009 Jan 13, at 18:54, Sjoerd Visscher wrote: >> It is not impossible, but a lot of work. And if you want to do it >> correctly you would have to support UTF-16 (BE of LE) and UTF-32 >> (BE of LE) as well. You can't expect someone to start writing utf >> encoders and decoders every time he needs a fast parser. > > ...whereas making a linked list of Word32 run quickly is trivial? Correction: a linked list of *indirect* Word32s. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/3c62093d/attachment.htm From DekuDekuplex at Yahoo.com Wed Jan 14 00:12:43 2009 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Wed Jan 14 00:03:59 2009 Subject: [Haskell-cafe] Re: posting newspaper article? References: <5ae4f2ba0901131822n1d6a1ccbtfbc474f1cdb47da8@mail.gmail.com> Message-ID: On Tue, 13 Jan 2009 20:22:55 -0600, "Galchin, Vasili" wrote: >[...] > > I don't want to risk the ire of the Haskell Cafe community. Is there >a moderator? I want to post an editorial by the Big Blue CEO which seems to >me to be very >interesting vis-a-vis the FPL community and Haskell in general. I have an >online subscription and can post to stimulate discussion. ???? Haskell-Cafe is not moderated, but the posting guidelines are available at "Mailing lists - HaskellWiki" (see http://haskell.org/haskellwiki/Mailing_lists). In general, if the quote is relevant to the functional programming language Haskell, and falls within the guidelines listed above as well as within the guidelines for fair use (see http://en.wikipedia.org/wiki/Fair_use), I can't see why it should "risk the ire of the Haskell Cafe community." The whole point of the mailing list should be to discuss Haskell and relevant topics. In addition, if the content of the editorial is related to beginner-level issues, you also have the option of posting to the Haskell-Beginners mailing list (see http://www.haskell.org/mailman/listinfo/beginners). -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ From vigalchin at gmail.com Wed Jan 14 00:13:52 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Wed Jan 14 00:05:06 2009 Subject: [Haskell-cafe] endian-ness .... Message-ID: <5ae4f2ba0901132113s1e767cb3q8631df5c1959e60c@mail.gmail.com> Hello, I am used to network-neutral endianness (TCP/IP) As far as "persistent" store, endian neutralness relies on a convention in a particular marshalling/serializing situation??? Sorry ... probably dumb question .. and I think I know the answer ... but "what the hey". I like to get a consensus answer. Regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090113/399fcba5/attachment.htm From jan.h.xie at gmail.com Wed Jan 14 00:16:50 2009 From: jan.h.xie at gmail.com (Xie Hanjian) Date: Wed Jan 14 00:08:17 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety In-Reply-To: <496D53B4.7060205@complete.org> References: <87eizkra83.fsf@nitai.hr> <20090108030656.GA4430@complete.org> <87hc48zv9g.fsf@nitai.hr> <49676DEC.9070208@complete.org> <87tz83vz3l.fsf@nitai.hr> <496CDF79.3030205@complete.org> <20090114021922.GA22414@aiur> <496D53B4.7060205@complete.org> Message-ID: <20090114051650.GA26036@aiur> * John Goerzen [2009-01-13 20:53:40 -0600]: > Xie Hanjian wrote: > > * John Goerzen [2009-01-13 12:37:45 -0600]: > > > > Redmine requires only ruby 1.8.6 and rails 2.1.2, which are both stable > > releases, so I think an upgrade of your ruby stack is very reasonable. > > It also requires a newer version of rake than is in Debian. Not a > problem as such, but you start working with gem install commands (and > their friends), and eventually find that after spending 30 minutes > installing/upgrading stuff, it bombs at the very end saying that some > component needed a newer version of something than is available, and it > can't install that component, so it's left the server hosed -- too new > to run the old version, not ready to accept the new. Great. > > It ought to have checked the dependencies *before* messing with my > system. And it ought not to have failed mysteriously anyhow. > > >> To anyone annoyed with Haskell's library install process: you have no > >> idea how good you have it unless you've tried Ruby and rails. > > > > Disagree. Rubygems is fairly easy to use. At lease, I can guess how to > > It is completely poorly documented on how to gem install something when > you don't have root. The gem(1) manpage is a joke. The online help > doesn't help much either. Turns out there is a magic combination of > undocumented environment variables and documented command-line options > that does it. Or at least, I *thought* it does it. > > The other problem about Rails is that code and data are inseparably > mixed. It will be just about impossible to install a rails app as a > Debian package because it needs write access to its install directory, > and this stuff is not easily configured to use /usr and /etc as appropriate. From your description it seems debian's rails stack mess you up, not ruby/rails itself. And I think install a rails app as a debian package is not a good idea. > > Anyhow, this is a Haskell list, so I'm not going to rant any more about > this here. I can give you details off-list if you like. It's touched a ok :-| Jan > nerve lately. > > -- John > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- jan=callcc{|jan|jan};jan.call(jan) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/d10aca24/attachment.bin From sanzhiyan at gmail.com Wed Jan 14 03:59:57 2009 From: sanzhiyan at gmail.com (Andrea Vezzosi) Date: Wed Jan 14 03:51:10 2009 Subject: [Haskell-cafe] [ANN] Working with HLint from Emacs In-Reply-To: References: Message-ID: <8625cd9c0901140059u6e083aedjc19d52852f1318c1@mail.gmail.com> Does it also let you apply a suggestion automatically? From ndmitchell at gmail.com Wed Jan 14 04:15:59 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Jan 14 04:07:13 2009 Subject: [Haskell-cafe] Re: [ANN] Working with HLint from Emacs In-Reply-To: <878wpf7yus.fsf@nitai.hr> References: <878wpf7yus.fsf@nitai.hr> Message-ID: <404396ef0901140115x42a272e3sa0e66051b1679bfc@mail.gmail.com> Hi Gour, > Alex> Module is available from > Alex> http://xtalk.msk.su/~ott/common/emacs/hs-lint.el > > Module is not under some dvcs? I put it in the main HLint repo last night: http://www.cs.york.ac.uk/fp/darcs/hlint/data/hs-lint.el Please send all patches for this particular file via Alex. Thanks Neil From RafaelGCPP.Linux at gmail.com Wed Jan 14 05:02:20 2009 From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto) Date: Wed Jan 14 04:53:36 2009 Subject: [Haskell-cafe] Re: The problem with Monads... In-Reply-To: <496D1E96.40500@gmx.net> References: <351ff25e0901130656k530348afj6633048d206d7f74@mail.gmail.com> <1231861860.17950.1.camel@jonathans-macbook> <351ff25e0901130809x22f5131dx60fede4bcf38b779@mail.gmail.com> <496D1E96.40500@gmx.net> Message-ID: <351ff25e0901140202n328c2741j3175e35ff8bbea1b@mail.gmail.com> Wadler's examples are way better than the ones in the documentation. But without his explanations of what he is doing, the examples alone are pretty worthless. I agree that all_about_monads could be a better source for the documentation, at least for completeness. But even there I would consider choosing simpler examples, like Wadler's expression evaluator. On Tue, Jan 13, 2009 at 21:07, Benedikt Huber wrote: > Rafael Gustavo da Cunha Pereira Pinto schrieb: > >> Yes, I've read it twice, and it is a nice explanation that "yes, the >> reader monad is an application and is a monad". How do I use it? Why not the >> function itself? How would the plumbing work in a real world example? >> > Hi Rafael, > > First of all, I agree that the documentation for mtl should be improved. > Especially Control.Monad.RWS and Control.Monad.List really need some more > information. > > The documentation for the Reader and Identity monad are quite detailled > though. They seem to be "inspired" by > http://www.haskell.org/all_about_monads/, which also has documentation on > Writer and Cont. > > Control.Monad.List is a good example for the lack of documentation: > There is a single sentence at the beginning > > "The List monad." > and then one declaration > > newtype ListT m a = ListT { runListT :: m [a] } > while the important information is hidden as one of many instance > declarations: > > Monad m => Functor (ListT m) > > Monad m => MonadPlus (ListT m) > > Btw, the quality of the examples in Control.Monad.Reader is debutable. From > Example 1: > > > -- The Reader monad, which implements this complicated check. > > calc_isCountCorrect :: Reader Bindings Bool > > calc_isCountCorrect = do > > count <- asks (lookupVar "count") > > bindings <- ask > > return (count == (Map.size bindings)) > > I think it is wrong (or weird at least) to call the function a 'Reader > monad'; the name 'calc_isCountCorrect' is horrible too (because of the calc_ > prefix), Finally, implementing > > > isCountCorrect :: Bindings -> Bool > > isCountCorrect bs = (bs Map.! "count") == Map.size bs > > using the Reader monad will convince everybody _not_ to use it. > > A suggestion: If license permits it, short versions of the articles on > all_about_monads would make a great documentation for mtl (except for RWS > and List, which are missing). > > benedikt > > > >> BTW, the article is really great as an brief introduction to monad >> transformers. For the whole concept of monads, my all time favorite is "The >> Haskell Programmer's Guide to the IO Monad" by Stefan Klinger. >> >> Chapters 14 to 19 of "Real World Haskell" also have a good introduction on >> the usage of the monads, but it lacks other monads, like the RWS or the >> Continuation... >> >> See, that is my point. The mathematical concept of monads is very >> palatable. The idea that monads are either patterns or structures to hide >> computations in sequence is also very easy to see. But how do we use them? >> Why should I use a Writer monad when I can use a (a,w) tuple? >> >> >> >> On Tue, Jan 13, 2009 at 13:51, Jonathan Cast > jonathanccast@fastmail.fm>> wrote: >> >> On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira >> Pinto >> wrote: >> > >> > Last night I was thinking on what makes monads so hard to take, and >> > came to a conclusion: the lack of a guided tour on the implemented >> > monads. >> >> ... >> >> > Inspired by the paper "Functional Programming with Overloading and >> > Higher-Order Polymorphism", >> > Mark P Jones >> > (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html >> ) >> > Advanced School of Functional Programming, 1995. >> > >> > SO WHAT? >> >> So have you read Jones' paper? Or do you have a *concrete* explanation >> of how it differs from your desired `guided tour'? >> >> jcc >> >> >> >> >> >> -- >> Rafael Gustavo da Cunha Pereira Pinto >> Electronic Engineer, MSc. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/d20383dc/attachment.htm From manlio_perillo at libero.it Wed Jan 14 06:03:09 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Jan 14 05:54:31 2009 Subject: [Haskell-cafe] Re: Issues with posix-realtime package In-Reply-To: <5ae4f2ba0901132007y674e73d0v4f8738976725db9a@mail.gmail.com> References: <5ae4f2ba0901091358j3e08366jad674d8b6ae69405@mail.gmail.com> <4967DDFD.2090105@libero.it> <5ae4f2ba0901092127p6228bb66ubf23b9b28e5f77c6@mail.gmail.com> <49688C16.8070506@libero.it> <5ae4f2ba0901101414m63725480ofe66069d3a8e7c04@mail.gmail.com> <49692321.6080308@libero.it> <5ae4f2ba0901101603kc6ed063ma599d80b07eccc79@mail.gmail.com> <496C7662.20508@libero.it> <5ae4f2ba0901132007y674e73d0v4f8738976725db9a@mail.gmail.com> Message-ID: <496DC66D.1040105@libero.it> Galchin, Vasili ha scritto: > Hi Manlio, > > Are you now talking about code in Code from HsUnix.h and execvpe.h? > Yes. Manlio From bugfact at gmail.com Wed Jan 14 06:30:11 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Wed Jan 14 06:21:24 2009 Subject: [Haskell-beginners] Re: [Haskell-cafe] The problem with Monads... In-Reply-To: References: <351ff25e0901130656k530348afj6633048d206d7f74@mail.gmail.com> <1231861860.17950.1.camel@jonathans-macbook> <16442B752A06A74AB4D9F9A5FF076E4B4DCAE8@ELON17P32001A.csfb.cs-group.com> <1231867639.3917.9.camel@derek-laptop> <351ff25e0901131035r16bdd19did9cce96e70d4352c@mail.gmail.com> Message-ID: > > I have written a reference manual for the basic Haskell monad functions, "A > Tour of the Haskell Monad functions". It contains a lot of examples. You can > find it at: > http://members.chello.nl/hjgtuyl/tourdemonad.html Wow! I like these examples. I'm a pragmatist, and although Haskell gave me the most intense joy I ever experienced with programming (and also frustrations ;-), I find it extremely difficult to learn it from research papers. But these small examples are exactly what I need, because my brain will easier recognize a pattern match with the specific examples, than with the abstract explanation (and I was pretty good at abstract algebra, but that's 20 years ago, and I filled these 2 decades with lots and lots of imperative and OO hacking ;-). I wish every function in every module in the documentation had an "examples" link next to the "source" link, or a link to examples on the wiki or something. I guess the smart computer scientists here will tell me that I need to lift my brain to learn to recognize abstract patterns, but I'm afraid this is not something that is given to all of us, certainly not in the short term. But I still want to enjoy Haskell, so keep the short examples coming :) > > As far as I know, there is no reference guide for advanced monads, like the > Reader, Writer and State monads. > > -- > Regards, > Henk-Jan van Tuyl > > > -- > http://functor.bamikanarie.com > http://Van.Tuyl.eu/ > -- > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/f8e570df/attachment.htm From ketil at malde.org Wed Jan 14 06:34:31 2009 From: ketil at malde.org (Ketil Malde) Date: Wed Jan 14 06:25:11 2009 Subject: [Haskell-cafe] Slow Text.JSON parser In-Reply-To: <1691A507-AFBA-417A-8A84-0C5F5B06BCAB@w3future.com> (Sjoerd Visscher's message of "Wed\, 14 Jan 2009 00\:39\:45 +0100") References: <3e62d4360901130416x78e37771od30311ca5abea69f@mail.gmail.com> <87d4er5nbm.fsf@malde.org> <20090113150050.GB6422@scytale.galois.com> <1691A507-AFBA-417A-8A84-0C5F5B06BCAB@w3future.com> Message-ID: <87wscy15q0.fsf@malde.org> Sjoerd Visscher writes: > JSON is a UNICODE format, like any modern format is today. ByteStrings > are not going to work. Well, neither is String as used in the code I responded to. I'm not intimately familiar with JSON, but I believe ByteStrings would work on UTF-8 input, and both ByteString and String would fail on UTF-16 and UTF-32. > If everybody starts yelling "ByteString" every time String performance > is an issue, I don't see how Haskell is ever going to be a "real world > programming language". Insisting on linked lists of 32-bit characters isn't going to help, either. I'm also looking forward to a fast, robust, and complete UniCode support, but the OP asked about performance. -k -- If I haven't seen further, it is by standing in the footprints of giants From duncan.coutts at worc.ox.ac.uk Wed Jan 14 06:46:10 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jan 14 06:37:21 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety In-Reply-To: <20090114021922.GA22414@aiur> References: <87eizkra83.fsf@nitai.hr> <20090108030656.GA4430@complete.org> <87hc48zv9g.fsf@nitai.hr> <49676DEC.9070208@complete.org> <87tz83vz3l.fsf@nitai.hr> <496CDF79.3030205@complete.org> <20090114021922.GA22414@aiur> Message-ID: <1231933570.28590.277.camel@localhost> On Wed, 2009-01-14 at 10:19 +0800, Xie Hanjian wrote: > * John Goerzen [2009-01-13 12:37:45 -0600]: > > > To anyone annoyed with Haskell's library install process: you have no > > idea how good you have it unless you've tried Ruby and rails. > > Disagree. Rubygems is fairly easy to use. At lease, I can guess how to > uninstall a package by trying 'gem uninstall foobar', but failed by > trying 'cabal uninstall/remove foobar' :-) It's a fair point. Patches gratefully accepted! :-) Duncan From briqueabraque at yahoo.com Wed Jan 14 06:59:46 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Wed Jan 14 06:51:22 2009 Subject: [Haskell-cafe] Recursive modules, GHC /= Report? Message-ID: Hi, Here: http://www.haskell.org/onlinereport/modules.html I read: "Modules may reference other modules via explicit import declarations, each giving the name of a module to be imported and specifying its entities to be imported. Modules may be mutually recursive." However, I get this from GHC: --- Module imports form a cycle for modules: main:Main imports: Control.Concurrent.MVar GtkMostrarConfig GtkLerECG Graphics.UI.Gtk main:GtkMostrarConfig imports: Control.Concurrent.MVar Graphics.UI.Gtk Main --- Aren't cycles of modules just recursive modules? Why wasn't that allowed? Thanks, Maur?cio From marlowsd at gmail.com Wed Jan 14 07:14:18 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jan 14 07:05:37 2009 Subject: [Haskell-cafe] HEADS UP: finalizer changes coming in GHC 6.10.2 Message-ID: <496DD71A.9060802@gmail.com> By popular demand, GHC 6.10.2 will support finalizers that are actually guaranteed to run, and run promptly. There aren't any API changes: this happens for finalizers created using newForeignPtr as normal. However, there's a catch. Previously it was possible to call back into Haskell from a finalizer (finalizers are C functions), by using foreign import "wrapper" or foreign export. According to the FFI spec, whether this is allowed or not is "system dependent". In GHC 6.10.1 and earlier it was allowed, but in 6.10.2 and later it is not. The reason being that C finalizers are now executed directly by the GC, when the runtime is not in a position to handle callbacks. You can still have fully-fledged Haskell finalizers if you want: we have Foreign.Concurrent.newForeignPtr for that purpose. But those finalizers are not subject to the same promptness guarantees that you get with C finalizers - they run in a separate thread, and are not guaranteed to be run at program exit. We'll make sure this is documented prominently in the 6.10.2 release notes, but I thought a heads-up would be a good idea right now as it turns out that there are existing libraries (e.g. LLVM) that will be affected. Cheers, Simon From briqueabraque at yahoo.com Wed Jan 14 07:14:28 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Wed Jan 14 07:05:49 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety In-Reply-To: <87zlhv6jvp.fsf@nitai.hr> References: <87eizkra83.fsf@nitai.hr> <87prirvz1j.fsf@nitai.hr> <87zlhv6jvp.fsf@nitai.hr> Message-ID: > Mauricio> No. Only sqlite3_exec with INSERT, SELECT stuff, > Mauricio> and saving everything that needs structure in pseudo-xml > Mauricio> strings. Not that efficient, but easy to change to blobs when > Mauricio> everything is ready and tested. > > I see...I'm thinking to maybe store only paths for bigger BLOBs, but > still there is need to store smaller (thumbnails pics) ones... > You can always uuencode the pictures. Package 'dataenc' seems nice, although I have not used it. Best, Maur?cio From naur at post11.tele.dk Wed Jan 14 07:53:39 2009 From: naur at post11.tele.dk (Thorkil Naur) Date: Wed Jan 14 07:46:29 2009 Subject: [Haskell-cafe] Recursive modules, GHC /= Report? In-Reply-To: References: Message-ID: <200901141353.42431.naur@post11.tele.dk> Hello, On Wednesday 14 January 2009 12:59, Mauricio wrote: > Hi, > > Here: > > http://www.haskell.org/onlinereport/modules.html > > I read: > > "Modules may reference other modules via > explicit import declarations, each giving > the name of a module to be imported and > specifying its entities to be imported. > Modules may be mutually recursive." > > However, I get this from GHC: > > --- > Module imports form a cycle for modules: > main:Main > imports: Control.Concurrent.MVar GtkMostrarConfig GtkLerECG > Graphics.UI.Gtk > main:GtkMostrarConfig > imports: Control.Concurrent.MVar Graphics.UI.Gtk Main > --- > > Aren't cycles of modules just recursive modules? Why > wasn't that allowed? Have you looked at http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#mutual-recursion ? I never tried this myself, but it seems to explain some important details about how to compile mutually recursive modules using GHC. > > Thanks, > Maur?cio > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > Best regards Thorkil From marlowsd at gmail.com Wed Jan 14 08:40:10 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jan 14 08:31:26 2009 Subject: [Haskell-cafe] Re: real haskell difficulties (at least for me) In-Reply-To: <20090114075837.f78b3a56.mle+cl@mega-nerd.com> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <10ed1a750901130821m9b3e8fev2528a0877ebf6be1@mail.gmail.com> <20090113171336.GD6699@scytale.galois.com> <20090114075837.f78b3a56.mle+cl@mega-nerd.com> Message-ID: <496DEB3A.6080108@gmail.com> Erik de Castro Lopo wrote: > Don Stewart wrote: > >> Well, the number one thing is to use Cabal and the cabal-install tool. >> That is the simplest way to avoid headaches. > > I'm sure cabal works very well for many people, but for anyone who > has used Debian based distributions for some time, cabal really > does seem like a backward step. > > For instance, I regularly develop on 6 machines; personal laptop, > home desktop, 2 work desktops and 2 work build machines. > > At work, the main output of my development work is Debian packages > (which get installed on hundreds of machines), and the Debian packages > I create have build depends on whatever compilers and libraries are > required to build them. We also have a build bot that runs nightly > in a clean chroot for each package so that build depends can be > verified to be correct. > > However, if I install compilers or libraries using cabal there is > no package to build depend on, breaking a system which currently > works very, very well for all the code we build in C, C++ and > Ocaml. Just in case this isn't clear yet - Cabal is not meant to be a replacement for native Debian packages, it is supposed to let the Debian folks package Haskell stuff more easily. We didn't want to duplicate everything that a good OS packaging system does in Cabal, that's just a waste of time and likely to conflict with what the OS packager is already doing. Sounds like the Debian folks could use some help with automatically packaging Cabal packages, though. Cheers, Simon From alexott at gmail.com Wed Jan 14 08:44:33 2009 From: alexott at gmail.com (Alex Ott) Date: Wed Jan 14 08:35:47 2009 Subject: [Haskell-cafe] [ANN] Working with HLint from Emacs In-Reply-To: <8625cd9c0901140059u6e083aedjc19d52852f1318c1@mail.gmail.com> (Andrea Vezzosi's message of "Wed, 14 Jan 2009 09:59:57 +0100") References: <8625cd9c0901140059u6e083aedjc19d52852f1318c1@mail.gmail.com> Message-ID: <87tz82dmta.fsf@gmail.com> >>>>> "AV" == Andrea Vezzosi writes: AV> Does it also let you apply a suggestion automatically? Not, i'll look for this suggestion, but i'm not sure, that this is possible -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/ http://xtalk.msk.su/~ott/ http://alexott-ru.blogspot.com/ From manlio_perillo at libero.it Wed Jan 14 09:02:22 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Jan 14 08:53:40 2009 Subject: [Haskell-cafe] about System.Posix.Files.fileAccess Message-ID: <496DF06E.6070602@libero.it> Hi. This is of course a personal opinion, but I think the interface of: fileAccess :: FilePath -> Bool -> Bool -> Bool -> IO Bool http://haskell.org/ghc/docs/latest/html/libraries/unix/System-Posix-Files.html#v:fileAccess is not very good. Is it possible to design (in theory) a better interface? Thanks Manlio Perillo From lemming at henning-thielemann.de Wed Jan 14 09:26:44 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Jan 14 09:17:55 2009 Subject: [Haskell-cafe] Maintaining laziness In-Reply-To: <60B73B62-9342-4972-AE32-F220B6E9B53E@informatik.uni-kiel.de> References: <715BD1A7-EBEA-4B88-A11F-599DE9E27428@informatik.uni-kiel.de> <9158C9F5-F937-48F4-B2CF-74A1C0086835@informatik.uni-kiel.de> <60B73B62-9342-4972-AE32-F220B6E9B53E@informatik.uni-kiel.de> Message-ID: On Tue, 13 Jan 2009, Jan Christiansen wrote: > I would be very interested in functions that can be improved with respect to > non-strictness as test cases for my work. See the List functions in http://hackage.haskell.org/cgi-bin/hackage-scripts/package/utility-ht Version 0.0.1 was before applying StrictCheck, 0.0.2 after processing its suggestions. I have stopped when I saw that it repeatedly shows examples where I expect, that they are unresolvable. From manlio_perillo at libero.it Wed Jan 14 09:49:21 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Jan 14 09:40:41 2009 Subject: [Haskell-cafe] walking a directory tree efficiently In-Reply-To: <20090113232708.GE7815@scytale.galois.com> References: <496D1BBD.8060101@libero.it> <20090113232708.GE7815@scytale.galois.com> Message-ID: <496DFB71.70109@libero.it> Don Stewart ha scritto: > manlio_perillo: >> Hi. >> >> During a tentative (quite unsuccessfull) to convert a simple Python >> script that prints on stdout a directory and all its subdirectory [1] in >> a good Haskell (mostly to start to do real practice with the language), >> I came across this blog post: >> http://blog.moertel.com/articles/2007/03/28/directory-tree-printing-in-haskell-part-three-lazy-i-o >> >> >> Since recently I read about alternatives to lazy IO (like iteratee), I'm >> curious to know if a flexible, efficient and safe alternative exists, >> for the task of display a directory tree. >> >> >> [1] http://paste.pocoo.org/show/99523/ >> > > If you can do it with strict IO in Python, do the same thing in Haskell > with System.IO.Strict. > It should be mechanical to translate Python > programs directly into naive IO-based Haskell using strict IO. Boring, > but mechanical. > But that's not the purpose of what I'm doing ;). I'm trying to practice with Haskell, by converting small Python scripts I have written. I hope, in future, to write a "big" program in Haskell. > There's no iteratee/fold-based IO system yet. > Yes, I know. By the way, I have managed to have a working program: http://hpaste.org/13919 I would like to receive some advices: 1) I have avoided the do notation, using functions like liftM. Is this a good practice? Is this as efficient as using do notation? 2) I have written some support functions: mapM' and filterM' Are they well written and generic? Are they already available in some package? Can you suggest better names? 3) I find (,) node `liftM` walkTree' path not very readable. Is it possible to express it in a more (not too much) verbose way? Thanks Manlio Perillo From manlio_perillo at libero.it Wed Jan 14 09:59:28 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Jan 14 09:50:40 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python Message-ID: <496DFDD0.1010109@libero.it> Hi. There are two features found in Python language, that I would like to see in Haskell. 1) In a Python string it is available the \U{name} escape, where name is a character name in the Unicode database. As an example: foo = u"abc\N{VULGAR FRACTION ONE HALF}" 2) In Python it is possible to import modules inside a function. In Haskell something like: joinPath' root name = joinPath [root, name] importing System.FilePath (joinPath) Thanks Manlio Perillo From johan.tibell at gmail.com Wed Jan 14 10:09:10 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Jan 14 10:00:27 2009 Subject: [Haskell-cafe] HEADS UP: finalizer changes coming in GHC 6.10.2 In-Reply-To: <496DD71A.9060802@gmail.com> References: <496DD71A.9060802@gmail.com> Message-ID: <90889fe70901140709q4c412708oed729c2df0b0fd05@mail.gmail.com> On Wed, Jan 14, 2009 at 1:14 PM, Simon Marlow wrote: > By popular demand, GHC 6.10.2 will support finalizers that are actually > guaranteed to run, and run promptly. There aren't any API changes: this > happens for finalizers created using newForeignPtr as normal. Does this effect GC performance even if you don't use finalizers? My knowledge of how finalizers affect GC performance is limited but now and then I stumble on some Java article (e.g. [1]) that claims that they can slow things down. That's no problem if there's no additional cost added to code which doesn't use finalizers. 1. http://java2go.blogspot.com/2007/09/javaone-2007-performance-tips-2-finish.html Cheers, Johan From ndmitchell at gmail.com Wed Jan 14 10:12:42 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Jan 14 10:03:52 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <496DFDD0.1010109@libero.it> References: <496DFDD0.1010109@libero.it> Message-ID: <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> Hi > 1) In a Python string it is available the \U{name} escape, where name is > a character name in the Unicode database. > > As an example: > foo = u"abc\N{VULGAR FRACTION ONE HALF}" Hmm, looks nice, and sensible. But as soon as you've got \N{....} syntax I want: "foo\E{show i}bar" i.e. embed expressions in strings. I think this would be fantastic. > 2) In Python it is possible to import modules inside a function. > > In Haskell something like: > > joinPath' root name = > joinPath [root, name] > importing System.FilePath (joinPath) Looks a bit ugly, but kind of useful. I'd make the syntax: joinPath' root name = joinPath [root,name] where import System.FilePath(joinPath) It does mean you need to read an entire file to see what functions it imports, but perhaps that is the way it should be. I could also imagine a syntax: joinPath' root name = import.System.FilePath.joinPath [root,name] i.e. doing an import and use at the same time. Nice ideas, but they probably want implemented in a Haskell compiler and using in real life before they are ready for Haskell' like thoughts. Thanks Neil From noteed at gmail.com Wed Jan 14 10:16:48 2009 From: noteed at gmail.com (minh thu) Date: Wed Jan 14 10:07:57 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> Message-ID: <40a414c20901140716n4264a3b4g64789de2205ea069@mail.gmail.com> 2009/1/14 Neil Mitchell : > Hi > >> 1) In a Python string it is available the \U{name} escape, where name is >> a character name in the Unicode database. >> >> As an example: >> foo = u"abc\N{VULGAR FRACTION ONE HALF}" > > Hmm, looks nice, and sensible. But as soon as you've got \N{....} syntax I want: > > "foo\E{show i}bar" > > i.e. embed expressions in strings. I think this would be fantastic. Hi, why not simpy "foo\E{i}bar" ? >> 2) In Python it is possible to import modules inside a function. >> >> In Haskell something like: >> >> joinPath' root name = >> joinPath [root, name] >> importing System.FilePath (joinPath) > > Looks a bit ugly, but kind of useful. I'd make the syntax: > > joinPath' root name = joinPath [root,name] > where import System.FilePath(joinPath) > > It does mean you need to read an entire file to see what functions it > imports, but perhaps that is the way it should be. I could also > imagine a syntax: > > joinPath' root name = import.System.FilePath.joinPath [root,name] > > i.e. doing an import and use at the same time. and why not simply System.FilePath.joinPath (without the import.) ? Cheers, Thu From sigbjorn.finne at gmail.com Wed Jan 14 10:26:17 2009 From: sigbjorn.finne at gmail.com (Sigbjorn Finne) Date: Wed Jan 14 10:17:44 2009 Subject: [Haskell-cafe] HEADS UP: finalizer changes coming in GHC 6.10.2 In-Reply-To: <496DD71A.9060802@gmail.com> References: <496DD71A.9060802@gmail.com> Message-ID: <496E0419.3000504@gmail.com> Thanks Simon, great stuff; I like the introduction of these 'native code finalizers', they've been sorely missed at times. You don't say, but will there be a dynamic check to catch such re-entries? --sigbjorn On 1/14/2009 04:14, Simon Marlow wrote: > By popular demand, GHC 6.10.2 will support finalizers that are > actually guaranteed to run, and run promptly. There aren't any API > changes: this happens for finalizers created using newForeignPtr as > normal. > > However, there's a catch. Previously it was possible to call back > into Haskell from a finalizer (finalizers are C functions), by using > foreign import "wrapper" or foreign export. According to the FFI > spec, whether this is allowed or not is "system dependent". In GHC > 6.10.1 and earlier it was allowed, but in 6.10.2 and later it is not. > The reason being that C finalizers are now executed directly by the > GC, when the runtime is not in a position to handle callbacks. > > You can still have fully-fledged Haskell finalizers if you want: we > have Foreign.Concurrent.newForeignPtr for that purpose. But those > finalizers are not subject to the same promptness guarantees that you > get with C finalizers - they run in a separate thread, and are not > guaranteed to be run at program exit. > > We'll make sure this is documented prominently in the 6.10.2 release > notes, but I thought a heads-up would be a good idea right now as it > turns out that there are existing libraries (e.g. LLVM) that will be > affected. > > Cheers, > Simon > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ndmitchell at gmail.com Wed Jan 14 10:26:39 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Jan 14 10:18:11 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <40a414c20901140716n4264a3b4g64789de2205ea069@mail.gmail.com> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <40a414c20901140716n4264a3b4g64789de2205ea069@mail.gmail.com> Message-ID: <404396ef0901140726m45f5c4a2ra1b31914c7ec5898@mail.gmail.com> >>> As an example: >>> foo = u"abc\N{VULGAR FRACTION ONE HALF}" >> >> Hmm, looks nice, and sensible. But as soon as you've got \N{....} syntax I want: >> >> "foo\E{show i}bar" >> >> i.e. embed expressions in strings. I think this would be fantastic. > > why not simpy "foo\E{i}bar" ? What if i is a string? You'd get: foo"i"bar Having different behaviour for string vs everything else would be equally bad. >> joinPath' root name = import.System.FilePath.joinPath [root,name] >> >> i.e. doing an import and use at the same time. > > and why not simply System.FilePath.joinPath (without the import.) ? That is the same as saying everything is always in scope but fully qualified. I'd rather have to explicitly say which modules were being used - I'm not sure my enhanced import idea is a good idea at all. Thanks Neil From ithika at gmail.com Wed Jan 14 10:30:24 2009 From: ithika at gmail.com (Dougal Stanton) Date: Wed Jan 14 10:21:46 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> Message-ID: <2d3641330901140730t2e2815cevba4b138774e8c1f1@mail.gmail.com> On Wed, Jan 14, 2009 at 3:12 PM, Neil Mitchell wrote: >> 2) In Python it is possible to import modules inside a function. >> >> In Haskell something like: >> >> joinPath' root name = >> joinPath [root, name] >> importing System.FilePath (joinPath) > > Looks a bit ugly, but kind of useful. I'd make the syntax: > > joinPath' root name = joinPath [root,name] > where import System.FilePath(joinPath) > > It does mean you need to read an entire file to see what functions it > imports, but perhaps that is the way it should be. I could also > imagine a syntax: > > joinPath' root name = import.System.FilePath.joinPath [root,name] > > i.e. doing an import and use at the same time. > This can be done with a fully-qualified name (or two). Not quite as succinct, but I assume the scope of these imports is only local anyway. > joinPath root path = jp [root,filename path] > where jp = System.FilePath.joinPath > filename = System.FilePath.takeFileName or > joinPath root path = System.FilePath.joinPath [root,System.FilePath.takeFileName path] Cheers, D From marlowsd at gmail.com Wed Jan 14 10:35:33 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jan 14 10:26:49 2009 Subject: [Haskell-cafe] HEADS UP: finalizer changes coming in GHC 6.10.2 In-Reply-To: <90889fe70901140709q4c412708oed729c2df0b0fd05@mail.gmail.com> References: <496DD71A.9060802@gmail.com> <90889fe70901140709q4c412708oed729c2df0b0fd05@mail.gmail.com> Message-ID: <496E0645.6070102@gmail.com> Johan Tibell wrote: > On Wed, Jan 14, 2009 at 1:14 PM, Simon Marlow wrote: >> By popular demand, GHC 6.10.2 will support finalizers that are actually >> guaranteed to run, and run promptly. There aren't any API changes: this >> happens for finalizers created using newForeignPtr as normal. > > Does this effect GC performance even if you don't use finalizers? > > My knowledge of how finalizers affect GC performance is limited but > now and then I stumble on some Java article (e.g. [1]) that claims > that they can slow things down. That's no problem if there's no > additional cost added to code which doesn't use finalizers. Yes, having lots of finalizers could affect GC performance, but that hasn't changed. There are things we could do to speed it up, if it became a serious bottleneck - for example, we currently look at all the weak pointers on every GC, but we could separate them by generation like we do for threads. Cheers, Simon From marlowsd at gmail.com Wed Jan 14 10:36:19 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jan 14 10:27:41 2009 Subject: [Haskell-cafe] HEADS UP: finalizer changes coming in GHC 6.10.2 In-Reply-To: <496E0419.3000504@gmail.com> References: <496DD71A.9060802@gmail.com> <496E0419.3000504@gmail.com> Message-ID: <496E0673.30303@gmail.com> Sigbjorn Finne wrote: > Thanks Simon, > > great stuff; I like the introduction of these 'native code finalizers', > they've > been sorely missed at times. > > You don't say, but will there be a dynamic check to catch such re-entries? There is (now) a dynamic check, yes. Cheers, Simon From manlio_perillo at libero.it Wed Jan 14 10:39:27 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Jan 14 10:30:40 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> Message-ID: <496E072F.2050906@libero.it> Neil Mitchell ha scritto: > Hi > >> 1) In a Python string it is available the \U{name} escape, where name is >> a character name in the Unicode database. >> >> As an example: >> foo = u"abc\N{VULGAR FRACTION ONE HALF}" > > Hmm, looks nice, and sensible. But as soon as you've got \N{....} syntax I want: > > "foo\E{show i}bar" > How this should/can work? There is Text.Printf for this. > i.e. embed expressions in strings. I think this would be fantastic. > >> 2) In Python it is possible to import modules inside a function. >> >> In Haskell something like: >> >> joinPath' root name = >> joinPath [root, name] >> importing System.FilePath (joinPath) > > Looks a bit ugly, but kind of useful. I'd make the syntax: > > joinPath' root name = joinPath [root,name] > where import System.FilePath(joinPath) > It seems a good solution. > It does mean you need to read an entire file to see what functions it > imports, Yes. That's the same with Python. I use imports inside a function only with care. Sometime they are necessary, to avoid circular import problems (but this not a problem with Haskell). > [...] > Nice ideas, but they probably want implemented in a Haskell compiler > and using in real life before they are ready for Haskell' like > thoughts. > The first feature requires some works. As far as I know GHC does not support the Unicode database at all. It would be nice to have an Haskell interface for the CLDR (Common Locale Data Repository), like done in babel: http://babel.edgewall.org/ http://unicode.org/cldr/ > Thanks > > Neil > Regards Manlio Perillo From lennart at augustsson.net Wed Jan 14 11:41:24 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Jan 14 11:32:34 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> Message-ID: When Haskell was designed there was a bried discussion (if my memory serves me) to have import be a decl, so it could occur anywhere a normal declaration can occur. I kinda like the idea, but some people didn't and it never happened. -- Lennart On Wed, Jan 14, 2009 at 3:12 PM, Neil Mitchell wrote: > Hi > >> 1) In a Python string it is available the \U{name} escape, where name is >> a character name in the Unicode database. >> >> As an example: >> foo = u"abc\N{VULGAR FRACTION ONE HALF}" > > Hmm, looks nice, and sensible. But as soon as you've got \N{....} syntax I want: > > "foo\E{show i}bar" > > i.e. embed expressions in strings. I think this would be fantastic. > >> 2) In Python it is possible to import modules inside a function. >> >> In Haskell something like: >> >> joinPath' root name = >> joinPath [root, name] >> importing System.FilePath (joinPath) > > Looks a bit ugly, but kind of useful. I'd make the syntax: > > joinPath' root name = joinPath [root,name] > where import System.FilePath(joinPath) > > It does mean you need to read an entire file to see what functions it > imports, but perhaps that is the way it should be. I could also > imagine a syntax: > > joinPath' root name = import.System.FilePath.joinPath [root,name] > > i.e. doing an import and use at the same time. > > Nice ideas, but they probably want implemented in a Haskell compiler > and using in real life before they are ready for Haskell' like > thoughts. > > Thanks > > Neil > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ketil at malde.org Wed Jan 14 11:43:07 2009 From: ketil at malde.org (Ketil Malde) Date: Wed Jan 14 11:33:44 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> (Neil Mitchell's message of "Wed\, 14 Jan 2009 15\:12\:42 +0000") References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> Message-ID: <873aflyh2c.fsf@malde.org> "Neil Mitchell" writes: >> 1) In a Python string it is available the \U{name} escape, where name is >> a character name in the Unicode database. >> As an example: >> foo = u"abc\N{VULGAR FRACTION ONE HALF}" Why not: import Unicode.Entities as U foo = "abc"++U.vulgar_fraction_one_half > Hmm, looks nice, and sensible. But as soon as you've got \N{....} syntax I want: > > "foo\E{show i}bar" "foo"++show i++"bar" Change the language - save two characters. >> 2) In Python it is possible to import modules inside a function. >> >> In Haskell something like: >> >> joinPath' root name = >> joinPath [root, name] >> importing System.FilePath (joinPath) > It does mean you need to read an entire file to see Well, then you might as well allow multiple modules per file as per the recent discussion. And multi-module files will possibly let you achieve the desired encapsulation without actually changing the language. -k -- If I haven't seen further, it is by standing in the footprints of giants From vpkaihla at gmail.com Wed Jan 14 11:59:19 2009 From: vpkaihla at gmail.com (Vesa Kaihlavirta) Date: Wed Jan 14 11:50:30 2009 Subject: [Haskell-cafe] Re: Arch Haskell News: Jan 11 2009 In-Reply-To: References: <20090111223053.GA1296@scytale.galois.com> Message-ID: <25acdd550901140859r5006f3b4i9dd37b53c8d08782@mail.gmail.com> On Tue, Jan 13, 2009 at 9:27 PM, Peter Hercek wrote: > Hi, > > Any idea why ghc 6.10.1 is still in Testing repository on archlinux? I have some idea :P The obvious reason: we wanted to minimize the amount of breakage the upgrade would cause. My guess was that the most common usage pattern for ghc on Arch is building one's own xmonad config, and there's still no release version of xmonad-contrib that builds on ghc-6.10.1. --vk P.S. you might wanna consider subscribing to http://www.haskell.org/mailman/listinfo/arch-haskell From redcom at fedoms.com Wed Jan 14 12:21:51 2009 From: redcom at fedoms.com (=?iso-8859-15?Q?G=FCnther_Schmidt?=) Date: Wed Jan 14 12:13:18 2009 Subject: [Haskell-cafe] Stack Overflow, tail recursion and CPS Message-ID: Hi all, I get a stack overflow when I want to insert a huge, lazy list into a Map. I have changed the insertion algo to use foldl to make it tail-recursive but still get a stack overflow as the "insert" remains lazy. Could CPS be a solution in these cases? G?nther From agocorona at gmail.com Wed Jan 14 12:22:12 2009 From: agocorona at gmail.com (Alberto G. Corona ) Date: Wed Jan 14 12:14:06 2009 Subject: [Haskell-cafe] Monads aren't evil? I think they are. In-Reply-To: References: <20090108231652.24b75fe3@tritium.xx> Message-ID: The question of imperative versus pure declarative coding has brought to my mind some may be off-topic speculations. (so please don?t read it if you have no time to waste): I?m interested in the misterious relation bentween mathematics, algoritms and reality (see thisfor example). Functional programming is declarative, you can model the entire world functionally with no concern for the order of calculations. The world is mathematical. The laws of physics have no concern for sequencing. But CPUs and communications are basically sequential. Life is sequential, and programs run along the time coordinate. Whenever you have to run a program, you or your compiler must sequence it. The sequentiation must be done by you or your compiler or both. The functional declarative code can be sequenced on-the-run by the compiler in the CPU by the runtime. but IO is different. You have to create, explicitly or implicitly the sequence of IO actions because the external events in the external world are not controlled by you or the compiler. So you, the programmer are the responsible of sequencing effects in coordination with the external world. so every language must give you ways to express sequencing of actions. that is why, to interact with the external world you must think in terms of algorithms, that is , imperatively, no matter if you make the imperative-sequence (relatively) explicit with monads or if you make it trough pairs (state, value) or unsafePerformIO or whatever. You have to think imperatively either way, because yo HAVE TO construct a sequence. I think that the elegant option is to recognize this different algorithmic nature of IO by using the IO monad. In other terms, the appearance of input-output in a problem means that you modelize just a part of the whole system. the interaction with the part of the system that the program do not control appears as input output. if the program includes the model of the environment that give the input output (including perhaps a model of yourself), then, all the code may be side effects free and unobservable. Thus, input output is a measure of the lack of a priori information. Because this information is given and demanded at precide points in the time dimension with a quantitative (real time) or ordered (sequential) measure, then these impure considerations must be taken into account in the program. However, the above is nonsensical, because if you know everithing a priory, then you don?t have a problem, so you don?t need a program. Because problem solving is to cope with unknow data that appears AFTER the program has been created, in oder to produce output at the corrrect time, then the program must have timing on it. has an algoritmic nature, is not pure mathemathical. This applies indeed to all living beings, that respond to the environment, and this creates the notion of time. Concerning monadic code with no side effects, In mathematical terms, sequenced (monadic) code are mathematically different from declarative code: A function describes what in mathematics is called a "manifold" with a number of dimensions equal to the number of parameters. In the other side, a sequence describe a particular trayectory in a manifold, a ordered set of points in a wider manyfold surface. For this reason the latter must be described algorithmically. The former can be said that include all possible trajectories, and can be expressed declaratively. The latter is a sequence . You can use the former to construct the later, but you must express the sequence because you are defining the concrete trajectory in the general manifold that solve your concrete problem, not other infinite sets of related problems. This essentially applies also to IO. Well this does not imply that you must use monads for it. For example, a way to express a sequence is a list where each element is a function of the previous. The complier is forced to sequence it in the way you whant, but this happens also with monad evaluation. This can be exemplified with the laws of Newton: they are declarative. Like any phisical formula. has no concern for sequencing. But when you need to simulate the behaviour of a ballistic weapon, you must use a sequence of instructions( that include the l newton laws). (well, in this case the trajectory is continuous integrable and can be expressed in a single function. In this case, the manifold includes a unique trajectory, but this is not the case in ordinary discrete problems,) . So any language need declarative as well as imperative elements to program mathematical models as well as algorithms. Cheers Alberto. 2009/1/11 Apfelmus, Heinrich > Ertugrul Soeylemez wrote: > > Let me tell you that usually 90% of my code is > > monadic and there is really nothing wrong with that. I use especially > > State monads and StateT transformers very often, because they are > > convenient and are just a clean combinator frontend to what you would do > > manually without them: passing state. > > The insistence on avoiding monads by experienced Haskellers, in > particular on avoiding the IO monad, is motivated by the quest for > elegance. > > The IO and other monads make it easy to fall back to imperative > programming patterns to "get the job done". But do you really need to > pass state around? Or is there a more elegant solution, an abstraction > that makes everything fall into place automatically? Passing state is a > valid implementation tool, but it's not a design principle. > > > A good example is probably the HGL (Haskell Graphics Library), a small > vector graphics library which once shipped with Hugs. The core is the type > > Graphic > > which represents a drawing and whose semantics are roughly > > Graphic = Pixel -> Color > > There are primitive graphics like > > empty :: Graphic > polygon :: [Point] -> Graphic > > and you can combine graphics by laying them on top of each other > > over :: Graphic -> Graphic -> Graphic > > This is an elegant and pure interface for describing graphics. > > After having constructed a graphic, you'll also want to draw it on > screen, which can be done with the function > > drawInWindow :: Graphic -> Window -> IO () > > This function is in the IO monad because it has the side-effect of > changing the current window contents. But just because drawing on a > screen involves IO does not mean that using it for describing graphics > is a good idea. However, using IO for *implementing* the graphics type > is fine > > type Graphics = Window -> IO () > > empty = \w -> return () > polygon (p:ps) = \w -> moveTo p w >> mapM_ (\p -> lineTo p w) ps > over g1 g2 = \w -> g1 w >> g2 w > drawInWindow = id > > > Consciously excluding monads and restricting the design space to pure > functions is the basic tool of thought for finding such elegant > abstractions. As Paul Hudak said in his message "A regressive view of > support for imperative programming in Haskell" > > In my opinion one of the key principles in the design of Haskell has > been the insistence on purity. It is arguably what led the Haskell > designers to "discover" the monadic solution to IO, and is more > generally what inspired many researchers to "discover" purely > functional solutions to many seemingly imperative problems. > > http://article.gmane.org/gmane.comp.lang.haskell.cafe/27214 > > The philosophy of Haskell is that searching for purely functional > solution is well worth it. > > > Regards, > H. Apfelmus > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/71fc060f/attachment.htm From redcom at fedoms.com Wed Jan 14 12:30:48 2009 From: redcom at fedoms.com (=?iso-8859-15?Q?G=FCnther_Schmidt?=) Date: Wed Jan 14 12:22:00 2009 Subject: [Haskell-cafe] Stack Overflow, tail recursion and CPS In-Reply-To: <5e0214850901140927w969d14dj6c5be4bb4e64617e@mail.gmail.com> References: <5e0214850901140927w969d14dj6c5be4bb4e64617e@mail.gmail.com> Message-ID: Hi Eugene, tried that, but since the action to be evaluated is the insertion into a structure that won't work. The strictness here doesn't go deep enough, it stopps short. G?nther Am 14.01.2009, 18:27 Uhr, schrieb Eugene Kirpichov : > Use foldl' ? > > 2009/1/14 G?nther Schmidt : >> Hi all, >> >> I get a stack overflow when I want to insert a huge, lazy list into a >> Map. >> >> I have changed the insertion algo to use foldl to make it >> tail-recursive but >> still get a stack overflow as the "insert" remains lazy. >> >> Could CPS be a solution in these cases? >> >> G?nther >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> -- Erstellt mit Operas revolution?rem E-Mail-Modul: http://www.opera.com/mail/ From ndmitchell at gmail.com Wed Jan 14 12:32:18 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Jan 14 12:23:28 2009 Subject: [Haskell-cafe] Stack Overflow, tail recursion and CPS In-Reply-To: References: Message-ID: <404396ef0901140932v67ddf58agc7b6d46be6382783@mail.gmail.com> Hi > I have changed the insertion algo to use foldl to make it tail-recursive but > still get a stack overflow as the "insert" remains lazy. Try foldl' and insertWith' - that should work. Thanks Neil From jvranish at gmail.com Wed Jan 14 12:37:58 2009 From: jvranish at gmail.com (Job Vranish) Date: Wed Jan 14 12:29:08 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <873aflyh2c.fsf@malde.org> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <873aflyh2c.fsf@malde.org> Message-ID: What I would really like to see is locally scoped imports but with parameterized modules. (so modules could take types and values as parameters) The places where I most want a feature like this is when I have a group of helper functions that need a value that is outside the modules scope, but that in general doesn't change. Usually we just curry the functions, but that generates a lot of wasted code. A good example might be the token parsersin parsec. Rather than have something like this: whiteSpace= P.whiteSpace lexer lexeme = P.lexeme lexer symbol = P.symbol lexer natural = P.natural lexer ... We could do something like: import ParsecToken lexer Having an import/module feature like this would replace almost all cases where someone might wish for a macro system for Haskell. >> Hmm, looks nice, and sensible. But as soon as you've got \N{....} syntax I want: >> >> "foo\E{show i}bar" > > "foo"++show i++"bar" > >Change the language - save two characters. For simple cases, doing "foo" ++ show i ++ "bar" isn't bad at all, but when you have five or six or ten (show i)s that you want to mix in, it can get pretty hard to read. On Wed, Jan 14, 2009 at 11:43 AM, Ketil Malde wrote: > "Neil Mitchell" writes: > > >> 1) In a Python string it is available the \U{name} escape, where name is > >> a character name in the Unicode database. > > >> As an example: > >> foo = u"abc\N{VULGAR FRACTION ONE HALF}" > > Why not: > > import Unicode.Entities as U > > foo = "abc"++U.vulgar_fraction_one_half > > > Hmm, looks nice, and sensible. But as soon as you've got \N{....} syntax > I want: > > > > "foo\E{show i}bar" > > "foo"++show i++"bar" > > Change the language - save two characters. > > >> 2) In Python it is possible to import modules inside a function. > >> > >> In Haskell something like: > >> > >> joinPath' root name = > >> joinPath [root, name] > >> importing System.FilePath (joinPath) > > > It does mean you need to read an entire file to see > > Well, then you might as well allow multiple modules per file as per > the recent discussion. And multi-module files will possibly let you > achieve the desired encapsulation without actually changing the > language. > > -k > -- > If I haven't seen further, it is by standing in the footprints of giants > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/dae43710/attachment.htm From inforichland at gmail.com Wed Jan 14 12:48:38 2009 From: inforichland at gmail.com (Tim Wawrzynczak) Date: Wed Jan 14 12:39:54 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <873aflyh2c.fsf@malde.org> Message-ID: <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> Having an import/module feature like this would replace almost all cases > where someone might wish for a macro system for Haskell. > Don't say that until you've tried Lisp macros... read some of Paul Graham's essays or try some Common Lisp for yourself... macros can be an incredibly powerful tool, but "macros" from C, etc. aren't really macros, they're more like find-and-replace expressions :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/09f1c28d/attachment.htm From leimy2k at gmail.com Wed Jan 14 13:13:19 2009 From: leimy2k at gmail.com (David Leimbach) Date: Wed Jan 14 13:04:30 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> Message-ID: <3e1162e60901141013u72b98740r61302c3e294d99cf@mail.gmail.com> > > > joinPath' root name = import.System.FilePath.joinPath [root,name] > How is this different from joinPath' root name = System.FilePath.joinPath [root,name] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/f38f6125/attachment-0001.htm From leimy2k at gmail.com Wed Jan 14 13:15:19 2009 From: leimy2k at gmail.com (David Leimbach) Date: Wed Jan 14 13:06:28 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <3e1162e60901141013u72b98740r61302c3e294d99cf@mail.gmail.com> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <3e1162e60901141013u72b98740r61302c3e294d99cf@mail.gmail.com> Message-ID: <3e1162e60901141015ic165534oa2f1f4bda9b1b680@mail.gmail.com> On Wed, Jan 14, 2009 at 10:13 AM, David Leimbach wrote: > >> joinPath' root name = import.System.FilePath.joinPath [root,name] >> > > How is this different from > > joinPath' root name = System.FilePath.joinPath [root,name] > > > I'm sorry I didn't mean "different", I meant "better than"? I don't get the advantage. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/2363f869/attachment.htm From redcom at fedoms.com Wed Jan 14 13:19:46 2009 From: redcom at fedoms.com (=?iso-8859-15?Q?G=FCnther_Schmidt?=) Date: Wed Jan 14 13:10:57 2009 Subject: [Haskell-cafe] Stack Overflow, tail recursion and CPS In-Reply-To: <404396ef0901140932v67ddf58agc7b6d46be6382783@mail.gmail.com> References: <404396ef0901140932v67ddf58agc7b6d46be6382783@mail.gmail.com> Message-ID: Hello Neil, thanks, that did indeed work. I guess I shot myself in the foot a bit here ... Cause my real problem isn't actually with Map but with IxSet (from HAppS) which to my knowledge does not have some sort of strict insert function. Me trying to be really clever just used Map as a random example here quietly hoping to get confirmation for "Yes, CPS is the anwer to force evaluation here, keep digging in that direction boy", or a straight CPS solution which I then would just translate to my problem. Um ... Didn't work, you were to clever, thanks a bunch Neil :) G?nther Am 14.01.2009, 18:32 Uhr, schrieb Neil Mitchell : > Hi > >> I have changed the insertion algo to use foldl to make it >> tail-recursive but >> still get a stack overflow as the "insert" remains lazy. > > Try foldl' and insertWith' - that should work. > > Thanks > > Neil -- Erstellt mit Operas revolution?rem E-Mail-Modul: http://www.opera.com/mail/ From jvranish at gmail.com Wed Jan 14 13:23:09 2009 From: jvranish at gmail.com (Job Vranish) Date: Wed Jan 14 13:14:19 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <873aflyh2c.fsf@malde.org> <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> Message-ID: On Wed, Jan 14, 2009 at 12:48 PM, Tim Wawrzynczak wrote: > > >> Having an import/module feature like this would replace almost all cases where someone might wish for a macro system for Haskell. > > Don't say that until you've tried Lisp macros... read some of Paul Graham's essays or try some Common Lisp for yourself... macros can be an incredibly powerful tool, but "macros" from C, etc. aren't really macros, they're more like find-and-replace expressions :) You're probably right. I've played around with LISP macros a little, but it seems that most of the cases where you would use a macro in LISP you don't need one in haskell due to lazy evaluation. Although I haven't played around with them enough to say much one way or another. Do you know of a particular example where a macro would be a big help in haskell? From jonathanccast at fastmail.fm Wed Jan 14 13:37:06 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Jan 14 13:28:42 2009 Subject: [Haskell-cafe] Stack Overflow, tail recursion and CPS In-Reply-To: References: <404396ef0901140932v67ddf58agc7b6d46be6382783@mail.gmail.com> Message-ID: <1231958226.28651.18.camel@jcchost> On Wed, 2009-01-14 at 19:19 +0100, G?nther Schmidt wrote: > Hello Neil, > > thanks, that did indeed work. > > I guess I shot myself in the foot a bit here ... > > Cause my real problem isn't actually with Map but with IxSet (from HAppS) > which to my knowledge does not have some sort of strict insert function. Does it by any chance have a Control.Parallel.Strategies.NFData instance? If it should happen to, then replacing (I didn't look up the type of insert!) foldl insert empty xn with foldl' ((result.result) (`using` rnf) insert) empty xn (where result is the Semantic Editor Combinator[1] result e f = e . f) would give you as much strictness as possible. Which might not be an improvement. jcc [1] This term was invented by Conal Elliot at . Semantic Editor Combinators are a clever technique for making point-less code readable.[2] [2] Does making point-free code readable miss the point of point-free style? From inforichland at gmail.com Wed Jan 14 13:39:59 2009 From: inforichland at gmail.com (Tim Wawrzynczak) Date: Wed Jan 14 13:32:06 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <873aflyh2c.fsf@malde.org> <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> Message-ID: <4335a3260901141039m626f33dawda5d03b0ee990c97@mail.gmail.com> > > You're probably right. > I've played around with LISP macros a little, but it seems that most > of the cases where you would use a macro in LISP you don't need one in > haskell due to lazy evaluation. Although I haven't played around with > them enough to say much one way or another. > > Do you know of a particular example where a macro would be a big help > in haskell? > Well, like many good programming tools, Lisp macros are another abstraction, but instead of dealing with data, they deal with code. They are a syntactic abstraction. They're often described as "programs that write programs." We all know how much Haskell likes abstractions ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/c4cf48d0/attachment.htm From miguelimo38 at yandex.ru Wed Jan 14 13:46:20 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Wed Jan 14 13:37:36 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <4335a3260901141039m626f33dawda5d03b0ee990c97@mail.gmail.com> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <873aflyh2c.fsf@malde.org> <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> <4335a3260901141039m626f33dawda5d03b0ee990c97@mail.gmail.com> Message-ID: > Well, like many good programming tools, Lisp macros are another > abstraction, but instead of dealing with data, they deal with code. I didn't know Lisp puts such an emphasis on the difference between code and data. From jonathanccast at fastmail.fm Wed Jan 14 13:48:28 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Jan 14 13:40:03 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <4335a3260901141039m626f33dawda5d03b0ee990c97@mail.gmail.com> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <873aflyh2c.fsf@malde.org> <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> <4335a3260901141039m626f33dawda5d03b0ee990c97@mail.gmail.com> Message-ID: <1231958908.28651.24.camel@jcchost> On Wed, 2009-01-14 at 12:39 -0600, Tim Wawrzynczak wrote: > You're probably right. > I've played around with LISP macros a little, but it seems > that most > of the cases where you would use a macro in LISP you don't > need one in > haskell due to lazy evaluation. Although I haven't played > around with > them enough to say much one way or another. > > Do you know of a particular example where a macro would be a > big help > in haskell? > > Well, like many good programming tools, Lisp macros are another > abstraction, but instead of dealing with data, they deal with code. Haskell already has a couple of abstraction tools for dealing with code. One is called `first-class functions'; another is called `lazy evaluation'. > They are a syntactic abstraction. What is this good for? I suspect most Lisp macros are parametric in form, rather than really syntactic; I know that every example of a Lisp macro I've seen is parametric in form. Parametric macros --- macros that don't deconstruct their arguments --- don't usually need to be macros at all in modern functional languages. Do you have an example of a macro that can't be replaced by higher-order functions and laziness? > They're often described as "programs that write programs." So are code generators. The most common example of a code generator is probably YACC --- but Parsec replaces it, with better readability even, with first-class parsers (built atop first-class functions). jcc From martijn at van.steenbergen.nl Wed Jan 14 13:56:02 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Wed Jan 14 13:47:12 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <1231958908.28651.24.camel@jcchost> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <873aflyh2c.fsf@malde.org> <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> <4335a3260901141039m626f33dawda5d03b0ee990c97@mail.gmail.com> <1231958908.28651.24.camel@jcchost> Message-ID: <496E3542.5080403@van.steenbergen.nl> Jonathan Cast wrote: > Haskell already has a couple of abstraction tools for dealing with code. > One is called `first-class functions'; another is called `lazy > evaluation'. And for all the rest there is TH? M. From inforichland at gmail.com Wed Jan 14 13:58:47 2009 From: inforichland at gmail.com (Tim Wawrzynczak) Date: Wed Jan 14 13:49:57 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <496E3542.5080403@van.steenbergen.nl> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <873aflyh2c.fsf@malde.org> <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> <4335a3260901141039m626f33dawda5d03b0ee990c97@mail.gmail.com> <1231958908.28651.24.camel@jcchost> <496E3542.5080403@van.steenbergen.nl> Message-ID: <4335a3260901141058l6a5ee80ep94f3392e76c394a7@mail.gmail.com> On Wed, Jan 14, 2009 at 12:56 PM, Martijn van Steenbergen < martijn@van.steenbergen.nl> wrote: > Jonathan Cast wrote: > >> Haskell already has a couple of abstraction tools for dealing with code. >> One is called `first-class functions'; another is called `lazy >> evaluation'. >> > > And for all the rest there is TH? > > M. > > Woah fellas, I wasn't trying to start a flame war, I was merely commenting that those who have not used Lisp don't really understand the power that macros can have in a language (such as Lisp) that supports them, and where code and data can be used interchangeably. And I've never used TH so I can't comment on that. Don't worry, I'm on your side :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/46fa9a16/attachment.htm From martijn at van.steenbergen.nl Wed Jan 14 14:01:42 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Wed Jan 14 13:52:53 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <4335a3260901141058l6a5ee80ep94f3392e76c394a7@mail.gmail.com> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <873aflyh2c.fsf@malde.org> <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> <4335a3260901141039m626f33dawda5d03b0ee990c97@mail.gmail.com> <1231958908.28651.24.camel@jcchost> <496E3542.5080403@van.steenbergen.nl> <4335a3260901141058l6a5ee80ep94f3392e76c394a7@mail.gmail.com> Message-ID: <496E3696.5070908@van.steenbergen.nl> Tim Wawrzynczak wrote: > Woah fellas, I wasn't trying to start a flame war, I was merely > commenting that those who have not used Lisp don't really understand the > power that macros can have in a language (such as Lisp) that supports > them, and where code and data can be used interchangeably. And I've > never used TH so I can't comment on that. Don't worry, I'm on your side :) Oh, I didn't mean that in a bad way. :-) I was just thinking that if something turns out hard to express in pure functions, you can always resort to Template Haskell. Martijn. From max.rabkin at gmail.com Wed Jan 14 14:06:26 2009 From: max.rabkin at gmail.com (Max Rabkin) Date: Wed Jan 14 13:58:14 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <1231958908.28651.24.camel@jcchost> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <873aflyh2c.fsf@malde.org> <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> <4335a3260901141039m626f33dawda5d03b0ee990c97@mail.gmail.com> <1231958908.28651.24.camel@jcchost> Message-ID: On Wed, Jan 14, 2009 at 10:48 AM, Jonathan Cast wrote: > Do you have an example of > a macro that can't be replaced by higher-order functions and laziness? I believe I do: one macro I found useful when writing a web app in Lisp was something I called hash-bind, which binds variables to the values in a hashtable, with the variable names as keys. For example: (hash-bind (a b) hashtable body) == (let ((a (lookup hashtable "a")) (b (lookup hashtable "b")) body) I found this very useful in places where I was given URL request parameters in a hashtable and wanted to extract some variables from it. I don't believe it can be replaced by a higher order function (though I may be wrong). --Max From asandroq at gmail.com Wed Jan 14 14:11:57 2009 From: asandroq at gmail.com (Alex Queiroz) Date: Wed Jan 14 14:03:07 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <873aflyh2c.fsf@malde.org> <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> <4335a3260901141039m626f33dawda5d03b0ee990c97@mail.gmail.com> <1231958908.28651.24.camel@jcchost> Message-ID: <54e12800901141111p65d9e19cke05124c71e698e5b@mail.gmail.com> Hallo, On Wed, Jan 14, 2009 at 5:06 PM, Max Rabkin wrote: > On Wed, Jan 14, 2009 at 10:48 AM, Jonathan Cast > wrote: >> Do you have an example of >> a macro that can't be replaced by higher-order functions and laziness? > > I believe I do: one macro I found useful when writing a web app in > Lisp was something I called hash-bind, which binds variables to the > values in a hashtable, with the variable names as keys. For example: > I have one for binding GET/POST variables to regular variables transparently and with error checking, just inside the body of the macro. -- -alex http://www.ventonegro.org/ From jonathanccast at fastmail.fm Wed Jan 14 14:14:50 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Jan 14 14:06:26 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <873aflyh2c.fsf@malde.org> <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> <4335a3260901141039m626f33dawda5d03b0ee990c97@mail.gmail.com> <1231958908.28651.24.camel@jcchost> Message-ID: <1231960490.28651.32.camel@jcchost> On Wed, 2009-01-14 at 11:06 -0800, Max Rabkin wrote: > On Wed, Jan 14, 2009 at 10:48 AM, Jonathan Cast > wrote: > > Do you have an example of > > a macro that can't be replaced by higher-order functions and laziness? > > I believe I do: one macro I found useful when writing a web app in > Lisp was something I called hash-bind, which binds variables to the > values in a hashtable, with the variable names as keys. For example: > > (hash-bind (a b) hashtable body) > == > (let > ((a (lookup hashtable "a")) > (b (lookup hashtable "b")) > body) > > I found this very useful in places where I was given URL request > parameters in a hashtable and wanted to extract some variables from > it. I don't believe it can be replaced by a higher order function > (though I may be wrong). Thanks! When you *know* there's a good reason people say something, and can't find a good example of *why*, it's a tremendous relief when when you find one. Sort of restores your faith in humanity :) jcc From max.rabkin at gmail.com Wed Jan 14 14:16:13 2009 From: max.rabkin at gmail.com (Max Rabkin) Date: Wed Jan 14 14:07:24 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <54e12800901141111p65d9e19cke05124c71e698e5b@mail.gmail.com> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <873aflyh2c.fsf@malde.org> <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> <4335a3260901141039m626f33dawda5d03b0ee990c97@mail.gmail.com> <1231958908.28651.24.camel@jcchost> <54e12800901141111p65d9e19cke05124c71e698e5b@mail.gmail.com> Message-ID: On Wed, Jan 14, 2009 at 11:11 AM, Alex Queiroz wrote: > I have one for binding GET/POST variables to regular variables > transparently and with error checking, just inside the body of the > macro. Noooo! You reinvented PHP. What happens if a request variable shadows the name of another variable used in the body? > -- > -alex > http://www.ventonegro.org/ > From asandroq at gmail.com Wed Jan 14 14:21:37 2009 From: asandroq at gmail.com (Alex Queiroz) Date: Wed Jan 14 14:12:46 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: References: <496DFDD0.1010109@libero.it> <873aflyh2c.fsf@malde.org> <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> <4335a3260901141039m626f33dawda5d03b0ee990c97@mail.gmail.com> <1231958908.28651.24.camel@jcchost> <54e12800901141111p65d9e19cke05124c71e698e5b@mail.gmail.com> Message-ID: <54e12800901141121u6e77c32odab1d3c87875d62@mail.gmail.com> Hallo, On Wed, Jan 14, 2009 at 5:16 PM, Max Rabkin wrote: > On Wed, Jan 14, 2009 at 11:11 AM, Alex Queiroz wrote: >> I have one for binding GET/POST variables to regular variables >> transparently and with error checking, just inside the body of the >> macro. > > Noooo! You reinvented PHP. What happens if a request variable shadows > the name of another variable used in the body? > I list the variables I want to bind in the form. I do not ask to automatically bind all of them. :) (query-let (id name job salary) (if (> salary 1000) ...)) -- -alex http://www.ventonegro.org/ From inforichland at gmail.com Wed Jan 14 14:30:28 2009 From: inforichland at gmail.com (Tim Wawrzynczak) Date: Wed Jan 14 14:21:38 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <1231960490.28651.32.camel@jcchost> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <873aflyh2c.fsf@malde.org> <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> <4335a3260901141039m626f33dawda5d03b0ee990c97@mail.gmail.com> <1231958908.28651.24.camel@jcchost> <1231960490.28651.32.camel@jcchost> Message-ID: <4335a3260901141130u13ea20dfj936b53093bc4de4c@mail.gmail.com> On Wed, Jan 14, 2009 at 1:14 PM, Jonathan Cast wrote: > On Wed, 2009-01-14 at 11:06 -0800, Max Rabkin wrote: > > On Wed, Jan 14, 2009 at 10:48 AM, Jonathan Cast > > wrote: > > > Do you have an example of > > > a macro that can't be replaced by higher-order functions and laziness? > > > > I believe I do: one macro I found useful when writing a web app in > > Lisp was something I called hash-bind, which binds variables to the > > values in a hashtable, with the variable names as keys. For example: > > > > (hash-bind (a b) hashtable body) > > == > > (let > > ((a (lookup hashtable "a")) > > (b (lookup hashtable "b")) > > body) > > > > I found this very useful in places where I was given URL request > > parameters in a hashtable and wanted to extract some variables from > > it. I don't believe it can be replaced by a higher order function > > (though I may be wrong). > > Thanks! When you *know* there's a good reason people say something, and > can't find a good example of *why*, it's a tremendous relief when when > you find one. Sort of restores your faith in humanity :) > > jcc > > > I thought of another good case (Shamelessly stolen from Paul Graham's 'On Lisp'). When defining a function to average the results of the list, you could define avg like this: (defun avg (&rest args) (/ (apply #'+ args) (length args))) Or as a macro like this: (defmacro avg (&rest args) `(/ (+ ,@args) ,(length args))) The reason the macro is better is that the length of the list is known at compile time, so you don't need to traverse the list to calculate the length of the list. Food for thought, anyway. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/190b33fb/attachment.htm From max.rabkin at gmail.com Wed Jan 14 14:34:05 2009 From: max.rabkin at gmail.com (Max Rabkin) Date: Wed Jan 14 14:25:15 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <4335a3260901141130u13ea20dfj936b53093bc4de4c@mail.gmail.com> References: <496DFDD0.1010109@libero.it> <873aflyh2c.fsf@malde.org> <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> <4335a3260901141039m626f33dawda5d03b0ee990c97@mail.gmail.com> <1231958908.28651.24.camel@jcchost> <1231960490.28651.32.camel@jcchost> <4335a3260901141130u13ea20dfj936b53093bc4de4c@mail.gmail.com> Message-ID: 2009/1/14 Tim Wawrzynczak : > The reason the macro is better is that the length of the list is known at > compile time, so you don't need to traverse the list to calculate the length > of the list. Or you could use a real compiler (perhaps even a glorious one) that does constant folding when the list length is constant, but have your function still work when it isn't constant. --Max From mle+cl at mega-nerd.com Wed Jan 14 14:57:07 2009 From: mle+cl at mega-nerd.com (Erik de Castro Lopo) Date: Wed Jan 14 14:48:21 2009 Subject: [Haskell-cafe] Re: real haskell difficulties (at least for me) In-Reply-To: <496DEB3A.6080108@gmail.com> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <10ed1a750901130821m9b3e8fev2528a0877ebf6be1@mail.gmail.com> <20090113171336.GD6699@scytale.galois.com> <20090114075837.f78b3a56.mle+cl@mega-nerd.com> <496DEB3A.6080108@gmail.com> Message-ID: <20090115065707.39bbbc74.mle+cl@mega-nerd.com> Simon Marlow wrote: > Sounds like the Debian folks could use some help with automatically > packaging Cabal packages, though. Well I've joined the debian-haskell mailing list and I'll do what I can to help. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "I would buy a Mac today if I was not working at Microsoft." -- Senior Microsoft exective Jim Allchin in a 200 email to Bill Gates : http://www.iowaconsumercase.org/010807/PLEX_7264.pdf From tretriluxana.s at gmail.com Wed Jan 14 15:45:22 2009 From: tretriluxana.s at gmail.com (Sukit Tretriluxana) Date: Wed Jan 14 15:36:33 2009 Subject: [Haskell-cafe] Haskell and C++ program Message-ID: <8252533f0901141245i58c1ab5y43c56945eb5ec40f@mail.gmail.com> Hi all, I was looking around Stroustrup's website and found a simple program that he showed how standard library can be used to make the program succinct and safe. See http://www.research.att.com/~bs/bs_faq2.html#simple-program. I wondered how a Haskell program equivalent to it looks like and I came up with the code below. import qualified Control.Exception as E main = E.catch (interact reverseDouble) (\_ -> print "format error") reverseDouble = unlines . doIt . words where doIt = intro . toStrings . reverse . toDoubles . input toDoubles = map (read::String->Double) toStrings = map show input = takeWhile (/= "end") intro l = ("read " ++ (show $ length l) ++ " elements") : "elements in reversed order" : I'm not a Haskell expert and I am pretty sure that this is not the optimal form a Haskell program that's equivalent to the C++ one. So I would like to see, from the Haskell experts in this group, how else (of course better form) such a program can be written. Thanks, Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/bc3aa1bc/attachment.htm From andrewcoppin at btinternet.com Tue Jan 13 14:22:04 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Jan 14 16:09:14 2009 Subject: [Haskell-cafe] unfoldr [ANN: HLint 1.2] In-Reply-To: <1afdeaec0901131057p24f83fa2y577a41f74ab3edd5@mail.gmail.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <496A70D2.5020809@btinternet.com> <404396ef0901120033x3aca958btc3b7f35c02be29cf@mail.gmail.com> <496BA053.6020003@btinternet.com> <20090112214808.170b457d@greenrd.org> <496CD9C0.7060904@btinternet.com> <1afdeaec0901131057p24f83fa2y577a41f74ab3edd5@mail.gmail.com> Message-ID: <496CE9DC.8010302@btinternet.com> Colin Adams wrote: > 2009/1/13 Andrew Coppin : > > >> One of the wonderful things about Haskell is that almost any time anybody >> posts code, at least one person will think up an alternative but equivilent >> way of achieving the same goal - sometimes by radically different steps. >> >> Maybe we should have a name for this effect? >> > > Confusion. > This is a worthy addition to the Humour page, IMHO... :-D From andrewcoppin at btinternet.com Tue Jan 13 14:20:56 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Jan 14 16:09:39 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> Message-ID: <496CE998.6070508@btinternet.com> Krzysztof Skrz?tnicki wrote: > My experience from using GHC under Windows XP is very similar. Many > packages (especially those involving bindings to C packages) are at > least painful to build. > +1 Also have to love packages that use Unix-specific features as part of their build process. (I even found a page on the Wiki that recommends the use of Bash scripts. Hmm...) I vividle remember Dons repeatedly telling me that I should try out [some package who's name escapes me], and then discovering that it doesn't actually work on Windows at all. (Couldn't this critical information be included somewhere prominent on Hackage??) From andrewcoppin at btinternet.com Mon Jan 12 14:56:47 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Jan 14 16:10:01 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: <404396ef0901120041n678d96fay78edb005f0059bbc@mail.gmail.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <404396ef0901120041n678d96fay78edb005f0059bbc@mail.gmail.com> Message-ID: <496BA07F.8010004@btinternet.com> Neil Mitchell wrote: > I can't really be blamed for making mistakes before HLint ;-) > Don't worry - self-programming computers are just around the corner... ;-) From dons at galois.com Wed Jan 14 16:47:21 2009 From: dons at galois.com (Don Stewart) Date: Wed Jan 14 16:38:14 2009 Subject: [Haskell-cafe] about System.Posix.Files.fileAccess In-Reply-To: <496DF06E.6070602@libero.it> References: <496DF06E.6070602@libero.it> Message-ID: <20090114214721.GC14115@scytale.galois.com> manlio_perillo: > Hi. > > This is of course a personal opinion, but I think the interface of: > fileAccess :: FilePath -> Bool -> Bool -> Bool -> IO Bool > http://haskell.org/ghc/docs/latest/html/libraries/unix/System-Posix-Files.html#v:fileAccess > > is not very good. > > Is it possible to design (in theory) a better interface? > It is possible (in theory) to design a better interface. :) -- Don From jgoerzen at complete.org Wed Jan 14 17:35:45 2009 From: jgoerzen at complete.org (John Goerzen) Date: Wed Jan 14 17:27:03 2009 Subject: [Haskell-cafe] Looking for Haskellers on Windows In-Reply-To: <4968ED62.1040906@mail.ru> References: <4968B545.9050407@mail.ru> <4968C650.3090900@mail.ru> <4968D700.8040907@complete.org> <4968ED62.1040906@mail.ru> Message-ID: <496E68C1.3090704@complete.org> Thank you for the hint. Please try this patch: http://git.complete.org/hdbc-odbc?a=commitdiff_plain;h=55af38aac8df9f94498680bc54af173851c32d6c and let me know if it fixes the issue for you. -- John kyra wrote: > John Goerzen wrote: >> G?nther Schmidt wrote: >>> Kyra I've tried any sort of values to any sort of columns. I tried "insert >>> into somesinglecolumntable (someNumbercolumn) values (?)" [toSql 5] ... >>> and so on. >>> >>> So I'm not certain at all the error message does actually give the right >>> clue. >>> >>> It just blows no matter what. > > It seems, I've managed to track down the issue. > > Access ODBC driver doesn't support sqlDescribeParam. > > bindCol (Database/HDBC/ODBC/Statement.hsc) contains the following stub > for this: > > do poke pdtype #{const SQL_CHAR} > poke pcolsize 0 > poke pdecdigits 0 > > This does not work. > > I've made an experiment replacing 'poke pcolsize 0' with 'poke pcolsize > 255'. Now all integer or varchar bindings work! > > It seems simpleSqlColumns or something similar must be used. > > Cheers, > Kyra > From jonathanccast at fastmail.fm Wed Jan 14 17:41:23 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Jan 14 17:32:58 2009 Subject: [Haskell-cafe] Haskell and C++ program In-Reply-To: <8252533f0901141245i58c1ab5y43c56945eb5ec40f@mail.gmail.com> References: <8252533f0901141245i58c1ab5y43c56945eb5ec40f@mail.gmail.com> Message-ID: <1231972883.28651.58.camel@jcchost> On Wed, 2009-01-14 at 12:45 -0800, Sukit Tretriluxana wrote: > Hi all, > > I was looking around Stroustrup's website and found a simple program > that he showed how standard library can be used to make the program > succinct and safe. See > http://www.research.att.com/~bs/bs_faq2.html#simple-program. I > wondered how a Haskell program equivalent to it looks like and I came > up with the code below. > > import qualified Control.Exception as E > > main = E.catch (interact reverseDouble) (\_ -> print "format error") > > reverseDouble = unlines . doIt . words > where doIt = intro . toStrings . reverse . toDoubles . input > toDoubles = map (read::String->Double) > toStrings = map show > input = takeWhile (/= "end") > intro l = ("read " ++ (show $ length l) ++ " elements") : > "elements in reversed order" : My only criticism is that I find code written with lots of secondary definitions like this confusing; so I would inline most of the definitions: reverseDouble = unlines . intro . map show . reverse . map (read :: String -> Double) . takeWhile (/= "end") . words where intro l = ("read " ++ show (length l) ++ " elements") : "elements in reversed order" : l I observe also in passing that the cast on read is somewhat inelegant; in a real application, the consumer of map read's output would specify its type sufficiently that the cast would be un-necessary. For example, the program could be specified to compute sines instead: main = E.catch (interact unlines . intro . map (show . sin . read) . words) $ \ _ -> print "format error" where intro l = ("read " ++ show (length l) ++ " arguments") : "computed sins" : l (Others will no doubt object to the use of lazy I/O. I disagree in principle with those objections.) jcc PS Stroustrup's comments about vectors are at best half right; push_back may extend the vector's length correctly, but operator[] on a vector certainly does not do bounds checking. From bugfact at gmail.com Wed Jan 14 17:47:20 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Wed Jan 14 17:38:30 2009 Subject: [Haskell-cafe] Haskell and C++ program In-Reply-To: <1231972883.28651.58.camel@jcchost> References: <8252533f0901141245i58c1ab5y43c56945eb5ec40f@mail.gmail.com> <1231972883.28651.58.camel@jcchost> Message-ID: > > > PS Stroustrup's comments about vectors are at best half right; push_back > may extend the vector's length correctly, but operator[] on a vector > certainly does not do bounds checking. > Sure it does, depending on how you configured the STL library. But this is off topic :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/3d355b3b/attachment.htm From ithika at gmail.com Wed Jan 14 17:47:41 2009 From: ithika at gmail.com (Dougal Stanton) Date: Wed Jan 14 17:38:51 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <4335a3260901141130u13ea20dfj936b53093bc4de4c@mail.gmail.com> References: <496DFDD0.1010109@libero.it> <873aflyh2c.fsf@malde.org> <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> <4335a3260901141039m626f33dawda5d03b0ee990c97@mail.gmail.com> <1231958908.28651.24.camel@jcchost> <1231960490.28651.32.camel@jcchost> <4335a3260901141130u13ea20dfj936b53093bc4de4c@mail.gmail.com> Message-ID: <2d3641330901141447g41b82d42jf7bdb040c5b6aba0@mail.gmail.com> > (defun avg (&rest args) > (/ (apply #'+ args) (length args))) > > Or as a macro like this: > > (defmacro avg (&rest args) > `(/ (+ ,@args) ,(length args))) > > The reason the macro is better is that the length of the list is known at > compile time, so you don't need to traverse the list to calculate the length > of the list. > I'm trying to work out how awesome the (+) operator is that you can add the values together without needing to traverse the list ;-) D From duncan.coutts at worc.ox.ac.uk Wed Jan 14 17:48:52 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jan 14 17:40:06 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <496CE998.6070508@btinternet.com> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> Message-ID: <1231973332.28590.287.camel@localhost> On Tue, 2009-01-13 at 19:20 +0000, Andrew Coppin wrote: > I vividle remember Dons repeatedly telling me that I should try out > [some package who's name escapes me], and then discovering that it > doesn't actually work on Windows at all. (Couldn't this critical > information be included somewhere prominent on Hackage??) This critical information should be provided on each package page on Hackage. It's not quite as trivial as it looks however. If you'd like to help out, we're working on a new hackage-server that allows users to upload build reports. That way we hope to discover automatically which packages do and do not build on various platforms. The basics work but we need more help in polishing it up. Duncan From allbery at ece.cmu.edu Wed Jan 14 17:57:31 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Jan 14 17:48:41 2009 Subject: [Haskell-cafe] about System.Posix.Files.fileAccess In-Reply-To: <496DF06E.6070602@libero.it> References: <496DF06E.6070602@libero.it> Message-ID: <41492B19-8C59-4F9B-93F3-C5563FE20A83@ece.cmu.edu> On 2009 Jan 14, at 9:02, Manlio Perillo wrote: > This is of course a personal opinion, but I think the interface of: > fileAccess :: FilePath -> Bool -> Bool -> Bool -> IO Bool > http://haskell.org/ghc/docs/latest/html/libraries/unix/System-Posix-Files.html#v > :fileAccess > > is not very good. The underlying system call access() is strongly disrecommended, so it's not really worth a better interface. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From bulat.ziganshin at gmail.com Wed Jan 14 18:03:22 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Jan 14 17:55:29 2009 Subject: [Haskell-cafe] Haskell and C++ program In-Reply-To: <1231972883.28651.58.camel@jcchost> References: <8252533f0901141245i58c1ab5y43c56945eb5ec40f@mail.gmail.com> <1231972883.28651.58.camel@jcchost> Message-ID: <706840091.20090115020322@gmail.com> Hello Jonathan, Thursday, January 15, 2009, 1:41:23 AM, you wrote: > reverseDouble = > unlines > . intro > . map show > . reverse > . map (read :: String -> Double) > . takeWhile (/= "end") > . words using arrows, this may be reversed: reverseDouble = words >>> takeWhile (/= "end") ... > I observe also in passing that the cast on read is somewhat inelegant; > in a real application, the consumer of map read's output would specify > its type sufficiently that the cast would be un-necessary. in small scripts explicit read casts are rather common -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From asandroq at gmail.com Wed Jan 14 18:10:42 2009 From: asandroq at gmail.com (Alex Queiroz) Date: Wed Jan 14 18:01:51 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <2d3641330901141447g41b82d42jf7bdb040c5b6aba0@mail.gmail.com> References: <496DFDD0.1010109@libero.it> <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> <4335a3260901141039m626f33dawda5d03b0ee990c97@mail.gmail.com> <1231958908.28651.24.camel@jcchost> <1231960490.28651.32.camel@jcchost> <4335a3260901141130u13ea20dfj936b53093bc4de4c@mail.gmail.com> <2d3641330901141447g41b82d42jf7bdb040c5b6aba0@mail.gmail.com> Message-ID: <54e12800901141510u172606a1x16cb96296cbfc3e9@mail.gmail.com> Hallo, On Wed, Jan 14, 2009 at 8:47 PM, Dougal Stanton wrote: >> (defun avg (&rest args) >> (/ (apply #'+ args) (length args))) >> >> Or as a macro like this: >> >> (defmacro avg (&rest args) >> `(/ (+ ,@args) ,(length args))) >> >> The reason the macro is better is that the length of the list is known at >> compile time, so you don't need to traverse the list to calculate the length >> of the list. >> > > > I'm trying to work out how awesome the (+) operator is that you can > add the values together without needing to traverse the list ;-) > Don't need to traverse the list at run time, not compile (actually macro-expansion) time. Cheers, -- -alex http://www.ventonegro.org/ From manlio_perillo at libero.it Wed Jan 14 18:22:49 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Jan 14 18:14:03 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <1231973332.28590.287.camel@localhost> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> Message-ID: <496E73C9.8020002@libero.it> Duncan Coutts ha scritto: > On Tue, 2009-01-13 at 19:20 +0000, Andrew Coppin wrote: > >> I vividle remember Dons repeatedly telling me that I should try out >> [some package who's name escapes me], and then discovering that it >> doesn't actually work on Windows at all. (Couldn't this critical >> information be included somewhere prominent on Hackage??) > > This critical information should be provided on each package page on > Hackage. It's not quite as trivial as it looks however. > > If you'd like to help out, we're working on a new hackage-server that > allows users to upload build reports. That way we hope to discover > automatically which packages do and do not build on various platforms. > The basics work but we need more help in polishing it up. > Do you know buildbot? http://buildbot.net/trac > Duncan > Manlio Perillo From lennart at augustsson.net Wed Jan 14 18:47:02 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Jan 14 18:38:11 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <1231958908.28651.24.camel@jcchost> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <873aflyh2c.fsf@malde.org> <4335a3260901140948k429c130csd5b2dd6ed7458472@mail.gmail.com> <4335a3260901141039m626f33dawda5d03b0ee990c97@mail.gmail.com> <1231958908.28651.24.camel@jcchost> Message-ID: With macros you can define new variable binding constructs. That's something I occasionally miss in Haskell. -- Lennart On Wed, Jan 14, 2009 at 6:48 PM, Jonathan Cast wrote: > On Wed, 2009-01-14 at 12:39 -0600, Tim Wawrzynczak wrote: >> You're probably right. >> I've played around with LISP macros a little, but it seems >> that most >> of the cases where you would use a macro in LISP you don't >> need one in >> haskell due to lazy evaluation. Although I haven't played >> around with >> them enough to say much one way or another. >> >> Do you know of a particular example where a macro would be a >> big help >> in haskell? >> >> Well, like many good programming tools, Lisp macros are another >> abstraction, but instead of dealing with data, they deal with code. > > Haskell already has a couple of abstraction tools for dealing with code. > One is called `first-class functions'; another is called `lazy > evaluation'. > >> They are a syntactic abstraction. > > What is this good for? I suspect most Lisp macros are parametric in > form, rather than really syntactic; I know that every example of a Lisp > macro I've seen is parametric in form. Parametric macros --- macros > that don't deconstruct their arguments --- don't usually need to be > macros at all in modern functional languages. Do you have an example of > a macro that can't be replaced by higher-order functions and laziness? > >> They're often described as "programs that write programs." > > So are code generators. The most common example of a code generator is > probably YACC --- but Parsec replaces it, with better readability even, > with first-class parsers (built atop first-class functions). > > jcc > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From allbery at ece.cmu.edu Wed Jan 14 18:59:31 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Jan 14 18:50:42 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <404396ef0901140726m45f5c4a2ra1b31914c7ec5898@mail.gmail.com> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <40a414c20901140716n4264a3b4g64789de2205ea069@mail.gmail.com> <404396ef0901140726m45f5c4a2ra1b31914c7ec5898@mail.gmail.com> Message-ID: <48F9F43A-A840-4B4D-9055-B12AA075A78E@ece.cmu.edu> On 2009 Jan 14, at 10:26, Neil Mitchell wrote: >>>> As an example: >>>> foo = u"abc\N{VULGAR FRACTION ONE HALF}" >>> >>> Hmm, looks nice, and sensible. But as soon as you've got \N{....} >>> syntax I want: >>> >>> "foo\E{show i}bar" >>> >>> i.e. embed expressions in strings. I think this would be fantastic. >> >> why not simpy "foo\E{i}bar" ? > > What if i is a string? You'd get: foo"i"bar > > Having different behaviour for string vs everything else would be > equally bad. ...except that show already *has* different behavior for String vs. everything else. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Wed Jan 14 19:02:34 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Jan 14 18:53:45 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <496E072F.2050906@libero.it> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <496E072F.2050906@libero.it> Message-ID: On 2009 Jan 14, at 10:39, Manlio Perillo wrote: > Neil Mitchell ha scritto: >> Hi >>> 1) In a Python string it is available the \U{name} escape, where >>> name is >>> a character name in the Unicode database. >>> >>> As an example: >>> foo = u"abc\N{VULGAR FRACTION ONE HALF}" >> Hmm, looks nice, and sensible. But as soon as you've got \N{....} >> syntax I want: >> "foo\E{show i}bar" > > How this should/can work? > There is Text.Printf for this. I vaguely recall seeing some TH go by that did this (albeit with $() TH foo). > Sometime they are necessary, to avoid circular import problems (but > this not a problem with Haskell). ...in theory. In practice GHC needs help with circular imports, and some cycles might be impossible to resolve. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From jonathanccast at fastmail.fm Wed Jan 14 19:05:57 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Jan 14 18:57:34 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <48F9F43A-A840-4B4D-9055-B12AA075A78E@ece.cmu.edu> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <40a414c20901140716n4264a3b4g64789de2205ea069@mail.gmail.com> <404396ef0901140726m45f5c4a2ra1b31914c7ec5898@mail.gmail.com> <48F9F43A-A840-4B4D-9055-B12AA075A78E@ece.cmu.edu> Message-ID: <1231977957.28651.70.camel@jcchost> On Wed, 2009-01-14 at 18:59 -0500, Brandon S. Allbery KF8NH wrote: > On 2009 Jan 14, at 10:26, Neil Mitchell wrote: > >>>> As an example: > >>>> foo = u"abc\N{VULGAR FRACTION ONE HALF}" > >>> > >>> Hmm, looks nice, and sensible. But as soon as you've got \N{....} > >>> syntax I want: > >>> > >>> "foo\E{show i}bar" > >>> > >>> i.e. embed expressions in strings. I think this would be fantastic. > >> > >> why not simpy "foo\E{i}bar" ? > > > > What if i is a string? You'd get: foo"i"bar > > > > Having different behaviour for string vs everything else would be > > equally bad. > > ...except that show already *has* different behavior for String vs. > everything else. Technically, showList has different behavior for Char vs. everything else. And not necessarily for *everything* else. And that's very well *not* what he meant. jcc From paolo at hypersonic.it Wed Jan 14 19:04:38 2009 From: paolo at hypersonic.it (Paolo Losi) Date: Wed Jan 14 19:01:13 2009 Subject: [Haskell-cafe] Re: walking a directory tree efficiently In-Reply-To: <496DFB71.70109@libero.it> References: <496D1BBD.8060101@libero.it> <20090113232708.GE7815@scytale.galois.com> <496DFB71.70109@libero.it> Message-ID: <496E7D96.3090509@hypersonic.it> Hi Manlio Manlio Perillo wrote: > By the way, I have managed to have a working program: > http://hpaste.org/13919 I've made some some minor refinements according to my own tastes :-) http://hpaste.org/13919/diff?old=0&new=2 Please note that in both cases IO exceptions are not handled. > I would like to receive some advices: > 1) I have avoided the do notation, using functions like liftM. > Is this a good practice? Avoinding the do notation is not good in itself. If it improves readability, is ok. But IMHO should not be used as a "smell" for bad coding style. > Is this as efficient as using do notation? Note that the do notation is desugared by the compiler as one of the first steps. do print "foo" print "foo" is exactly equivalent to print "foo" >> print "foo" in terms of generated code > 2) I have written some support functions: mapM' and filterM' > Are they well written and generic? mapM' is generic and already implemented: fmap (Note that a Monad is also a Functor) filterM' is specific enough not to deserve any package filterM' = fmap . map I replaced its use with a solution that I like more... > Are they already available in some package? > Can you suggest better names? > 3) I find > (,) node `liftM` walkTree' path > not very readable. > Is it possible to express it in a more (not too much) verbose way? I find it readable... It's ok IMO. You'll quickly be able to read that expressions without even thinking (sooner that what you may think) > Thanks Manlio Perillo Paolo PS: Since I'm new to haskell as well, I hope you'll want to review _my_ code next turn ;-) From duncan.coutts at worc.ox.ac.uk Wed Jan 14 19:12:03 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jan 14 19:03:12 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <496E73C9.8020002@libero.it> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> Message-ID: <1231978323.28590.298.camel@localhost> On Thu, 2009-01-15 at 00:22 +0100, Manlio Perillo wrote: > Duncan Coutts ha scritto: > > On Tue, 2009-01-13 at 19:20 +0000, Andrew Coppin wrote: > > > >> I vividle remember Dons repeatedly telling me that I should try out > >> [some package who's name escapes me], and then discovering that it > >> doesn't actually work on Windows at all. (Couldn't this critical > >> information be included somewhere prominent on Hackage??) > > > > This critical information should be provided on each package page on > > Hackage. It's not quite as trivial as it looks however. > > > > If you'd like to help out, we're working on a new hackage-server that > > allows users to upload build reports. That way we hope to discover > > automatically which packages do and do not build on various platforms. > > The basics work but we need more help in polishing it up. > > > > Do you know buildbot? > http://buildbot.net/trac Yeah, it's great for some kinds of projects. For example it's used for ghc. However it is very centralised, synchronous and needs ssh on Windows. What we've implemented is using cabal-install to generate build logs and summary info and to upload that to the hackage server. The advantage is that we should get an order or two magnitude more results than if we used a handful of buildbots. It also means we do not have to administer the buildbots, people can administer their own cabal-install setups. We don't need to care so much about individual results if we have enough results. We plan to have two reporting modes, anonymous with minimal info, and non-anonymous with full build logs. So far we've got both but have not separated them yet. Duncan From lrpalmer at gmail.com Wed Jan 14 19:52:38 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Wed Jan 14 19:43:48 2009 Subject: [Haskell-cafe] Re: walking a directory tree efficiently In-Reply-To: <496E7D96.3090509@hypersonic.it> References: <496D1BBD.8060101@libero.it> <20090113232708.GE7815@scytale.galois.com> <496DFB71.70109@libero.it> <496E7D96.3090509@hypersonic.it> Message-ID: <7ca3f0160901141652p701c877ekff0945798268ab67@mail.gmail.com> On Wed, Jan 14, 2009 at 5:04 PM, Paolo Losi wrote: > > 2) I have written some support functions: mapM' and filterM' >> Are they well written and generic? >> > > mapM' is generic and already implemented: fmap > (Note that a Monad is also a Functor) Except for when it isn't, which is really annoying because it ought to be. I just pretend it is, and then grit my teeth and kill a baby when I get bitten. And mapM' is not fmap, but fmap.fmap (or liftM.map if you prefer). > > > filterM' is specific enough not to deserve any package > filterM' = fmap . map Uh, I think you're looking at the wrong one. filterM' :: (a -> m Bool) -> m [a] -> m [a] I would write this as: filterM' p = filterM p . return And then probably just go inline it. > that I like more... > > Are they already available in some package? >> Can you suggest better names? >> 3) I find >> (,) node `liftM` walkTree' path >> not very readable. >> Is it possible to express it in a more (not too much) verbose way? >> > > I find it readable... It's ok IMO. A bit ugly, perhaps. With the notation from Control.Applicative: (,) node <$> walkTree' path I would really like to be able to do a proper-looking tuple section though; (node,) <$> walkTree' path Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/98f7020a/attachment.htm From vigalchin at gmail.com Wed Jan 14 23:49:24 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Wed Jan 14 23:40:34 2009 Subject: [Haskell-cafe] software correctness ... can we in FPL step up to the plate?? Message-ID: <5ae4f2ba0901142049y32b7e5a1x90154e87057e3177@mail.gmail.com> http://www.businessweek.com/the_thread/techbeat/archives/2009/01/nsa_dhs_industr.html?link_position=link3 ... I think that http://www.galois.com is already doing as stated in the article/ ...... I sincerely think there is a segway for Haskell here with strong and static type checking.. ?? Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/ddf18f94/attachment.htm From vigalchin at gmail.com Thu Jan 15 00:38:06 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Jan 15 00:29:15 2009 Subject: [Haskell-cafe] Re: Issues with posix-realtime package In-Reply-To: <496DC66D.1040105@libero.it> References: <5ae4f2ba0901091358j3e08366jad674d8b6ae69405@mail.gmail.com> <4967DDFD.2090105@libero.it> <5ae4f2ba0901092127p6228bb66ubf23b9b28e5f77c6@mail.gmail.com> <49688C16.8070506@libero.it> <5ae4f2ba0901101414m63725480ofe66069d3a8e7c04@mail.gmail.com> <49692321.6080308@libero.it> <5ae4f2ba0901101603kc6ed063ma599d80b07eccc79@mail.gmail.com> <496C7662.20508@libero.it> <5ae4f2ba0901132007y674e73d0v4f8738976725db9a@mail.gmail.com> <496DC66D.1040105@libero.it> Message-ID: <5ae4f2ba0901142138w64ba8c60rf7b1646998cd8880@mail.gmail.com> Hi Manlio, ok .. yeh ... I will have to remove the code in HsUnix.h and/or remove references. Currently I am trying to finish another Haskell project. I don't think these include files shouldcause "correctness" problems, yes? If so, I will get to this problem later. ??? Regards, Vasili On Wed, Jan 14, 2009 at 5:03 AM, Manlio Perillo wrote: > Galchin, Vasili ha scritto: > >> Hi Manlio, >> >> Are you now talking about code in Code from HsUnix.h and execvpe.h? >> >> > Yes. > > > Manlio > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090114/3b1721a6/attachment.htm From ekirpichov at gmail.com Thu Jan 15 01:49:10 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Thu Jan 15 01:40:18 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <1231978323.28590.298.camel@localhost> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> <1231978323.28590.298.camel@localhost> Message-ID: <5e0214850901142249y92dbc31g42f9e0b2108b3cbd@mail.gmail.com> Would be nice if after a failed build cabal asked whether or not to upload its log immediately, and (on the hackage side) this led to an email being sent to the maintainer. 2009/1/15 Duncan Coutts : > On Thu, 2009-01-15 at 00:22 +0100, Manlio Perillo wrote: >> Duncan Coutts ha scritto: >> > On Tue, 2009-01-13 at 19:20 +0000, Andrew Coppin wrote: >> > >> >> I vividle remember Dons repeatedly telling me that I should try out >> >> [some package who's name escapes me], and then discovering that it >> >> doesn't actually work on Windows at all. (Couldn't this critical >> >> information be included somewhere prominent on Hackage??) >> > >> > This critical information should be provided on each package page on >> > Hackage. It's not quite as trivial as it looks however. >> > >> > If you'd like to help out, we're working on a new hackage-server that >> > allows users to upload build reports. That way we hope to discover >> > automatically which packages do and do not build on various platforms. >> > The basics work but we need more help in polishing it up. >> > >> >> Do you know buildbot? >> http://buildbot.net/trac > > Yeah, it's great for some kinds of projects. For example it's used for > ghc. However it is very centralised, synchronous and needs ssh on > Windows. > > What we've implemented is using cabal-install to generate build logs and > summary info and to upload that to the hackage server. The advantage is > that we should get an order or two magnitude more results than if we > used a handful of buildbots. It also means we do not have to administer > the buildbots, people can administer their own cabal-install setups. We > don't need to care so much about individual results if we have enough > results. > > We plan to have two reporting modes, anonymous with minimal info, and > non-anonymous with full build logs. So far we've got both but have not > separated them yet. > > Duncan > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- ??????? ???????? ??????????? ??????.??????? From gour at mail.inet.hr Thu Jan 15 02:00:04 2009 From: gour at mail.inet.hr (Gour) Date: Thu Jan 15 01:51:25 2009 Subject: [Haskell-cafe] Re: databases in Haskell & type-safety References: <87eizkra83.fsf@nitai.hr> <87prirvz1j.fsf@nitai.hr> <87zlhv6jvp.fsf@nitai.hr> Message-ID: <87mydtkqa3.fsf@gaura-nitai.no-ip.org> >>>>> "Mauricio" == Mauricio writes: Mauricio> You can always uuencode the pictures. Package 'dataenc' seems Mauricio> nice, although I have not used it. Thanks. It looks like a nice 'workaround' with base64 encoding. Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/fe4ef308/attachment.bin From sigbjorn.finne at gmail.com Thu Jan 15 02:55:42 2009 From: sigbjorn.finne at gmail.com (Sigbjorn Finne) Date: Thu Jan 15 02:47:07 2009 Subject: [Haskell-cafe] ANN: hs-dotnet, version 0.3.0 Message-ID: <496EEBFE.8050800@gmail.com> Hi, the first public release of hs-dotnet is now available - a pragmatic take on interoperating between Haskell (via GHC) and .NET. For downloads and (some) info, see: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hs-dotnet http://haskell.forkIO.com/dotnet Feedback most welcome, both on what's there and what you would like to see better handled/supported next. enjoy --sigbjorn From ekirpichov at gmail.com Thu Jan 15 02:59:00 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Thu Jan 15 02:50:08 2009 Subject: [Haskell-cafe] ANN: hs-dotnet, version 0.3.0 In-Reply-To: <496EEBFE.8050800@gmail.com> References: <496EEBFE.8050800@gmail.com> Message-ID: <5e0214850901142359p4f574d18w46741fe66d99233@mail.gmail.com> This is terrific, thank you! btw, this will allow to write Visual Haskell in Haskell :) 2009/1/15 Sigbjorn Finne : > Hi, > > the first public release of hs-dotnet is now available - a pragmatic > take on interoperating between Haskell (via GHC) and .NET. For > downloads and (some) info, see: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hs-dotnet > http://haskell.forkIO.com/dotnet > > Feedback most welcome, both on what's there and what you would like > to see better handled/supported next. > > enjoy > --sigbjorn > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From duncan.coutts at worc.ox.ac.uk Thu Jan 15 04:51:42 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 15 04:42:50 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <5e0214850901142249y92dbc31g42f9e0b2108b3cbd@mail.gmail.com> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> <1231978323.28590.298.camel@localhost> <5e0214850901142249y92dbc31g42f9e0b2108b3cbd@mail.gmail.com> Message-ID: <1232013102.28590.303.camel@localhost> On Thu, 2009-01-15 at 09:49 +0300, Eugene Kirpichov wrote: > Would be nice if after a failed build cabal asked whether or not to > upload its log immediately, and (on the hackage side) this led to an > email being sent to the maintainer. It should not be quite that synchronous but yes that's the general idea. Packages can fail to install for many reasons that are not the fault of the package author, for example missing C libraries. Also, I think maintainers would not be pleased to receive 10's of emails per day! :-) I think in practise it will have to be opt-in for package authors/maintainers and it should only send aggregated information (like "it appears not to work on windows with ghc-6.8"). Duncan From ekirpichov at gmail.com Thu Jan 15 05:06:23 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Thu Jan 15 04:57:30 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <1232013102.28590.303.camel@localhost> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> <1231978323.28590.298.camel@localhost> <5e0214850901142249y92dbc31g42f9e0b2108b3cbd@mail.gmail.com> <1232013102.28590.303.camel@localhost> Message-ID: <5e0214850901150206y735d9232q97c3bd693f59681a@mail.gmail.com> Well, I thought about these 10's of emails too; probably hackage could send an email when a new broken build arrives but only if there were no 'unresolved' broken builds before this one; or probably an email at the first broken build and a weekly email reminding "you've got some unresolved broken builds". As for missing C libraries: could cabal probably integrate with the native package manager (apt/rpm/..) and ask the user whether to invoke it to install these libraries in case they are missing? However, this is not a solution for Windows since there's no native package manager. An easier solution might be to add a (flag-dependent) "broken-build-message" field to .cabal files, where authors could put useful info to be printed when a build breaks, like, "have you installed libpcre?" or "please see troubleshooting.txt". /me promises to do some cabal tickets from the 'easy ticket list' after the last exam 2009/1/15 Duncan Coutts : > On Thu, 2009-01-15 at 09:49 +0300, Eugene Kirpichov wrote: >> Would be nice if after a failed build cabal asked whether or not to >> upload its log immediately, and (on the hackage side) this led to an >> email being sent to the maintainer. > > It should not be quite that synchronous but yes that's the general idea. > > Packages can fail to install for many reasons that are not the fault of > the package author, for example missing C libraries. Also, I think > maintainers would not be pleased to receive 10's of emails per day! :-) > I think in practise it will have to be opt-in for package > authors/maintainers and it should only send aggregated information (like > "it appears not to work on windows with ghc-6.8"). > > Duncan > > > From manlio_perillo at libero.it Thu Jan 15 05:53:07 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Thu Jan 15 05:44:20 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <2076f2f90901142200t181f0dabw487a08df8a081d14@mail.gmail.com> References: <496DFDD0.1010109@libero.it> <2076f2f90901142200t181f0dabw487a08df8a081d14@mail.gmail.com> Message-ID: <496F1593.80800@libero.it> Artyom Shalkhakov ha scritto: > Hi Manlio, > Hi Artyom. Note that it seems you have sent this message only to me; I'm sending the reply to both you and the mailing list. > 2009/1/14 Manlio Perillo : >> 2) In Python it is possible to import modules inside a function. >> >> In Haskell something like: >> >> joinPath' root name = >> joinPath [root, name] >> importing System.FilePath (joinPath) > > I guess you're talking about first-class modules, the ones that > might be passed to functions as arguments, returned from functions > as a result, loaded at run-time, etc. No, I was not going that far :). I simply was proposing a method to keep imported definitions local to a function. By the way, here is a strange (for me) problem I hit, and made me think about this extension. Suppose a file foo.hs defines: import Control.Monad import System.Posix.Files as PF isDirectory :: FilePath -> IO Bool isDirectory path = PF.isDirectory `liftM` PF.getFileStatus path If I try to load the file from ghci I get: Prelude> :l foo.hs [1 of 1] Compiling Main ( foo.hs, interpreted ) Ok, modules loaded: Main. *Main> isDirectory "/var" :1:0: Ambiguous occurrence `isDirectory' It could refer to either `Main.isDirectory', defined at foo.hs:6:0 or `PF.isDirectory', imported from System.Posix.Files at foo.hs:2:0-30 > [...] Manlio Perillo From manlio_perillo at libero.it Thu Jan 15 05:55:36 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Thu Jan 15 05:46:48 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <496E072F.2050906@libero.it> Message-ID: <496F1628.3040901@libero.it> Brandon S. Allbery KF8NH ha scritto: > > [... about Python import local to functions ...] > >> Sometime they are necessary, to avoid circular import problems (but >> this not a problem with Haskell). > > ...in theory. In practice GHC needs help with circular imports, and some > cycles might be impossible to resolve. > This is interesting. Where can I find some examples? Is this explained in the Real World Haskell book? Thanks Manlio Perillo From manlio_perillo at libero.it Thu Jan 15 05:57:35 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Thu Jan 15 05:48:46 2009 Subject: [Haskell-cafe] about System.Posix.Files.fileAccess In-Reply-To: <41492B19-8C59-4F9B-93F3-C5563FE20A83@ece.cmu.edu> References: <496DF06E.6070602@libero.it> <41492B19-8C59-4F9B-93F3-C5563FE20A83@ece.cmu.edu> Message-ID: <496F169F.20901@libero.it> Brandon S. Allbery KF8NH ha scritto: > On 2009 Jan 14, at 9:02, Manlio Perillo wrote: >> This is of course a personal opinion, but I think the interface of: >> fileAccess :: FilePath -> Bool -> Bool -> Bool -> IO Bool >> http://haskell.org/ghc/docs/latest/html/libraries/unix/System-Posix-Files.html#v:fileAccess >> >> >> is not very good. > > > The underlying system call access() is strongly disrecommended, so it's > not really worth a better interface. > I can't see problems with access function. Of course it is a problem if used incorrectly: if (access("foo", F_OK) { fd = open("foo", ...) } Manlio Perillo From gleb.alexeev at gmail.com Thu Jan 15 06:00:18 2009 From: gleb.alexeev at gmail.com (Gleb Alexeyev) Date: Thu Jan 15 05:51:27 2009 Subject: [Haskell-cafe] Re: some ideas for Haskell', from Python In-Reply-To: <496F1593.80800@libero.it> References: <496DFDD0.1010109@libero.it> <2076f2f90901142200t181f0dabw487a08df8a081d14@mail.gmail.com> <496F1593.80800@libero.it> Message-ID: Manlio Perillo wrote: > import System.Posix.Files as PF Try this: > import qualified System.Posix.Files as PF The problem you described should go away. From gale at sefer.org Thu Jan 15 06:14:52 2009 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 15 06:05:59 2009 Subject: [Haskell-cafe] ANN: hs-dotnet, version 0.3.0 In-Reply-To: <496EEBFE.8050800@gmail.com> References: <496EEBFE.8050800@gmail.com> Message-ID: <2608b8a80901150314m1dedb2b4v37577f1f067d764e@mail.gmail.com> Sigbjorn Finne wrote: > the first public release of hs-dotnet is now available Fantastic accomplishment! I can only repeat dons' comment - this could be game-changing. Some obvious questions that come to mind: We see that it is already possible to expose a Haskell function to .NET as a callback. That's exciting! Can we go to the next step and register it as part of an assembly? Is it be possible for a running .NET app to fire up the GHC runtime and call into compiled Haskell? Is it possible at all for a .NET function not to have any side effects? If so, is there any way to label it as such and then call it from Haskell outside of the IO monad? Thanks, Yitz From marco-oweber at gmx.de Thu Jan 15 06:35:08 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Thu Jan 15 06:26:19 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <496DFDD0.1010109@libero.it> References: <496DFDD0.1010109@libero.it> Message-ID: <20090115113508.GA9957@gmx.de> > 1) In a Python string it is available the \U{name} escape, where name is > a character name in the Unicode database. > > As an example: > foo = u"abc\N{VULGAR FRACTION ONE HALF}" > I think you can use quasi quotation of ghc to achieve this ? Your code would look like this then: let foo = [$mystr|abc\N{VULGAR FRACTION ONE HALF}] Sincerly Marc Weber From manlio_perillo at libero.it Thu Jan 15 06:38:14 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Thu Jan 15 06:29:23 2009 Subject: [Haskell-cafe] Re: some ideas for Haskell', from Python In-Reply-To: References: <496DFDD0.1010109@libero.it> <2076f2f90901142200t181f0dabw487a08df8a081d14@mail.gmail.com> <496F1593.80800@libero.it> Message-ID: <496F2026.5050808@libero.it> Gleb Alexeyev ha scritto: > Manlio Perillo wrote: > >> import System.Posix.Files as PF > > Try this: > > > import qualified System.Posix.Files as PF > > The problem you described should go away. > Ah, thanks! I really missed the qualified! Manlio Perillo From manlio_perillo at libero.it Thu Jan 15 06:45:26 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Thu Jan 15 06:36:36 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <1231978323.28590.298.camel@localhost> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> <1231978323.28590.298.camel@localhost> Message-ID: <496F21D6.60905@libero.it> Duncan Coutts ha scritto: > [...] >> Do you know buildbot? >> http://buildbot.net/trac > > Yeah, it's great for some kinds of projects. For example it's used for > ghc. However it is very centralised, synchronous and needs ssh on > Windows. > > What we've implemented is using cabal-install to generate build logs and > summary info and to upload that to the hackage server. The advantage is > that we should get an order or two magnitude more results than if we > used a handful of buildbots. This seems a good idea. However, it is possible for a thirdy part user to submit build logs for a specific platform? In detail: - The package author submit his package, and additional build logs for each platform he have access to - Other users can submit additional build logs for their platform I think, however, that a centralized system has its advantages. As an example, a newly submitted package can be put in a 'incoming queue', and moved to the final destination only if it builds (and tests succeed) on all the supported platforms. > [..] Manlio Perillo From immanuel203 at gmail.com Thu Jan 15 06:52:05 2009 From: immanuel203 at gmail.com (Immanuel Litzroth) Date: Thu Jan 15 06:43:14 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <496DFDD0.1010109@libero.it> References: <496DFDD0.1010109@libero.it> Message-ID: > 2) In Python it is possible to import modules inside a function. > > In Haskell something like: > > joinPath' root name = > joinPath [root, name] > importing System.FilePath (joinPath) > > In Python importing a module has totally different semantics from importing in Haskell. I runs the initialization code for the module & makes the names in that module available to you code. In Haskell modules are just namespace control, and you can always refer to names imported through import X through the syntax X.name. This means that the local import in Python solves two problems 1) making a name available locally. 2) running initialization code only when a specific function is called. Neither of those makes any sense for Haskell as far as I can tell. Immanuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/69755593/attachment.htm From bugfact at gmail.com Thu Jan 15 06:53:08 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Jan 15 06:44:17 2009 Subject: [Haskell-cafe] ANN: hs-dotnet, version 0.3.0 In-Reply-To: <2608b8a80901150314m1dedb2b4v37577f1f067d764e@mail.gmail.com> References: <496EEBFE.8050800@gmail.com> <2608b8a80901150314m1dedb2b4v37577f1f067d764e@mail.gmail.com> Message-ID: Nice! Maybe efforts could be combined by integrating some of this work: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Salsa which statically types checks all the calls to DOTNET (emulates the C# type system using type families, I found it nifty) On Thu, Jan 15, 2009 at 12:14 PM, Yitzchak Gale wrote: > Sigbjorn Finne wrote: > > the first public release of hs-dotnet is now available > > Fantastic accomplishment! I can only repeat dons' comment > - this could be game-changing. > > Some obvious questions that come to mind: > > We see that it is already possible to expose a Haskell function > to .NET as a callback. That's exciting! Can we go to the next step > and register it as part of an assembly? > > Is it be possible for a running .NET app to fire > up the GHC runtime and call into compiled Haskell? > > Is it possible at all for a .NET function not to have any side effects? > If so, is there any way to label it as such and then call it > from Haskell outside of the IO monad? > > Thanks, > Yitz > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/d456a579/attachment-0001.htm From duncan.coutts at worc.ox.ac.uk Thu Jan 15 07:05:55 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 15 06:57:02 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <496F21D6.60905@libero.it> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> <1231978323.28590.298.camel@localhost> <496F21D6.60905@libero.it> Message-ID: <1232021155.28590.308.camel@localhost> On Thu, 2009-01-15 at 12:45 +0100, Manlio Perillo wrote: > Duncan Coutts ha scritto: > > [...] > >> Do you know buildbot? > >> http://buildbot.net/trac > > > > Yeah, it's great for some kinds of projects. For example it's used for > > ghc. However it is very centralised, synchronous and needs ssh on > > Windows. > > > > What we've implemented is using cabal-install to generate build logs and > > summary info and to upload that to the hackage server. The advantage is > > that we should get an order or two magnitude more results than if we > > used a handful of buildbots. > > This seems a good idea. > However, it is possible for a thirdy part user to submit build logs for > a specific platform? Yes. > In detail: > - The package author submit his package, and additional build logs > for each platform he have access to > - Other users can submit additional build logs for their platform > > > I think, however, that a centralized system has its advantages. > As an example, a newly submitted package can be put in a 'incoming > queue', and moved to the final destination only if it builds (and tests > succeed) on all the supported platforms. What we really want is both. We want to let random users on random platforms submit simple anonymous build reports (no logs). In addition since any client can upload reports we can set up a number of dedicated clients that will build every new package in a chroot and upload non-anonymous detailed build reports with build logs. The only downside compared to a more centralised system is that we do not get to centrally monitor the status of the dedicated build clients. Duncan From gale at sefer.org Thu Jan 15 07:12:54 2009 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 15 07:04:01 2009 Subject: [Haskell-cafe] Haskell and C++ program In-Reply-To: <8252533f0901141245i58c1ab5y43c56945eb5ec40f@mail.gmail.com> References: <8252533f0901141245i58c1ab5y43c56945eb5ec40f@mail.gmail.com> Message-ID: <2608b8a80901150412n5ec32a7akf360c4321a614314@mail.gmail.com> Sukit Tretriluxana: > I was looking around Stroustrup's website and found > a simple program... I wondered how a Haskell > program equivalent to it looks like... > main = E.catch (interact reverseDouble) (\_ -> print "format error") > toDoubles = map (read::String->Double) For a "safe" program in Haskell, we would not normally use an unsafe function like "read", and then try to rescue it by catching IO exceptions. Instead, we would write the program safely to begin with. Something like this (building on Jonathan's idea): import Data.Maybe (listToMaybe) main = interact reverseDouble reverseDouble = unlines . intro . maybe ["format error"] (map show . reverse) . mapM (readMaybe :: String -> Maybe Double) . takeWhile (/= "end") . words where intro l = ("read " ++ show (length l) ++ " elements") : "elements in reversed order" : l readMaybe :: Read a => String -> Maybe a readMaybe = listToMaybe . map fst . reads The function "readMaybe" returns the pure value "Nothing" if there is a format error instead of throwing an IO exception. It has been proposed to make it part of the standard libraries - I'm not sure what the status is of that process. Regards, Yitz From apfelmus at quantentunnel.de Thu Jan 15 07:17:23 2009 From: apfelmus at quantentunnel.de (Apfelmus, Heinrich) Date: Thu Jan 15 07:08:06 2009 Subject: [Haskell-cafe] Re: Haskell and C++ program In-Reply-To: <1231972883.28651.58.camel@jcchost> References: <8252533f0901141245i58c1ab5y43c56945eb5ec40f@mail.gmail.com> <1231972883.28651.58.camel@jcchost> Message-ID: Jonathan Cast wrote: > reverseDouble = > unlines > . intro > . map show > . reverse > . map (read :: String -> Double) > . takeWhile (/= "end") > . words > where > intro l = > ("read " ++ show (length l) ++ " elements") : > "elements in reversed order" : > l This can be simplified to ... . map show . reverse . map read . ... = { map f . reverse = reverse . map f } ... . reverse . map show . map read . ... = { map f . map g = map (f . g) } ... . reverse . map (show . read) . ... = { show . read = id } ... . reverse . map id . ... = { map id = id } ... . reverse . ... In other words, reverseDouble = unlines. intro . reverse . takeWhile (/= "end") . words where intro xs = ("read " ++ show (length xs) ++ " elements") : "elements in reversed order" : xs And the doubles disappeared completely. :) Regards, H. Apfelmus From manlio_perillo at libero.it Thu Jan 15 07:20:30 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Thu Jan 15 07:11:40 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <5e0214850901150206y735d9232q97c3bd693f59681a@mail.gmail.com> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> <1231978323.28590.298.camel@localhost> <5e0214850901142249y92dbc31g42f9e0b2108b3cbd@mail.gmail.com> <1232013102.28590.303.camel@localhost> <5e0214850901150206y735d9232q97c3bd693f59681a@mail.gmail.com> Message-ID: <496F2A0E.5040901@libero.it> Eugene Kirpichov ha scritto: > Well, I thought about these 10's of emails too; probably hackage could > send an email when a new broken build arrives but only if there were > no 'unresolved' broken builds before this one; or probably an email at > the first broken build and a weekly email reminding "you've got some > unresolved broken builds". > > As for missing C libraries: could cabal probably integrate with the > native package manager (apt/rpm/..) and ask the user whether to invoke > it to install these libraries in case they are missing? I like the idea. An "external package" database, where for each "software" we have an Haskell name, with this name mapped to each specific package. > However, this > is not a solution for Windows since there's no native package manager. > For windows an "Haskell external package" name can be mapped to an URL to a "well know" Windows installer. > [...] Manlio Perillo From manlio_perillo at libero.it Thu Jan 15 07:26:44 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Thu Jan 15 07:17:54 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <1232021155.28590.308.camel@localhost> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> <1231978323.28590.298.camel@localhost> <496F21D6.60905@libero.it> <1232021155.28590.308.camel@localhost> Message-ID: <496F2B84.1080508@libero.it> Duncan Coutts ha scritto: > [...] >> This seems a good idea. >> However, it is possible for a thirdy part user to submit build logs for >> a specific platform? > > Yes. > Ok, that's great! >> In detail: >> - The package author submit his package, and additional build logs >> for each platform he have access to >> - Other users can submit additional build logs for their platform >> >> >> I think, however, that a centralized system has its advantages. >> As an example, a newly submitted package can be put in a 'incoming >> queue', and moved to the final destination only if it builds (and tests >> succeed) on all the supported platforms. > > What we really want is both. We want to let random users on random > platforms submit simple anonymous build reports (no logs). > > In addition since any client can upload reports we can set up a number > of dedicated clients that will build every new package in a chroot and > upload non-anonymous detailed build reports with build logs. > Since nowdays virtual machines are very affordable, it would be nice to have a set of standard virtual system images, preconfigured to run Cabal installation process. So that when I compile a package on my system, Cabal can be instructed to: 1) Start each virtual machine on the system 2) Submit the package to each machine an get the report 3) Stop each virtual machine Is this a feasible task? The only "problem" is with proprietary operating systems like Windows and Mac OS, where pre-configured systems can not be provided. > [...] Manlio Perillo From ekirpichov at gmail.com Thu Jan 15 07:27:59 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Thu Jan 15 07:19:07 2009 Subject: [Haskell-cafe] Re: Haskell and C++ program In-Reply-To: References: <8252533f0901141245i58c1ab5y43c56945eb5ec40f@mail.gmail.com> <1231972883.28651.58.camel@jcchost> Message-ID: <5e0214850901150427g3c230bdcna55a6dd00fd4baa9@mail.gmail.com> Well, your program is not equivalent to the C++ version, since it doesn't bail on incorrect input. 2009/1/15 Apfelmus, Heinrich : > Jonathan Cast wrote: >> reverseDouble = >> unlines >> . intro >> . map show >> . reverse >> . map (read :: String -> Double) >> . takeWhile (/= "end") >> . words >> where >> intro l = >> ("read " ++ show (length l) ++ " elements") : >> "elements in reversed order" : >> l > > This can be simplified to > > ... . map show . reverse . map read . ... > > = { map f . reverse = reverse . map f } > > ... . reverse . map show . map read . ... > > = { map f . map g = map (f . g) } > > ... . reverse . map (show . read) . ... > > = { show . read = id } > > ... . reverse . map id . ... > > = { map id = id } > > ... . reverse . ... > > In other words, > > reverseDouble = > unlines. intro . reverse . takeWhile (/= "end") . words > where > intro xs = > ("read " ++ show (length xs) ++ " elements") : > "elements in reversed order" : > xs > > And the doubles disappeared completely. :) > > > Regards, > H. Apfelmus > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From duncan.coutts at worc.ox.ac.uk Thu Jan 15 07:36:28 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 15 07:27:34 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <496F2B84.1080508@libero.it> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> <1231978323.28590.298.camel@localhost> <496F21D6.60905@libero.it> <1232021155.28590.308.camel@localhost> <496F2B84.1080508@libero.it> Message-ID: <1232022988.28590.313.camel@localhost> On Thu, 2009-01-15 at 13:26 +0100, Manlio Perillo wrote: > >> In detail: > >> - The package author submit his package, and additional build logs > >> for each platform he have access to > >> - Other users can submit additional build logs for their platform > >> > >> > >> I think, however, that a centralized system has its advantages. > >> As an example, a newly submitted package can be put in a 'incoming > >> queue', and moved to the final destination only if it builds (and tests > >> succeed) on all the supported platforms. > > > > What we really want is both. We want to let random users on random > > platforms submit simple anonymous build reports (no logs). > > > > In addition since any client can upload reports we can set up a number > > of dedicated clients that will build every new package in a chroot and > > upload non-anonymous detailed build reports with build logs. > > > > Since nowdays virtual machines are very affordable, it would be nice to > have a set of standard virtual system images, preconfigured to run Cabal > installation process. > > So that when I compile a package on my system, Cabal can be instructed to: > 1) Start each virtual machine on the system > 2) Submit the package to each machine an get the report > 3) Stop each virtual machine > > > Is this a feasible task? Yes, and the great thing is that anyone could do that. That's the advantage of a decentralised system. It does not require the permission or help of the cabal/hackage hackers to do it. > The only "problem" is with proprietary operating systems like Windows > and Mac OS, where pre-configured systems can not be provided. True. The other issue is that perhaps knowing something builds on a clean virtual machine is not quite so useful as knowing it builds on 100's of messy machines in dozens of different configurations. So that's not to say that using dedicated build clients running on virtual machines is not useful, it is. But we don't need lots and lots of those. Duncan From gale at sefer.org Thu Jan 15 07:38:24 2009 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 15 07:29:35 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <1232021155.28590.308.camel@localhost> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> <1231978323.28590.298.camel@localhost> <496F21D6.60905@libero.it> <1232021155.28590.308.camel@localhost> Message-ID: <2608b8a80901150438j22f4a8bcn24dc32510c71b1d6@mail.gmail.com> Duncan Coutts wrote: > We want to let random users on random > platforms submit simple anonymous build reports (no logs)... > The only downside compared to a more centralised system is that we do > not get to centrally monitor the status of the dedicated build clients. And that we open ourselves up to some serious security concerns - like hostile build reports and DOS. -Yitz From apfelmus at quantentunnel.de Thu Jan 15 07:40:45 2009 From: apfelmus at quantentunnel.de (Apfelmus, Heinrich) Date: Thu Jan 15 07:31:26 2009 Subject: [Haskell-cafe] Re: Haskell and C++ program In-Reply-To: <5e0214850901150427g3c230bdcna55a6dd00fd4baa9@mail.gmail.com> References: <8252533f0901141245i58c1ab5y43c56945eb5ec40f@mail.gmail.com> <1231972883.28651.58.camel@jcchost> <5e0214850901150427g3c230bdcna55a6dd00fd4baa9@mail.gmail.com> Message-ID: Eugene Kirpichov wrote: > Well, your program is not equivalent to the C++ version, since it > doesn't bail on incorrect input. Oops. That's because my assertion show . read = id is wrong. We only have read . show = id show . read <= id (in the "less defined than" sense) Regards, H. Apfelmus From briqueabraque at yahoo.com Thu Jan 15 07:50:15 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Thu Jan 15 07:41:41 2009 Subject: [Haskell-cafe] Type errors, would extensions help? Message-ID: Hi, I have this problem trying to define a function inside a do expression. I tried this small code to help me check. This works well: --- import Data.Ratio ; main = do { printNumber <- let { print :: (Num n,Show n) => n -> IO () ; print n = do { putStrLn $ show n} } in return print ; print (1%5) ; print 5.0 } --- However, just removing 'Num n' gives: Ambiguous type variable `n' in the constraint: `Show n' arising from a use of `print' at teste.hs:7:16-20 Why is it ambiguous? Since I don't use numeric functions, 'Num n,Show n' doesn't seem more specific. Besides that, the real problem I have is a similar function declared inside a 'let' as col :: (WidgetClass w) => w->IO Int col wid = do {... that, after beeing used with w beeing Table (and instance WidgetClass Table do exist) refuses beeing used with DrawingArea (also with instance WidgetClass DrawingArea), but I wasn't able to simulate that in a small program, and don't know if it's related to the case I'm showing. Thanks for your kindness, Maur?cio From manlio_perillo at libero.it Thu Jan 15 07:51:58 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Thu Jan 15 07:43:09 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <2608b8a80901150438j22f4a8bcn24dc32510c71b1d6@mail.gmail.com> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> <1231978323.28590.298.camel@localhost> <496F21D6.60905@libero.it> <1232021155.28590.308.camel@localhost> <2608b8a80901150438j22f4a8bcn24dc32510c71b1d6@mail.gmail.com> Message-ID: <496F316E.90401@libero.it> Yitzchak Gale ha scritto: > Duncan Coutts wrote: >> We want to let random users on random >> platforms submit simple anonymous build reports (no logs)... >> The only downside compared to a more centralised system is that we do >> not get to centrally monitor the status of the dedicated build clients. > > And that we open ourselves up to some serious security concerns - > like hostile build reports and DOS. > DOS is always a problem, for every application open to the Internet. As for hostile builds reports, I don't see it as a security concern. > -Yitz > Manlio Perillo From bulat.ziganshin at gmail.com Thu Jan 15 07:53:20 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Jan 15 07:46:10 2009 Subject: [Haskell-cafe] Re: Haskell and C++ program In-Reply-To: <5e0214850901150427g3c230bdcna55a6dd00fd4baa9@mail.gmail.com> References: <8252533f0901141245i58c1ab5y43c56945eb5ec40f@mail.gmail.com> <1231972883.28651.58.camel@jcchost> <5e0214850901150427g3c230bdcna55a6dd00fd4baa9@mail.gmail.com> Message-ID: <1083429385.20090115155320@gmail.com> Hello Eugene, Thursday, January 15, 2009, 3:27:59 PM, you wrote: but at least "length.map show" is eq to length :) > Well, your program is not equivalent to the C++ version, since it > doesn't bail on incorrect input. > 2009/1/15 Apfelmus, Heinrich : >> Jonathan Cast wrote: >>> reverseDouble = >>> unlines >>> . intro >>> . map show >>> . reverse >>> . map (read :: String -> Double) >>> . takeWhile (/= "end") >>> . words >>> where >>> intro l = >>> ("read " ++ show (length l) ++ " elements") : >>> "elements in reversed order" : >>> l >> >> This can be simplified to >> >> ... . map show . reverse . map read . ... >> >> = { map f . reverse = reverse . map f } >> >> ... . reverse . map show . map read . ... >> >> = { map f . map g = map (f . g) } >> >> ... . reverse . map (show . read) . ... >> >> = { show . read = id } >> >> ... . reverse . map id . ... >> >> = { map id = id } >> >> ... . reverse . ... >> >> In other words, >> >> reverseDouble = >> unlines. intro . reverse . takeWhile (/= "end") . words >> where >> intro xs = >> ("read " ++ show (length xs) ++ " elements") : >> "elements in reversed order" : >> xs >> >> And the doubles disappeared completely. :) >> >> >> Regards, >> H. Apfelmus >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From m.gubinelli at gmail.com Thu Jan 15 08:01:20 2009 From: m.gubinelli at gmail.com (Massimiliano Gubinelli) Date: Thu Jan 15 07:52:28 2009 Subject: [Haskell-cafe] walking a directory tree efficiently Message-ID: <21475846.post@talk.nabble.com> Hi, what about avoid the use of the unfold over the tree and construct it directly (e.g. see http://hpaste.org/13919#a3)? I wonder if there is (an easy) possibility to construct the tree lazily so that output start immediately for large trees. best, Massimiliano Gubinelli -- View this message in context: http://www.nabble.com/walking-a-directory-tree-efficiently-tp21446337p21475846.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From duncan.coutts at worc.ox.ac.uk Thu Jan 15 08:05:57 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 15 07:57:03 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <2608b8a80901150438j22f4a8bcn24dc32510c71b1d6@mail.gmail.com> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> <1231978323.28590.298.camel@localhost> <496F21D6.60905@libero.it> <1232021155.28590.308.camel@localhost> <2608b8a80901150438j22f4a8bcn24dc32510c71b1d6@mail.gmail.com> Message-ID: <1232024757.28590.322.camel@localhost> On Thu, 2009-01-15 at 14:38 +0200, Yitzchak Gale wrote: > Duncan Coutts wrote: > > We want to let random users on random > > platforms submit simple anonymous build reports (no logs)... > > The only downside compared to a more centralised system is that we do > > not get to centrally monitor the status of the dedicated build clients. > > And that we open ourselves up to some serious security concerns - > like hostile build reports and DOS. Detailed build reports with logs are not anonymous, clients will need an account on hackage (ie username and password). Yes, we could get flooded with anonymous build reports, but they're much smaller and hopefully they'll either be obviously bogus or drowned out by the volume of legit reports. So the information content and reliability of each data item is lower but hopefully the volume makes up for it, so long as we do the statistics carefully. As Manlio says, we're always open to DOS attacks. We just have to make sure we're not more vulnerable than average by doing too much work on the server side compared to the work done by the client (ie the processing of anonymous reports has to be fairly cheap). Duncan From gale at sefer.org Thu Jan 15 08:09:37 2009 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 15 08:00:44 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <496F316E.90401@libero.it> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> <1231978323.28590.298.camel@localhost> <496F21D6.60905@libero.it> <1232021155.28590.308.camel@localhost> <2608b8a80901150438j22f4a8bcn24dc32510c71b1d6@mail.gmail.com> <496F316E.90401@libero.it> Message-ID: <2608b8a80901150509t5debea77h2bca8fa018eaaa16@mail.gmail.com> Duncan Coutts wrote: >>> let random users... submit... build reports... I wrote: >> ...we open ourselves up to... hostile build reports and DOS. Manlio Perillo wrote: > DOS is always a problem, for every application open to the Internet. Yes. But I didn't mean just generic flooding. I meant abusing the effect of build reports to create a DOS. > As for hostile builds reports, I don't see it as a security concern. Hostile build reports could effectively remove a package from hackage. Or bless a faulty package, causing problems on other people's systems. -Yitz From gleb.alexeev at gmail.com Thu Jan 15 08:20:41 2009 From: gleb.alexeev at gmail.com (Gleb Alexeyev) Date: Thu Jan 15 08:11:52 2009 Subject: [Haskell-cafe] Re: Type errors, would extensions help? In-Reply-To: References: Message-ID: Mauricio wrote: > Hi, > > I have this problem trying to define a function > inside a do expression. I tried this small code > to help me check. This works well: > > --- > import Data.Ratio ; > main = do { > printNumber <- let { > print :: (Num n,Show n) => n -> IO () ; > print n = do { putStrLn $ show n} > } in return print ; > print (1%5) ; > print 5.0 > } > --- I guess you intended to call printNumber in the quoted snippet? There's a way to use GHC's extensions to do what you want, let me illustrate with simpler example: {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ImpredicativeTypes #-} t1 () = do f <- (return id :: IO (forall a. a->a)) return (f "foo", f True) However, I would call this style unnatural and unnecessary. What's wrong with plain 'let' or 'where' that work without any extensions? t2 () = do let f = id return (f "foo", f True) From ketil at malde.org Thu Jan 15 08:25:11 2009 From: ketil at malde.org (Ketil Malde) Date: Thu Jan 15 08:15:45 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <1232013102.28590.303.camel@localhost> (Duncan Coutts's message of "Thu\, 15 Jan 2009 09\:51\:42 +0000") References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> <1231978323.28590.298.camel@localhost> <5e0214850901142249y92dbc31g42f9e0b2108b3cbd@mail.gmail.com> <1232013102.28590.303.camel@localhost> Message-ID: <87y6xcya4o.fsf@malde.org> Duncan Coutts writes: > On Thu, 2009-01-15 at 09:49 +0300, Eugene Kirpichov wrote: >> Would be nice if after a failed build cabal asked whether or not to >> upload its log immediately, and (on the hackage side) this led to an >> email being sent to the maintainer. > It should not be quite that synchronous but yes that's the general idea. Perhaps the maintainer should receive a build summary at regular intervals? This would also work as a check whether there is a live maintainer at the other end of the listed maintainer address. (And hopefully be enough of an annoyance on the libraries@ list that people would start looking for maintainers for orphaned packages :-) -k -- If I haven't seen further, it is by standing in the footprints of giants From gale at sefer.org Thu Jan 15 08:38:45 2009 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 15 08:29:52 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <1232024757.28590.322.camel@localhost> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> <1231978323.28590.298.camel@localhost> <496F21D6.60905@libero.it> <1232021155.28590.308.camel@localhost> <2608b8a80901150438j22f4a8bcn24dc32510c71b1d6@mail.gmail.com> <1232024757.28590.322.camel@localhost> Message-ID: <2608b8a80901150538w506197c8g660bbd3f29723b34@mail.gmail.com> Duncan Coutts wrote: > Detailed build reports with logs are not anonymous, clients will need an > account on hackage (ie username and password). Right. If we experience problems with that in the future, we just have to make sure that it won't be too hard to set up captcha. > they'll either be obviously bogus Aren't we talking about an automated system? If we don't explicitly design for the possibility of hostile reports, any automated recognition will be trivial to circumvent. > or drowned out by the volume of legit reports. Again, if this is automated, it is trivial generate the required volume. -Yitz From lemming at henning-thielemann.de Thu Jan 15 08:43:51 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 15 08:34:59 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> Message-ID: On Sun, 11 Jan 2009, Neil Mitchell wrote: > I am pleased to announce HLint version 1.2. HLint is a lint-like tool > for Haskell that detects and suggests improvements for your code. > HLint is compatible with most GHC extensions, and supports a wide > variety of suggestions, and can be extended with additional user > suggestions. > > To install: cabal update && cabal install hlint Fails for me, because of the base-4 dependency. - I'm still using GHC-6.8.2. Can HLint suggest view-pattern-free expressions, such that the program also runs on GHC-6.8 ? :-) From ndmitchell at gmail.com Thu Jan 15 08:59:38 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Jan 15 08:50:44 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> Message-ID: <404396ef0901150559gf203e9l14e791c100af0f16@mail.gmail.com> Hi Henning, >> To install: cabal update && cabal install hlint > > Fails for me, because of the base-4 dependency. - I'm still using GHC-6.8.2. > Can HLint suggest view-pattern-free expressions, such that the program also > runs on GHC-6.8 ? :-) HLint is written using view-patterns so requires GHC 6.10 to compile it. After you have it compiled its just a standard Haskell binary, so can be run on any Haskell code and will never suggest view-patterns anyway. Alas compiling without GHC 6.10 is not possible, but if you can get a binary from elsewhere it should run on your machine (subject to cabal configure stuff being set appropriately, which I don't understand...). Thanks Neil From apfelmus at quantentunnel.de Thu Jan 15 09:06:03 2009 From: apfelmus at quantentunnel.de (Apfelmus, Heinrich) Date: Thu Jan 15 08:56:50 2009 Subject: [Haskell-cafe] Re: Monads aren't evil? I think they are. In-Reply-To: <20090111111016.492d7dc9@tritium.xx> References: <20090108231652.24b75fe3@tritium.xx> <20090111111016.492d7dc9@tritium.xx> Message-ID: Ertugrul Soeylemez wrote: > [...] Thank you for your reply, I think I can refine my thoughts. And make them much longer... ;) The elegance I have in mind comes from abstraction, that is when a type takes a meaning on its own, independent of its implementation. Let's take the example of vector graphics again data Graphic empty :: Graphic polygon :: [Point] -> Graphic over :: Graphic -> Graphic -> Graphic All primitives can be explained in terms of our intuition on pictures alone; it is completely unnecessary to know that Graphic is implemented as type Graphics = Window -> IO () empty = \w -> return () polygon (p:ps) = \w -> moveTo p w >> mapM_ (\p -> lineTo p w) ps over g1 g2 = \w -> g1 w >> g2 w Furthermore, this independence is often exemplified by the existence of many different implementations. For instance, Graphics can as well be written as type Graphics = Pixel -> Color empty = const Transparent polygon (p:ps) = foldr over empty $ zipWith line (p:ps) ps over g1 g2 = \p -> if g1 p == Transparent then g2 p else g1 p Incidentally, this representation also makes a nice formalization of the intuitive notion of pictures, making it possible to verify the correctness of other implementations. Of course, taking it as definition for Graphic would still fall short of the original goal of creating meaning independent of any implementation. But this can be achieved by stating the laws that relate the available operations. For instance, we have g = empty `over` g = g `over` empty (identity element) g `over` (h `over` j) = (g `over` h) `over` j (associativity) g `over` g = g (idempotence) The first two equations say that Graphics is a monoid. Abstraction and equational laws are the cornerstones of functional programming. For more, see also the following classics John Hughes. The Design of a Pretty-printing Library. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.8777 Philip Wadler. A prettier printer. http://homepages.inf.ed.ac.uk/wadler/topics/ language-design.html#prettier Richard Bird. A program to solve Sudoku Slides: http://icfp06.cs.uchicago.edu/bird-talk.pdf (From this point of view, the feature of non-pure languages to allow side effects in every function is useless and distracting. Why on earth would I want over to potentially have side effects? That would just invalidate the laws while offering nothing in return.) > Often, the monadic solution _is_ the elegant solution. Please don't > confuse monads with impure operations. I use the monadic properties of > lists, often together with monad transformers, to find elegant > solutions. As long as you're not abusing monads to program > imperatively, I think, they are an excellent and elegant structure. > > I do use state monads where there is no more elegant solution than passing > state around. It's simply that: you have a structure, which you modify > continuously in a complex fashion, such as a neural network or an > automaton. Monads are the way to go here, unless you want to do > research and find a better way to express this. In the light of the discussion above, the state monad for a particular state is an implementation, not an abstraction. There is no independent meaning in "stateful computation with an automaton as state", it is defined by its sole implementation. Sure, it does reduce boilerplate and simplifies the implementation, but it doesn't offer any insights. In other words, "passing state" is not an abstraction and it's a good idea to consciously exclude it from the design space when searching for a good abstraction. Similar for the other monads, maybe except the nondeterminism monad to some extend. Of course, a good abstraction depends on the problem domain. For automata, in particular finite state automata, I can imagine that the operations on corresponding regular expressions like concatenation, alternation and Kleene star are viable candidates. I have no clue about neural networks. On a side note, not every function that involves "state" does need the state monad. For instance, an imperative language might accumulate a value with a while-loop and updating a state variable, but in Haskell we simply pass a parameter to the recursive call foldl f z [] = z foldl f z (x:xs) = foldl f (f z x) xs Another example is "modifying" a value where a simple function of type s -> s like insert 1 'a' :: Map k v -> Map k v will do the trick. > Personally I prefer this: > > somethingWithRandomsM :: (Monad m, Random a) => m a -> Something a > > over these: > > somethingWithRandoms1 :: [a] -> Something a > somethingWithRandoms2 :: RandomGen g => g -> Something a > >> Consciously excluding monads and restricting the design space to pure >> functions is the basic tool of thought for finding such elegant >> abstractions. [...] > > You don't need to exclude monads to restrict the design space to pure > functions. Everything except IO and ST (and some related monads) is > pure. As said, often monads _are_ the elegant solutions. Just look at > parser monads. Thanks for the reminder, there is indeed a portion of designs that I overlooked in my previous post, namely when the abstraction involves a parameter. For instance, data Parser a parse :: Parser a -> String -> Maybe a is a thing that can parse values of some type a . Here, the abstraction solves a whole class of problems, one for every type. Similarly data Random a denotes a value that "wiggles randomly". For instance, we can sample them with a random seed sample :: RandomGen g => Random a -> g -> [a] or inspect its distribution distribution :: Eq a => Random a -> [(a,Probability)] The former can be implemented with a state monad, for the latter see also Martin Erwig, Steve Kollmansberger. Probabilistic functional programming in Haskell. http://web.engr.oregonstate.edu/~erwig/papers/PFP_JFP06.pdf In these cases, it is a good idea to check whether the abstraction can be made a monad, just like it is good to realize that Graphic is a monoid. The same goes for applicative functors. These "abstractions about abstractions" are useful design guides, but this is very different from using a particular monad like the state monad and hoping that using it somehow gives an insight into the problem domain. Regards, H. Apfelmus From lemming at henning-thielemann.de Thu Jan 15 09:06:50 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 15 08:58:08 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: <404396ef0901150559gf203e9l14e791c100af0f16@mail.gmail.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <404396ef0901150559gf203e9l14e791c100af0f16@mail.gmail.com> Message-ID: On Thu, 15 Jan 2009, Neil Mitchell wrote: > Hi Henning, > >>> To install: cabal update && cabal install hlint >> >> Fails for me, because of the base-4 dependency. - I'm still using GHC-6.8.2. >> Can HLint suggest view-pattern-free expressions, such that the program also >> runs on GHC-6.8 ? :-) > > HLint is written using view-patterns so requires GHC 6.10 to compile > it. After you have it compiled its just a standard Haskell binary, so > can be run on any Haskell code and will never suggest view-patterns > anyway. My question was, whether HLint can help translating HLint to code without view patterns. From ndmitchell at gmail.com Thu Jan 15 09:12:33 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Jan 15 09:03:41 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <404396ef0901150559gf203e9l14e791c100af0f16@mail.gmail.com> Message-ID: <404396ef0901150612q66b939f7ua495c1319b2d1cd9@mail.gmail.com> Hi > My question was, whether HLint can help translating HLint to code without > view patterns. Ah, I misunderstood. Yes, it could (in theory), but it can't automatically apply the hints it generates. Upgrading to GHC 6.10 is probably easier :-) Thanks Neil From jgoerzen at complete.org Thu Jan 15 09:19:57 2009 From: jgoerzen at complete.org (John Goerzen) Date: Thu Jan 15 09:11:05 2009 Subject: [Haskell-cafe] ANN: hs-dotnet, version 0.3.0 In-Reply-To: <496EEBFE.8050800@gmail.com> References: <496EEBFE.8050800@gmail.com> Message-ID: <496F460D.1040103@complete.org> Sigbjorn Finne wrote: > Hi, > > the first public release of hs-dotnet is now available - a pragmatic > take on interoperating between Haskell (via GHC) and .NET. For > downloads and (some) info, see: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hs-dotnet > http://haskell.forkIO.com/dotnet > > Feedback most welcome, both on what's there and what you would like > to see better handled/supported next. Nice! Has there been any effort to support Mono? -- John From sigbjorn.finne at gmail.com Thu Jan 15 09:26:28 2009 From: sigbjorn.finne at gmail.com (Sigbjorn Finne) Date: Thu Jan 15 09:17:50 2009 Subject: [Haskell-cafe] ANN: hs-dotnet, version 0.3.0 In-Reply-To: <496F460D.1040103@complete.org> References: <496EEBFE.8050800@gmail.com> <496F460D.1040103@complete.org> Message-ID: <496F4794.6030905@gmail.com> On 1/15/2009 06:19, John Goerzen wrote: > Sigbjorn Finne wrote: > >> ... >> >> >> > Nice! > > Has there been any effort to support Mono? > Only in spirit so far. I'm keen to find the time to do it and if it would directly help people having Mono as a deployment target, even better. thanks --sigbjorn From greg at gregorycollins.net Thu Jan 15 09:43:42 2009 From: greg at gregorycollins.net (Gregory Collins) Date: Thu Jan 15 09:34:57 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <2608b8a80901150538w506197c8g660bbd3f29723b34@mail.gmail.com> (Yitzchak Gale's message of "Thu, 15 Jan 2009 15:38:45 +0200") References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> <1231978323.28590.298.camel@localhost> <496F21D6.60905@libero.it> <1232021155.28590.308.camel@localhost> <2608b8a80901150438j22f4a8bcn24dc32510c71b1d6@mail.gmail.com> <1232024757.28590.322.camel@localhost> <2608b8a80901150538w506197c8g660bbd3f29723b34@mail.gmail.com> Message-ID: "Yitzchak Gale" writes: >> or drowned out by the volume of legit reports. > > Again, if this is automated, it is trivial generate the > required volume. It won't help re: botnets, but you can stop casual flooding attacks by rate-limiting per IP on the server. -- Gregory Collins From sigbjorn.finne at gmail.com Thu Jan 15 09:46:52 2009 From: sigbjorn.finne at gmail.com (Sigbjorn Finne) Date: Thu Jan 15 09:38:15 2009 Subject: [Haskell-cafe] ANN: hs-dotnet, version 0.3.0 In-Reply-To: <2608b8a80901150314m1dedb2b4v37577f1f067d764e@mail.gmail.com> References: <496EEBFE.8050800@gmail.com> <2608b8a80901150314m1dedb2b4v37577f1f067d764e@mail.gmail.com> Message-ID: <496F4C5C.4090601@gmail.com> Thanks Yitzchak, I'm thinking and acting on having that available in your quiver & have prototyped the ability to do so a couple of times in the past (stand-alone Haskell code as fully fledged .NET classes/assemblies, both the dynamic and static kind.) I didn't want to hold up the initial release to do this right now _and_ would really like to get a better gauge at how important having that piece would be to users looking to use Haskell in a .NET context. There's only so much time it seems, but no shortage of interesting projects to hack on :-) cheers --sigbjorn On 1/15/2009 03:14, Yitzchak Gale wrote: > Sigbjorn Finne wrote: > >> the first public release of hs-dotnet is now available >> > > Fantastic accomplishment! I can only repeat dons' comment > - this could be game-changing. > > Some obvious questions that come to mind: > > We see that it is already possible to expose a Haskell function > to .NET as a callback. That's exciting! Can we go to the next step > and register it as part of an assembly? > > Is it be possible for a running .NET app to fire > up the GHC runtime and call into compiled Haskell? > > Is it possible at all for a .NET function not to have any side effects? > If so, is there any way to label it as such and then call it > from Haskell outside of the IO monad? > > Thanks, > Yitz > From byorgey at seas.upenn.edu Thu Jan 15 10:04:42 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Thu Jan 15 09:55:48 2009 Subject: [Haskell-cafe] ANN: split-0.1.1 (doc bugfix; new functions wordsBy and linesBy) In-Reply-To: <20090113220919.GB1232@seas.upenn.edu> References: <20090113220919.GB1232@seas.upenn.edu> Message-ID: <20090115150441.GA26496@seas.upenn.edu> > * fixes a couple Haddock bugs that were preventing the documentation > from building on Hackage, and OK, the documentation is really *actually* fixed now. Thanks to Ross Paterson for upgrading haddock on the Hackage build machine! Check out the Haddocky, documentationy goodness: http://hackage.haskell.org/packages/archive/split/0.1.1/doc/html/Data-List-Split.html -Brent From jgoerzen at complete.org Thu Jan 15 10:34:38 2009 From: jgoerzen at complete.org (John Goerzen) Date: Thu Jan 15 10:25:47 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt Message-ID: <20090115153438.GA1340@hustlerturf.com> Hi folks, Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml hacker: http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/ It's a great post, and I encourage people to read it. I'd like to highlight one particular paragraph: One thing that does annoy me about Haskell- naming. Say you've noticed a common pattern, a lot of data structures are similar to the difference list I described above, in that they have an empty state and the ability to append things onto the end. Now, for various reasons, you want to give this pattern a name using on Haskell's tools for expressing common idioms as general patterns (type classes, in this case). What name do you give it? I'd be inclined to call it something like "Appendable". But no, Haskell calls this pattern a "Monoid". Yep, that's all a monoid is- something with an empty state and the ability to append things to the end. Well, it's a little more general than that, but not much. Simon Peyton Jones once commented that the biggest mistake Haskell made was to call them "monads" instead of "warm, fluffy things". Well, Haskell is exacerbating that mistake. Haskell developers, stop letting the category theorists name things. Please. I beg of you. I'd like to echo that sentiment! He went on to add: If you?re not a category theorists, and you're learning (or thinking of learning) Haskell, don't get scared off by names like "monoid" or "functor". And ignore anyone who starts their explanation with references to category theory- you don't need to know category theory, and I don't think it helps. I'd echo that one too. -- John From lennart at augustsson.net Thu Jan 15 10:57:42 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Jan 15 10:48:48 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <20090115153438.GA1340@hustlerturf.com> References: <20090115153438.GA1340@hustlerturf.com> Message-ID: I have replied on his blog, but I'll repeat the gist of it here. Why is there a fear of using existing terminology that is exact? Why do people want to invent new words when there are already existing ones with the exact meaning that you want? If I see Monoid I know what it is, if I didn't know I could just look on Wikipedia. If I see Appendable I can guess what it might be, but exactly what does it mean? -- Lennart On Thu, Jan 15, 2009 at 3:34 PM, John Goerzen wrote: > Hi folks, > > Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml > hacker: > > http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/ > > It's a great post, and I encourage people to read it. I'd like to > highlight one particular paragraph: > > > One thing that does annoy me about Haskell- naming. Say you've > noticed a common pattern, a lot of data structures are similar to > the difference list I described above, in that they have an empty > state and the ability to append things onto the end. Now, for > various reasons, you want to give this pattern a name using on > Haskell's tools for expressing common idioms as general patterns > (type classes, in this case). What name do you give it? I'd be > inclined to call it something like "Appendable". But no, Haskell > calls this pattern a "Monoid". Yep, that's all a monoid is- > something with an empty state and the ability to append things to > the end. Well, it's a little more general than that, but not > much. Simon Peyton Jones once commented that the biggest mistake > Haskell made was to call them "monads" instead of "warm, fluffy > things". Well, Haskell is exacerbating that mistake. Haskell > developers, stop letting the category theorists name > things. Please. I beg of you. > > I'd like to echo that sentiment! > > He went on to add: > > If you?re not a category theorists, and you're learning (or thinking > of learning) Haskell, don't get scared off by names like "monoid" or > "functor". And ignore anyone who starts their explanation with > references to category theory- you don't need to know category > theory, and I don't think it helps. > > I'd echo that one too. > > -- John > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From lemming at henning-thielemann.de Thu Jan 15 11:00:28 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 15 10:51:36 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: <404396ef0901150612q66b939f7ua495c1319b2d1cd9@mail.gmail.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <404396ef0901150559gf203e9l14e791c100af0f16@mail.gmail.com> <404396ef0901150612q66b939f7ua495c1319b2d1cd9@mail.gmail.com> Message-ID: On Thu, 15 Jan 2009, Neil Mitchell wrote: > Hi > >> My question was, whether HLint can help translating HLint to code without >> view patterns. > > Ah, I misunderstood. Yes, it could (in theory), but it can't > automatically apply the hints it generates. Upgrading to GHC 6.10 is > probably easier :-) Also throwing away Hugs ... (YHC too ?) From ganesh.sittampalam at credit-suisse.com Thu Jan 15 11:12:05 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Jan 15 11:05:27 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> Lennart Augustsson wrote: > I have replied on his blog, but I'll repeat the gist of it here. > Why is there a fear of using existing terminology that is exact? > Why do people want to invent new words when there are already > existing ones with the exact meaning that you want? If I see Monoid I > know what it is, if I didn't know I could just look on Wikipedia. > If I see Appendable I can guess what it might be, but exactly what > does it mean? I would suggest that having to look things up slows people down and might distract them from learning other, perhaps more useful, things about the language. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From jgoerzen at complete.org Thu Jan 15 11:15:36 2009 From: jgoerzen at complete.org (John Goerzen) Date: Thu Jan 15 11:06:50 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> Message-ID: <496F6128.7080108@complete.org> Lennart Augustsson wrote: > I have replied on his blog, but I'll repeat the gist of it here. > Why is there a fear of using existing terminology that is exact? > Why do people want to invent new words when there are already existing > ones with the exact meaning that you want? > If I see Monoid I know what it is, if I didn't know I could just look > on Wikipedia. > If I see Appendable I can guess what it might be, but exactly what does it mean? Picture someone that doesn't yet know Haskell. If I see Appendable I can guess what it might be. If I see "monoid", I have no clue whatsoever, because I've never heard of a monoid before. Using existing terminology isn't helpful if the people using the language have never heard of it. Wikipedia's first sentence about monoids is: In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single, associative binary operation and an identity element. Which is *not* intuitive to someone that comes from a background in.... any other programming language. A lot of communities have the "not invented here" disease -- they don't like to touch things that other people have developed. We seem to have the "not named here" disease -- we don't want to give things a sensible name for a programming language that is actually useful. Here's another, less egregious, example: isInfixOf. I would have called that function "contains" or something. Plenty of other languages have functions that do the same thing, and I can't think of one that names it anything like "isInfixOf". If you're learning Haskell, which communicates the idea more clearly: * Appendable or * Monoid I can immediately figure out what the first one means. With the second, I could refer to the GHC documentation, which does not describe what a Monoid does. Or read a wikipedia article about a branch of mathematics and try to figure out how it applies to Haskell. The GHC docs for something called Appendable could very easily state that it's a monoid. (And the docs for Monoid ought to spell out what it is in simple terms, not by linking to a 14-year-old paper.) I guess the bottom line question is: who is Haskell for? Category theorists, programmers, or both? I'd love it to be for both, but I've got to admit that Brian has a point that it is trending to the first in some areas. -- John From john at n-brain.net Thu Jan 15 11:17:55 2009 From: john at n-brain.net (John A. De Goes) Date: Thu Jan 15 11:09:04 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <20090110231141.6B5DC93C4C@mail.avvanta.com> References: <4965DC5D.1050006@libero.it> <20090108121015.3bc72877@solaris> <2B642E87-554D-421A-9E36-2D8633F14F59@n-brain.net> <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> <20090108221549.GA30539@hustlerturf.com> <4438705C-9069-4780-B6A9-7E928997D6EA@n-brain.net> <49676BEF.9050005@complete.org> <20090110231141.6B5DC93C4C@mail.avvanta.com> Message-ID: On Jan 10, 2009, at 4:11 PM, Donn Cave wrote: > Quoth "John A. De Goes" : > > | Take a language like Ruby or Python (or Java, or C#, etc.). The vast > | majority of code written in these languages does not "get down to > the > | C level". When I say, "vast majority", I'm referring to > 99.999%. > | That's because the standard libraries provide sufficiently > | comprehensive platform-agnostic abstractions to do what most people > | need to do. As a result, libraries for these languages are built on > | the standard libraries, and do not require native code. > > Maybe I haven't been paying enough attention, but I see Python and > Haskell in about the same position on this, especially in light of > how different they are (Haskell's FFI is a lot easier!) Plenty of > Python software depends on C library modules and foreign code. The > particular examples you mention - DB and UI - are great examples > where it's sort of crazy to do otherwise for just the reasons you > go on to list. Python has pure interfaces to all the major databases. While it's true there are no "native" GUI libraries, there are pure Python libraries for just about everything else. Haskell is not yet to this point. > The arguments you list in favor of native code are reasonable (though > some of them cut both ways - in particular it's a bold assertion > that bug fixes and general development are more likely in a Haskell > implementation, compared to a widely used C implementation that it > parallels.) I don't think it's a bold assertion. If I'm using a Haskell library that wraps a C library, and find a bug in it, my chances of tracking down the bug in C code and submitting a patch to whatever group maintains it are exactly zero. On the other hand, if it's a pure Haskell library, I'll at least take a look. What would you do? > But each case has its own merits, and it's perilous to > generalize. It would have been absurd for Python to take the approach > that Java takes (lacking the major corporate backing), and probably so > also for Haskell. (Though Haskell may in the end need it for APIs > that involve I/O, the way things seem to be going in GHC.) Safe, composable IO needs to be pushed into the core (ideally, into the standard). And it needs to be powerful enough to handle the different use cases: text parsing, binary data, random IO, and interactive IO. The currently exposed semantics are neither safe nor composable. Regards, John From thomas.dubuisson at gmail.com Thu Jan 15 11:22:00 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Thu Jan 15 11:13:07 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> Message-ID: <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh wrote: > Lennart Augustsson wrote: >> I have replied on his blog, but I'll repeat the gist of it here. >> Why is there a fear of using existing terminology that is exact? >> Why do people want to invent new words when there are already >> existing ones with the exact meaning that you want? If I see Monoid I >> know what it is, if I didn't know I could just look on Wikipedia. >> If I see Appendable I can guess what it might be, but exactly what >> does it mean? > > I would suggest that having to look things up slows people down > and might distract them from learning other, perhaps more useful, > things about the language. Exactly. For example, the entry for monoid on Wikipedia starts: "In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single, associative binary operation and an identity element." I've had some set theory, but most programmers I know have not. From ndmitchell at gmail.com Thu Jan 15 11:25:22 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Jan 15 11:16:32 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <404396ef0901150559gf203e9l14e791c100af0f16@mail.gmail.com> <404396ef0901150612q66b939f7ua495c1319b2d1cd9@mail.gmail.com> Message-ID: <404396ef0901150825w6f777499p353b49ba7363a9a@mail.gmail.com> >> Ah, I misunderstood. Yes, it could (in theory), but it can't >> automatically apply the hints it generates. Upgrading to GHC 6.10 is >> probably easier :-) > > Also throwing away Hugs ... (YHC too ?) Yes :-( I normally develop in Hugs, for a change I wanted to try GHCi. It's also a project that has loads of pattern matching at a fairly complex level, so the benefits offered by view-patterns and pattern-guards were just too hard to pass up. I'm also using SYB and Uniplate on SYB quite extensively. Now we just need Haskell' to standardise the useful bits (pattern guards, rank-2 types, deriving Data) throw away the junk (n+k, monomorphism restriction) and I can write beautiful programs for all Haskell thingies. Thanks Neil PS. I think I threw away Yhc when I imported Data.Map :-) From jgoerzen at complete.org Thu Jan 15 11:31:21 2009 From: jgoerzen at complete.org (John Goerzen) Date: Thu Jan 15 11:22:36 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: References: <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> <20090108221549.GA30539@hustlerturf.com> <4438705C-9069-4780-B6A9-7E928997D6EA@n-brain.net> <49676BEF.9050005@complete.org> <20090110231141.6B5DC93C4C@mail.avvanta.com> Message-ID: <20090115163121.GA2646@hustlerturf.com> On Thu, Jan 15, 2009 at 09:17:55AM -0700, John A. De Goes wrote: > On Jan 10, 2009, at 4:11 PM, Donn Cave wrote: >> Maybe I haven't been paying enough attention, but I see Python and >> Haskell in about the same position on this, especially in light of >> how different they are (Haskell's FFI is a lot easier!) Plenty of >> Python software depends on C library modules and foreign code. The >> particular examples you mention - DB and UI - are great examples >> where it's sort of crazy to do otherwise for just the reasons you >> go on to list. > > Python has pure interfaces to all the major databases. While it's true > there are no "native" GUI libraries, there are pure Python libraries for > just about everything else. Haskell is not yet to this point. By "pure" do you mean "containing python code only"? I'm looking through a few, and: PostgreSQL - psycopg - C PostgreSQL - pgsql - C PostgreSQL - pygresql - C MySQL - mysqldb - C MS SQL Server - pymssql - C And any interface that uses ODBC will, by necessity, be calling to C, because ODBC is defined as a C API and not a network protocol. Where are all these pure-Python drivers? > I don't think it's a bold assertion. If I'm using a Haskell library that > wraps a C library, and find a bug in it, my chances of tracking down the > bug in C code and submitting a patch to whatever group maintains it are > exactly zero. On the other hand, if it's a pure Haskell library, I'll at Why? > least take a look. What would you do? You have to balance that against the chances of there being bugs in code that is used by far fewer people. I don't care what language you're talking about -- I'm going to expect the C PostgreSQL library to be less buggy than a pure reimplementation in any other language, and will have less concern about its maintenance and stability in the future. It's a lot of wheel reinvention to try to re-implement a database protocol in n languages instead of do it in 1 and bind to it everywhere else. AFAIK, the only language where that sort of wheel reinvention is popular is Java. But then Java seems to encourage wheel reinvention anyhow ;-) -- John From lennart at augustsson.net Thu Jan 15 11:33:33 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Jan 15 11:24:40 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496F6128.7080108@complete.org> References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> Message-ID: Why do people think that you should be able to understand everything without ever looking things up? I'll get back to my example from the comment on the blog post. If I see 'ghee' in a cook book I'll check what it is (if I don't know). It has a precise meaning and next time I'll know. Inventing a new word for it serves no purpose, but to confuse people. Parts of Computer Science seem to love to invent new words for existing concepts. Again, I think this just confuses people in the long run. Or use existing words in a different way (like 'functor' in C++.) When it comes to 'isInfixOf', I think that is a particularely stupid name. As you point out, there are existing names for this function. I would probably have picked something like isSubstringOf instead of inventing something that is totally non-standard. I'm not saying Haskell always gets naming right, all I want is to reuse words that exist instead of inventing new ones. (And 'monoid' is not category theory, it's very basic (abstract) algebra.) I don't know any category theory, but if someone tells me that blah is an endomorphism I'm happy to call it that, knowing that I have a name that anyone can figure out with just a little effort. -- Lennart On Thu, Jan 15, 2009 at 4:15 PM, John Goerzen wrote: > Lennart Augustsson wrote: >> I have replied on his blog, but I'll repeat the gist of it here. >> Why is there a fear of using existing terminology that is exact? >> Why do people want to invent new words when there are already existing >> ones with the exact meaning that you want? >> If I see Monoid I know what it is, if I didn't know I could just look >> on Wikipedia. >> If I see Appendable I can guess what it might be, but exactly what does it mean? > > Picture someone that doesn't yet know Haskell. > > If I see Appendable I can guess what it might be. If I see "monoid", I > have no clue whatsoever, because I've never heard of a monoid before. > > Using existing terminology isn't helpful if the people using the > language have never heard of it. > > Wikipedia's first sentence about monoids is: > > In abstract algebra, a branch of mathematics, a monoid is an algebraic > structure with a single, associative binary operation and an identity > element. > > Which is *not* intuitive to someone that comes from a background in.... > any other programming language. > > A lot of communities have the "not invented here" disease -- they don't > like to touch things that other people have developed. We seem to have > the "not named here" disease -- we don't want to give things a sensible > name for a programming language that is actually useful. > > Here's another, less egregious, example: isInfixOf. I would have called > that function "contains" or something. Plenty of other languages have > functions that do the same thing, and I can't think of one that names it > anything like "isInfixOf". > > If you're learning Haskell, which communicates the idea more clearly: > > * Appendable > > or > > * Monoid > > I can immediately figure out what the first one means. With the second, > I could refer to the GHC documentation, which does not describe what a > Monoid does. Or read a wikipedia article about a branch of mathematics > and try to figure out how it applies to Haskell. > > The GHC docs for something called Appendable could very easily state > that it's a monoid. (And the docs for Monoid ought to spell out what it > is in simple terms, not by linking to a 14-year-old paper.) > > I guess the bottom line question is: who is Haskell for? Category > theorists, programmers, or both? I'd love it to be for both, but I've > got to admit that Brian has a point that it is trending to the first in > some areas. > > -- John > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From lennart at augustsson.net Thu Jan 15 11:36:26 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Jan 15 11:27:32 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> Message-ID: Most people don't understand pure functional programming either. Does that mean we should introduce unrestricted side effects in Haskell? -- Lennart On Thu, Jan 15, 2009 at 4:22 PM, Thomas DuBuisson wrote: > On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh > wrote: >> Lennart Augustsson wrote: >>> I have replied on his blog, but I'll repeat the gist of it here. >>> Why is there a fear of using existing terminology that is exact? >>> Why do people want to invent new words when there are already >>> existing ones with the exact meaning that you want? If I see Monoid I >>> know what it is, if I didn't know I could just look on Wikipedia. >>> If I see Appendable I can guess what it might be, but exactly what >>> does it mean? >> >> I would suggest that having to look things up slows people down >> and might distract them from learning other, perhaps more useful, >> things about the language. > > Exactly. For example, the entry for monoid on Wikipedia starts: > "In abstract algebra, a branch of mathematics, a monoid is an > algebraic structure with a single, associative binary operation and an > identity element." > > I've had some set theory, but most programmers I know have not. > From john at n-brain.net Thu Jan 15 11:38:39 2009 From: john at n-brain.net (John A. De Goes) Date: Thu Jan 15 11:29:47 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <2608b8a80901150538w506197c8g660bbd3f29723b34@mail.gmail.com> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> <1231978323.28590.298.camel@localhost> <496F21D6.60905@libero.it> <1232021155.28590.308.camel@localhost> <2608b8a80901150438j22f4a8bcn24dc32510c71b1d6@mail.gmail.com> <1232024757.28590.322.camel@localhost> <2608b8a80901150538w506197c8g660bbd3f29723b34@mail.gmail.com> Message-ID: <53FB178F-E959-4676-B3D5-994E33F52438@n-brain.net> There's no point wasting development resources on threats that may never emerge. If attacks become a problem, it can be dealt with then -- when more information on the nature of the threat is available, so a better solution can be developed than now (when there is no information, only speculation). We're not talking about an airline control system here, where waste is more than acceptable if it trivially reduces risk. Regards, John On Jan 15, 2009, at 6:38 AM, Yitzchak Gale wrote: > Duncan Coutts wrote: >> Detailed build reports with logs are not anonymous, clients will >> need an >> account on hackage (ie username and password). > > Right. If we experience problems with that in the future, > we just have to make sure that it won't be too hard > to set up captcha. > >> they'll either be obviously bogus > > Aren't we talking about an automated system? If we don't > explicitly design for the possibility of hostile reports, any > automated recognition will be trivial to circumvent. > >> or drowned out by the volume of legit reports. > > Again, if this is automated, it is trivial generate the > required volume. > > -Yitz > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ganesh.sittampalam at credit-suisse.com Thu Jan 15 11:40:59 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Jan 15 11:33:01 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B4DCB00@ELON17P32001A.csfb.cs-group.com> Lennart Augustsson wrote: > a name that anyone can figure out with just a little effort. I think the problem is that all these pieces of "little effort" soon mount up. It's not just the cost of looking it up, but also of remembering it the next time and so on. It's fine when you only encounter the occasional unfamiliar term, but a barrage of them all at once can be quite disorienting. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From rmm-haskell at z.odi.ac Thu Jan 15 11:46:50 2009 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Thu Jan 15 11:38:01 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> Message-ID: <1EA2D132-8873-42AD-8A77-6DF8491E76DA@z.odi.ac> For what it's worth, many (most/all?) programmers I know in person don't have the slightest clue about Category Theory and they may have known about abstract algebra once upon a time but certainly don't remember any of it now. They usually understand the concepts perfectly well enough but by "lay terms" or by no particular name at all. Personally, I don't mind it too much if the generic typeclasses are named using extremely accurate terms like Monoid, but saying that someone should then look up the abstract math concept and try to map this to something very concrete and simple such as a string seems like wasted effort. Usually when encountering something like "Monoid" (if I didn't already know it), I'd look it up in the library docs. The problem I've had with this tactic is twofold: First, the docs for the typeclass usually don't give any practical examples, so sometimes it's hard to be sure that the "append" in "mappend" means what you think it means. Second is that there appears to be no way to document an _instance_. It would be really handy if there were even a single line under "Instances > Monoid ([] a)" that explained how the type class was implemented for the list type. As it is, if you know what a Monoid is already, it's easy to figure out how it would be implemented. If you don't, you're either stuck reading a bunch of pages on the generic math term monoid and then finally realizing that it means "appendable" (and other similar things), or grovelling through the library source code seeing how the instance is implemented. My 2 cents, -Ross On Jan 15, 2009, at 11:36 AM, Lennart Augustsson wrote: > Most people don't understand pure functional programming either. Does > that mean we should introduce unrestricted side effects in Haskell? > > -- Lennart > > On Thu, Jan 15, 2009 at 4:22 PM, Thomas DuBuisson > wrote: >> On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh >> wrote: >>> Lennart Augustsson wrote: >>>> I have replied on his blog, but I'll repeat the gist of it here. >>>> Why is there a fear of using existing terminology that is exact? >>>> Why do people want to invent new words when there are already >>>> existing ones with the exact meaning that you want? If I see >>>> Monoid I >>>> know what it is, if I didn't know I could just look on Wikipedia. >>>> If I see Appendable I can guess what it might be, but exactly what >>>> does it mean? >>> >>> I would suggest that having to look things up slows people down >>> and might distract them from learning other, perhaps more useful, >>> things about the language. >> >> Exactly. For example, the entry for monoid on Wikipedia starts: >> "In abstract algebra, a branch of mathematics, a monoid is an >> algebraic structure with a single, associative binary operation and >> an >> identity element." >> >> I've had some set theory, but most programmers I know have not. >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From himself at poczta.nom.pl Thu Jan 15 11:47:04 2009 From: himself at poczta.nom.pl (Andrzej Jaworski) Date: Thu Jan 15 11:38:25 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt Message-ID: <6E27196D036A456FBB144A9E3D75E55A@bzdryk> If you called your girlfriend "Kitten" and on a mountain trip she broke her leg would cry/phone for help to treat your Kitten or would you use a stupid high-brow term "woman"? Or perhaps you would rename "Washington Square" for " My Kitten Square" ? There are hundreds programming languages designed by hackers, that is why I have chosen Haskell... From lennart at augustsson.net Thu Jan 15 11:49:48 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Jan 15 11:40:56 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B4DCB00@ELON17P32001A.csfb.cs-group.com> References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <16442B752A06A74AB4D9F9A5FF076E4B4DCB00@ELON17P32001A.csfb.cs-group.com> Message-ID: I won't deny that Haskell has a large number of unfamiliar term if you've only seen Java before. But I don't think that giving them all happy fuzzy names will help people in the long run. -- Lennart On Thu, Jan 15, 2009 at 4:40 PM, Sittampalam, Ganesh wrote: > Lennart Augustsson wrote: >> a name that anyone can figure out with just a little effort. > > I think the problem is that all these pieces of "little effort" > soon mount up. It's not just the cost of looking it up, but also > of remembering it the next time and so on. It's fine when you > only encounter the occasional unfamiliar term, but a barrage of > them all at once can be quite disorienting. > > Ganesh > > ============================================================================== > Please access the attached hyperlink for an important electronic communications disclaimer: > > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > ============================================================================== > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jgoerzen at complete.org Thu Jan 15 11:51:14 2009 From: jgoerzen at complete.org (John Goerzen) Date: Thu Jan 15 11:42:22 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> Message-ID: <496F6982.9000002@complete.org> Lennart Augustsson wrote: > Why do people think that you should be able to understand everything > without ever looking things up? I don't. But looking things up has to be helpful. In all to many cases, looking things up means clicking the link to someone's old academic paper or some article about abstract math in Wikipedia. It does not answer the questions: * Why is this in Haskell? * Why would I want to use it? * How does it benefit me? * How do I use it in Haskell? If the docs for things like Monoids were more newbie-friendly, I wouldn't gripe about it as much. Though if all we're talking about is naming, I would still maintain that newbie-friendly naming is a win. We can always say "HEY MATHEMETICIANS: APPENDABLE MEANS MONOID" in the haddock docs ;-) Much as I dislike Java's penchant for 200-character names for things, I'm not sure Monoid is more descriptive than SomeSortOfGenericThingThatYouCanAppendStuffToClassTemplateAbstractInterfaceThingy :-) -- John From wss at Cs.Nott.AC.UK Thu Jan 15 11:44:45 2009 From: wss at Cs.Nott.AC.UK (Wouter Swierstra) Date: Thu Jan 15 11:43:09 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496F6128.7080108@complete.org> References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> Message-ID: <3229D3F9-5ACF-40AE-A67D-84F7376EA446@cs.nott.ac.uk> At the risk of painting my own bikeshed... > If you're learning Haskell, which communicates the idea more clearly: > > * Appendable > > or > > * Monoid Would you call function composition (on endofunctions) "appending"? The join of a monad? A semi-colon (as in sequencing two imperative statements)? How do you append two numbers? Addition, multiplication, or something else entirely? All these operations are monoidal, i.e., are associative and have both left and right identities. If that's exactly what they have in common, why invent a new name? "Appendable" may carry some intuition, but it is not precise and sometimes quite misleading. > I guess the bottom line question is: who is Haskell for? Category > theorists, programmers, or both? I'd love it to be for both, but I've > got to admit that Brian has a point that it is trending to the first > in > some areas. One of my grievances about Haskell is the occasional disregard for existing terminology. "Stream Fusion" is about lazy lists/co-lists, not streams; "type families" mean something entirely different to type theorists. This kind of misnomer is even more confusing than a name that doesn't mean anything (at least, until you learn more category theory). Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From lennart at augustsson.net Thu Jan 15 11:53:51 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Jan 15 11:44:57 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <1EA2D132-8873-42AD-8A77-6DF8491E76DA@z.odi.ac> References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> <1EA2D132-8873-42AD-8A77-6DF8491E76DA@z.odi.ac> Message-ID: By no means do I suggest that Wikipedia should replace Haskell library documentation. I think the libraries should be documented in a mostly stand-alone way (i.e., no references to old papers etc.). In the case of Monoid, a few lines of text is enough to convey the meaning of it and gives an example. -- Lennart On Thu, Jan 15, 2009 at 4:46 PM, Ross Mellgren wrote: > For what it's worth, many (most/all?) programmers I know in person don't > have the slightest clue about Category Theory and they may have known about > abstract algebra once upon a time but certainly don't remember any of it > now. They usually understand the concepts perfectly well enough but by "lay > terms" or by no particular name at all. > > Personally, I don't mind it too much if the generic typeclasses are named > using extremely accurate terms like Monoid, but saying that someone should > then look up the abstract math concept and try to map this to something very > concrete and simple such as a string seems like wasted effort. > > Usually when encountering something like "Monoid" (if I didn't already know > it), I'd look it up in the library docs. The problem I've had with this > tactic is twofold: > > First, the docs for the typeclass usually don't give any practical examples, > so sometimes it's hard to be sure that the "append" in "mappend" means what > you think it means. > > Second is that there appears to be no way to document an _instance_. It > would be really handy if there were even a single line under "Instances > > Monoid ([] a)" that explained how the type class was implemented for the > list type. As it is, if you know what a Monoid is already, it's easy to > figure out how it would be implemented. If you don't, you're either stuck > reading a bunch of pages on the generic math term monoid and then finally > realizing that it means "appendable" (and other similar things), or > grovelling through the library source code seeing how the instance is > implemented. > > My 2 cents, > > -Ross > > > On Jan 15, 2009, at 11:36 AM, Lennart Augustsson wrote: > >> Most people don't understand pure functional programming either. Does >> that mean we should introduce unrestricted side effects in Haskell? >> >> -- Lennart >> >> On Thu, Jan 15, 2009 at 4:22 PM, Thomas DuBuisson >> wrote: >>> >>> On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh >>> wrote: >>>> >>>> Lennart Augustsson wrote: >>>>> >>>>> I have replied on his blog, but I'll repeat the gist of it here. >>>>> Why is there a fear of using existing terminology that is exact? >>>>> Why do people want to invent new words when there are already >>>>> existing ones with the exact meaning that you want? If I see Monoid I >>>>> know what it is, if I didn't know I could just look on Wikipedia. >>>>> If I see Appendable I can guess what it might be, but exactly what >>>>> does it mean? >>>> >>>> I would suggest that having to look things up slows people down >>>> and might distract them from learning other, perhaps more useful, >>>> things about the language. >>> >>> Exactly. For example, the entry for monoid on Wikipedia starts: >>> "In abstract algebra, a branch of mathematics, a monoid is an >>> algebraic structure with a single, associative binary operation and an >>> identity element." >>> >>> I've had some set theory, but most programmers I know have not. >>> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From john at n-brain.net Thu Jan 15 11:54:00 2009 From: john at n-brain.net (John A. De Goes) Date: Thu Jan 15 11:45:15 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <20090115163121.GA2646@hustlerturf.com> References: <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> <20090108221549.GA30539@hustlerturf.com> <4438705C-9069-4780-B6A9-7E928997D6EA@n-brain.net> <49676BEF.9050005@complete.org> <20090110231141.6B5DC93C4C@mail.avvanta.com> <20090115163121.GA2646@hustlerturf.com> Message-ID: <00783854-3308-4C04-ACB1-F1D33E90478B@n-brain.net> On Jan 15, 2009, at 9:31 AM, John Goerzen wrote: > By "pure" do you mean "containing python code only"? I'm looking > through a few, and: Search for "pure python mysql" or "pure python postgresql" and you'll see at least two implementations. In addition, there are plenty of pure Python databases for those who want and are able to stay strictly within Python. >> I don't think it's a bold assertion. If I'm using a Haskell library >> that >> wraps a C library, and find a bug in it, my chances of tracking >> down the >> bug in C code and submitting a patch to whatever group maintains it >> are >> exactly zero. On the other hand, if it's a pure Haskell library, >> I'll at > > Why? I'm tired of C. I'm not going to use any unpaid time writing or maintaining anything written in C. I assume if C were my favorite language, I'd be hanging around c-cafe instead of haskell-cafe. :-) > You have to balance that against the chances of there being bugs in > code that is used by far fewer people. That's true. > It's a lot of wheel reinvention to try to re-implement a database > protocol in n languages instead of do it in 1 and bind to it > everywhere else. Why is wheel reinvention a bad thing? A combination of cooperation and competition is best for every endeavor. We have lots of companies in the business of making tires, each trying to outdo the other, but for any given company, they are all united behind the goal of producing the best possible tire. The consumers benefit. > AFAIK, the only language where that sort of wheel reinvention is > popular is Java. But then Java seems to encourage wheel reinvention > anyhow ;-) The Java reinventions look and feel like Java, because they're native implementations. This is even more important in Haskell where the differences between Haskell and C is about as large as you can get. Regards, John From lemming at henning-thielemann.de Thu Jan 15 11:53:34 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 15 11:45:36 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: <404396ef0901150825w6f777499p353b49ba7363a9a@mail.gmail.com> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <404396ef0901150559gf203e9l14e791c100af0f16@mail.gmail.com> <404396ef0901150612q66b939f7ua495c1319b2d1cd9@mail.gmail.com> <404396ef0901150825w6f777499p353b49ba7363a9a@mail.gmail.com> Message-ID: On Thu, 15 Jan 2009, Neil Mitchell wrote: > I normally develop in Hugs, for a change I wanted to try GHCi. It's > also a project that has loads of pattern matching at a fairly complex > level, so the benefits offered by view-patterns and pattern-guards > were just too hard to pass up. Are you sure that you can't come up with some nice functions like 'maybe' to replace those view patterns by function calls? Did you really try? I remember the recent discussion on pattern combinators here on Haskell Cafe. From rmm-haskell at z.odi.ac Thu Jan 15 11:56:09 2009 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Thu Jan 15 11:47:16 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> <1EA2D132-8873-42AD-8A77-6DF8491E76DA@z.odi.ac> Message-ID: <95746804-EC70-4388-8CF9-080648BF002C@z.odi.ac> Of course not, the wikipedians would probably have your head for notability guidelines or something ;-) But seriously, I would have saved many hours of my life and probably many future ones if type class instances were documented and showed up in the haddock docs. -Ross On Jan 15, 2009, at 11:53 AM, Lennart Augustsson wrote: > By no means do I suggest that Wikipedia should replace Haskell library > documentation. > I think the libraries should be documented in a mostly stand-alone way > (i.e., no references to old papers etc.). In the case of Monoid, a > few lines of text is enough to convey the meaning of it and gives an > example. > > -- Lennart > > On Thu, Jan 15, 2009 at 4:46 PM, Ross Mellgren haskell@z.odi.ac> wrote: >> For what it's worth, many (most/all?) programmers I know in person >> don't >> have the slightest clue about Category Theory and they may have >> known about >> abstract algebra once upon a time but certainly don't remember any >> of it >> now. They usually understand the concepts perfectly well enough but >> by "lay >> terms" or by no particular name at all. >> >> Personally, I don't mind it too much if the generic typeclasses are >> named >> using extremely accurate terms like Monoid, but saying that someone >> should >> then look up the abstract math concept and try to map this to >> something very >> concrete and simple such as a string seems like wasted effort. >> >> Usually when encountering something like "Monoid" (if I didn't >> already know >> it), I'd look it up in the library docs. The problem I've had with >> this >> tactic is twofold: >> >> First, the docs for the typeclass usually don't give any practical >> examples, >> so sometimes it's hard to be sure that the "append" in "mappend" >> means what >> you think it means. >> >> Second is that there appears to be no way to document an >> _instance_. It >> would be really handy if there were even a single line under >> "Instances > >> Monoid ([] a)" that explained how the type class was implemented >> for the >> list type. As it is, if you know what a Monoid is already, it's >> easy to >> figure out how it would be implemented. If you don't, you're either >> stuck >> reading a bunch of pages on the generic math term monoid and then >> finally >> realizing that it means "appendable" (and other similar things), or >> grovelling through the library source code seeing how the instance is >> implemented. >> >> My 2 cents, >> >> -Ross >> >> >> On Jan 15, 2009, at 11:36 AM, Lennart Augustsson wrote: >> >>> Most people don't understand pure functional programming either. >>> Does >>> that mean we should introduce unrestricted side effects in Haskell? >>> >>> -- Lennart >>> >>> On Thu, Jan 15, 2009 at 4:22 PM, Thomas DuBuisson >>> wrote: >>>> >>>> On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh >>>> wrote: >>>>> >>>>> Lennart Augustsson wrote: >>>>>> >>>>>> I have replied on his blog, but I'll repeat the gist of it here. >>>>>> Why is there a fear of using existing terminology that is exact? >>>>>> Why do people want to invent new words when there are already >>>>>> existing ones with the exact meaning that you want? If I see >>>>>> Monoid I >>>>>> know what it is, if I didn't know I could just look on Wikipedia. >>>>>> If I see Appendable I can guess what it might be, but exactly >>>>>> what >>>>>> does it mean? >>>>> >>>>> I would suggest that having to look things up slows people down >>>>> and might distract them from learning other, perhaps more useful, >>>>> things about the language. >>>> >>>> Exactly. For example, the entry for monoid on Wikipedia starts: >>>> "In abstract algebra, a branch of mathematics, a monoid is an >>>> algebraic structure with a single, associative binary operation >>>> and an >>>> identity element." >>>> >>>> I've had some set theory, but most programmers I know have not. >>>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> From wchogg at gmail.com Thu Jan 15 11:57:01 2009 From: wchogg at gmail.com (Creighton Hogg) Date: Thu Jan 15 11:48:09 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <1EA2D132-8873-42AD-8A77-6DF8491E76DA@z.odi.ac> References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> <1EA2D132-8873-42AD-8A77-6DF8491E76DA@z.odi.ac> Message-ID: <814617240901150857r337d7586o6b0df12cdb8098e8@mail.gmail.com> On Thu, Jan 15, 2009 at 10:46 AM, Ross Mellgren wrote: > Usually when encountering something like "Monoid" (if I didn't already know > it), I'd look it up in the library docs. The problem I've had with this > tactic is twofold: > > First, the docs for the typeclass usually don't give any practical examples, > so sometimes it's hard to be sure that the "append" in "mappend" means what > you think it means. > > Second is that there appears to be no way to document an _instance_. It > would be really handy if there were even a single line under "Instances > > Monoid ([] a)" that explained how the type class was implemented for the > list type. As it is, if you know what a Monoid is already, it's easy to > figure out how it would be implemented. If you don't, you're either stuck > reading a bunch of pages on the generic math term monoid and then finally > realizing that it means "appendable" (and other similar things), or > grovelling through the library source code seeing how the instance is > implemented. I think you have a good point regarding documentation. Usually what I end up doing is just going into ghci & testing out the instances with some trivial cases to make sure I have good intuition for how it's going to work. I don't think this a problem with the term 'monoid' though, but just a very generic problem with documentation. I have to do the same thing to understand an instance of Foldable despite how literal the name is. I don't know if it's very practical, but I like the idea of haddock generating either links to the source of the instance or some kind of expandable block that will show you the literal code. Cheers, Creighton From jgoerzen at complete.org Thu Jan 15 11:56:59 2009 From: jgoerzen at complete.org (John Goerzen) Date: Thu Jan 15 11:48:26 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> Message-ID: <496F6ADB.5050300@complete.org> Lennart Augustsson wrote: > Most people don't understand pure functional programming either. Does > that mean we should introduce unrestricted side effects in Haskell? The key is to introduce concepts to them in terms they can understand. You introduce it one way to experienced abstract mathematicians, and a completely different way to experienced Perl hackers. I wouldn't expect a mathematician to grok Perl, and I wouldn't expect $PERL_HACKER to grok abstract math. People have different backgrounds to draw upon, and we are under-serving one community. -- John From lennart at augustsson.net Thu Jan 15 12:01:56 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Jan 15 11:53:01 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496F6982.9000002@complete.org> References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <496F6982.9000002@complete.org> Message-ID: I think the documentation should be reasonably newbie-friendly too. But that doesn't mean we should call Monoid Appendable. Appendable is just misleading, since Monoid is more general than appending. -- Lennart On Thu, Jan 15, 2009 at 4:51 PM, John Goerzen wrote: > Lennart Augustsson wrote: >> Why do people think that you should be able to understand everything >> without ever looking things up? > > I don't. But looking things up has to be helpful. In all to many > cases, looking things up means clicking the link to someone's old > academic paper or some article about abstract math in Wikipedia. It > does not answer the questions: > > * Why is this in Haskell? > > * Why would I want to use it? > > * How does it benefit me? > > * How do I use it in Haskell? > > If the docs for things like Monoids were more newbie-friendly, I > wouldn't gripe about it as much. > > Though if all we're talking about is naming, I would still maintain that > newbie-friendly naming is a win. We can always say "HEY MATHEMETICIANS: > APPENDABLE MEANS MONOID" in the haddock docs ;-) > > Much as I dislike Java's penchant for 200-character names for things, > I'm not sure Monoid is more descriptive than > SomeSortOfGenericThingThatYouCanAppendStuffToClassTemplateAbstractInterfaceThingy > :-) > > -- John > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ndmitchell at gmail.com Thu Jan 15 12:02:56 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Jan 15 11:54:07 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <404396ef0901150559gf203e9l14e791c100af0f16@mail.gmail.com> <404396ef0901150612q66b939f7ua495c1319b2d1cd9@mail.gmail.com> <404396ef0901150825w6f777499p353b49ba7363a9a@mail.gmail.com> Message-ID: <404396ef0901150902m8e18b7fi3d2b309773bba0cb@mail.gmail.com> > Are you sure that you can't come up with some nice functions like 'maybe' to > replace those view patterns by function calls? Did you really try? I > remember the recent discussion on pattern combinators here on Haskell Cafe. I could, but it would look more ugly - and I want my code to be beautiful :-) For HLint, view-patterns are something I could live without, SYB is something I couldn't live without. SYB makes me GHC only, view-patterns make me GHC 6.10 only. I could port it to GHC 6.8.3, but I don't think its worth the effort, and the complication that would ensue. In general a view-pattern, as used in HLint, can be translated away by: foo (view -> RHS) ... = ... foo new_var ... | RHS <- view new_var = ... But its more ugly, requires more intermediate variables, isn't as clear and isn't a generally correct translation (but I think it would almost always work in HLint). Thanks Neil From lennart at augustsson.net Thu Jan 15 12:04:49 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Jan 15 11:55:56 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <95746804-EC70-4388-8CF9-080648BF002C@z.odi.ac> References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> <1EA2D132-8873-42AD-8A77-6DF8491E76DA@z.odi.ac> <95746804-EC70-4388-8CF9-080648BF002C@z.odi.ac> Message-ID: I'm totally with you on the instance documentation. I wish haddock allowed it. On Thu, Jan 15, 2009 at 4:56 PM, Ross Mellgren wrote: > Of course not, the wikipedians would probably have your head for notability > guidelines or something ;-) > > But seriously, I would have saved many hours of my life and probably many > future ones if type class instances were documented and showed up in the > haddock docs. > > -Ross From mail at justinbogner.com Thu Jan 15 12:04:59 2009 From: mail at justinbogner.com (mail@justinbogner.com) Date: Thu Jan 15 11:56:19 2009 Subject: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> Message-ID: <87ljtcpkjo.fsf@justinbogner.com> John Goerzen writes: > Wikipedia's first sentence about monoids is: > > In abstract algebra, a branch of mathematics, a monoid is an algebraic > structure with a single, associative binary operation and an identity > element. > > Which is *not* intuitive to someone that comes from a background in.... > any other programming language. > Instead of Wikipedia, why not try a dictionary? Looking up monoid using dictionary.com: An operator * and a value x form a monoid if * is associative and x is its left and right identity. On the other hand, appendable doesn't seem to be a word, and while you can infer that it means "something that can be appended to", that's only half of the story... From ifl2009 at shu.edu Thu Jan 15 12:09:21 2009 From: ifl2009 at shu.edu (IFL 2009) Date: Thu Jan 15 12:00:30 2009 Subject: [Haskell-cafe] IFL 2009: Call for Papers Message-ID: Call for Papers IFL 2009 Seton Hall University SOUTH ORANGE, NJ, USA http://tltc.shu.edu/blogs/projects/IFL2009/ The 21st IFL symposium, IFL 2009, will be held for the first time in the USA. The hosting institution is Seton Hall University in South Orange, NJ, USA and the symposium dates are September 23-25, 2009. It is our goal to make IFL a regular event held in the USA. The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2009 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Following the IFL tradition, IFL 2009 will use a post-symposium review process to produce a formal proceedings which we expect to be published by Springer in the Lecture Notes in Computer Science series. All participants in IFL 2009 are invited to submit either a draft paper or and extended abstract describing work to be presented at the symposium. These submissions will be screened by the program committee chair to make sure they are within the scope of IFL and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full arcticle for the formal review process. These revised submissions will be reviewed by the program committee using prevailing academic standards to select the best articles that will appear in the formal proceedings. TOPICS IFL welcomes submissions describing practical and theoretical as well as submissions describing applications and tools. If you are not sure if your work is appropriate for IFL 2009, please contact the PC chair at ifl2009@shu.edu. Topics of interest include, but are not limited to: language concepts type checking contracts compilation techniques staged compilation runtime function specialization runtime code generation partial evaluation (abstract) interpretation generic programming techniques automatic program generation array processing concurrent/parallel programming concurrent/parallel program execution functional programming and embedded systems functional programming and web applications functional programming and security novel memory management techniques runtime profiling and performance measurements debugging and tracing virtual/abstract machine architectures validation and verification of functional programs tools and programming techniques PAPER SUBMISSIONS Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to present them at the symposium. All contributions must be written in English, conform to the Springer-Verlag LNCS series format and not exceed 16 pages. The draft proceedings will appear as a technical report of the Department of Mathematics and Computer Science of Seton Hall University. IMPORTANT DATES Registration deadline August 15, 2009 Presentation submission deadline August 15, 2009 IFL 2009 Symposium September 23-25, 2009 Submission for review process deadline November 1, 2009 Notification Accept/Reject December 22, 2009 Camera ready version January 15, 2010 PROGRAM COMMITTEE Peter Achten University of Nijmegen, The Netherlands Jost Berthold Philipps-Universit?t Marburg, Germany Andrew Butterfield University of Dublin, Ireland Robby Findler Northwestern University, USA Kathleen Fisher AT&T Research, USA Cormac Flanagan University of California at Santa Cruz, USA Matthew Flatt University of Utah, USA Matthew Fluet Toyota Technological Institute at Chicago, USA Daniel Friedman Indiana University, USA Andy Gill University of Kansas, USA Clemens Grelck University of Amsterdam/Hertfordshire, The Netherlands/UK Jurriaan Hage Utrecht University, The Netherlands Ralf Hinze Oxford University, UK Paul Hudak Yale University, USA John Hughes Chalmers University of Technology, Sweden Patricia Johann University of Strathclyde, UK Yukiyoshi Kameyama University of Tsukuba, Japan Marco T. Moraz?n (Chair) Seton Hall University, USA Rex Page University of Oklahoma, USA Fernando Rubio Universidad Complutense de Madrid, Spain Sven-Bodo Scholz University of Hertfordshire, UK Manuel Serrano INRIA Sophia-Antipolis, France Chung-chieh Shan Rutgers University, USA David Walker Princeton University, USA Vikt?ria Zs?k E?tv?s Lor?nd University, Hungary PETER LANDIN PRIZE The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 euros. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/f6944183/attachment.htm From tanimoto at arizona.edu Thu Jan 15 12:10:57 2009 From: tanimoto at arizona.edu (Paulo Tanimoto) Date: Thu Jan 15 12:02:04 2009 Subject: [Haskell-cafe] Re: Compiling regex-posix-0.93.2 on windows In-Reply-To: <48F912A4.9060306@list.mightyreason.com> References: <48F912A4.9060306@list.mightyreason.com> Message-ID: Hi Chris et al: On Fri, Oct 17, 2008 at 4:33 PM, Chris Kuklewicz wrote: > I am not sure what is going wrong. I have not been using Haskell on > windows. I am also copying this reply to haskell-cafe and libaries mailing > lists. Does anyone know? I get passed that error on Cygwin by installing it like this: $ cabal update $ cabal install --extra-include-dirs="c:\cygwin\usr\include" regex-posix However, when I try using regex-posix, I get: $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> import Text.Regex.Posix Prelude Text.Regex.Posix> "Hello World" =~ "W" :: String Loading package syb ... linking ... done. Loading package base-3.0.3.0 ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package regex-base-0.93.1 ... linking ... done. Loading package regex-posix-0.93.2 ... linking ... ghci-haskeline.exe: unable to load package `regex-posix-0.93.2' Prelude Text.Regex.Posix> :q Leaving GHCi. : C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1\HSregex-posix-0.93.2.o: unknown symbol `_regerror' Compiling reveals more details: $ cat > reg.hs << EOF > import Text.Regex.Posix > > test = "Hello World!" =~ "W" :: String > > main = putStrLn test > EOF $ ghc --make reg.hs Linking reg.exe ... C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0xa2f): undefined reference to `regerror' C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0xa83): undefined reference to `regerror' C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0xb6b): undefined reference to `regfree' C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0xd39): undefined reference to `regcomp' C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0xf8f): undefined reference to `regexec' C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0x3656): undefined reference to `regexec' C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0x3aaa): undefined reference to `regexec' C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0x3e06): undefined reference to `regexec' C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0x4bcd): undefined reference to `regexec' C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0x512e): more undefined references to `regexec' follow collect2: ld returned 1 exit status Any ideas? I feel like I'm missing something very simple. Thanks, Paulo From mail at justinbogner.com Thu Jan 15 12:11:50 2009 From: mail at justinbogner.com (mail@justinbogner.com) Date: Thu Jan 15 12:03:09 2009 Subject: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> <1EA2D132-8873-42AD-8A77-6DF8491E76DA@z.odi.ac> Message-ID: <87hc40pk89.fsf@justinbogner.com> Ross Mellgren writes: > Usually when encountering something like "Monoid" (if I didn't already > know it), I'd look it up in the library docs. The problem I've had > with this tactic is twofold: > > First, the docs for the typeclass usually don't give any practical > examples, so sometimes it's hard to be sure that the "append" in > "mappend" means what you think it means. I second this, many of the docs are sorely lacking examples (and there are of course docs that simply reference a paper, which is usually too long to be helpful in the short term...) From andrei.formiga at gmail.com Thu Jan 15 12:14:27 2009 From: andrei.formiga at gmail.com (Andrei Formiga) Date: Thu Jan 15 12:05:33 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <3229D3F9-5ACF-40AE-A67D-84F7376EA446@cs.nott.ac.uk> References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <3229D3F9-5ACF-40AE-A67D-84F7376EA446@cs.nott.ac.uk> Message-ID: On Thu, Jan 15, 2009 at 1:44 PM, Wouter Swierstra wrote: > > Would you call function composition (on endofunctions) "appending"? The join > of a monad? A semi-colon (as in sequencing two imperative statements)? How > do you append two numbers? Addition, multiplication, or something else > entirely? > > All these operations are monoidal, i.e., are associative and have both left > and right identities. If that's exactly what they have in common, why invent > a new name? "Appendable" may carry some intuition, but it is not precise and > sometimes quite misleading. > I think this highlights an interesting point: Haskell is more abstract than most other languages. While in other languages "Appendable" might just mean what Brian suggested in his post, "something with an empty state and the ability to append things to the end", in Haskell it applies to numbers and everything else that has an associative operator, that is, everything that is a monoid. So "Appendable" for numbers would be quite wrong; either it would never be used in situations where one wanted to "append things to the end" (which is limiting), or it would be used in these situations, which would be quite confusing. I think it is much more important to have good documentation about the typeclasses (and everything else in the library). This issue was mentioned recently in a discussion about monads, and the documentation for the Haskell library is quite uninformative. It would be nice if 1) people would not be scared of names like "monoid" and "functor" and 2) the documentation clearly stated what these things are, in a programming context, preferably with some examples. I think 2 would mitigate some of the fear mentioned in 1, if newcomers started to experience things like "hey, that's one funky-named stuff this monoid thing, but I see here in the documentation that it is quite simple". -- []s, Andrei Formiga From mail at justinbogner.com Thu Jan 15 12:13:25 2009 From: mail at justinbogner.com (mail@justinbogner.com) Date: Thu Jan 15 12:06:10 2009 Subject: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> <1EA2D132-8873-42AD-8A77-6DF8491E76DA@z.odi.ac> Message-ID: <87d4eopk5m.fsf@justinbogner.com> "Lennart Augustsson" writes: > By no means do I suggest that Wikipedia should replace Haskell library > documentation. > I think the libraries should be documented in a mostly stand-alone way > (i.e., no references to old papers etc.). In the case of Monoid, a > few lines of text is enough to convey the meaning of it and gives an > example. I don't think references to old papers are a bad thing (they might be good papers), but such references should certainly not be a replacement for a brief explanation and helpful example! From ganesh.sittampalam at credit-suisse.com Thu Jan 15 12:15:56 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Jan 15 12:08:29 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <496F6982.9000002@complete.org> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B4DCB02@ELON17P32001A.csfb.cs-group.com> Lennart Augustsson wrote: > I think the documentation should be reasonably newbie-friendly too. > But that doesn't mean we should call Monoid Appendable. > Appendable is just misleading, since Monoid is more general than > appending. Then why does it have a member named 'mappend'? :-) Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From dons at galois.com Thu Jan 15 12:19:16 2009 From: dons at galois.com (Don Stewart) Date: Thu Jan 15 12:10:17 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <20090115153438.GA1340@hustlerturf.com> References: <20090115153438.GA1340@hustlerturf.com> Message-ID: <20090115171916.GG15657@scytale.galois.com> jgoerzen: > Hi folks, > > Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml > hacker: > > http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/ > > It's a great post, and I encourage people to read it. I'd like to > highlight one particular paragraph: I'd also recommend yesterday's post http://intoverflow.wordpress.com/2009/01/13/why-haskell-is-beyond-ready-for-prime-time/ Why Haskell is beyond ready for prime time For a few other insights. (Notably, the joy of hoogle/hayoo library search) From ganesh.sittampalam at credit-suisse.com Thu Jan 15 12:13:20 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Jan 15 12:10:27 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B4DCB01@ELON17P32001A.csfb.cs-group.com> Lennart Augustsson wrote: > Most people don't understand pure functional programming either. > Does that mean we should introduce unrestricted side effects in > Haskell? No, just that we should seek to minimise the new stuff they have to get to grips with. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From dpiponi at gmail.com Thu Jan 15 12:47:41 2009 From: dpiponi at gmail.com (Dan Piponi) Date: Thu Jan 15 12:38:47 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <20090115153438.GA1340@hustlerturf.com> References: <20090115153438.GA1340@hustlerturf.com> Message-ID: <625b74080901150947t714899cck28e0ba7b1e5e4305@mail.gmail.com> On Thu, Jan 15, 2009 at 7:34 AM, John Goerzen quoted: > I'd be inclined to call it something like "Appendable". But I don't know what Appendable means. Maybe it means > class Appendable a where > append :: a x -> x -> a x ie. a container x's lets you can add an x to the end or maybe it means > class Appendable a where > append :: a -> x -> a ie. something that you can append anything to or maybe it means > class Appendable a where > append :: a -> a -> a so you can append any two elements of the same type together. Why use words that are so vague when there's already word that unambiguously says what the type class looks like? And even worse, why use duplicate terminology to make it even harder to see when mathematicians and computer scientists are talking about the same thing, so widening the divide between two groups of people who have much to share. -- Dan From lennart at augustsson.net Thu Jan 15 13:00:44 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Jan 15 12:51:52 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B4DCB02@ELON17P32001A.csfb.cs-group.com> References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <496F6982.9000002@complete.org> <16442B752A06A74AB4D9F9A5FF076E4B4DCB02@ELON17P32001A.csfb.cs-group.com> Message-ID: Beats me. As I said, I don't think Haskell gets all the names right. :) On Thu, Jan 15, 2009 at 5:15 PM, Sittampalam, Ganesh wrote: > Lennart Augustsson wrote: >> I think the documentation should be reasonably newbie-friendly too. >> But that doesn't mean we should call Monoid Appendable. >> Appendable is just misleading, since Monoid is more general than >> appending. > > Then why does it have a member named 'mappend'? :-) > > Ganesh > > ============================================================================== > Please access the attached hyperlink for an important electronic communications disclaimer: > > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > ============================================================================== > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From p.f.moore at gmail.com Thu Jan 15 13:04:24 2009 From: p.f.moore at gmail.com (Paul Moore) Date: Thu Jan 15 12:55:32 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> Message-ID: <79990c6b0901151004s4da9ed24ob2c646a00abb2169@mail.gmail.com> 2009/1/15 Lennart Augustsson : > Why do people think that you should be able to understand everything > without ever looking things up? Understand, no, but "have an intuition about", very definitely yes. In mathematics (and I speak as someone with a mathematical degree, so if I caricature anyone, please excuse it as failing memory rather than intent!!!) there's a tendency to invent terminology, rather than use natural names, because new names don't have unwanted connotations - it's the need for precision driving things. In programming, the need is for *communication* and as such, using words with natural - if imprecise, and occasionally even (slightly) wrong - connotations is extremely helpful. > I'll get back to my example from the comment on the blog post. If I > see 'ghee' in a cook book I'll check what it is (if I don't know). If a significant proportion of words require me to look them up, my flow of understanding is lost and I'll either give up, end up with a muddled impression, or take far longer to understand than the recipe merits (and so, I'll probably not use that cook book again). > I'm not saying Haskell always gets naming right, all I want is to > reuse words that exist instead of inventing new ones. But you seem to be insisting that mathematical terminology is the place to reuse from - whereas, in fact, computing might be a better basis (although computing doesn't insist on the precision that maths needs, so in any "that's not precisely what I mean" argument, non-mathematical terminology starts off an a disadvantage, even though absolute precision may not be the key requirement). > (And 'monoid' is not category theory, it's very basic (abstract) algebra.) Well, I did a MSc course in mathematics, mostly pure maths including algebra, set theory and similar areas, and I never came across the term. Of course, my degree was 25 years ago, so maybe "monoid" is a term that wasn't invented then ;-)) > I don't > know any category theory, but if someone tells me that blah is an > endomorphism I'm happy to call it that, knowing that I have a name > that anyone can figure out with just a little effort. But unless you invest time researching, you can't draw any conclusions from that. If someone tells you it's a mapping, you can infer that it probably "maps" some things to one another, which gives you a (minimal, imprecise, and possibly wrong in some corner cases, but nevertheless useful) indication of what's going on. Mathematical precision isn't appropriate in all disciplines. Paul. From anton at appsolutions.com Thu Jan 15 13:04:55 2009 From: anton at appsolutions.com (Anton van Straaten) Date: Thu Jan 15 12:56:03 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B4DCB02@ELON17P32001A.csfb.cs-group.com> References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <496F6982.9000002@complete.org> <16442B752A06A74AB4D9F9A5FF076E4B4DCB02@ELON17P32001A.csfb.cs-group.com> Message-ID: <496F7AC7.2040507@appsolutions.com> Sittampalam, Ganesh wrote: > Lennart Augustsson wrote: >> I think the documentation should be reasonably newbie-friendly too. >> But that doesn't mean we should call Monoid Appendable. >> Appendable is just misleading, since Monoid is more general than >> appending. > > Then why does it have a member named 'mappend'? :-) That's a mistake - and in fact, it's a good demonstration of why Monoid should not be named something like Appendable - because it misleads people into thinking that the structure is less general than it really is. Anton From robgreayer at yahoo.com Thu Jan 15 13:11:08 2009 From: robgreayer at yahoo.com (Robert Greayer) Date: Thu Jan 15 13:02:17 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] Message-ID: <33686.49877.qm@web65711.mail.ac4.yahoo.com> ----- Original Message ---- From: John A. De Goes On Jan 15, 2009, at 9:31 AM, John Goerzen wrote: >> AFAIK, the only language where that sort of wheel reinvention is >> popular is Java. But then Java seems to encourage wheel reinvention >> anyhow ;-) > The Java reinventions look and feel like Java, because they're native implementations. > This is even more important in Haskell where the differences between > Haskell and C is about as large as you can get. The Java reinventions largely exist because of the huge deployment-time benefits you get from pure-Java code (cross-platform portability of compiled (byte) code, dynamic loading of compiled code over a network, etc.). Such reinventions are much less important for Haskell, since the typical deployment model for a Haskell program is much closer to that of a C program than a Java program or even a Python program. From leimy2k at gmail.com Thu Jan 15 13:14:00 2009 From: leimy2k at gmail.com (David Leimbach) Date: Thu Jan 15 13:05:08 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <33686.49877.qm@web65711.mail.ac4.yahoo.com> References: <33686.49877.qm@web65711.mail.ac4.yahoo.com> Message-ID: <3e1162e60901151014y6112ffa8k3cc3c687fd3ecd42@mail.gmail.com> On Thu, Jan 15, 2009 at 10:11 AM, Robert Greayer wrote: > > > > > ----- Original Message ---- > From: John A. De Goes > On Jan 15, 2009, at 9:31 AM, John Goerzen wrote: > >> AFAIK, the only language where that sort of wheel reinvention is > >> popular is Java. But then Java seems to encourage wheel reinvention > >> anyhow ;-) > > > The Java reinventions look and feel like Java, because they're native > implementations. > > This is even more important in Haskell where the differences between > > Haskell and C is about as large as you can get. > > The Java reinventions largely exist because of the huge deployment-time > benefits you get from pure-Java code (cross-platform portability of compiled > (byte) code, dynamic loading of compiled code over a network, etc.). Such > reinventions are much less important for Haskell, since the typical > deployment model for a Haskell program is much closer to that of a C program > than a Java program or even a Python program. > I think deployment of Haskell is even easier than that of python, in that you don't have to have all the developer packages installed on target machines to have other's benefit from their use in your binary.... at least with GHC that is. I've often been quite happily surprised what can be done with little in terms of runtime dependencies with Haskell. Dave > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/2a38a664/attachment.htm From dave at zednenem.com Thu Jan 15 13:21:34 2009 From: dave at zednenem.com (David Menendez) Date: Thu Jan 15 13:12:42 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <1EA2D132-8873-42AD-8A77-6DF8491E76DA@z.odi.ac> References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> <1EA2D132-8873-42AD-8A77-6DF8491E76DA@z.odi.ac> Message-ID: <49a77b7a0901151021v5c26d3d5k635231574caab7ea@mail.gmail.com> On Thu, Jan 15, 2009 at 11:46 AM, Ross Mellgren wrote: > > Usually when encountering something like "Monoid" (if I didn't already know > it), I'd look it up in the library docs. The problem I've had with this > tactic is twofold: > > First, the docs for the typeclass usually don't give any practical examples, > so sometimes it's hard to be sure that the "append" in "mappend" means what > you think it means. The documentation for Monoid is embarrassingly brief. "The monoid class. A minimal complete definition must supply mempty and mappend, and these should satisfy the monoid laws." It doesn't even list the monoid laws! > Second is that there appears to be no way to document an _instance_. It > would be really handy if there were even a single line under "Instances > > Monoid ([] a)" that explained how the type class was implemented for the > list type. As it is, if you know what a Monoid is already, it's easy to > figure out how it would be implemented. Not necessarily. Any instance of MonadPlus (or Alternative) has at least two reasonable Monoid instances: (mplus, mzero) and (liftM2 mappend, return mempty). [] uses the first and Maybe uses the second. I recommend not creating direct instances of Monoid for this reason. If you want to use Monoid with Int, you have to use Sum Int or Product Int. -- Dave Menendez From martindemello at gmail.com Thu Jan 15 13:21:50 2009 From: martindemello at gmail.com (Martin DeMello) Date: Thu Jan 15 13:13:07 2009 Subject: [Haskell-cafe] Arch Haskell News: Jan 11 2009 In-Reply-To: <20090111223053.GA1296@scytale.galois.com> References: <20090111223053.GA1296@scytale.galois.com> Message-ID: On Mon, Jan 12, 2009 at 4:00 AM, Don Stewart wrote: > Arch Haskell News: Jan 11 2009 > > Hey all, welcome to the first Arch Haskell News of 2009. (News about > Haskell on the Arch Linux platform). > > Arch now has 827 Haskell packages in AUR. FWIW I just replaced gentoo[1] on my desktop with arch, at least in part due to this sort of community enthusiasm :) [1] i was going to replace it anyway, but wasn't sure what with martin From lennart at augustsson.net Thu Jan 15 13:27:26 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Jan 15 13:18:32 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <79990c6b0901151004s4da9ed24ob2c646a00abb2169@mail.gmail.com> References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <79990c6b0901151004s4da9ed24ob2c646a00abb2169@mail.gmail.com> Message-ID: That's very true. But programming is one where mathematical precision is needed, even if you want to call it something else. On Thu, Jan 15, 2009 at 6:04 PM, Paul Moore wrote: > > Mathematical precision isn't appropriate in all disciplines. > From manlio_perillo at libero.it Thu Jan 15 13:31:41 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Thu Jan 15 13:23:06 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <20090115163121.GA2646@hustlerturf.com> References: <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> <20090108221549.GA30539@hustlerturf.com> <4438705C-9069-4780-B6A9-7E928997D6EA@n-brain.net> <49676BEF.9050005@complete.org> <20090110231141.6B5DC93C4C@mail.avvanta.com> <20090115163121.GA2646@hustlerturf.com> Message-ID: <496F810D.7010803@libero.it> John Goerzen ha scritto: >> Python has pure interfaces to all the major databases. While it's true >> there are no "native" GUI libraries, there are pure Python libraries for >> just about everything else. Haskell is not yet to this point. > > By "pure" do you mean "containing python code only"? I'm looking > through a few, and: > > PostgreSQL - psycopg - C > PostgreSQL - pgsql - C > PostgreSQL - pygresql - C > MySQL - mysqldb - C > MS SQL Server - pymssql - C > > And any interface that uses ODBC will, by necessity, be calling to C, > because ODBC is defined as a C API and not a network protocol. > > Where are all these pure-Python drivers? > Time ago, I implemented a client for the network protocol used by PostgreSQL: http://hg.mperillo.ath.cx/twisted/pglib/ it covers almost all the protocol features (only extended queries are not supported). It is implemented using Twisted. I would like to reimplement it in Haskell, sometime in the future. I tried to implement the MySQL network protocol, too, but it is a *mess*, so I gave up (and, at that time, there were strange claims about copyright). It is also possible to support MSSQL and Sybase, implementing a client for the TDS (Tabular Data Stream) protocol. TDS, too, is a mess (well, if you compare it with the PostgreSQL protocol), and last time I studied it, the freeTDS project only had a reversed engineered protocol documentation; now Microsoft has made the TDS variant used my MSSQL public: http://msdn.microsoft.com/en-us/library/cc448435.aspx So, in theory, it should not really be a problem to implement native and robust support for PostgreSQL, MySQL, MSSQL and Sybase. One benefit of these implementation would be builtin support to concurrency [1]. For PostgreSQL, a native implementation can be useful to listen notifies. > [...] [1] the libpq API *has* support for async API, but it is not complete (and well tested like sync API, IMHO). As an example there is no support for async function call, although "The Function Call sub-protocol is a legacy feature that is probably best avoided in new code. Similar results can be accomplished by setting up a prepared statement that does SELECT function($1, ...). The Function Call cycle can then be replaced with Bind/Execute." P.S.: the PostgreSQL protocol is really well designed Regards Manlio Perillo From newsham at lava.net Thu Jan 15 13:36:11 2009 From: newsham at lava.net (Tim Newsham) Date: Thu Jan 15 13:27:35 2009 Subject: [Haskell-cafe] software correctness ... can we in FPL step up to the plate?? In-Reply-To: <5ae4f2ba0901142049y32b7e5a1x90154e87057e3177@mail.gmail.com> References: <5ae4f2ba0901142049y32b7e5a1x90154e87057e3177@mail.gmail.com> Message-ID: > http://www.businessweek.com/the_thread/techbeat/archives/2009/01/nsa_dhs_industr.html?link_position=link3 > ... > > I think that http://www.galois.com is already doing as stated in the > article/ ...... I sincerely think there is a segway for Haskell here with > strong and static type checking.. Strong static type checking is a very useful tool, but there's a lot more to securing against the 25 most common errors. For example, you can use the type system to ensure that output encoding is always applied to user-provided data, but you must first be aware of this issue and write libraries that enforce this and make use of these libraries a requirement in applications or application frameworks. Some problems such as cross-site request forgery are best addressed by the application framework, so framework authors must be aware of these issues and implement protections for the issue. This usually involves the use of some cryptographic primitives, and the type system doesn't do anything to make sure you get that right. Security issues are (mostly) a subset of correctness issues. Haskell provides some tools to help you make sure your program is correct, but there are a lot of ways to write incorrect software despite the help these tools provide. These tools are very valuable and should be sold to the wider developer community, but they are no silver bullet. > Vasili Tim Newsham http://www.thenewsh.com/~newsham/ From anton at appsolutions.com Thu Jan 15 13:46:40 2009 From: anton at appsolutions.com (Anton van Straaten) Date: Thu Jan 15 13:37:54 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496F6982.9000002@complete.org> References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <496F6982.9000002@complete.org> Message-ID: <496F8490.5060604@appsolutions.com> John Goerzen wrote: > Though if all we're talking about is naming, I would still maintain that > newbie-friendly naming is a win. We can always say "HEY MATHEMETICIANS: > APPENDABLE MEANS MONOID" in the haddock docs ;-) This is backwards. The real problem here is that most people coming from other languages aren't used to working with structures as abstract as monoids, and a natural first instinct is to try to un-abstract them, in this case via the suggested renaming. The thought process tends to be something like "I didn't have this problem in language X, Haskell must be doing something wrong." This instinct is not appropriate in the Haskell context. (Although as others have noted, the documentation doesn't do much to help guide people through this.) One of the most mind-bogglingly important features of Haskell is that it is actually possible to make effective use of structures such as monoids in real code. In most languages, you wouldn't even try this. But if you're going to create a zoo of abstract structures like monoids, with the aim of being able to use them as very general building blocks, the last thing you should be doing is naming them according to particular applications they have. This goes against the goal of abstracting in the first place, and will ultimately be confusing and misleading. (As I pointed out in another comment, the misleadingly-named 'mappend' is an example of this.) If there's an existing name for the exact structure in question, it makes sense to use that name. If you're unfamiliar with the structure, then you're going to need to learn a name for it anyway - why not learn a name by which it is already known in other contexts? The main counter to the latter question is "I want to give it a new name in order to connote an intended use," but unless the connotation in question is as general as the structure being named, this is a mistake. This issue is not unique to structures from abstract algebra & category theory. It can arise any time you have a very polymorphic function, for example. It can often make sense to provide a more specifically named and typed alias for a very general function, to make its use more natural and/or constrained in a particular context, e.g.: specificName :: SpecificType1 -> SpecificType2 specificName = moreGeneralFunction Similarly, in the case of monoid, we need to be able to do this, at least conceptually: Appendable = Monoid ...possibly with some additional constraints. In other words, "HEY PROGRAMMERS: YOU CAN USE MONOID AS AN APPENDABLE THINGY (AMONG OTHER THINGS)". This is perhaps an argument for a class alias mechanism, such as the one described at: http://repetae.net/recent/out/classalias.html But in the absence of such a mechanism, we shouldn't succumb to the temptation to confuse abstractions with their applications. > Much as I dislike Java's penchant for 200-character names for things, > I'm not sure Monoid is more descriptive than > SomeSortOfGenericThingThatYouCanAppendStuffToClassTemplateAbstractInterfaceThingy > :-) Usable descriptive names for very abstract structures are just not possible in general, except by agreeing on names, which can ultimately come to seem descriptive. For example, there's nothing fundamentally descriptive about the word "append". Anton From briqueabraque at yahoo.com Thu Jan 15 13:46:25 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Thu Jan 15 13:38:02 2009 Subject: [Haskell-cafe] Re: Type errors, would extensions help? In-Reply-To: References: Message-ID: >> I have this problem trying to define a function >> inside a do expression. I tried this small code >> to help me check. This works well: > I guess you intended to call printNumber in the quoted snippet? > (...) > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE ImpredicativeTypes #-} After you pointed my dumb mistake, I was able to build the first example -- without any of the extensions! Haskell can be misterious some times. Strange enough, I can't get the original (and, to my eyes, equal) problem to work. This is the smallest I could get it to be: --- WARNING: wrong use of gtk, just to get an example --- import Graphics.UI.Gtk ; main = do { initGUI ; j1 <- drawingAreaNew ; j2 <- tableNew 1 1 True ; notebook <- do { note <- notebookNew ; insertInNotebook <- let { colocar :: (WidgetClass w) => w -> String -> IO Int ; colocar wid texto = do { lb <- labelNew Nothing ; labelSetMarkup lb texto ; notebookAppendPageMenu note wid lb lb } } in return $ colocar ; insertInNotebook j1 "J1" ; insertInNotebook j2 "J2" ; return note } ; putStrLn "Finish" } --- GHC says: teste.hs:15:21: Couldn't match expected type `DrawingArea' against inferred type `Table' In the first argument of `insertInNotebook', namely `j2' In a stmt of a 'do' expression: insertInNotebook j2 "J2" (...) but I would like first argument of insert... to be any instance of WidgetClass, be it Drawing... or Table. Thanks, Maur?cio From rmm-haskell at z.odi.ac Thu Jan 15 13:49:41 2009 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Thu Jan 15 13:40:51 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <49a77b7a0901151021v5c26d3d5k635231574caab7ea@mail.gmail.com> References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> <1EA2D132-8873-42AD-8A77-6DF8491E76DA@z.odi.ac> <49a77b7a0901151021v5c26d3d5k635231574caab7ea@mail.gmail.com> Message-ID: <783DF161-EED6-42A5-93BD-5F4AF9FB1422@z.odi.ac> On Jan 15, 2009, at 1:21 PM, David Menendez wrote: > On Thu, Jan 15, 2009 at 11:46 AM, Ross Mellgren haskell@z.odi.ac> wrote: >> Second is that there appears to be no way to document an >> _instance_. It >> would be really handy if there were even a single line under >> "Instances > >> Monoid ([] a)" that explained how the type class was implemented >> for the >> list type. As it is, if you know what a Monoid is already, it's >> easy to >> figure out how it would be implemented. > > Not necessarily. Any instance of MonadPlus (or Alternative) has at > least two reasonable Monoid instances: (mplus, mzero) and (liftM2 > mappend, return mempty). [] uses the first and Maybe uses the second. Sorry my brain apparently misfired writing the original email. What I meant to say is that for the Monoid instance on [a] it's fairly easy (knowing what a Monoid is) to figure out how it's implemented, but that's not true for other classes or instances. That is to say, I agree with you, and intended to up front ;-) -Ross From donn at avvanta.com Thu Jan 15 13:52:33 2009 From: donn at avvanta.com (Donn Cave) Date: Thu Jan 15 13:43:40 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] References: <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> <20090108221549.GA30539@hustlerturf.com> <4438705C-9069-4780-B6A9-7E928997D6EA@n-brain.net> <49676BEF.9050005@complete.org> <20090110231141.6B5DC93C4C@mail.avvanta.com> <20090115163121.GA2646@hustlerturf.com> <00783854-3308-4C04-ACB1-F1D33E90478B@n-brain.net> <33686.49877.qm@web65711.mail.ac4.yahoo.com> Message-ID: <20090115185233.BADF5276D7B@mail.avvanta.com> Quoth Robert Greayer : > The Java reinventions largely exist because of the huge deployment-time > benefits you get from pure-Java code (cross-platform portability of > compiled (byte) code, dynamic loading of compiled code over a network, > etc.). Such reinventions are much less important for Haskell, since > the typical deployment model for a Haskell program is much closer to > that of a C program than a Java program or even a Python program. To me this argument can cut both ways. To come back to the LDAP example, Perl gets exactly this benefit from its natural implementation, compared to Python's interface to C OpenLDAP - you don't have to install OpenLDAP, eliminating a big nuisance for an interface that might have only a trivial role in your application. Perl is more portable in this particular respect, because it can do LDAP on its own. In general, I think it may be absurd to make general statements on this. (Though I imagine one generally valid comparison we can make between Java and Haskell libraries, is that Java's development was better funded.) Donn From bugfact at gmail.com Thu Jan 15 13:59:48 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Jan 15 13:50:54 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <79990c6b0901151004s4da9ed24ob2c646a00abb2169@mail.gmail.com> Message-ID: It is rather funny. When we are young kids, we learn weird symbols like A B C a b c 1 2 3 which we accept after a while. Then we get to learn more complex symbols like ! ? + - / and that takes some time to get used to, but eventually, that works too. But Functor, Monoid or Monad, that we cannot accept anymore. Why, because these are not intuitive? Are the symbols above "intuitive"? When I started learning Haskell I also found it insane that strange terminology was used everywhere... But every time I try to find a better name, the name is too specific for the situation at hand. Just like Appendable is a good name for specific instances of Monoid In F# they renamed Monads to Workflows for the same reason. I find this just as confusing since a Monad has nothing to do with "work" and maybe a little bit with a single threaded "flow"... I would have hoped that we could all stick to the same terminology that was invented a long time ago... Since Haskell is mainly for computer scientists, changing all of this to make it more accessible to newcomers might lead to the mistake: "if you try to please the whole world, you please nobody". I mainly think the problem is not the name, but the lack of many tiny examples demonstrating typical use cases for each concept. On Thu, Jan 15, 2009 at 7:27 PM, Lennart Augustsson wrote: > That's very true. But programming is one where mathematical precision > is needed, even if you want to call it something else. > > On Thu, Jan 15, 2009 at 6:04 PM, Paul Moore wrote: > > > > Mathematical precision isn't appropriate in all disciplines. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/a0ec18fe/attachment.htm From ryani.spam at gmail.com Thu Jan 15 14:03:21 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Jan 15 13:54:27 2009 Subject: [Haskell-cafe] Re: Type errors, would extensions help? In-Reply-To: References: Message-ID: <2f9b2d30901151103n369dcaeu40256c31309ab4a3@mail.gmail.com> I suggest you start using "let" in your do blocks; both of these problems are solvable with let. Binding with <- instead of "let" makes the type system work harder, and will generally require type annotations & extensions for polymorphic results. And it's almost never what you want, anyways; you don't often have an object of type "IO (forall a. a -> a)" instead of "forall a. IO (a -> a)" and this situation usually means you should be using "let" instead. Here's the Gtk example; the let on "mkNotebook" is not strictly necessary but is just showing the concept in more places; I tend to avoid x <- do ... in my code; I feel it means I should be abstracting more. main = do initGUI j1 <- drawingAreaNew j2 <- tableNew 1 1 True let mkNotebook = do note <- notebookNew let insertInNoteBook wid texto = do lb <- labelNew Nothing labelSetMarkup lb texto notebookAppendPageMenu note wid lb lb insertInNotebook j1 "J1" insertInNotebook j2 "J2" return note notebook <- mkNotebook putStrLn "Finish" Also, is there a reason you hate the layout rule and are using explicit semicolons everywhere? -- ryan On Thu, Jan 15, 2009 at 10:46 AM, Mauricio wrote: >>> I have this problem trying to define a function >>> inside a do expression. I tried this small code >>> to help me check. This works well: > >> I guess you intended to call printNumber in the quoted snippet? >> (...) >> {-# LANGUAGE RankNTypes #-} >> {-# LANGUAGE ImpredicativeTypes #-} > > After you pointed my dumb mistake, I was able to build > the first example -- without any of the extensions! Haskell > can be misterious some times. > > Strange enough, I can't get the original (and, to my eyes, > equal) problem to work. This is the smallest I could get it > to be: > > --- WARNING: wrong use of gtk, just to get an example > --- > import Graphics.UI.Gtk ; > main = do { > initGUI ; > j1 <- drawingAreaNew ; j2 <- tableNew 1 1 True ; > notebook <- do { > note <- notebookNew ; > insertInNotebook <- let { > colocar :: (WidgetClass w) => w -> String -> IO Int ; > colocar wid texto = do { > lb <- labelNew Nothing ; > labelSetMarkup lb texto ; > notebookAppendPageMenu note wid lb lb > } } in return $ colocar ; > insertInNotebook j1 "J1" ; > insertInNotebook j2 "J2" ; > return note > } ; > putStrLn "Finish" > } > --- > > GHC says: > > teste.hs:15:21: > Couldn't match expected type `DrawingArea' > against inferred type `Table' > In the first argument of `insertInNotebook', namely `j2' > In a stmt of a 'do' expression: insertInNotebook j2 "J2" > (...) > > but I would like first argument of insert... to be any > instance of WidgetClass, be it Drawing... or Table. > > Thanks, > Maur?cio > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jgoerzen at complete.org Thu Jan 15 14:10:42 2009 From: jgoerzen at complete.org (John Goerzen) Date: Thu Jan 15 14:01:51 2009 Subject: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York] In-Reply-To: <20090115185233.BADF5276D7B@mail.avvanta.com> References: <814617240901080741y63e627c9m714b85fdcce470d4@mail.gmail.com> <20090108180619.GE22269@scytale.galois.com> <20090108221549.GA30539@hustlerturf.com> <4438705C-9069-4780-B6A9-7E928997D6EA@n-brain.net> <49676BEF.9050005@complete.org> <20090110231141.6B5DC93C4C@mail.avvanta.com> <20090115163121.GA2646@hustlerturf.com> <00783854-3308-4C04-ACB1-F1D33E90478B@n-brain.net> <33686.49877.qm@web65711.mail.ac4.yahoo.com> <20090115185233.BADF5276D7B@mail.avvanta.com> Message-ID: <496F8A32.6040506@complete.org> Donn Cave wrote: > Quoth Robert Greayer : > >> The Java reinventions largely exist because of the huge deployment-time >> benefits you get from pure-Java code (cross-platform portability of >> compiled (byte) code, dynamic loading of compiled code over a network, >> etc.). Such reinventions are much less important for Haskell, since >> the typical deployment model for a Haskell program is much closer to >> that of a C program than a Java program or even a Python program. > > To me this argument can cut both ways. To come back to the LDAP example, > Perl gets exactly this benefit from its natural implementation, compared > to Python's interface to C OpenLDAP - you don't have to install OpenLDAP, > eliminating a big nuisance for an interface that might have only a trivial > role in your application. Perl is more portable in this particular respect, > because it can do LDAP on its own. This cuts both (and many) ways. Someone else touched on how Haskell binaries are easier to deploy than Python programs because you don't have to have Python and a runtime set of things on all your machines. That is true. It is also true that Python programs are easier to install than Haskell ones because I can just apt-get install python-whateverIneed on every machine they'll run on, and don't have to worry about compiling them for that architecture. Moreover, I don't have to recompile them when a security bug is found in one of the libraries I use; I just upgrade the library, something that my OS might do for me automatically. Haskell is currently in somewhat of an unfortunate static linking stage. Dynamically-loaded libraries are pretty much the norm in C, as well as in many other languages. But if, say, the ByteString module has a security hole, I can't just upgrade it on a target box; I have to recompile all programs that use it, on all platforms. I have the luxury of not having to work with proprietary dinosaur systems. My package manager will just handle the LDAP stuff for me, whether it's Perl, Python, or Haskell. But to say that the Perl approach is better, or even more portable, I think misses the mark. Does it have the same level of stability and reliability as the C version? Is it as compatible with other servers? As full-featured? Does it get new features added as fast? The answers to all of these may be "yes"; I don't know. There are legitimate reasons for reimplementing things in other languages. But to return to the very beginning of the thread -- I do not see the simple fact that some Haskell modules have bindings to C underneath the covers as either a plus or a minus to those modules. Haskell code can be written well, or poorly, as can C code. Not using C is no guarantee of quality, and neither is using C. A well-designed FFI binding to a quality C library can turn out very nicely, as can pure Haskell code. -- John From greenspan.levi at googlemail.com Thu Jan 15 14:14:45 2009 From: greenspan.levi at googlemail.com (Levi Greenspan) Date: Thu Jan 15 14:05:52 2009 Subject: [Haskell-cafe] How to simplify this code? Message-ID: <3e62d4360901151114l1c7442fob8f35410c88f8162@mail.gmail.com> Dear list members, I started looking into monadic programming in Haskell and I have some difficulties to come up with code that is concise, easy to read and easy on the eyes. In particular I would like to have a function "add" with following type signature: JSON a => MyData -> String -> a -> MyData. MyData holds a JSValue and add should add a key and a value to this JSON object. here is what I came up with and I am far from satisfied. Maybe someone can help me to simplify this... module Test where import Text.JSON import Data.Maybe (isJust, fromJust) import Control.Monad data MyData = MyData { json :: JSValue } deriving (Read, Show) jsObj :: JSValue -> Maybe (JSObject JSValue) jsObj (JSObject o) = Just o jsObj _ = Nothing add :: JSON a => MyData -> String -> a -> MyData add m k v = fromJust $ (return $ json m) >>= jsObj >>= (return . fromJSObject) >>= (return . ((k, showJSON v):)) >>= (return . toJSObject) >>= (return . showJSON) >>= \js -> (return $ m { json = js }) add2 :: JSON a => MyData -> String -> a -> MyData add2 m k v = fromJust $ (\js -> m { json = js }) `liftM` (showJSON `liftM` (toJSObject `liftM` (((k, showJSON v):) `liftM` (fromJSObject `liftM` (jsObj $ json m))))) add3 :: JSON a => MyData -> String -> a -> MyData add3 = undefined -- How to simplify add? What the code essentially does is that using functions from Text.JSON, it gets the list of key-value pairs and conses another pair to it before wrapping it again in the JSValue-Type. Many thanks, Levi From gour at mail.inet.hr Thu Jan 15 14:15:30 2009 From: gour at mail.inet.hr (Gour) Date: Thu Jan 15 14:06:23 2009 Subject: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> Message-ID: <877i4wgz3h.fsf@nitai.hr> >>>>> "John" == John Goerzen writes: John> I guess the bottom line question is: who is Haskell for? Category John> theorists, programmers, or both? I'd love it to be for both, but John> I've got to admit that Brian has a point that it is trending to John> the first in some areas. Thank you for so nicely put it together... Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/03df5d20/attachment.bin From duncan.coutts at worc.ox.ac.uk Thu Jan 15 14:31:29 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 15 14:22:34 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <87y6xcya4o.fsf@malde.org> References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> <1231978323.28590.298.camel@localhost> <5e0214850901142249y92dbc31g42f9e0b2108b3cbd@mail.gmail.com> <1232013102.28590.303.camel@localhost> <87y6xcya4o.fsf@malde.org> Message-ID: <1232047889.28590.332.camel@localhost> On Thu, 2009-01-15 at 14:25 +0100, Ketil Malde wrote: > Duncan Coutts writes: > > > On Thu, 2009-01-15 at 09:49 +0300, Eugene Kirpichov wrote: > >> Would be nice if after a failed build cabal asked whether or not to > >> upload its log immediately, and (on the hackage side) this led to an > >> email being sent to the maintainer. > > > It should not be quite that synchronous but yes that's the general idea. > > Perhaps the maintainer should receive a build summary at regular > intervals? This would also work as a check whether there is a live > maintainer at the other end of the listed maintainer address. (And > hopefully be enough of an annoyance on the libraries@ list that people > would start looking for maintainers for orphaned packages :-) It may well be tempting to plague maintainers until they fix their packages however in practise it will not work. We want a low barrier to entry for packages on hackage and we do not want to annoy package maintainers to the point where they decide to stop using hackage at all. Of course we also want to measure package quality. The approach I've always advocated is to define subsets of hackage that do meet higher quality levels. Be defining such subsets and holding them up as being a "good thing" in the community then it puts social pressure on maintainers to have their packages in those higher quality subsets. Then to help them do that they may choose to opt-in to various services like receiving a build summary at regular intervals. So it's the same goal but without the stick. Duncan From andrewcoppin at btinternet.com Thu Jan 15 14:46:02 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Jan 15 14:37:11 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <20090115153438.GA1340@hustlerturf.com> References: <20090115153438.GA1340@hustlerturf.com> Message-ID: <496F927A.3060007@btinternet.com> John Goerzen wrote: > Haskell > developers, stop letting the category theorists name > things. Please. I beg of you. > > I'd like to echo that sentiment! > > He went on to add: > > If you?re not a category theorists, and you're learning (or thinking > of learning) Haskell, don't get scared off by names like "monoid" or > "functor". And ignore anyone who starts their explanation with > references to category theory- you don't need to know category > theory, and I don't think it helps. > > I'd echo that one too. > I am constantly shocked and saddened at the Haskell community's attitude here. It seems to boil down to "Why should we make it easier to learn Haskell? If people aren't prepaired to learn abstract algebra, category theory, predicate logic and type system theory, why should we bother to help them?" So much for the famously helpful Haskell community. I am seriously beginning to wonder if the people using Haskell actually realise what regular programmers do and don't know about. (You may recall my recent straw poll where 80% of the programmer nerds I asked had no clue what a "coroutine" is or what "existential quantification" means.) Notice that "monoid" sounds almost *exactly* like "monad". And yet, what you use them for is wildly unrelated. In a similar vein, who here can tell me off the top of their head what the difference between an epimorphism and a hylomorphism is? I've got a brick-thick group theory book sat right next to me and *I* can't even remember! Best of all, if Joe Programmer makes any attempt to look these terms up, the information they get will be almost completely useless for the purposes of writing code or reading somebody else's. I was especially amused by the assertion that "existential quantification" is a more precise term than "type variable hiding". (The former doesn't even tell you that the feature in question is related to the type system! Even the few people in my poll who knew of the term couldn't figure out how it might be related to Haskell. And one guy argued that "forall" should denote universal rather than existential quantification...) The sad thing is, it's not actually complicated. The documentation just makes it seem like it is! :-( Databases are based on the relational algebra. But that doesn't seem to stop them from coming up with names for things that normal humans can understand without first taking a course in relational algebra. (Does the Oracle user guide state that "a relation is simply a subset of the extended Cartesian product of the respective domains of its attributes"? No, I don't *think* so! It says "Oracle manages tables which are made up of rows..." Technically less precise, but vastly easier to comprehend.) Why can't we do the same? If we *must* insist on using the most obscure possible name for everything, can we at least write some documentation that doesn't require a PhD to comprehend?? (Anybody who attempts to argue that "monoid" is not actually an obscure term has clearly lost contact with the real world.) As somebody else said, it basically comes down to this: Who the hell is Haskell actually "for"? If it's seriously intended to be used by programmers, things need to change. And if things aren't going to change, then let's all stop pretending that Haskell actually cares about real programmers. Sorry if this sounds like just another clueless rant, but I'm really getting frustrated about all this. Nobody seems to think there's actually a problem here, despite the incontravertible fact that there is... PS. As a small aside... Is the Monoid class actually used *anywhere* in all of Haskell? Surely saying that something is a monoid is so vague as to be unhelpful. "The most you can say about almost everything is practically nothing" and all that. All it means is that the type in question has a function that happens to take 2 arguments, and this function happens to have an identity value. How is this information useful? Surely what you'd want to know is what that function *does*?! And since a given type can only be a Monoid instance in one way, wouldn't passing the function and its identity in as parameters be simpler anyway? The integers form at least two different monoids AFAIK... From patperry at stanford.edu Thu Jan 15 14:49:59 2009 From: patperry at stanford.edu (Patrick Perry) Date: Thu Jan 15 14:41:06 2009 Subject: [Haskell-cafe] ANN: monad-interleave 0.1 Message-ID: My two favorite functions in Haskell are "unsafeInterleaveIO" and "unsafeInterleaveST". I'm surprised there isn't a type class for them. I just fixed this by adding the "monad-interleave" package to hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/monad-interleave The package adds a "Control.Monad.Interleave" module. Here is the entirety of the module: \begin{code} -- | Monads that have an operation like 'unsafeInterleaveIO'. class Monad m => MonadInterleave m where -- | Get the baton from the monad without doing any computation. unsafeInterleave :: m a -> m a instance MonadInterleave IO where unsafeInterleave = unsafeInterleaveIO {-# INLINE unsafeInterleave #-} instance MonadInterleave (ST s) where unsafeInterleave = unsafeInterleaveST {-# INLINE unsafeInterleave #-} instance MonadInterleave (Lazy.ST s) where unsafeInterleave = Lazy.unsafeInterleaveST {-# INLINE unsafeInterleave #-} \end{code} Use it if you need it. Patrick From miguelimo38 at yandex.ru Thu Jan 15 15:08:36 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Thu Jan 15 14:59:49 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <1EA2D132-8873-42AD-8A77-6DF8491E76DA@z.odi.ac> References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> <1EA2D132-8873-42AD-8A77-6DF8491E76DA@z.odi.ac> Message-ID: > For what it's worth, many (most/all?) programmers I know in person > don't have the slightest clue about Category Theory and they may > have known about abstract algebra once upon a time but certainly > don't remember any of it now. They usually understand the concepts > perfectly well enough but by "lay terms" or by no particular name at > all. One of my friend once said "... and by 'programmer' I mean 'category theory specialist'". From jgoerzen at complete.org Thu Jan 15 15:11:40 2009 From: jgoerzen at complete.org (John Goerzen) Date: Thu Jan 15 15:02:48 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496F927A.3060007@btinternet.com> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> Message-ID: <20090115201140.GA7325@hustlerturf.com> On Thu, Jan 15, 2009 at 07:46:02PM +0000, Andrew Coppin wrote: > John Goerzen wrote: > > If we *must* insist on using the most obscure possible name for > everything, can we at least write some documentation that doesn't > require a PhD to comprehend?? (Anybody who attempts to argue that > "monoid" is not actually an obscure term has clearly lost contact with > the real world.) Several people have suggested this, and I think it would go a long way towards solving the problem. The problem is: this documentation can really only be written by those that understand the concepts, understand how they are used practically, and have the time and inclination to submit patches. Experience suggests there may be no such people out there :-) > As somebody else said, it basically comes down to this: Who the hell is > Haskell actually "for"? If it's seriously intended to be used by > programmers, things need to change. And if things aren't going to > change, then let's all stop pretending that Haskell actually cares about > real programmers. It might surprise you to see me say this, but I don't see this discussion as necessarily a weakness. I know of no other language community out there that has such a strong participation of both academics and applied users. This is a great strength. And, of course, Haskell's roots are firmly in academia. I think there there is a ton of interest in Haskell from the, ahem, "real world" programmer types. In fact, it seems to me that's where Haskell's recent growth has been. There are a lot of things showing up on Hackage relating to networking, Unicode encoding, databases, web apps, and the like. The nice thing about Haskell is that you get to put the theory in front of a lot of people that would like to use it to solve immediate programming problems. But they will only use it if you can explain it in terms they understand. There are a number of efforts in that direction: various websites, articles, books, libraries, etc. And I think the efforts are succeeding. But that doesn't mean there is no room for improvement. -- John From ketil at malde.org Thu Jan 15 15:21:52 2009 From: ketil at malde.org (Ketil Malde) Date: Thu Jan 15 15:12:24 2009 Subject: [Haskell-cafe] real haskell difficulties (at least for me) In-Reply-To: <1232047889.28590.332.camel@localhost> (Duncan Coutts's message of "Thu\, 15 Jan 2009 19\:31\:29 +0000") References: <027A7D7FCDF44376AC625F076AD23870@createnet.org> <220e47b40901130833r6aa9c364rdd96deb2a680cdcc@mail.gmail.com> <496CE998.6070508@btinternet.com> <1231973332.28590.287.camel@localhost> <496E73C9.8020002@libero.it> <1231978323.28590.298.camel@localhost> <5e0214850901142249y92dbc31g42f9e0b2108b3cbd@mail.gmail.com> <1232013102.28590.303.camel@localhost> <87y6xcya4o.fsf@malde.org> <1232047889.28590.332.camel@localhost> Message-ID: <87mydsxqu7.fsf@malde.org> Duncan Coutts writes: >> Perhaps the maintainer should receive a build summary at regular >> intervals? This would also work as a check whether there is a live >> maintainer at the other end of the listed maintainer address. (And >> hopefully be enough of an annoyance on the libraries@ list that people >> would start looking for maintainers for orphaned packages :-) > It may well be tempting to plague maintainers Hey, I only want to plague the libraries@ list, which is subscriber-only, and therefore serves to prevent bug reports from reaching anybody. I'd actually *like* to have reports on build failures on stuff I'm responsible for, as long as there's some sensible rate limiting. Perhaps a maintainer-selected interval could be an option? -k -- If I haven't seen further, it is by standing in the footprints of giants From sylvan at student.chalmers.se Thu Jan 15 15:36:46 2009 From: sylvan at student.chalmers.se (Sebastian Sylvan) Date: Thu Jan 15 15:27:55 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496F927A.3060007@btinternet.com> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> Message-ID: <3d96ac180901151236k5d9479a2n9a1071325656d3a0@mail.gmail.com> On Thu, Jan 15, 2009 at 7:46 PM, Andrew Coppin wrote: > The sad thing is, it's not actually complicated. The documentation just > makes it seem like it is! :-( > This is so true for a heck of a lot of things. Existential quantification being just one of them. Loads of things in Haskell have big powerful (but scary) names which I really think intimidate people, the situation isn't helped when a lot of tutorials use the theoretical basis for the construct as a starting point, rather then actually describing the construct from the perspective of a programmer first (see Monads). Haskell really isn't that difficult compared to other languages, but people still get the impression that you need to be a big brain on a stick to use it, terminology is certainly part of the equation. This doesn't mean that making up new words is always better, but we should certainly strive to exploit any opportunity to clarify the issue and (this means that haddock comments and language books/tutorials shouldn't refer to academic papers first and foremost, but use common English and practical examples to describe what's being used, and academic nerds can consult the footnotes for their fill of papers containing pages of squiggly symbols!). -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/d97f367f/attachment.htm From duncan.coutts at worc.ox.ac.uk Thu Jan 15 15:38:15 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 15 15:30:21 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496F927A.3060007@btinternet.com> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> Message-ID: <1232051895.28590.350.camel@localhost> On Thu, 2009-01-15 at 19:46 +0000, Andrew Coppin wrote: > PS. As a small aside... Is the Monoid class actually used *anywhere* in > all of Haskell? Yes. They're used quite a lot in Cabal. Package databases are monoids. Configuration files are monoids. Command line flags and sets of command line flags are monoids. Package build information is a monoid. It is also used in the Foldable class which is a nice interface for traversing/visiting structures. Binary serialisation is also a monoid. Duncan From dons at galois.com Thu Jan 15 15:51:28 2009 From: dons at galois.com (Don Stewart) Date: Thu Jan 15 15:42:19 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <1232051895.28590.350.camel@localhost> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <1232051895.28590.350.camel@localhost> Message-ID: <20090115205128.GE17581@scytale.galois.com> duncan.coutts: > On Thu, 2009-01-15 at 19:46 +0000, Andrew Coppin wrote: > > > PS. As a small aside... Is the Monoid class actually used *anywhere* in > > all of Haskell? > > Yes. > > They're used quite a lot in Cabal. Package databases are monoids. > Configuration files are monoids. Command line flags and sets of command > line flags are monoids. Package build information is a monoid. > > It is also used in the Foldable class which is a nice interface for > traversing/visiting structures. Binary serialisation is also a monoid. Also, xmonad configuration hooks are monoidal. So all those xmonad users gluing together keybindings are using the Monoid class. -- Don From allbery at ece.cmu.edu Thu Jan 15 15:54:34 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Jan 15 15:45:42 2009 Subject: [Haskell-cafe] about System.Posix.Files.fileAccess In-Reply-To: <496F169F.20901@libero.it> References: <496DF06E.6070602@libero.it> <41492B19-8C59-4F9B-93F3-C5563FE20A83@ece.cmu.edu> <496F169F.20901@libero.it> Message-ID: On 2009 Jan 15, at 5:57, Manlio Perillo wrote: > Brandon S. Allbery KF8NH ha scritto: >> On 2009 Jan 14, at 9:02, Manlio Perillo wrote: >>> This is of course a personal opinion, but I think the interface of: >>> fileAccess :: FilePath -> Bool -> Bool -> Bool -> IO Bool >>> http://haskell.org/ghc/docs/latest/html/libraries/unix/System-Posix-Files.html#v >>> :fileAccess >>> >>> is not very good. >> The underlying system call access() is strongly disrecommended, so >> it's not really worth a better interface. > > I can't see problems with access function. > > Of course it is a problem if used incorrectly: > > if (access("foo", F_OK) { > fd = open("foo", ...) > } The problem is there are very few uses of access() which are safe and not already covered better by stat() (getFileStatus). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From nicolas.frisby at gmail.com Thu Jan 15 15:57:31 2009 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Thu Jan 15 15:48:38 2009 Subject: [Haskell-cafe] Proposal for associated type synonyms in Template Haskell In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33281447EE7@EA-EXMSG-C334.europe.corp.microsoft.com> References: <49104B62.5010308@cs.ru.nl> <491052AB.2010302@cs.ru.nl> <4b39c80a0811040600y16257eafh5037a851284af10e@mail.gmail.com> <4911B442.7080104@cs.ru.nl> <52f14b210811110311v8ab419au5f33b08b9681f84d@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33281447EE7@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <5ce89fb50901151257k1ddc932crcf7cb5970b5ffb7e@mail.gmail.com> Any movement on this? (I am actually just looking forward to generating kind ascriptions and having access to the kinds when processing TH.Dec, TH.Type, and such.) 2008/11/27 Simon Peyton-Jones : > I've been away. I hope others will reply to this thread too; whatever you > decide will end up in TH indefinitely. I know that Roman is interested in > this. > > > > ? You focus just on type families in class declarations (which is > indeed where associated types started). But I suggest you also allow them > at top level, as GHC does using the syntax > > type family T a :: * > > Indeed, since you propose to add to Dec, that'll happen automatically. But > perhaps "AssocTySynKindD" is not a good name. Perhaps "TySynFamilyD"? > > > > ? GHC uses > > type instance T [a] = Tree a > > as the way to add an equation to the definition of T. So perhaps > "TySynInstance" rather than "AssocTySynD"? > > > > ? I agree that it'd be good to do data type/newtype families at the > same time. Roman needs this. > > > > ? Your proposal for kinds looks fine. > > > > Simon > > > > From: haskell-cafe-bounces@haskell.org > [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Jos? Pedro Magalh?es > Sent: 11 November 2008 11:11 > To: Haskell Cafe > Subject: Re: [Haskell-cafe] Proposal for associated type synonyms in > Template Haskell > > > > Hello Thomas, > > I see this is a proposal for a partial implementation of #1673 > (http://hackage.haskell.org/trac/ghc/ticket/1673). Maybe it would be good if > the remaining syntax (associated datatypes and type families) would also be > defined and implemented in TH. Or maybe there isn't much demand for this?... > > > Cheers, > Pedro > > On Wed, Nov 5, 2008 at 15:57, Thomas van Noort wrote: > > Hello, > > Recently, we released a library on Hackage for generic rewriting (package > "rewriting" if you are curious). The user of the library is expected to > define type class instances to enable rewriting on his or her own datatypes. > As these instances follow the datatype declarations closely, we tried to > generate the instances using Template Haskell. Unfortunately, associated > type synonyms are not yet supported by TH. > > After a presentation at the WGP'08, Simon encouraged us to write a proposal > about adding associated type synonyms to TH, so that it can be added to GHC. > So, here is our proposal. > > The TH AST must allow 1) kind declarations of associated type synonyms > in class declarations and 2) their definitions in instance declarations. For > example, > > class Foo a where > type Bar a :: * > > instance Foo Int where > type Bar Int = String > > The TH library defines a datatype Dec which contains a constructor for class > declarations and instance declarations: > > data Dec > = ... > | ClassD Cxt Name [Name] [FunDep] [Dec] > | InstanceD Cxt Type [Dec] > ... > > 1) Associated type synonym kind declarations > > We suggest to add a constructor to the Dec type: > > ... > | AssocTySynKindD Name [Name] (Maybe Kind) > ... > > assocTySynKindD :: Name -> [Name] -> Maybe KindQ -> DecQ > > The first field is the name of the associated type synonym, the second field > is a list of type variables, and the third field is an optional kind. Since > kinds are not yet defined in TH, we have to add some kind of kind definition > (pun intended): > > data Kind > = StarK > | ArrowK Kind Kind > > type KindQ = Q Kind > starK :: KindQ > arrowK :: KindQ -> KindQ -> KindQ > > We explicitly choose not to reuse the Type type to define kinds (i.e., type > Kind = Type as in GHC) since we think a separation between the two worlds is > much clearer to the users of TH. > > 2) Associated type synonym definitions > > We suggest to add another constructor to the Dec type: > > ... > | AssocTySynD Name [Type] Type > ... > > assocTySynD :: Name -> [TypeQ] -> TypeQ -> DecQ > > The first field is the name of the type synonym, the second field is a list > of type arguments, and the third field is the body of the type synonym. > > We would like to hear your comments to this proposal. > > Regards, > Thomas > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From dons at galois.com Thu Jan 15 16:02:50 2009 From: dons at galois.com (Don Stewart) Date: Thu Jan 15 15:53:40 2009 Subject: [Haskell-cafe] ANNOUNCE: gitit 0.2 release - wiki using HAppS, git, pandoc In-Reply-To: <20081108203244.GA6568@berkeley.edu> References: <20081108203244.GA6568@berkeley.edu> Message-ID: <20090115210250.GA17800@scytale.galois.com> Hey, since doing a recent upgrade of gitit, I'm getting: $ gitit ******************************************************************************** Warning: jsMath not found. If you want support for math, copy the jsMath directory into static/js/ jsMath can be obtained from http://www.math.union.edu/~dpvc/jsMath/ ******************************************************************************** gitit: Version tag too large: (VersionId {unVersion = 0},VersionId {unVersion = 128}) (Gitit.State.Password) How do I work around this, and get back my content? :) -- Don jgm: > I've uploaded an early version of gitit, a Haskell wiki program, to > HackageDB. Gitit uses HAppS as a webserver, git for file storage, > pandoc for rendering the (markdown) pages, and highlighting-kate for > highlighted source code. > > Some nice features of gitit: > > - Pages and uploaded files are stored in a git repository and may > be added, deleted, and modified directly using git. > - Pages may be organized into subdirectories. > - Pandoc's extended version of markdown is used, so you can do tables, > footnotes, syntax-highlighted code blocks, and LaTeX math. (And > you can you pandoc to convert pages into many other formats.) > - Math is rendered using jsMath (which must be installed > separately). > - Source code files in the repository are automatically rendered with > syntax highlighting (plain/text version is also available). > > You can check it out on my webserver: http://johnmacfarlane.net:5001/ > Or try it locally: > > cabal update > cabal install pandoc -fhighlighting > cabal install gitit > gitit # note: this will create two subdirectories in the working directory > # then browse to http://localhost:5001. > > There's a git repository at http://github.com/jgm/gitit/tree/master. > Comments and patches are welcome. > > John > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From wagner.andrew at gmail.com Thu Jan 15 16:03:55 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Thu Jan 15 15:55:01 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <20090115205128.GE17581@scytale.galois.com> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <1232051895.28590.350.camel@localhost> <20090115205128.GE17581@scytale.galois.com> Message-ID: I think perhaps the correct question here is not "how many instances of Monoid are there?", but "how many functions are written that can use an arbitrary Monoid". E.g., the fact that there are a lot of instances of Monad doesn't make it useful. There are a lot of instances of Monad because it's useful to have instances of Monad. Why? Because of http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html ! Look at all the cool stuff you can automagically do with your type just because it's an instance of Monad! I think that's the point. What can you do with arbitrary Monoids? Not much, as evidenced by http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html On Thu, Jan 15, 2009 at 3:51 PM, Don Stewart wrote: > duncan.coutts: > > On Thu, 2009-01-15 at 19:46 +0000, Andrew Coppin wrote: > > > > > PS. As a small aside... Is the Monoid class actually used *anywhere* in > > > all of Haskell? > > > > Yes. > > > > They're used quite a lot in Cabal. Package databases are monoids. > > Configuration files are monoids. Command line flags and sets of command > > line flags are monoids. Package build information is a monoid. > > > > It is also used in the Foldable class which is a nice interface for > > traversing/visiting structures. Binary serialisation is also a monoid. > > Also, xmonad configuration hooks are monoidal. So all those xmonad users > gluing together keybindings are using the Monoid class. > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/7a1ac9a3/attachment.htm From bugfact at gmail.com Thu Jan 15 16:08:11 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Jan 15 15:59:19 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <20090115205128.GE17581@scytale.galois.com> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <1232051895.28590.350.camel@localhost> <20090115205128.GE17581@scytale.galois.com> Message-ID: Graphic composition using painters algorithm can be seen as a monoid. data Graphic = Empty | Graphic `Over` Graphic | Ellipse Bounds | .... instance Monoid Graphic where mempty = Empty mappend = Over So all functions that operate on monoids can be used on Graphic as well, like mconcat that converts a [Graphic] into a Graphic On Thu, Jan 15, 2009 at 9:51 PM, Don Stewart wrote: > duncan.coutts: > > On Thu, 2009-01-15 at 19:46 +0000, Andrew Coppin wrote: > > > > > PS. As a small aside... Is the Monoid class actually used *anywhere* in > > > all of Haskell? > > > > Yes. > > > > They're used quite a lot in Cabal. Package databases are monoids. > > Configuration files are monoids. Command line flags and sets of command > > line flags are monoids. Package build information is a monoid. > > > > It is also used in the Foldable class which is a nice interface for > > traversing/visiting structures. Binary serialisation is also a monoid. > > Also, xmonad configuration hooks are monoidal. So all those xmonad users > gluing together keybindings are using the Monoid class. > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/c5abddaa/attachment.htm From gour at mail.inet.hr Thu Jan 15 16:15:05 2009 From: gour at mail.inet.hr (Gour) Date: Thu Jan 15 16:05:55 2009 Subject: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> Message-ID: <87y6xcfezq.fsf@nitai.hr> >>>>> "Andrew" == Andrew Coppin writes: Andrew> If we *must* insist on using the most obscure possible name for Andrew> everything, can we at least write some documentation that Andrew> doesn't require a PhD to comprehend?? (Anybody who attempts to Andrew> argue that "monoid" is not actually an obscure term has clearly Andrew> lost contact with the real world.) *thumb up* Let the elitists enjoy in obscure terminology, but pls. write docs for programmers (with examples included). Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/43e7cd95/attachment.bin From andrewcoppin at btinternet.com Thu Jan 15 16:17:20 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Jan 15 16:08:29 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <3d96ac180901151236k5d9479a2n9a1071325656d3a0@mail.gmail.com> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <3d96ac180901151236k5d9479a2n9a1071325656d3a0@mail.gmail.com> Message-ID: <496FA7E0.4060202@btinternet.com> Sebastian Sylvan wrote: > > > On Thu, Jan 15, 2009 at 7:46 PM, Andrew Coppin > > wrote: > > The sad thing is, it's not actually complicated. The documentation > just makes it seem like it is! :-( > > > This is so true for a heck of a lot of things. Existential > quantification being just one of them. Loads of things in Haskell have > big powerful (but scary) names which I really think intimidate people, > the situation isn't helped when a lot of tutorials use the theoretical > basis for the construct as a starting point, rather then actually > describing the construct from the perspective of a programmer first > (see Monads). > Haskell really isn't that difficult compared to other languages, but > people still get the impression that you need to be a big brain on a > stick to use it, terminology is certainly part of the equation. > > This doesn't mean that making up new words is always better, but we > should certainly strive to exploit any opportunity to clarify the > issue and (this means that haddock comments and language > books/tutorials shouldn't refer to academic papers first and foremost, > but use common English and practical examples to describe what's being > used, and academic nerds can consult the footnotes for their fill of > papers containing pages of squiggly symbols!). I basically agree with most of what you just said. I'm not sure having a Monoid class is actually useful for anything - but if we must have it, there seems to be little better possible name for something so vague. {-# LANGUAGE ExistentialQuantification #-} is an absurd name and should be changed to something that, at a minimum, tells you it's something to do with the type system. (Ideally it would also be pronouncible.) Of course, nobody will take any notice, since changing this would induce mass breakage for all the millions of LoC that already use the old name. I think "documenting" a package by saying "read this academic paper" should be banned. (Most especially if the paper in question isn't even available online and can only be obtained from a reputable university library!!) For example, I was looking at one of the monad transformers (I don't even remember which one now), and the Haddoc contained some type signatures and a line saying "read this paper". The paper in question mentioned the transformer in passing as a 5-line example of how to use polymorphism, but *still* without explaining how to actually use it! (I.e., the paper was about polymorphism, and this transformer was just a quick example.) What the hell?? I presume I can call "more documentation please!" without upsetting even the most ardant category theory millitant... ;-) Unfortunately, it's not going to write itself, and I have no idea how to solve the problem. (That is, even if I wrote some better documentation myself, I don't know how to submit it to get it into the official package documentation. E.g., Parsec has a great tutorial document, but the Haddoc pages are barren. It'd be easy to fix, but I don't know how to submit the updates.) From dpiponi at gmail.com Thu Jan 15 16:19:15 2009 From: dpiponi at gmail.com (Dan Piponi) Date: Thu Jan 15 16:10:24 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <20090115201140.GA7325@hustlerturf.com> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <20090115201140.GA7325@hustlerturf.com> Message-ID: <625b74080901151319t50476f16xe0a8be4ea3083fdb@mail.gmail.com> On Thu, Jan 15, 2009 at 12:11 PM, John Goerzen wrote: > On Thu, Jan 15, 2009 at 07:46:02PM +0000, Andrew Coppin wrote: >> John Goerzen wrote: >> >> can we at least write some documentation that doesn't >> require a PhD to comprehend? > Several people have suggested this, and I think it would go a long way > towards solving the problem. That sounds like a good plan. Which precise bit of documentation should I update? Make a new wiki page? Put it in here: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html -- Dan From andrewcoppin at btinternet.com Thu Jan 15 16:21:30 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Jan 15 16:12:36 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <1232051895.28590.350.camel@localhost> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <1232051895.28590.350.camel@localhost> Message-ID: <496FA8DA.7050907@btinternet.com> Duncan Coutts wrote: > On Thu, 2009-01-15 at 19:46 +0000, Andrew Coppin wrote: > > >> PS. As a small aside... Is the Monoid class actually used *anywhere* in >> all of Haskell? >> > > Yes. > > They're used quite a lot in Cabal. Package databases are monoids. > Configuration files are monoids. Command line flags and sets of command > line flags are monoids. Package build information is a monoid. > OK, well then my next question would be "in what say is defining configuration files as a monoid superior to, uh, not defining them as a monoid?" What does it allow you to do that you couldn't otherwise? I'm not seeing any obvious advantage, but you presumably did this for a reason... > It is also used in the Foldable class which is a nice interface for > traversing/visiting structures. Binary serialisation is also a monoid. > Foldable I'm vaguely familiar with. Its utility is more apparent. From jonathanccast at fastmail.fm Thu Jan 15 16:21:57 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Jan 15 16:13:36 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <20090115153438.GA1340@hustlerturf.com> References: <20090115153438.GA1340@hustlerturf.com> Message-ID: <1232054517.6800.9.camel@jcchost> On Thu, 2009-01-15 at 09:34 -0600, John Goerzen wrote: > Hi folks, > > Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml > hacker: > > http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/ > > It's a great post, and I encourage people to read it. I'd like to > highlight one particular paragraph: > > > One thing that does annoy me about Haskell- naming. Say you've > noticed a common pattern, a lot of data structures are similar to > the difference list I described above, in that they have an empty > state and the ability to append things onto the end. Now, for > various reasons, you want to give this pattern a name using on > Haskell's tools for expressing common idioms as general patterns > (type classes, in this case). What name do you give it? I'd be > inclined to call it something like "Appendable". But no, Haskell > calls this pattern a "Monoid". Yep, that's all a monoid is- > something with an empty state and the ability to append things to > the end. Well, it's a little more general than that, but not > much. Simon Peyton Jones once commented that the biggest mistake > Haskell made was to call them "monads" instead of "warm, fluffy > things". Well, Haskell is exacerbating that mistake. Haskell > developers, stop letting the category theorists name > things. Please. I beg of you. > > I'd like to echo that sentiment! No. Never. We will fight in the mailing lists. We will fight in the blog posts. We will never surrender. Where, in the history of western civilization, has there ever been an engineering discipline whose adherents were permitted to remain ignorant of the basic mathematical terminology and methodology that their enterprise is founded on? Why should software engineering be the lone exception? No one may be a structural engineer, and remain ignorant of physics. No one may be a chemical engineer, and remain ignorant of chemistry. Why on earth should any one be permitted to be a software engineer, and remain ignorant of computing science? jcc From leimy2k at gmail.com Thu Jan 15 16:27:26 2009 From: leimy2k at gmail.com (David Leimbach) Date: Thu Jan 15 16:18:31 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <1232051895.28590.350.camel@localhost> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <1232051895.28590.350.camel@localhost> Message-ID: <3e1162e60901151327t443da307x5b1afd5a55b9fca9@mail.gmail.com> On Thu, Jan 15, 2009 at 12:38 PM, Duncan Coutts wrote: > On Thu, 2009-01-15 at 19:46 +0000, Andrew Coppin wrote: > > > PS. As a small aside... Is the Monoid class actually used *anywhere* in > > all of Haskell? > > Yes. > > They're used quite a lot in Cabal. Package databases are monoids. > Configuration files are monoids. Command line flags and sets of command > line flags are monoids. Package build information is a monoid. > > It is also used in the Foldable class which is a nice interface for > traversing/visiting structures. Binary serialisation is also a monoid. > The Writer Monad requires that you give it a Monoid for it to do its work properly. > > Duncan > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/1b692a60/attachment.htm From miguelimo38 at yandex.ru Thu Jan 15 16:28:48 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Thu Jan 15 16:20:00 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496F927A.3060007@btinternet.com> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> Message-ID: > Notice that "monoid" sounds almost *exactly* like "monad". And yet, > what you use them for is wildly unrelated. Well, monads are monoids. I remember explaining you that... From andrewcoppin at btinternet.com Thu Jan 15 16:29:14 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Jan 15 16:20:21 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <1232054517.6800.9.camel@jcchost> References: <20090115153438.GA1340@hustlerturf.com> <1232054517.6800.9.camel@jcchost> Message-ID: <496FAAAA.9050609@btinternet.com> Jonathan Cast wrote: > Where, in the history of western civilization, has there ever been an > engineering discipline whose adherents were permitted to remain ignorant > of the basic mathematical terminology and methodology that their > enterprise is founded on? Why should software engineering be the lone > exception? > > No one may be a structural engineer, and remain ignorant of physics. No > one may be a chemical engineer, and remain ignorant of chemistry. Why > on earth should any one be permitted to be a software engineer, and > remain ignorant of computing science? > Indeed. Because abstract alebra is highly relevant to computer programming. Oh, wait... Many people complain that too many "database experts" don't know the first thing about basic normalisation rules, SQL injection attacks, why you shouldn't use cursors, and so forth. But almost nobody complains that database experts don't know set theory or relational alebra. Why should proramming be any different? Don't get me wrong, there are mathematical concepts that are relevant to computing, and we should encourage people to learn about them. But you really *should not* need to do an undergraduate course in mathematical theory just to work out how to concat two lists. That's absurd. Some kind of balance needs to be found. From naur at post11.tele.dk Thu Jan 15 16:38:12 2009 From: naur at post11.tele.dk (Thorkil Naur) Date: Thu Jan 15 16:30:58 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> Message-ID: <200901152238.14387.naur@post11.tele.dk> Hello, On Thursday 15 January 2009 19:59, Peter Verswyvelen wrote: > It is rather funny. When we are young kids, we learn weird symbols like > A B C a b c 1 2 3 > > which we accept after a while. > > Then we get to learn more complex symbols like > > ! ? + - / > > and that takes some time to get used to, but eventually, that works too. > > But Functor, Monoid or Monad, that we cannot accept anymore. Why, because > these are not intuitive? Are the symbols above "intuitive"? I think there is a simple explanation of this: Consider the amount of time you spent, as a young kid, to learn to get used to these funny 1, 2, a, b, x, y, +, - and so on. I haven't got the exact schedules from school, but my impression is that we are talking about hours and hours of drill and practice, over weeks, months, years. I mean, do you show your small children (say, 5 years old) how to write numbers to represent, say, the number of oranges in a bowl and then they comprehend after, say, a couple of minutes? Or half an hour? No. Learning to get used to such things, let alone use them effectively to solve common problems, takes time. And also, of course, intense and qualified guidance, in some form. So, to learn to become familiar and effective in using new and complex concepts, we should just accept that it sometimes may take a while. And that's it. It is all a matter of practice, exposure, and guidance. > ... Best regards Thorkil From dvogel at intercarve.net Thu Jan 15 16:43:41 2009 From: dvogel at intercarve.net (Drew Vogel) Date: Thu Jan 15 16:34:51 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> Message-ID: <496FAE0D.7030004@intercarve.net> Lennart Augustsson wrote: > Why do people think that you should be able to understand everything > without ever looking things up? > I'll get back to my example from the comment on the blog post. If I > see 'ghee' in a cook book I'll check what it is (if I don't know). It > has a precise meaning and next time I'll know. Inventing a new word > for it serves no purpose, but to confuse people. > Parts of Computer Science seem to love to invent new words for > existing concepts. Again, I think this just confuses people in the > long run. Or use existing words in a different way (like 'functor' in > C++.) > ghee is ghee. There are variations of ghee, but when a cookbook calls for ghee, just about any variation will work fine. Furthermore, whenever a cookbook calls for ghee, you are making food. Conversely a monoid is an algebraic structure. A Monoid (the type class) is an abstraction used to ensure that a particular variation of a monoid is actually representative of a monoid. There are many variations (:i Monoid shows 17 instances). Most are used for different purposes and few are interchangeable for a given purpose. Inventing new words definitely serves a purpose; it is a form of abstraction. We need new words to manage conceptual complexity just as we build abstractions to manage code complexity. In fact, Monoid was once a new word that was invented to serve that very purpose. I don't think the solution to this problem is to rename it to Appendable. I think the "solution" is to allow programmers to alias Monoid as Appendable similar to the way you can alias a module when you imort it. The details of that solution would be very difficult to introduce though. Drew P. Vogel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/80bdb6c8/signature.bin From jonathanccast at fastmail.fm Thu Jan 15 16:50:11 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Jan 15 16:44:56 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496F6ADB.5050300@complete.org> References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> <496F6ADB.5050300@complete.org> Message-ID: <1232056211.6800.28.camel@jcchost> On Thu, 2009-01-15 at 10:56 -0600, John Goerzen wrote: > Lennart Augustsson wrote: > > Most people don't understand pure functional programming either. Does > > that mean we should introduce unrestricted side effects in Haskell? > > The key is to introduce concepts to them in terms they can understand. > > You introduce it one way to experienced abstract mathematicians, and a > completely different way to experienced Perl hackers. I wouldn't expect > a mathematician to grok Perl, and I wouldn't expect $PERL_HACKER to grok > abstract math. People have different backgrounds to draw upon, and we > are under-serving one community. False. We are failing to meet the un-realistic expectations of advanced Perl/Python/Ruby/C/C++/Java/any other imperative language programmers as to the ease with which they should be able to learn Haskell. jcc From jonathanccast at fastmail.fm Thu Jan 15 16:51:43 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Jan 15 16:48:10 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B4DCB01@ELON17P32001A.csfb.cs-group.com> References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCB01@ELON17P32001A.csfb.cs-group.com> Message-ID: <1232056303.6800.31.camel@jcchost> On Thu, 2009-01-15 at 17:13 +0000, Sittampalam, Ganesh wrote: > Lennart Augustsson wrote: > > Most people don't understand pure functional programming either. > > Does that mean we should introduce unrestricted side effects in > > Haskell? > > No, just that we should seek to minimise the new stuff they have > to get to grips with. How does forcing them to learn proposed terminology such as `Appendable' help here? Learners of Haskell do still need to learn what the new word means. (Or are you suggesting we should aim for programmers to be able to use Haskell (or just certain libraries?) without learning it first?) jcc From jonathanccast at fastmail.fm Thu Jan 15 16:56:11 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Jan 15 16:48:36 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496FA7E0.4060202@btinternet.com> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <3d96ac180901151236k5d9479a2n9a1071325656d3a0@mail.gmail.com> <496FA7E0.4060202@btinternet.com> Message-ID: <1232056571.6800.34.camel@jcchost> On Thu, 2009-01-15 at 21:17 +0000, Andrew Coppin wrote: > Sebastian Sylvan wrote: > > > > > > On Thu, Jan 15, 2009 at 7:46 PM, Andrew Coppin > > > wrote: > > > > The sad thing is, it's not actually complicated. The documentation > > just makes it seem like it is! :-( > > > > > > This is so true for a heck of a lot of things. Existential > > quantification being just one of them. Loads of things in Haskell have > > big powerful (but scary) names which I really think intimidate people, > > the situation isn't helped when a lot of tutorials use the theoretical > > basis for the construct as a starting point, rather then actually > > describing the construct from the perspective of a programmer first > > (see Monads). > > Haskell really isn't that difficult compared to other languages, but > > people still get the impression that you need to be a big brain on a > > stick to use it, terminology is certainly part of the equation. > > > > This doesn't mean that making up new words is always better, but we > > should certainly strive to exploit any opportunity to clarify the > > issue and (this means that haddock comments and language > > books/tutorials shouldn't refer to academic papers first and foremost, > > but use common English and practical examples to describe what's being > > used, and academic nerds can consult the footnotes for their fill of > > papers containing pages of squiggly symbols!). > > I basically agree with most of what you just said. > > I'm not sure having a Monoid class is actually useful for anything - but > if we must have it, there seems to be little better possible name for > something so vague. > > {-# LANGUAGE ExistentialQuantification #-} is an absurd name and should > be changed to something that, at a minimum, tells you it's something to > do with the type system. (Ideally it would also be pronouncible.) Of > course, nobody will take any notice, since changing this would induce > mass breakage for all the millions of LoC that already use the old name. > > I think "documenting" a package by saying "read this academic paper" > should be banned. (Most especially if the paper in question isn't even > available online and can only be obtained from a reputable university > library!!) For example, I was looking at one of the monad transformers > (I don't even remember which one now), and the Haddoc contained some > type signatures and a line saying "read this paper". The paper in > question mentioned the transformer in passing as a 5-line example of how > to use polymorphism, but *still* without explaining how to actually use > it! (I.e., the paper was about polymorphism, and this transformer was > just a quick example.) What the hell?? > > I presume I can call "more documentation please!" without upsetting even > the most ardant category theory millitant... ;-) But you don't seem to be capable of separating your valid complaints from your invalid ones. Everyone wants the Haddock documentation to be maximally useful. But the should never be a confusion between *defining* a term used in a library and *choosing* that term. They are simply different activities, and neither can be a substitute for the other. jcc From thomas.dubuisson at gmail.com Thu Jan 15 16:59:32 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Thu Jan 15 16:50:39 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <1232056303.6800.31.camel@jcchost> References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCB01@ELON17P32001A.csfb.cs-group.com> <1232056303.6800.31.camel@jcchost> Message-ID: <4c44d90b0901151359h708b3980t912f51d847bb598c@mail.gmail.com> > How does forcing them to learn proposed terminology such as `Appendable' > help here? Learners of Haskell do still need to learn what the new word > means. The contention is that 'Appendable' is an intuitive naming that people will already have a rudimentary grasp of. This as opposed to Monoid, which absolutely requires looking up for the average coder. From haskell at list.mightyreason.com Thu Jan 15 17:00:50 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Thu Jan 15 16:52:11 2009 Subject: [Haskell-cafe] Re: Compiling regex-posix-0.93.2 on windows In-Reply-To: References: <48F912A4.9060306@list.mightyreason.com> Message-ID: Paulo: I suggest doing this more carefully. Get the source from hackage. Edit the regex-posix.cabal file to add the include and lib directories you need on Cygwin. cabal "configure" it. cabal "build" it. cabal "install" it. Then in an unrelated directory try and run "ghci -package regex-posix". This should load regex-posix-VERSION. If this fails then I think that the cabal file needs fixing. If that works then please test it with these commands: > Prelude> :m + Text.Regex.Posix > Prelude Text.Regex.Posix> (Text.Regex.Posix.=~) "ab" "(()|[ab])(b)" :: (String,String,String,[String]) The right answer by the way is: > ("","ab","",["a","","b"]) But on FreeBSD/NetBSD/OS X there is a bug that I have found and it prints: > ("a","b","",["","","b"]) Which just goes to show that a mountain of QuickCheck is what is sometimes needed to catch really hard to trigger bugs. This is the other bug I reported: > Prelude Text.Regex.Posix> (Text.Regex.Posix.=~) "XababaY" "(X)(aba|ab|b)*(Y)" :: (String,String,String,[String]) > ("","XababaY","",["X","b","Y"]) The above answer is impossible (what matched "a" next to "b"?), but I now think I know WTF the library code is doing wrong (I think it is matching "ababa" in two passes and the second pass is greedy which is a broken strategy). The right answer is: > ("","XababaY","",["X","aba","Y"]) Cheers, Chris PS: Yes, I have reported these bug to Apple, FreeBSD, and NetBSD this month. From jonathanccast at fastmail.fm Thu Jan 15 17:03:39 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Jan 15 16:55:16 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496FAAAA.9050609@btinternet.com> References: <20090115153438.GA1340@hustlerturf.com> <1232054517.6800.9.camel@jcchost> <496FAAAA.9050609@btinternet.com> Message-ID: <1232057019.6800.41.camel@jcchost> On Thu, 2009-01-15 at 21:29 +0000, Andrew Coppin wrote: > Jonathan Cast wrote: > > Where, in the history of western civilization, has there ever been an > > engineering discipline whose adherents were permitted to remain ignorant > > of the basic mathematical terminology and methodology that their > > enterprise is founded on? Why should software engineering be the lone > > exception? > > > > No one may be a structural engineer, and remain ignorant of physics. No > > one may be a chemical engineer, and remain ignorant of chemistry. Why > > on earth should any one be permitted to be a software engineer, and > > remain ignorant of computing science? > Indeed. Because abstract alebra is highly relevant to computer > programming. Oh, wait... Beg pardon? That was an argument? I'm sorry, but I can't infer your middle term. > Many people complain that too many "database experts" don't know the > first thing about basic normalisation rules, SQL injection attacks, why > you shouldn't use cursors, and so forth. But almost nobody complains > that database experts don't know set theory or relational alebra. I didn't know this. I intend to start. But, in any case, you picked your counter-example *from within software engineering*, at least as broadly understood. My claim is that the computer industry as a whole is *sick*, that we are simply going about this enterprise of dealing with these (memory-limited) universal Turing machines (= implementations of lambda calculus = universal recursive functions) *wrong*. More cases of this, within the computer industry, re-enforces my claim, rather than weakening it. > Don't get me wrong, there are mathematical concepts that are relevant to > computing, You mean like monads? > and we should encourage people to learn about them. But you > really *should not* need to do an undergraduate course in mathematical > theory just to work out how to concat two lists. Look, if you want (++), you know where to find it. Or are you complaining that you shouldn't have to study mathematics to understand what (++) and, say, the choice operation on events, have in common? jcc From jonathanccast at fastmail.fm Thu Jan 15 17:04:30 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Jan 15 16:56:08 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <4c44d90b0901151359h708b3980t912f51d847bb598c@mail.gmail.com> References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCB01@ELON17P32001A.csfb.cs-group.com> <1232056303.6800.31.camel@jcchost> <4c44d90b0901151359h708b3980t912f51d847bb598c@mail.gmail.com> Message-ID: <1232057070.6800.43.camel@jcchost> On Thu, 2009-01-15 at 21:59 +0000, Thomas DuBuisson wrote: > > How does forcing them to learn proposed terminology such as `Appendable' > > help here? Learners of Haskell do still need to learn what the new word > > means. > > The contention is that 'Appendable' is an intuitive naming that people > will already have a rudimentary grasp of. But this contention is false. jcc From duncan.coutts at worc.ox.ac.uk Thu Jan 15 17:05:00 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 15 16:56:22 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <1232051895.28590.350.camel@localhost> <20090115205128.GE17581@scytale.galois.com> Message-ID: <1232057100.28590.357.camel@localhost> On Thu, 2009-01-15 at 16:03 -0500, Andrew Wagner wrote: > I think perhaps the correct question here is not "how many instances > of Monoid are there?", but "how many functions are written that can > use an arbitrary Monoid". E.g., the fact that there are a lot of > instances of Monad doesn't make it useful. There are a lot of > instances of Monad because it's useful to have instances of Monad. > Why? Because > of http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html ! Look at all the cool stuff you can automagically do with your type just because it's an instance of Monad! I think that's the point. What can you do with arbitrary Monoids? Not much, as evidenced by http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html Data.Foldable has several functions that use an arbitrary monoid. A new API I've been working on for manipulating cabal files uses a tree of values of any monoid type. Sets of installation paths is a monoid and is parametrised by another monoid type (so we can have both sets of file paths and path templates). A similar point applies for package indexes. Most of the utility functions for handling command line arguments in Cabal are parameterised by the monoid, because different command line flags are different kinds of monoid. Some are list monoids, others are first / last style monoids. But it's not just the ability to write generic functions that is relevant. By making a type an instance of Monoid instead of exporting emptyFoo, joinFoo functions it makes the API clearer because it shows that we are re-using an existing familiar concept rather than inventing a new one. It also means the user already knows that joinFoo must be associative and have unit emptyFoo without having to read the documentation. Duncan From dpiponi at gmail.com Thu Jan 15 17:06:30 2009 From: dpiponi at gmail.com (Dan Piponi) Date: Thu Jan 15 16:57:41 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496FAAAA.9050609@btinternet.com> References: <20090115153438.GA1340@hustlerturf.com> <1232054517.6800.9.camel@jcchost> <496FAAAA.9050609@btinternet.com> Message-ID: <625b74080901151406m786c5ba1u8f5bde8e3a6e60ad@mail.gmail.com> On Thu, Jan 15, 2009 at 1:29 PM, Andrew Coppin wrote: > But you > really *should not* need to do an undergraduate course in mathematical > theory just to work out how to concat two lists. That's absurd. Some kind of > balance needs to be found. Balance is good, but it's hard to find a balance when people exaggerate so much. Firstly: You don't need monoids to concat two lists. You need monoids when you want to abstract the operation of concatting two lists so that the same code can be reused in other ways. A good example is the writer monad. The author of that monad could have made it work just with strings. But one of the coollest things about Haskell is the way it's so amenable to micro-refactoring. By realising there's a bunch of other things the Writer monad can do using *exactly the same implementation* you get reusability. If you don't want this kind of reusability you may be better off with C or Fortran. Secondly: you don't need an "undergraduate course." to understand monoids. A monoid is just a collection of things with an operation allowing you to combine two things to get another one. And an element that acts like 'nothing' so that when you combine it with other elements it leaves them unchanged (and an additional simple condition). This would be the first 30 seconds of a course on monoids that presupposes nothing more than a naive idea of what a set is. The only thing that's difficult about monoids is that it's a new word. There's little 'theory' involved. Your talk of undergraduate courses to concat two lists isn't grounded in any kind of reality, muddies the waters, and probably scares people away from Haskell by giving the impression that it's much harder than it is. -- Dan From steve at fenestra.com Thu Jan 15 17:06:41 2009 From: steve at fenestra.com (Steve Schafer) Date: Thu Jan 15 16:57:54 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <1232054517.6800.9.camel@jcchost> References: <20090115153438.GA1340@hustlerturf.com> <1232054517.6800.9.camel@jcchost> Message-ID: On Thu, 15 Jan 2009 13:21:57 -0800, you wrote: >Where, in the history of western civilization, has there ever been an >engineering discipline whose adherents were permitted to remain ignorant >of the basic mathematical terminology and methodology that their >enterprise is founded on? Umm, all of them? >No one may be a structural engineer, and remain ignorant of physics. No >one may be a chemical engineer, and remain ignorant of chemistry. Why >on earth should any one be permitted to be a software engineer, and >remain ignorant of computing science? Do you know any actual working structural or chemical engineers? Most engineering disciplines require a basic grasp of the underlying theory, yes, but not much beyond that. Pretty much everything else is covered by rules (either rules of thumb or published standards). Show me an electrical engineer who can explain the physics of a pn junction and how it acts as a rectifier, or a civil engineer who can explain why the stress/strain curve of a steel beam has the shape that it does, or a chemical engineer who can explain molecular orbital theory. Those kinds of engineers do exist, of course, but they are few and far between. If you aim your product only at the kinds of engineers who _can_ do those things, you will be reaching a tiny, tiny fraction of the overall population. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ From westondan at imageworks.com Thu Jan 15 17:10:07 2009 From: westondan at imageworks.com (Dan Weston) Date: Thu Jan 15 17:01:16 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> Message-ID: <496FB43F.70202@imageworks.com> Maybe you can explain that again? I see how the subset of Kleisli arrows (a -> m a) forms a monoid (a, return . id, >>=), but what to do with (a -> m b)? (>>=) is not closed under this larger set. Dan Miguel Mitrofanov wrote: >> Notice that "monoid" sounds almost *exactly* like "monad". And yet, >> what you use them for is wildly unrelated. > > Well, monads are monoids. I remember explaining you that... > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From roconnor at theorem.ca Thu Jan 15 17:16:04 2009 From: roconnor at theorem.ca (roconnor@theorem.ca) Date: Thu Jan 15 17:07:10 2009 Subject: Names in Haskell (Was: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt) Message-ID: What I don't understand is why Monoid and Monad are objectionable, while Hash, Vector, Boolean, and Integer are (presumably) not objectionable. They all appear equally technical to me. -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From jgoerzen at complete.org Thu Jan 15 17:16:11 2009 From: jgoerzen at complete.org (John Goerzen) Date: Thu Jan 15 17:07:22 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <1232056211.6800.28.camel@jcchost> References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> <496F6ADB.5050300@complete.org> <1232056211.6800.28.camel@jcchost> Message-ID: <20090115221611.GA10586@hustlerturf.com> On Thu, Jan 15, 2009 at 01:50:11PM -0800, Jonathan Cast wrote: > On Thu, 2009-01-15 at 10:56 -0600, John Goerzen wrote: > > Lennart Augustsson wrote: > > > Most people don't understand pure functional programming either. Does > > > that mean we should introduce unrestricted side effects in Haskell? > > > > The key is to introduce concepts to them in terms they can understand. > > > > You introduce it one way to experienced abstract mathematicians, and a > > completely different way to experienced Perl hackers. I wouldn't expect > > a mathematician to grok Perl, and I wouldn't expect $PERL_HACKER to grok > > abstract math. People have different backgrounds to draw upon, and we > > are under-serving one community. > > False. We are failing to meet the un-realistic expectations of advanced > Perl/Python/Ruby/C/C++/Java/any other imperative language programmers as > to the ease with which they should be able to learn Haskell. What part of that are you saying is false? That people have different backgrouns and learn differently? > > jcc > > > From allbery at ece.cmu.edu Thu Jan 15 17:17:51 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Jan 15 17:08:59 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: <496F1628.3040901@libero.it> References: <496DFDD0.1010109@libero.it> <404396ef0901140712t2972863bp2ef9185c0c4f973c@mail.gmail.com> <496E072F.2050906@libero.it> <496F1628.3040901@libero.it> Message-ID: <7DDE19A1-E164-4C88-A669-47FE52374659@ece.cmu.edu> On 2009 Jan 15, at 5:55, Manlio Perillo wrote: > Brandon S. Allbery KF8NH ha scritto: > > > > [... about Python import local to functions ...] >>> Sometime they are necessary, to avoid circular import problems >>> (but this not a problem with Haskell). >> ...in theory. In practice GHC needs help with circular imports, and >> some cycles might be impossible to resolve. > > This is interesting. > Where can I find some examples? http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#mutual-recursion The "impossible to resolve" is my interpretation of a discussion on the lists several months ago. I don't see any mention in RWH offhand. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From duncan.coutts at worc.ox.ac.uk Thu Jan 15 17:18:27 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 15 17:09:32 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <4c44d90b0901151359h708b3980t912f51d847bb598c@mail.gmail.com> References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCB01@ELON17P32001A.csfb.cs-group.com> <1232056303.6800.31.camel@jcchost> <4c44d90b0901151359h708b3980t912f51d847bb598c@mail.gmail.com> Message-ID: <1232057907.28590.371.camel@localhost> On Thu, 2009-01-15 at 21:59 +0000, Thomas DuBuisson wrote: > > How does forcing them to learn proposed terminology such as `Appendable' > > help here? Learners of Haskell do still need to learn what the new word > > means. > > The contention is that 'Appendable' is an intuitive naming that people > will already have a rudimentary grasp of. This as opposed to Monoid, > which absolutely requires looking up for the average coder. It reminds me a bit of my school French classes. Our teacher often brought up the subject of "false friends", that is words in the foreign language that sound superficially familiar to one in the native language but are in fact different in subtle but important ways. In this case Appendable has the wrong connotations for what the Monoid class does. Appendable does not sound symmetric to me and it places too much emphasis on monoids that resemble lists. Perhaps there is a more common word that reflects the meaning without being misleading. But if we cannot find one, then picking a name that is unfamiliar to most people may well be better than picking a name that is misleading or is too narrow. Duncan From miguelimo38 at yandex.ru Thu Jan 15 17:24:03 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Thu Jan 15 17:15:23 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496FB43F.70202@imageworks.com> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <496FB43F.70202@imageworks.com> Message-ID: On 16 Jan 2009, at 01:10, Dan Weston wrote: > Maybe you can explain that again? Sure. Consider the following setting: a category C and a bifunctor T : C x C -> C, which is associative and have a (left and right) unit I. This is what is called "monoidal category". A "monoid" is an object X in C with two morphisms: I -> X and T(X, X) - > X, satisfying two relatively simple conditions (I don't want to draw commutative diagrams). If your category is a category of sets, and T is a cartesian product, then you have ordinary monoids (I is a one-element set, first morphism is a unit of a monoid, and second morphism is monoid multiplication). If, however, you category is a category of endofunctors of some category D (that is, functors D -> D), and T is composition, then our "monoids" become monads on D: I is an identity functor, first morphism is "return", and second one is "join". > > > I see how the subset of Kleisli arrows (a -> m a) forms a monoid (a, > return . id, >>=), but what to do with (a -> m b)? (>>=) is not > closed under this larger set. > > Dan > > Miguel Mitrofanov wrote: >>> Notice that "monoid" sounds almost *exactly* like "monad". And >>> yet, what you use them for is wildly unrelated. >> Well, monads are monoids. I remember explaining you that... >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > From duncan.coutts at worc.ox.ac.uk Thu Jan 15 17:27:29 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 15 17:18:33 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496FA8DA.7050907@btinternet.com> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <1232051895.28590.350.camel@localhost> <496FA8DA.7050907@btinternet.com> Message-ID: <1232058449.28590.379.camel@localhost> On Thu, 2009-01-15 at 21:21 +0000, Andrew Coppin wrote: > OK, well then my next question would be "in what say is defining > configuration files as a monoid superior to, uh, not defining them as a > monoid?" What does it allow you to do that you couldn't otherwise? I'm > not seeing any obvious advantage, but you presumably did this for a > reason... [ I know I'm repeating myself from elsewhere in this thread but this is the better question for the answer :-) ] By making a type an instance of Monoid instead of exporting emptyFoo, joinFoo functions it makes the API clearer because it shows that we are re-using an existing familiar concept rather than inventing a new one. It also means the user already knows that joinFoo must be associative and have unit emptyFoo without having to read the documentation. Perhaps it's what OO programmers would call a design pattern. Identify a pattern, give it a name and then when the pattern crops up again (and again) then the reader of the code will have an easier time because they are already familiar with that named pattern. Of course the fact that we can occasionally use the pattern to parametrise and write more re-usable code is a bonus. Duncan From andrewcoppin at btinternet.com Thu Jan 15 17:32:09 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Jan 15 17:23:15 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <1232058449.28590.379.camel@localhost> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <1232051895.28590.350.camel@localhost> <496FA8DA.7050907@btinternet.com> <1232058449.28590.379.camel@localhost> Message-ID: <496FB969.7000600@btinternet.com> Duncan Coutts wrote: > By making a type an instance of Monoid instead of exporting > emptyFoo, joinFoo functions it makes the API clearer because it shows > that we are re-using an existing familiar concept rather than inventing > a new one. It also means the user already knows that joinFoo must be > associative and have unit emptyFoo without having to read the > documentation. > I don't know about you, but rather than knowing that joinFoo is associative, I'd be *far* more interested in finding out what it actually _does_. Knowing that it's a monoid doesn't really tell me anything useful. A monoid can be almost anything. As an aside, the integers form two different monoids. Haskell can't [easily] handle that. Does anybody know of a language that can? From bugfact at gmail.com Thu Jan 15 17:34:21 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Jan 15 17:25:30 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496FA7E0.4060202@btinternet.com> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <3d96ac180901151236k5d9479a2n9a1071325656d3a0@mail.gmail.com> <496FA7E0.4060202@btinternet.com> Message-ID: > > I'm not sure having a Monoid class is actually useful for anything - but if > we must have it, there seems to be little better possible name for something > so vague. > IMO the Monoid class is useful since, if you define mempty and mappend, you get mconcat for free. I don't see what the problem is. Most people will accept Functor, as it used a lot. Monoid might be less used, but if you reject it, then by principle you must just as well reject Functor, and any other type classes. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/1126bfd7/attachment.htm From pbeadling at mail2web.com Thu Jan 15 17:34:22 2009 From: pbeadling at mail2web.com (Phil) Date: Thu Jan 15 17:26:16 2009 Subject: [Haskell-cafe] Multiple State Monads In-Reply-To: <7ca3f0160901131708p4211c1eay34a0dfdb3d8177e@mail.gmail.com> Message-ID: Inline.... On 14/01/2009 01:08, "Luke Palmer" wrote: > On Tue, Jan 13, 2009 at 5:45 PM, Phil wrote: >> mcSimulate :: Double -> Double -> Word64 -> [Dou >> ble] >> mcSimulate startStock endTime seedForSeed = fst expiryStock : mcSimulate >> startStock endTime newSeedForSeed >> >> It is abundantly clear that the startStock and endTime are just being passed >> around from call to call unchanged ? that is their value is constant >> throughout the the simulation. For the purposes here when I'm only passing 2 >> 'constants' around it doesn't strike me as too odd, but my list of >> 'constants' is likely to grow as I bolt more functionality onto this. For >> readability, I understand that I can create new types to encapsulate complex >> data types into a single type , but I can't help thinking that passing say 9 >> or 10 'constants' around and around like this 'feels wrong'. If I sit back >> and think about it, it doesn't strike me as implausible that the compiler >> will recognize what I'm doing and optimize this out for me, and what I'm >> doing is thinking about the whole think like a C++ programmer (which I >> traditionally am) would. > > You can factor out constants in a couple ways. If you are just passing > constants between a recursive call to the same function, you can factor out > the recursive bit into a separate function: > > something param1 param2 = go > where > go = ... param1 ... param2 ... etc ... go ... > etc = ... > > Where go takes only the parameters that change, and the rest is handled by its > enclosing scope. You might buy a little performance this way too, depending > on the compiler's cleverness (I'm not sure how it optimizes these things). > > > [PHIL] > Firstly ? thanks for your advice. > > When I say constants, I should be clear ? these are parameters passed in by > the user, but they remain constant throughout the recursive call. I think the > example above is only relevant if they are constants at compile time? If not > I?m not sure I follow the example. If we have something like > > mcSimulate :: Double -> Double -> Word64 -> [Double] > mcSimulate startStock endTime seedForSeed = fst expiryStock : mcSimulate > startStock endTime newSeedForSeed > where > expiryStock = iterate evolveUnderlying (startStock, ranq1Init seedForSeed) > !! truncate (endTime/timeStep) > newSeedForSeed = seedForSeed + 246524 > > Here startStock and endTime are not altered from iteration to iteration, but > they are not known at compile time. I see that I can reduce this to something > like > > test seedForSeed = fst expiryStock : test newSeedForSeed > where > expiryStock = iterate evolveUnderlying (_startStock, ranq1Init > seedForSeed) !! truncate (_endTime/timeStep) > newSeedForSeed = seedForSeed + 246524 > > But don?t understand how I ?feed? the _startStock and _endTime in? > > Could you explain this in detail, or confirm my suspicions that it only works > for compile-time constants? > > > Thanks again, > > Phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/e6c9ab7d/attachment-0001.htm From duncan.coutts at worc.ox.ac.uk Thu Jan 15 17:35:59 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 15 17:27:05 2009 Subject: [Haskell-cafe] Re: Compiling regex-posix-0.93.2 on windows In-Reply-To: References: <48F912A4.9060306@list.mightyreason.com> Message-ID: <1232058959.28590.383.camel@localhost> On Thu, 2009-01-15 at 22:00 +0000, ChrisK wrote: > Paulo: I suggest doing this more carefully. > > Get the source from hackage. > > Edit the regex-posix.cabal file to add the include and lib directories you need > on Cygwin. I should note that you do not need to edit the .cabal file to do this. As of Cabal-1.4 there are extra command line flags to configure (or equivalently to cabal install) --extra-include-dirs=dir --extra-lib-dirs=dir Duncan From duncan.coutts at worc.ox.ac.uk Thu Jan 15 17:39:40 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 15 17:30:44 2009 Subject: Names in Haskell (Was: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt) In-Reply-To: References: Message-ID: <1232059180.28590.388.camel@localhost> On Thu, 2009-01-15 at 17:16 -0500, roconnor@theorem.ca wrote: > What I don't understand is why Monoid and Monad are objectionable, while > Hash, Vector, Boolean, and Integer are (presumably) not objectionable. > They all appear equally technical to me. It's simply that other languages' libraries already have those terms in them. So there is nothing new to learn. That seems to be the crux of the argument. Duncan From dpiponi at gmail.com Thu Jan 15 17:42:41 2009 From: dpiponi at gmail.com (Dan Piponi) Date: Thu Jan 15 17:33:47 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <496FB43F.70202@imageworks.com> Message-ID: <625b74080901151442pe1bcfe7qfb23ba317abe1b7f@mail.gmail.com> On Thu, Jan 15, 2009 at 2:24 PM, Miguel Mitrofanov wrote: > If, however, you category is a category of endofunctors of some category D > (that is, functors D -> D), and T is composition, then our "monoids" become > monads on D: I is an identity functor, first morphism is "return", and > second one is "join". You can see this more concretely in Haskell code here: http://sigfpe.blogspot.com/2008/11/from-monoids-to-monads.html (This probably ought to be in a separate thread.) -- Dan From dave at zednenem.com Thu Jan 15 17:43:08 2009 From: dave at zednenem.com (David Menendez) Date: Thu Jan 15 17:34:14 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <1232058449.28590.379.camel@localhost> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <1232051895.28590.350.camel@localhost> <496FA8DA.7050907@btinternet.com> <1232058449.28590.379.camel@localhost> Message-ID: <49a77b7a0901151443x70bff91bj562ca94e414a60e@mail.gmail.com> On Thu, Jan 15, 2009 at 5:27 PM, Duncan Coutts wrote: > On Thu, 2009-01-15 at 21:21 +0000, Andrew Coppin wrote: > >> OK, well then my next question would be "in what say is defining >> configuration files as a monoid superior to, uh, not defining them as a >> monoid?" What does it allow you to do that you couldn't otherwise? I'm >> not seeing any obvious advantage, but you presumably did this for a >> reason... > > [ I know I'm repeating myself from elsewhere in this thread but this is > the better question for the answer :-) ] > > By making a type an instance of Monoid instead of exporting > emptyFoo, joinFoo functions it makes the API clearer because it shows > that we are re-using an existing familiar concept rather than inventing > a new one. It also means the user already knows that joinFoo must be > associative and have unit emptyFoo without having to read the > documentation. I assume these are all documented where the type is defined? One disadvantage of Monoid compared to Monad is that you really need to explain what operation your Monoid instance performs. For example, the documentation for Maybe describes what its Monad instance does, but not its Monoid instance. I don't think any of the instances for [] are documented. (Admittedly, this is difficult, since [] is not actually exported from anywhere.) -- Dave Menendez From bugfact at gmail.com Thu Jan 15 17:48:52 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Jan 15 17:39:59 2009 Subject: [Haskell-cafe] F# active patterns versus GHC's view Message-ID: When I first read about active patterns in F#, I found it really cool idea, since it allows creating fake data constructors that can be used for pattern matching, giving many views to a single piece of data, and allowing backwards compatibility when you completely change or hide a data structure. So for example one could define a Polar pattern and a Rect pattern that give different views of a Complex number, e.g (pseudo code follows) pattern Polar c = (mag c, phase c) pattern Rect c = (real c, imag c) This seems handy: polarMul (Polar m1 p1) (Polar m2 p2) = mkComplexFromPolar (m1*m2) (p1+p2) However, I think it is flawed, since the following case c of Polar _ _ -> "it's polar!" Rect _ _ -> "it's rect!" seems like valid code but does not make any sense. So I think the GHC extension of view patterns is better than the active patterns in F#? A good coding style is to provide constructor functions and hide data constructors. But then one looses the ability to perform pattern matching, which is so cool in Haskell. Would I have to conclude that it would be good coding style to use view patterns as much as possible in Haskell, creating auxiliary data constructors to expose the "public members" of the hidden data constructors? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/2db935f3/attachment.htm From mnislaih at gmail.com Thu Jan 15 18:05:34 2009 From: mnislaih at gmail.com (pepe) Date: Thu Jan 15 17:56:47 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <1232058449.28590.379.camel@localhost> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <1232051895.28590.350.camel@localhost> <496FA8DA.7050907@btinternet.com> <1232058449.28590.379.camel@localhost> Message-ID: <2ACD14C8-76A5-4D6C-A9F5-FCFFF6701EFD@gmail.com> On 15/01/2009, at 23:27, Duncan Coutts wrote: > On Thu, 2009-01-15 at 21:21 +0000, Andrew Coppin wrote: > >> OK, well then my next question would be "in what say is defining >> configuration files as a monoid superior to, uh, not defining them >> as a >> monoid?" What does it allow you to do that you couldn't otherwise? >> I'm >> not seeing any obvious advantage, but you presumably did this for a >> reason... > > [ I know I'm repeating myself from elsewhere in this thread but this > is > the better question for the answer :-) ] > > By making a type an instance of Monoid instead of exporting > emptyFoo, joinFoo functions it makes the API clearer because it shows > that we are re-using an existing familiar concept rather than > inventing > a new one. It also means the user already knows that joinFoo must be > associative and have unit emptyFoo without having to read the > documentation. > > Perhaps it's what OO programmers would call a design pattern. > Identify a > pattern, give it a name and then when the pattern crops up again (and > again) then the reader of the code will have an easier time because > they > are already familiar with that named pattern. Exactly, documenting knowledge was one of the benefits of design patterns. Monoid looks like the Composite pattern, one of the original GoF patterns. Is Composite is a better name for Monoid? I guess that when the GoF folks were writing the book they had to come up with quite a few names, and some came out better than others. If anything, the Haskell approach is more consistent. From cgibbard at gmail.com Thu Jan 15 18:08:54 2009 From: cgibbard at gmail.com (Cale Gibbard) Date: Thu Jan 15 18:00:00 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496F927A.3060007@btinternet.com> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> Message-ID: <89ca3d1f0901151508k6753af82t88028ff9b6d14d69@mail.gmail.com> > off the top of their head what the difference between an epimorphism and a > hylomorphism is? They're not even from the same branch of mathematics. Epimorphisms are defined in category theory, as arrows which can be cancelled when they appear on the right of a composite, that is, if f is an epimorphism, and g . f = h . f, then g = h. Such arrows are somewhat comparable to surjective functions. Hylomorphisms are from recursion theory. They are the composite of an anamorphism (which builds up a recursive structure from an initial seed) with a catamorphism, (which replaces the constructors in that recursive structure with other functions). Terminology has value, in that it allows you to see things in a new way which is clearer than what could otherwise be achieved. Any programmer worth their salt should be comfortable absorbing a new term, the same way they learn a new library function. We should remember that Haskell's beauty is not an accident. It is proportional to the amount of effort which went into building the solid mathematical foundations describing its semantics, and designing a language which reflected those semantics as clearly as possible. Discarding those foundations in an attempt to get more users is a price I would personally never want to see us pay. - Cale From cgibbard at gmail.com Thu Jan 15 18:10:48 2009 From: cgibbard at gmail.com (Cale Gibbard) Date: Thu Jan 15 18:01:54 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B4DCB02@ELON17P32001A.csfb.cs-group.com> References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <496F6982.9000002@complete.org> <16442B752A06A74AB4D9F9A5FF076E4B4DCB02@ELON17P32001A.csfb.cs-group.com> Message-ID: <89ca3d1f0901151510i6f07c72bxba6cd7e90f3dfe5f@mail.gmail.com> 2009/1/15 Sittampalam, Ganesh : > Lennart Augustsson wrote: >> I think the documentation should be reasonably newbie-friendly too. >> But that doesn't mean we should call Monoid Appendable. >> Appendable is just misleading, since Monoid is more general than >> appending. > > Then why does it have a member named 'mappend'? :-) > > Ganesh Good question. The names of the methods of the Monoid class are inappropriate. My personal preference would be: class Monoid m where zero :: m (++) :: m -> m -> m (in the Prelude of course) - Cale From ddssff at gmail.com Thu Jan 15 18:11:00 2009 From: ddssff at gmail.com (David Fox) Date: Thu Jan 15 18:02:10 2009 Subject: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt In-Reply-To: <87ljtcpkjo.fsf@justinbogner.com> References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <87ljtcpkjo.fsf@justinbogner.com> Message-ID: On Thu, Jan 15, 2009 at 9:04 AM, wrote: > John Goerzen writes: > > Wikipedia's first sentence about monoids is: > > > > In abstract algebra, a branch of mathematics, a monoid is an algebraic > > structure with a single, associative binary operation and an identity > > element. > > > > Which is *not* intuitive to someone that comes from a background in.... > > any other programming language. > > > > Instead of Wikipedia, why not try a dictionary? Looking up monoid using > dictionary.com: > > An operator * and a value x form a monoid if * is > associative and x is its left and right identity. > > On the other hand, appendable doesn't seem to be a word, and while you > can infer that it means "something that can be appended to", that's only > half of the story... > > > ?Monoid isn't something I came across and didn't understand, its something I should have been using for a long time before I discovered it. But it never jumped out at me when I was browsing the library documentation tree. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/52dc8024/attachment.htm From tanimoto at arizona.edu Thu Jan 15 18:14:31 2009 From: tanimoto at arizona.edu (Paulo Tanimoto) Date: Thu Jan 15 18:05:37 2009 Subject: [Haskell-cafe] Re: Compiling regex-posix-0.93.2 on windows In-Reply-To: References: <48F912A4.9060306@list.mightyreason.com> Message-ID: Hi Chris, Good call, I'm following your advice. ghci fails to load with the package that it seemed to compile just fine. Here are some details (also see file attached). Thank you! Paulo $ wget http://hackage.haskell.org/packages/archive/regex-posix/0.93.2/regex-posix-0.93.2.tar.gz $ vim regex-posix.cabal ----------------------------------------------------------------- CC-Options: -DHAVE_REGEX_H -- Includes: Include-Dirs: f:\cygwin\usr\include -- Extra-Libraries: -- Extra-Lib-Dirs: ----------------------------------------------------------------- $ ghci -package regex-posix WARNING: GHCi invoked via 'ghci.exe' in *nix-like shells (cygwin-bash, in particular) doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper instead GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package base-3.0.3.0 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package regex-base-0.93.1 ... linking ... done. Loading package regex-posix-0.93.2 ... linking ... : unable to load package `regex-posix-0.93.2' : C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1\HSregex-posix-0.93.2.o: unknown symbol `_regerror' On Thu, Jan 15, 2009 at 4:00 PM, ChrisK wrote: > Paulo: I suggest doing this more carefully. > > Get the source from hackage. > > Edit the regex-posix.cabal file to add the include and lib directories you > need on Cygwin. > > cabal "configure" it. > > cabal "build" it. > > cabal "install" it. > > Then in an unrelated directory try and run "ghci -package regex-posix". > This should load regex-posix-VERSION. If this fails then I think that the > cabal file needs fixing. > > If that works then please test it with these commands: >> >> Prelude> :m + Text.Regex.Posix >> Prelude Text.Regex.Posix> (Text.Regex.Posix.=~) "ab" "(()|[ab])(b)" :: >> (String,String,String,[String]) > > The right answer by the way is: >> ("","ab","",["a","","b"]) > > But on FreeBSD/NetBSD/OS X there is a bug that I have found and it prints: >> ("a","b","",["","","b"]) > > Which just goes to show that a mountain of QuickCheck is what is sometimes > needed to catch really hard to trigger bugs. > > This is the other bug I reported: >> >> Prelude Text.Regex.Posix> (Text.Regex.Posix.=~) "XababaY" >> "(X)(aba|ab|b)*(Y)" :: (String,String,String,[String]) >> ("","XababaY","",["X","b","Y"]) > > The above answer is impossible (what matched "a" next to "b"?), but I now > think I know WTF the library code is doing wrong (I think it is matching > "ababa" in two passes and the second pass is greedy which is a broken > strategy). The right answer is: > >> ("","XababaY","",["X","aba","Y"]) > > Cheers, > Chris > > PS: Yes, I have reported these bug to Apple, FreeBSD, and NetBSD this month. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- A non-text attachment was scrubbed... Name: regex-posix.log Type: application/octet-stream Size: 5328 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/a7042735/regex-posix.obj From derek.a.elkins at gmail.com Thu Jan 15 18:14:36 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Thu Jan 15 18:05:53 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <79990c6b0901151004s4da9ed24ob2c646a00abb2169@mail.gmail.com> Message-ID: <1232061276.5866.3.camel@derek-laptop> Actually programming requires -far more- precision than mathematics ever has. The standards of "formal" and "precise" that mathematicians use are a joke to computer scientists and programmers. Communication is also more important or at least more center stage in mathematics than programming. Mathematical proofs are solely about communicating understanding and are not required to execute on a machine. On Thu, 2009-01-15 at 18:27 +0000, Lennart Augustsson wrote: > That's very true. But programming is one where mathematical precision > is needed, even if you want to call it something else. > > On Thu, Jan 15, 2009 at 6:04 PM, Paul Moore wrote: > > > > Mathematical precision isn't appropriate in all disciplines. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From cgibbard at gmail.com Thu Jan 15 18:16:20 2009 From: cgibbard at gmail.com (Cale Gibbard) Date: Thu Jan 15 18:07:27 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496F6128.7080108@complete.org> References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> Message-ID: <89ca3d1f0901151516i82e933fvb2ebdf1596bd67af@mail.gmail.com> > If you're learning Haskell, which communicates the idea more clearly: > > * Appendable > > or > > * Monoid > > I can immediately figure out what the first one means. With the second, > I could refer to the GHC documentation, which does not describe what a > Monoid does. Or read a wikipedia article about a branch of mathematics > and try to figure out how it applies to Haskell. However, "Appendable" carries baggage with it which is highly misleading. Consider, for instance, the monoid of rational numbers under multiplication (which, by the way, is quite useful with the writer transformed list monad for dealing with probabilities) -- you can claim that multiplication here is a sort of "appending", perhaps, but it's not really appropriate. Modular addition, or multiplication in some group is even farther from it. From cgibbard at gmail.com Thu Jan 15 18:17:31 2009 From: cgibbard at gmail.com (Cale Gibbard) Date: Thu Jan 15 18:08:37 2009 Subject: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <87ljtcpkjo.fsf@justinbogner.com> Message-ID: <89ca3d1f0901151517y52c32913h674ff2d7de0d2cc8@mail.gmail.com> Yes! The library documentation tree has a way of making everything seem equally important, when that is not the case. This is why we need well-crafted tutorials and books. 2009/1/15 David Fox : > ?Monoid isn't something I came across and didn't understand, its something I > should have been using for a long time before I discovered it. But it never > jumped out at me when I was browsing the library documentation tree. From manlio_perillo at libero.it Thu Jan 15 18:18:04 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Thu Jan 15 18:09:13 2009 Subject: [Haskell-cafe] version information in the documentation Message-ID: <496FC42C.7080002@libero.it> Hi. I'm reading the GHC documentation, in detail: http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html I have noted that there is no indication about the GHC version where an extension has been first implemented. The same with the documentation from the libraries. I think that this is an important information, and should be added. Thanks Manlio Perillo From tanimoto at arizona.edu Thu Jan 15 18:18:21 2009 From: tanimoto at arizona.edu (Paulo Tanimoto) Date: Thu Jan 15 18:09:28 2009 Subject: [Haskell-cafe] Re: Compiling regex-posix-0.93.2 on windows In-Reply-To: <1232058959.28590.383.camel@localhost> References: <48F912A4.9060306@list.mightyreason.com> <1232058959.28590.383.camel@localhost> Message-ID: Duncan, On Thu, Jan 15, 2009 at 4:35 PM, Duncan Coutts wrote: > I should note that you do not need to edit the .cabal file to do this. > As of Cabal-1.4 there are extra command line flags to configure (or > equivalently to cabal install) > > --extra-include-dirs=dir --extra-lib-dirs=dir > > Duncan Thanks, Duncan, I did notice those flags and was using them. It's a nice addition! Paulo From briqueabraque at yahoo.com Thu Jan 15 18:20:47 2009 From: briqueabraque at yahoo.com (Mauricio) Date: Thu Jan 15 18:12:04 2009 Subject: [Haskell-cafe] Re: Type errors, would extensions help? In-Reply-To: <2f9b2d30901151103n369dcaeu40256c31309ab4a3@mail.gmail.com> References: <2f9b2d30901151103n369dcaeu40256c31309ab4a3@mail.gmail.com> Message-ID: Thanks, everything works now. What should I read to better understand the difference for the type system between using <- and 'let'? That is not intuitive for me. About layout, I used to filter my code to better fit everyone taste before posting to this list. The filter stoped working due to some problems in 'Language.Haskell', but I'll rewrite it with haskell-src-exts before posting again. Thanks, Maur?cio > I suggest you start using "let" in your do blocks; both of these > problems are solvable with let. > > Binding with <- instead of "let" makes the type system work harder, > and will generally require type annotations & extensions for > polymorphic results. (...) > Also, is there a reason you hate the layout rule and are using > explicit semicolons everywhere? > >>>> I have this problem trying to define a function >>>> inside a do expression. (...) From cgibbard at gmail.com Thu Jan 15 18:21:20 2009 From: cgibbard at gmail.com (Cale Gibbard) Date: Thu Jan 15 18:12:28 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <1232061276.5866.3.camel@derek-laptop> References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <79990c6b0901151004s4da9ed24ob2c646a00abb2169@mail.gmail.com> <1232061276.5866.3.camel@derek-laptop> Message-ID: <89ca3d1f0901151521v40e9fb8p4a8d7f2c6b9cbd4e@mail.gmail.com> While you're absolutely correct and I agree with you, to be fair, essentially all mathematicians have a sense of "rigourisability" (whether they recognise it or not), which is a peculiar standard that they apply to everything they hear or read. The level of rigour at which mathematicians communicate is designed not to bore the listener with details that they could easily supply for themselves, being an intelligent mathematician, and not a mechanical abstraction. - Cale 2009/1/15 Derek Elkins : > Actually programming requires -far more- precision than mathematics ever > has. The standards of "formal" and "precise" that mathematicians use > are a joke to computer scientists and programmers. Communication is > also more important or at least more center stage in mathematics than > programming. Mathematical proofs are solely about communicating > understanding and are not required to execute on a machine. > > On Thu, 2009-01-15 at 18:27 +0000, Lennart Augustsson wrote: >> That's very true. But programming is one where mathematical precision >> is needed, even if you want to call it something else. >> >> On Thu, Jan 15, 2009 at 6:04 PM, Paul Moore wrote: >> > >> > Mathematical precision isn't appropriate in all disciplines. >> > >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dave at zednenem.com Thu Jan 15 18:21:28 2009 From: dave at zednenem.com (David Menendez) Date: Thu Jan 15 18:12:47 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496FB969.7000600@btinternet.com> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <1232051895.28590.350.camel@localhost> <496FA8DA.7050907@btinternet.com> <1232058449.28590.379.camel@localhost> <496FB969.7000600@btinternet.com> Message-ID: <49a77b7a0901151521o460c6c9u6080ff71e30514c0@mail.gmail.com> On Thu, Jan 15, 2009 at 5:32 PM, Andrew Coppin wrote: > > As an aside, the integers form two different monoids. Haskell can't [easily] > handle that. Does anybody know of a language that can? Some of the ML-derived languages can do that. Essentially, your code takes another module which implements a monoid as an argument. The catch is that you have to explicitly provide the monoid implementation in order to use your code. -- Dave Menendez From jonathanccast at fastmail.fm Thu Jan 15 18:21:11 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Jan 15 18:13:04 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <20090115221611.GA10586@hustlerturf.com> References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> <496F6ADB.5050300@complete.org> <1232056211.6800.28.camel@jcchost> <20090115221611.GA10586@hustlerturf.com> Message-ID: <1232061671.6800.53.camel@jcchost> On Thu, 2009-01-15 at 16:16 -0600, John Goerzen wrote: > On Thu, Jan 15, 2009 at 01:50:11PM -0800, Jonathan Cast wrote: > > On Thu, 2009-01-15 at 10:56 -0600, John Goerzen wrote: > > > Lennart Augustsson wrote: > > > > Most people don't understand pure functional programming either. Does > > > > that mean we should introduce unrestricted side effects in Haskell? > > > > > > The key is to introduce concepts to them in terms they can understand. > > > > > > You introduce it one way to experienced abstract mathematicians, and a > > > completely different way to experienced Perl hackers. I wouldn't expect > > > a mathematician to grok Perl, and I wouldn't expect $PERL_HACKER to grok > > > abstract math. People have different backgrounds to draw upon, and we > > > are under-serving one community. > > > > False. We are failing to meet the un-realistic expectations of advanced > > Perl/Python/Ruby/C/C++/Java/any other imperative language programmers as > > to the ease with which they should be able to learn Haskell. > > What part of that are you saying is false? That people have different > backgrouns and learn differently? Not just differently. Some people learn faster than others. These relative speeds also vary across different subjects. I think the implicit assumption in most complaints about learning Haskell is that the ease with which any given developer learns Haskell (or learns a new Haskell library or concept) should be comparable to the ease with which said developers learns conventional languages, e.g. Perl. This assumption is false. In fact, if someone finds Perl particularly easy to learn (relative to other subjects), I would expect that person to find Haskell particularly hard to learn (relative to other subjects). Of course mathematicians find Haskell easier to learn than Perl programmers do; this is a consequence of the nature of Haskell, the nature of Perl, and the nature of mathematics. We are under no obligation to obtain equivalent outcomes from non-interchangeable people. That people who lack natural aptitude, or relevant prior knowledge, for learning Haskell have more difficulty than those with relevant natural aptitude or prior knowledge is in no way a failure of the Haskell community. jcc From vanenkj at gmail.com Thu Jan 15 18:23:04 2009 From: vanenkj at gmail.com (John Van Enk) Date: Thu Jan 15 18:14:15 2009 Subject: [Haskell-cafe] F# active patterns versus GHC's view In-Reply-To: References: Message-ID: I've often thought having constructor "views" would be handy. data Foo = Foo A B C D E F G H I view Bar = (Foo A _ C _ _ _ G _ I) => Bar A C G I This does bring up problems with case alternatives though. I think the correct answer for these kinds of views is with the record pattern matching syntax, though, I wish there was a more terse way to notate it. data Foo = { a :: A, b :: B, c :: C, d :: D, e :: E, f :: F, g :: G } f (Foo {a = var_a, g = var_g}) = ... /jve 2009/1/15 Peter Verswyvelen > When I first read about active patterns in F#, I found it really cool idea, > since it allows creating fake data constructors that can be used for pattern > matching, giving many views to a single piece of data, and allowing > backwards compatibility when you completely change or hide a data structure. > So for example one could define a Polar pattern and a Rect pattern that > give different views of a Complex number, e.g (pseudo code follows) > > pattern Polar c = (mag c, phase c) > pattern Rect c = (real c, imag c) > > This seems handy: > > polarMul (Polar m1 p1) (Polar m2 p2) = mkComplexFromPolar (m1*m2) (p1+p2) > > However, I think it is flawed, since the following > > case c of > Polar _ _ -> "it's polar!" > Rect _ _ -> "it's rect!" > > seems like valid code but does not make any sense. > > So I think the GHC extension of view patterns is better than the active > patterns in F#? > > A good coding style is to provide constructor functions and hide data > constructors. But then one looses the ability to perform pattern matching, > which is so cool in Haskell. Would I have to conclude that it would be good > coding style to use view patterns as much as possible in Haskell, > creating auxiliary data constructors to expose the "public members" of the > hidden data constructors? > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/1ee13952/attachment.htm From manlio_perillo at libero.it Thu Jan 15 18:22:58 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Thu Jan 15 18:14:26 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <20090115153438.GA1340@hustlerturf.com> References: <20090115153438.GA1340@hustlerturf.com> Message-ID: <496FC552.3010107@libero.it> John Goerzen ha scritto: > Hi folks, > > Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml > hacker: > > http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/ > > It's a great post, and I encourage people to read it. I'd like to > highlight one particular paragraph: > > > One thing that does annoy me about Haskell- naming. I'm fine with current names. However I would like to see better documentation, and examples. You can't just have in the documentation: this is xxx from yyy branch of mathematics, see this paper. You should explain how (and why) to use xxx. > [...] Regards Manlio Perillo From max.rabkin at gmail.com Thu Jan 15 18:25:12 2009 From: max.rabkin at gmail.com (Max Rabkin) Date: Thu Jan 15 18:16:19 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <89ca3d1f0901151516i82e933fvb2ebdf1596bd67af@mail.gmail.com> References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <89ca3d1f0901151516i82e933fvb2ebdf1596bd67af@mail.gmail.com> Message-ID: On Thu, Jan 15, 2009 at 3:16 PM, Cale Gibbard wrote: > However, "Appendable" carries baggage with it which is highly > misleading. Consider, for instance, the monoid of rational numbers > under multiplication (which, by the way, is quite useful with the > writer transformed list monad for dealing with probabilities) -- you > can claim that multiplication here is a sort of "appending", perhaps, > but it's not really appropriate. It's rather funny that there's a mathematical sense in which all monoid operations *are* appending. The free monoid on a set has appending as its operation, and the free monoid is initial in the category of monoids on that set (by definition), so all monoid operations are appending, modulo some equivalence relation. :) --Max From lennart at augustsson.net Thu Jan 15 18:26:37 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Jan 15 18:17:43 2009 Subject: [Haskell-cafe] Re: Type errors, would extensions help? In-Reply-To: References: <2f9b2d30901151103n369dcaeu40256c31309ab4a3@mail.gmail.com> Message-ID: The <- binding is lambda binding (look at how it desugars). Lambda bindings are monomorphic without any type extensions. The monadic 'let' binding is like regular 'let', so it's a point where the type checker does generalization, and so you get (possibly) polymorphic bindings from let. -- Lennart On Thu, Jan 15, 2009 at 11:20 PM, Mauricio wrote: > Thanks, everything works now. > > What should I read to better understand the difference > for the type system between using <- and 'let'? That is > not intuitive for me. > > About layout, I used to filter my code to better fit > everyone taste before posting to this list. The filter > stoped working due to some problems in 'Language.Haskell', > but I'll rewrite it with haskell-src-exts before > posting again. > > Thanks, > Maur?cio > >> I suggest you start using "let" in your do blocks; both of these >> problems are solvable with let. > >> >> >> Binding with <- instead of "let" makes the type system work harder, >> and will generally require type annotations & extensions for >> polymorphic results. (...) > >> Also, is there a reason you hate the layout rule and are using >> explicit semicolons everywhere? >> >>>>> I have this problem trying to define a function >>>>> inside a do expression. (...) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jonathanccast at fastmail.fm Thu Jan 15 18:33:54 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Jan 15 18:25:34 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <89ca3d1f0901151516i82e933fvb2ebdf1596bd67af@mail.gmail.com> Message-ID: <1232062434.6800.57.camel@jcchost> On Thu, 2009-01-15 at 15:25 -0800, Max Rabkin wrote: > On Thu, Jan 15, 2009 at 3:16 PM, Cale Gibbard wrote: > > However, "Appendable" carries baggage with it which is highly > > misleading. Consider, for instance, the monoid of rational numbers > > under multiplication (which, by the way, is quite useful with the > > writer transformed list monad for dealing with probabilities) -- you > > can claim that multiplication here is a sort of "appending", perhaps, > > but it's not really appropriate. > > It's rather funny that there's a mathematical sense in which all > monoid operations *are* appending. The free monoid on a set has > appending as its operation, and the free monoid is initial in the > category of monoids on that set (by definition), so all monoid > operations are appending, modulo some equivalence relation. Right. So we start explaining that to new Haskellers. We already have participants in this discussion who can never quite remember where the term Monad comes from; and now we need them to remember some complicated argument about quotients of free monoids justifying the term `Append'? jcc From dan.doel at gmail.com Thu Jan 15 18:36:42 2009 From: dan.doel at gmail.com (Dan Doel) Date: Thu Jan 15 18:27:57 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <49a77b7a0901151521o460c6c9u6080ff71e30514c0@mail.gmail.com> References: <20090115153438.GA1340@hustlerturf.com> <496FB969.7000600@btinternet.com> <49a77b7a0901151521o460c6c9u6080ff71e30514c0@mail.gmail.com> Message-ID: <200901151836.43167.dan.doel@gmail.com> On Thursday 15 January 2009 6:21:28 pm David Menendez wrote: > On Thu, Jan 15, 2009 at 5:32 PM, Andrew Coppin > > wrote: > > As an aside, the integers form two different monoids. Haskell can't > > [easily] handle that. Does anybody know of a language that can? > > Some of the ML-derived languages can do that. Essentially, your code > takes another module which implements a monoid as an argument. > > The catch is that you have to explicitly provide the monoid > implementation in order to use your code. You can do that in Haskell, as well, although it will end up uglier than ML. You can write your own dictionary type: data Monoid a = Monoid { unit :: a , bin :: m -> m -> m } And pass that around: twice :: Monoid m -> m -> m twice mon m = bin mon m m And even manually simulate locally opening the dictionary with a where clause twice mon m = m ++ m where (++) = bin mon This is, after all, what GHC translates type classes into behind the scenes (although that isn't necessarily how they must be implemented). Some folks even argue that type classes are overused and this style should be significantly more common. -- Dan From sdh33 at cornell.edu Thu Jan 15 18:38:59 2009 From: sdh33 at cornell.edu (Stephen Hicks) Date: Thu Jan 15 18:30:05 2009 Subject: [Haskell-cafe] Cabal dependencies Message-ID: <50b5ae760901151538t16a35203o5b409202b9588929@mail.gmail.com> Hi, I'm having some difficulty specifying dependencies in my .cabal file for a package I'm looking to upload to hackage soon. The difficulty is as follows. I basically want to specify parsec (>= 2.1 && < 3.0.0) || (> 3.0.0 && < 4) The problem is that 3.0.0 as it exists on hackage is missing a constructor that I need (namely, Postfix, in the compatibility module). The bug was fixed and will presumably work fine if a newer version of parsec is ever uploaded to hackage, and my package works fine with older parsecs as well - I just want to exclude this one version. How can I go about doing that? A secondary question is this - I can actually compile with version 3.0.0 by just not using this constructor, although it does reduce the package's functionality. I've seen flags in various .cabal files, and presumably I could invent a flag to make it work with 3.0.0, but I'm confused about how these flags are set. Specifically, cabal-install has never asked me anything about flags, so what's the point? Or does it automatically set whichever flags satisfy the dependencies? Thanks, steve From cgibbard at gmail.com Thu Jan 15 18:41:25 2009 From: cgibbard at gmail.com (Cale Gibbard) Date: Thu Jan 15 18:32:31 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496FA8DA.7050907@btinternet.com> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <1232051895.28590.350.camel@localhost> <496FA8DA.7050907@btinternet.com> Message-ID: <89ca3d1f0901151541s53909c9csc261c9dc42579aa6@mail.gmail.com> 2009/1/15 Andrew Coppin : > OK, well then my next question would be "in what say is defining > configuration files as a monoid superior to, uh, not defining them as a > monoid?" What does it allow you to do that you couldn't otherwise? I'm not > seeing any obvious advantage, but you presumably did this for a reason... I can't speak from the perspective of the Cabal developers, but combining configurations with partial information using a monoid operation is generally a good way to structure things. Basically, this would be analogous to the way that the First monoid (or the Last monoid) works, but across a number of fields. You have an empty or default configuration which specifies nothing that serves as the identity, and then a way of layering choices together, which is the monoid operation. - Cale From steve at fenestra.com Thu Jan 15 18:50:14 2009 From: steve at fenestra.com (Steve Schafer) Date: Thu Jan 15 18:41:21 2009 Subject: Names in Haskell (Was: [Haskell-cafe] Comments from OCaml HackerBr ian Hurt) In-Reply-To: References: Message-ID: On Thu, 15 Jan 2009 17:16:04 -0500 (EST), you wrote: >What I don't understand is why Monoid and Monad are objectionable, while >Hash, Vector, Boolean, and Integer are (presumably) not objectionable. >They all appear equally technical to me. I think the name issue is a red herring. The real issue is that, after being confronted by a concept with an unfamiliar name, it can be very difficult to figure out the nature of the concept. That is, it's not the name itself that's the problem, it's the fact that trying to understand what it means often leads you on an interminable Alice-in-Wonderland-esque journey that never seems to get anywhere. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ From ryani.spam at gmail.com Thu Jan 15 18:52:04 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Jan 15 18:43:11 2009 Subject: [Haskell-cafe] How to simplify this code? In-Reply-To: <3e62d4360901151114l1c7442fob8f35410c88f8162@mail.gmail.com> References: <3e62d4360901151114l1c7442fob8f35410c88f8162@mail.gmail.com> Message-ID: <2f9b2d30901151552pf2bc431m4cfbe3b87cf59f57@mail.gmail.com> Here's a series of refactorings that I feel gets to the essence of the code. For reference, here's the original. > add :: JSON a => MyData -> String -> a -> MyData > add m k v = fromJust $ (return $ json m) >>= jsObj >>= (return . > fromJSObject) >>= (return . ((k, showJSON v):)) >>= (return . > toJSObject) >>= (return . showJSON) >>= \js -> (return $ m { json = js > }) -- turn into do notation add :: JSON a => MyData -> String -> a -> MyData add m k v = fromJust $ do t1 <- return $ json m t2 <- jsObj t1 t3 <- return $ fromJSObject t2 t4 <- return ( (k, showJSON v) : t3 ) t5 <- return $ toJSObject t4 js <- return $ showJSON t5 t6 <- return $ m { json = js } return t6 -- replace "var <- return exp" with "let var = exp" add :: JSON a => MyData -> String -> a -> MyData add m k v = fromJust $ do let t1 = json m t2 <- jsObj t1 let t3 = fromJSObject t2 let t4 = (k, showJSON v) : t3 let t5 = toJSObject t4 let js = showJSON t5 let t6 = m { json = js } return t6 -- inline some small definitions add m k v = fromJust $ do t2 <- jsObj (json m) let js = showJSON $ toJSObject ((k, showJSON v) : fromJSObject t2) let t6 = m { json = js } return t6 -- there's only one real "Maybe" object in here, and we fromJust afterwards, -- so put the "can't fail" assumption in the right place. -- -- This is the only refactoring that I felt was at all "tricky" to figure out. add m k v = let t2 = fromJust $ jsObj (json m) js = showJSON $ toJSObject ((k, showJSON v) : fromJSObject t2) t6 = m { json = js } in t6 -- sugar let, inline t6 add m k v = m { json = js } where t2 = fromJust $ jsObj (json m) js = showJSON $ toJSObject ((k, showJSON v) : fromJSObject t2) -- inline t2 add m k v = m { json = js } where js = showJSON $ toJSObject ((k, showJSON v) : fromJSObject (fromJust $ jsObj (json m))) -- uninline dictionary entry add m k v = m { json = js } where js = showJSON $ toJSObject (newEntry : fromJSObject (fromJust $ jsObj (json m))) newEntry = (k, showJSON v) -- factor out modification modifyJSON f m = m { json = f (json m) } add m k v = modifyJson go m where go js = showJSON $ toJSObject (newEntry : fromJSObject (fromJust $ jsObj js)) newEntry = (k, showJSON v) -- turn into pipeline modifyJSON f m = m { json = f (json m) } add m k v = modifyJSON go m where go js = showJSON $ toJSObject $ (newEntry :) $ fromJSObject $ fromJust $ jsObj js newEntry = (k, showJSON v) -- pointless modifyJSON f m = m { json = f (json m) } add m k v = modifyJSON go m where go = showJSON . toJSObject . (newEntry :) . fromJSObject . fromJust . jsObj newEntry = (k, showJSON v) Final result: > modifyJSON f m = m { json = f (json m) } > > add m k v = modifyJSON go m where > go = showJSON . toJSObject . (newEntry :) . fromJSObject . fromJust . jsObj > newEntry = (k, showJSON v) Some stylistic choices are debatable (pointless vs. not, inline vs. not), but I think this is a lot more readable than the >>= and liftM madness you had going. I also might refactor the (fromJSObject --> some transformation --> toJSObject) path; this seems like a fundamental operation on "MyData", but I don't know enough about the library you are using to suggest the direction to go with this. -- ryan On Thu, Jan 15, 2009 at 11:14 AM, Levi Greenspan wrote: > Dear list members, > > I started looking into monadic programming in Haskell and I have some > difficulties to come up with code that is concise, easy to read and > easy on the eyes. In particular I would like to have a function "add" > with following type signature: JSON a => MyData -> String -> a -> > MyData. MyData holds a JSValue and add should add a key and a value to > this JSON object. here is what I came up with and I am far from > satisfied. Maybe someone can help me to simplify this... > > module Test where > > import Text.JSON > import Data.Maybe (isJust, fromJust) > import Control.Monad > > data MyData = MyData { json :: JSValue } deriving (Read, Show) > > jsObj :: JSValue -> Maybe (JSObject JSValue) > jsObj (JSObject o) = Just o > jsObj _ = Nothing > > add :: JSON a => MyData -> String -> a -> MyData > add m k v = fromJust $ (return $ json m) >>= jsObj >>= (return . > fromJSObject) >>= (return . ((k, showJSON v):)) >>= (return . > toJSObject) >>= (return . showJSON) >>= \js -> (return $ m { json = js > }) > > add2 :: JSON a => MyData -> String -> a -> MyData > add2 m k v = fromJust $ (\js -> m { json = js }) `liftM` (showJSON > `liftM` (toJSObject `liftM` (((k, showJSON v):) `liftM` (fromJSObject > `liftM` (jsObj $ json m))))) > > add3 :: JSON a => MyData -> String -> a -> MyData > add3 = undefined -- How to simplify add? > > > What the code essentially does is that using functions from Text.JSON, > it gets the list of key-value pairs and conses another pair to it > before wrapping it again in the JSValue-Type. > > Many thanks, > Levi > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From haskell at list.mightyreason.com Thu Jan 15 18:54:09 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Thu Jan 15 18:45:24 2009 Subject: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt In-Reply-To: <4c44d90b0901151359h708b3980t912f51d847bb598c@mail.gmail.com> References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCB01@ELON17P32001A.csfb.cs-group.com> <1232056303.6800.31.camel@jcchost> <4c44d90b0901151359h708b3980t912f51d847bb598c@mail.gmail.com> Message-ID: Thomas DuBuisson wrote: >> How does forcing them to learn proposed terminology such as `Appendable' >> help here? Learners of Haskell do still need to learn what the new word >> means. > > The contention is that 'Appendable' is an intuitive naming that people > will already have a rudimentary grasp of. This as opposed to Monoid, > which absolutely requires looking up for the average coder. Intuition tells me: * 'Appendable' add an element to the back of a (finite) linear collection. * There is a 'Prependable' somewhere that add the element to the front. * There is an inverse 'pop' or 'deque' operation nearby. Absolutely none of those things are true. Let's try for 'Mergeable' * mconcat joins two collections, not a collection and an element. * Is should be a split operation. The above is true for the list instance, but false in general. Look at the instances already given that violate the "collection" idea: > Monoid Any > Monoid All > Monoid (Last a) > Monoid (First a) > Num a => Monoid (Product a) > Num a => Monoid (Sum a) And I don't even see an (Ord a)=>(Max a) or a Min instance. So the original article, which coined 'Appendable', did so without much thought in the middle of a long post. But it does show the thinking was about collections and there is one ONE instance of Monoid at http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html#t%3AMonoid that is about a collection (Monoid ([] a)) that has a split operation. ONE. From claus.reinke at talk21.com Thu Jan 15 18:58:45 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Jan 15 18:49:57 2009 Subject: Names in Haskell (Was: [Haskell-cafe] Comments from OCamlHacker Brian Hurt) References: <1232059180.28590.388.camel@localhost> Message-ID: >> What I don't understand is why Monoid and Monad are objectionable, while >> Hash, Vector, Boolean, and Integer are (presumably) not objectionable. >> They all appear equally technical to me. > > It's simply that other languages' libraries already have those terms in > them. So there is nothing new to learn. 1. Imagine learning English. Easy, everyone here has been there, done that. 2. Imagine learning English as a second language. Slightly different: a. you can use an English-native language dictionary. won't get you all the way, but is fairly essential for beginners. b. you can use an English-English dictionary. once you know enough of the language to "bootstrap", this is preferred over (a), as it helps to get familiar with the language, and to improve your autonomy every time you need to look something up (instead of clinging to the crutches of translation). c. you can use an English-GOB (General Ontology Base) dictionary. languages are just syntax. understand the principles behind them! can be really useful, but probably not when you're still learning your second language, knowing neither English nor GOB. once you've seen at least two examples of everything, and know enough to read about generalizations, the situation changes. Does this help?-) Claus From ryani.spam at gmail.com Thu Jan 15 19:02:32 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Jan 15 18:53:37 2009 Subject: [Haskell-cafe] Re: Type errors, would extensions help? In-Reply-To: References: <2f9b2d30901151103n369dcaeu40256c31309ab4a3@mail.gmail.com> Message-ID: <2f9b2d30901151602g5fce43maef8f44852ac83ce@mail.gmail.com> Here's the desugaring: > do { pattern <- expression ; rest } desugars to > expression >>= \temp -> case temp of > pattern -> do { rest } > _ -> fail "Pattern match failure" (where "temp" is a fresh variable not used elsewhere, and the failure message usually includes source position) Whereas > do { let pattern = expression ; rest } desugars to > let pattern = expression in do { rest } -- ryan On Thu, Jan 15, 2009 at 3:26 PM, Lennart Augustsson wrote: > The <- binding is lambda binding (look at how it desugars). Lambda > bindings are monomorphic without any type extensions. The monadic > 'let' binding is like regular 'let', so it's a point where the type > checker does generalization, and so you get (possibly) polymorphic > bindings from let. > > -- Lennart > > On Thu, Jan 15, 2009 at 11:20 PM, Mauricio wrote: >> Thanks, everything works now. >> >> What should I read to better understand the difference >> for the type system between using <- and 'let'? That is >> not intuitive for me. >> >> About layout, I used to filter my code to better fit >> everyone taste before posting to this list. The filter >> stoped working due to some problems in 'Language.Haskell', >> but I'll rewrite it with haskell-src-exts before >> posting again. >> >> Thanks, >> Maur?cio >> >>> I suggest you start using "let" in your do blocks; both of these >>> problems are solvable with let. >> >>> >>> >>> Binding with <- instead of "let" makes the type system work harder, >>> and will generally require type annotations & extensions for >>> polymorphic results. (...) >> >>> Also, is there a reason you hate the layout rule and are using >>> explicit semicolons everywhere? >>> >>>>>> I have this problem trying to define a function >>>>>> inside a do expression. (...) >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From vigalchin at gmail.com Thu Jan 15 19:15:14 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Jan 15 19:06:21 2009 Subject: [Haskell-cafe] GHCi debugger question Message-ID: <5ae4f2ba0901151615n6b5e9844l67f7a86db670e3d1@mail.gmail.com> Hello, I have a collection of functions .. but no "main" function. I am reading "Step Inside the GHCi debugger" from Monad.Reader Issue 10 by Bernie Pope. If I don't have a "main" function can I still use the ghci debugger? (I tried to set a breakpoint on one of my functions but it didn't work). Regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/63ea50bd/attachment.htm From derek.a.elkins at gmail.com Thu Jan 15 19:17:15 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Thu Jan 15 19:08:32 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <20090115201140.GA7325@hustlerturf.com> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <20090115201140.GA7325@hustlerturf.com> Message-ID: <1232065035.5866.34.camel@derek-laptop> On Thu, 2009-01-15 at 14:11 -0600, John Goerzen wrote: > On Thu, Jan 15, 2009 at 07:46:02PM +0000, Andrew Coppin wrote: > > John Goerzen wrote: > > > > If we *must* insist on using the most obscure possible name for > > everything, can we at least write some documentation that doesn't > > require a PhD to comprehend?? (Anybody who attempts to argue that > > "monoid" is not actually an obscure term has clearly lost contact with > > the real world.) > > Several people have suggested this, and I think it would go a long way > towards solving the problem. The problem is: this documentation can > really only be written by those that understand the concepts, > understand how they are used practically, and have the time and > inclination to submit patches. Experience suggests there may be no > such people out there :-) > > > As somebody else said, it basically comes down to this: Who the hell is > > Haskell actually "for"? If it's seriously intended to be used by > > programmers, things need to change. And if things aren't going to > > change, then let's all stop pretending that Haskell actually cares about > > real programmers. > > It might surprise you to see me say this, but I don't see this > discussion as necessarily a weakness. I know of no other language > community out there that has such a strong participation of both > academics and applied users. This is a great strength. And, of > course, Haskell's roots are firmly in academia. > > I think there there is a ton of interest in Haskell from the, ahem, > "real world" programmer types. In fact, it seems to me that's where > Haskell's recent growth has been. There are a lot of things showing > up on Hackage relating to networking, Unicode encoding, databases, web > apps, and the like. > > The nice thing about Haskell is that you get to put the theory in > front of a lot of people that would like to use it to solve immediate > programming problems. But they will only use it if you can explain it > in terms they understand. There are plenty of "real world" programmer types who are using these scarily named things, Monoid, Monad, Functor, Existential Quantification. Programmers such as you*. Despite poor documentation, which everyone agrees could be improved, they've somehow managed to understand these things anyway. My impression is that to most of them Monoids, Functors, and Monads are Just Another Interface and Existential Quantification is Just Another Language Feature. There are poorly documented interfaces in every language**. Any "real world" programmer has some (plenty...) of experience dealing with this issue. These programmers do what they need to do to get stuff done. Again, somehow they learn how to use these things without waiting for "us" to provide an "explanation" in "terms they can understand;" too busy trying to get stuff done. > > There are a number of efforts in that direction: various websites, > articles, books, libraries, etc. And I think the efforts are > succeeding. But that doesn't mean there is no room for improvement. No one doubts that there is room for improvement. However, the direction is better documentation, not different names. Better names is fine, but I have not heard any remotely convincing alternative for any of the above terms. * Or me for that matter. I'm not an academic now and certainly wasn't when I started learning Haskell. I didn't know what a monoid was, had never heard of category theory or monads or functors. I was using monads and functors and monoids in less than a month after I started using Haskell. ** Heck, papers and decades worth of mathematical texts at almost every level is a heck of a lot more documentation than most "poorly documented" interfaces have. From derek.a.elkins at gmail.com Thu Jan 15 19:28:50 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Thu Jan 15 19:20:02 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <4c44d90b0901151359h708b3980t912f51d847bb598c@mail.gmail.com> References: <20090115153438.GA1340@hustlerturf.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCAFF@ELON17P32001A.csfb.cs-group.com> <4c44d90b0901150822q3201ad1bn12bcd5bc4125aaae@mail.gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCB01@ELON17P32001A.csfb.cs-group.com> <1232056303.6800.31.camel@jcchost> <4c44d90b0901151359h708b3980t912f51d847bb598c@mail.gmail.com> Message-ID: <1232065730.5866.43.camel@derek-laptop> On Thu, 2009-01-15 at 21:59 +0000, Thomas DuBuisson wrote: > > How does forcing them to learn proposed terminology such as `Appendable' > > help here? Learners of Haskell do still need to learn what the new word > > means. > > The contention is that 'Appendable' is an intuitive naming that people > will already have a rudimentary grasp of. This as opposed to Monoid, > which absolutely requires looking up for the average coder. In programming, -every- name requires looking up or some other way of checking meaning. Other than perhaps arithmetic operators (and I have had that bite me), I have -never- in any language written code using a name without having some assurance that it actually meant what I thought it meant. Usually you have to "look something up" to even know a name exists no matter how "intuitive" it turns out to be. From derek.a.elkins at gmail.com Thu Jan 15 19:55:45 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Thu Jan 15 19:46:59 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <89ca3d1f0901151521v40e9fb8p4a8d7f2c6b9cbd4e@mail.gmail.com> References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <79990c6b0901151004s4da9ed24ob2c646a00abb2169@mail.gmail.com> <1232061276.5866.3.camel@derek-laptop> <89ca3d1f0901151521v40e9fb8p4a8d7f2c6b9cbd4e@mail.gmail.com> Message-ID: <1232067345.5866.50.camel@derek-laptop> On Thu, 2009-01-15 at 18:21 -0500, Cale Gibbard wrote: > While you're absolutely correct and I agree with you, to be fair, > essentially all mathematicians have a sense of "rigourisability" > (whether they recognise it or not), which is a peculiar standard that > they apply to everything they hear or read. The level of rigour at > which mathematicians communicate is designed not to bore the listener > with details that they could easily supply for themselves, being an > intelligent mathematician, and not a mechanical abstraction. Indeed. One way to describe "rigorizable" is that it is (ideally) just enough precision to be unambiguous. Programmers don't have that luxury and thus clarity and hence communication suffer, which was exactly my point. From phercek at gmail.com Thu Jan 15 19:57:25 2009 From: phercek at gmail.com (Peter Hercek) Date: Thu Jan 15 19:48:49 2009 Subject: [Haskell-cafe] Re: GHCi debugger question In-Reply-To: <5ae4f2ba0901151615n6b5e9844l67f7a86db670e3d1@mail.gmail.com> References: <5ae4f2ba0901151615n6b5e9844l67f7a86db670e3d1@mail.gmail.com> Message-ID: Galchin, Vasili wrote: > I have a collection of functions .. but no "main" function. I am > reading "Step Inside the GHCi debugger" from Monad.Reader Issue 10 by > Bernie Pope. If I don't have a "main" function can I still use the ghci > debugger? (I tried to set a breakpoint on one of my functions but it > didn't work). It does not matter you do not have main function, just start debugging whatever function you have e.g. by: :step ... Setting breakpoints works too without main. Actually, I'm aware only of one thing which does not work without main. It is :main command. But that command does not seem to do much, looks like it only sets program arguments and calls main. Peter. From es at ertes.de Thu Jan 15 20:03:52 2009 From: es at ertes.de (Ertugrul Soeylemez) Date: Thu Jan 15 19:55:15 2009 Subject: [Haskell-cafe] Re: Monads aren't evil? I think they are. References: <20090108231652.24b75fe3@tritium.xx> <20090111111016.492d7dc9@tritium.xx> Message-ID: <20090116020352.129ae857@tritium.xx> "Apfelmus, Heinrich" wrote: > [...] but this is very different from using a particular monad like > the state monad and hoping that using it somehow gives an insight into > the problem domain. You're right, mostly. However, there are a lot of problems, where you cannot provide any useful abstraction, or the abstraction would destroy the convenience and clarity of expressing the problem as something as simple as a stateful computation. The 'insight' into a problem often comes from expressing its solution, not the problem itself. Please consider that I'm talking about real-world applications, so my problems are things like internal database servers. Of course, there may be better ways to model such a thing, but a 'StateT (Map a b) IO' computation is the way to go for someone, who wants to get the job done rather than doing research, and in fact I think this is a very beautiful and elegant approach exploiting Haskell's (or at least GHC's) great RTS features. Greets, Ertugrul. -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/ From andy at adradh.org.uk Thu Jan 15 20:17:03 2009 From: andy at adradh.org.uk (andy morris) Date: Thu Jan 15 20:08:09 2009 Subject: [Haskell-cafe] F# active patterns versus GHC's view In-Reply-To: References: Message-ID: If you don't mind using GHC extensions (which in a view pattern thread probably isn't much of a stretch to assume :) ), there's always record punning (-XNamedFieldPuns): data Foo = { [snip] } f (Foo { a, g }) = ... 2009/1/15 John Van Enk : > I've often thought having constructor "views" would be handy. > data Foo = Foo A B C D E F G H I > view Bar = (Foo A _ C _ _ _ G _ I) => Bar A C G I > This does bring up problems with case alternatives though. > I think the correct answer for these kinds of views is with the record > pattern matching syntax, though, I wish there was a more terse way to notate > it. > data Foo = { > a :: A, > b :: B, > c :: C, > d :: D, > e :: E, > f :: F, > g :: G > } > f (Foo {a = var_a, g = var_g}) = ... > /jve > > > 2009/1/15 Peter Verswyvelen >> >> When I first read about active patterns in F#, I found it really cool >> idea, since it allows creating fake data constructors that can be used for >> pattern matching, giving many views to a single piece of data, and allowing >> backwards compatibility when you completely change or hide a data structure. >> So for example one could define a Polar pattern and a Rect pattern that >> give different views of a Complex number, e.g (pseudo code follows) >> pattern Polar c = (mag c, phase c) >> pattern Rect c = (real c, imag c) >> This seems handy: >> polarMul (Polar m1 p1) (Polar m2 p2) = mkComplexFromPolar (m1*m2) (p1+p2) >> However, I think it is flawed, since the following >> case c of >> Polar _ _ -> "it's polar!" >> Rect _ _ -> "it's rect!" >> seems like valid code but does not make any sense. >> So I think the GHC extension of view patterns is better than the active >> patterns in F#? >> A good coding style is to provide constructor functions and hide data >> constructors. But then one looses the ability to perform pattern matching, >> which is so cool in Haskell. Would I have to conclude that it would be good >> coding style to use view patterns as much as possible in Haskell, >> creating auxiliary data constructors to expose the "public members" of the >> hidden data constructors? >> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From derek.a.elkins at gmail.com Thu Jan 15 20:21:06 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Thu Jan 15 20:12:23 2009 Subject: Names in Haskell (Was: [Haskell-cafe] Comments from OCaml HackerBr ian Hurt) In-Reply-To: References: Message-ID: <1232068866.5866.60.camel@derek-laptop> On Thu, 2009-01-15 at 18:50 -0500, Steve Schafer wrote: > On Thu, 15 Jan 2009 17:16:04 -0500 (EST), you wrote: > > >What I don't understand is why Monoid and Monad are objectionable, while > >Hash, Vector, Boolean, and Integer are (presumably) not objectionable. > >They all appear equally technical to me. > > I think the name issue is a red herring. The real issue is that, after > being confronted by a concept with an unfamiliar name, it can be very > difficult to figure out the nature of the concept. That is, it's not the > name itself that's the problem, it's the fact that trying to understand > what it means often leads you on an interminable > Alice-in-Wonderland-esque journey that never seems to get anywhere. I agree with interminable but certainly you go somewhere. A lot of people like Haskell for this property. "How do you know that a monoid action is isomorphic to a monoid homomorphism into an endomorphism monoid?" "Well, I was trying to append two lists in Haskell..." For an actual interminable Alice-in-Wonderland-esque journey that never seems to get anywhere, try to write C# programs that inter-operate with Microsoft Office. From lrpalmer at gmail.com Thu Jan 15 20:28:57 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Jan 15 20:20:04 2009 Subject: [Haskell-cafe] Multiple State Monads In-Reply-To: References: <7ca3f0160901131708p4211c1eay34a0dfdb3d8177e@mail.gmail.com> Message-ID: <7ca3f0160901151728y6d3ad668rf46a9c158eded6d5@mail.gmail.com> On Thu, Jan 15, 2009 at 3:34 PM, Phil wrote: > On 14/01/2009 01:08, "Luke Palmer" wrote: > > On Tue, Jan 13, 2009 at 5:45 PM, Phil wrote: > > mcSimulate :: Double -> Double -> Word64 -> [Dou > ble] > mcSimulate startStock endTime seedForSeed = fst expiryStock : mcSimulate > startStock endTime newSeedForSeed > > It is abundantly clear that the startStock and endTime are just being > passed around from call to call unchanged ? that is their value is constant > throughout the the simulation. For the purposes here when I'm only passing > 2 'constants' around it doesn't strike me as too odd, but my list of > 'constants' is likely to grow as I bolt more functionality onto this. For > readability, I understand that I can create new types to encapsulate complex > data types into a single type , but I can't help thinking that passing say 9 > or 10 'constants' around and around like this 'feels wrong'. If I sit back > and think about it, it doesn't strike me as implausible that the compiler > will recognize what I'm doing and optimize this out for me, and what I'm > doing is thinking about the whole think like a C++ programmer (which I > traditionally am) would. > > > You can factor out constants in a couple ways. If you are just passing > constants between a recursive call to the same function, you can factor out > the recursive bit into a separate function: > > something param1 param2 = go > where > go = ... param1 ... param2 ... etc ... go ... > etc = ... > > Where go takes only the parameters that change, and the rest is handled by > its enclosing scope. You might buy a little performance this way too, > depending on the compiler's cleverness (I'm not sure how it optimizes these > things). > > > [PHIL] > Firstly ? thanks for your advice. > > When I say constants, I should be clear ? these are parameters passed in by > the user, but they remain constant throughout the recursive call. I think > the example above is only relevant if they are constants at compile time? > If not I'm not sure I follow the example. If we have something like > > mcSimulate :: Double -> Double -> Word64 -> [Double] > mcSimulate startStock endTime seedForSeed = fst expiryStock : mcSimulate > startStock endTime newSeedForSeed > where > expiryStock = iterate evolveUnderlying (startStock, ranq1Init > seedForSeed) !! truncate (endTime/timeStep) > newSeedForSeed = seedForSeed + 246524 > > Here startStock and endTime are not altered from iteration to iteration, > but they are not known at compile time. I see that I can reduce this to > something like > > test seedForSeed = fst expiryStock : test newSeedForSeed > where > expiryStock = iterate evolveUnderlying (_startStock, ranq1Init > seedForSeed) !! truncate (_endTime/timeStep) > newSeedForSeed = seedForSeed + 246524 > > But don't understand how I 'feed' the _startStock and _endTime in? > > Could you explain this in detail, or confirm my suspicions that it only > works for compile-time constants? > > Compile-time constants could be handled by simple top-level bindings. This technique is specifically for the case you are after: mcSimulate :: Double -> Double -> Word64 -> [Double] mcSimulate startStock endTime seedForSeed = go seedForSeed where go = fst expiryStock : go newSeedForSeed where expiryStock = iterate evolveUnderlying (startStock, ranq1Init seedForSeed) !! truncate (endTime/timeStep) newSeedForSeed = seedForSeed + 246524 See what's going on there? I don't know about that nested where. In Real Life I would probably use a let instead for expiryStock and newSeedForSeed. Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/cc27306f/attachment.htm From eyal.lotem at gmail.com Thu Jan 15 20:30:52 2009 From: eyal.lotem at gmail.com (eyal.lotem@gmail.com) Date: Thu Jan 15 20:21:57 2009 Subject: [Haskell-cafe] Re: How to simplify this code? In-Reply-To: <2f9b2d30901151552pf2bc431m4cfbe3b87cf59f57@mail.gmail.com> References: <3e62d4360901151114l1c7442fob8f35410c88f8162@mail.gmail.com> <2f9b2d30901151552pf2bc431m4cfbe3b87cf59f57@mail.gmail.com> Message-ID: Very nice series of refactorings! I'd like to add that it might be a better argument order to replace: JSON a => MyData -> String -> a -> MyData with: JSON a => String -> a -> MyData -> MyData Just so you can get a (MyData -> MyData) transformer, which is often useful. Eyal On Jan 16, 1:52?am, "Ryan Ingram" wrote: > Here's a series of refactorings that I feel gets to the essence of the code. > > For reference, here's the original. > > > add :: JSON a => MyData -> String -> a -> MyData > > add m k v = fromJust $ (return $ json m) >>= jsObj >>= (return . > > fromJSObject) >>= (return . ((k, showJSON v):)) >>= (return . > > toJSObject) >>= (return . showJSON) >>= \js -> (return $ m { json = js > > }) > > -- turn into do notation > add :: JSON a => MyData -> String -> a -> MyData > add m k v = fromJust $ do > ? ? ? ? t1 <- return $ json m > ? ? ? ? t2 <- jsObj t1 > ? ? ? ? t3 <- return $ fromJSObject t2 > ? ? ? ? t4 <- return ( (k, showJSON v) : t3 ) > ? ? ? ? t5 <- return $ toJSObject t4 > ? ? ? ? js <- return $ showJSON t5 > ? ? ? ? t6 <- return $ m { json = js } > ? ? ? ? return t6 > > -- replace "var <- return exp" with "let var = exp" > add :: JSON a => MyData -> String -> a -> MyData > add m k v = fromJust $ do > ? ? ? ? let t1 = json m > ? ? ? ? t2 <- jsObj t1 > ? ? ? ? let t3 = fromJSObject t2 > ? ? ? ? let t4 = (k, showJSON v) : t3 > ? ? ? ? let t5 = toJSObject t4 > ? ? ? ? let js = showJSON t5 > ? ? ? ? let t6 = m { json = js } > ? ? ? ? return t6 > > -- inline some small definitions > add m k v = fromJust $ do > ? ? ? ? t2 <- jsObj (json m) > ? ? ? ? let js = showJSON $ toJSObject ((k, showJSON v) : fromJSObject t2) > ? ? ? ? let t6 = m { json = js } > ? ? ? ? return t6 > > -- there's only one real "Maybe" object in here, and we fromJust afterwards, > -- so put the "can't fail" assumption in the right place. > -- > -- This is the only refactoring that I felt was at all "tricky" to figure out. > add m k v = > ? ? ? ? let t2 = fromJust $ jsObj (json m) > ? ? ? ? ? ? js = showJSON $ toJSObject ((k, showJSON v) : fromJSObject t2) > ? ? ? ? ? ? t6 = m { json = js } > ? ? ? ? in t6 > > -- sugar let, inline t6 > add m k v = m { json = js } where > ? ? t2 = fromJust $ jsObj (json m) > ? ? js = showJSON $ toJSObject ((k, showJSON v) : fromJSObject t2) > > -- inline t2 > add m k v = m { json = js } where > ? ? js = showJSON $ toJSObject ((k, showJSON v) : fromJSObject > (fromJust $ jsObj (json m))) > > -- uninline dictionary entry > add m k v = m { json = js } where > ? ? js = showJSON $ toJSObject (newEntry : fromJSObject (fromJust $ > jsObj (json m))) > ? ? newEntry = (k, showJSON v) > > -- factor out modification > modifyJSON f m = m { json = f (json m) } > add m k v = modifyJson go m where > ? ? go js = showJSON $ toJSObject (newEntry : fromJSObject (fromJust $ > jsObj js)) > ? ? newEntry = (k, showJSON v) > > -- turn into pipeline > modifyJSON f m = m { json = f (json m) } > add m k v = modifyJSON go m where > ? ? go js = showJSON $ toJSObject $ (newEntry :) $ fromJSObject $ > fromJust $ jsObj js > ? ? newEntry = (k, showJSON v) > > -- pointless > modifyJSON f m = m { json = f (json m) } > add m k v = modifyJSON go m where > ? ? go = showJSON . toJSObject . (newEntry :) . fromJSObject . fromJust . jsObj > ? ? newEntry = (k, showJSON v) > > Final result: > > > modifyJSON f m = m { json = f (json m) } > > > add m k v = modifyJSON go m where > > ? ? go = showJSON . toJSObject . (newEntry :) . fromJSObject . fromJust . jsObj > > ? ? newEntry = (k, showJSON v) > > Some stylistic choices are debatable (pointless vs. not, inline vs. > not), but I think this is a lot more readable than the >>= and liftM > madness you had going. > > I also might refactor the (fromJSObject --> some transformation --> > toJSObject) path; this seems like a fundamental operation on "MyData", > but I don't know enough about the library you are using to suggest the > direction to go with this. > > ? -- ryan > > On Thu, Jan 15, 2009 at 11:14 AM, Levi Greenspan > > wrote: > > Dear list members, > > > I started looking into monadic programming in Haskell and I have some > > difficulties to come up with code that is concise, easy to read and > > easy on the eyes. In particular I would like to have a function "add" > > with following type signature: JSON a => MyData -> String -> a -> > > MyData. MyData holds a JSValue and add should add a key and a value to > > this JSON object. here is what I came up with and I am far from > > satisfied. Maybe someone can help me to simplify this... > > > module Test where > > > import Text.JSON > > import Data.Maybe (isJust, fromJust) > > import Control.Monad > > > data MyData = MyData { json :: JSValue } deriving (Read, Show) > > > jsObj :: JSValue -> Maybe (JSObject JSValue) > > jsObj (JSObject o) = Just o > > jsObj _ = Nothing > > > add :: JSON a => MyData -> String -> a -> MyData > > add m k v = fromJust $ (return $ json m) >>= jsObj >>= (return . > > fromJSObject) >>= (return . ((k, showJSON v):)) >>= (return . > > toJSObject) >>= (return . showJSON) >>= \js -> (return $ m { json = js > > }) > > > add2 :: JSON a => MyData -> String -> a -> MyData > > add2 m k v = fromJust $ (\js -> m { json = js }) `liftM` (showJSON > > `liftM` (toJSObject `liftM` (((k, showJSON v):) `liftM` (fromJSObject > > `liftM` (jsObj $ json m))))) > > > add3 :: JSON a => MyData -> String -> a -> MyData > > add3 = undefined -- How to simplify add? > > > What the code essentially does is that using functions from Text.JSON, > > it gets the list of key-value pairs and conses another pair to it > > before wrapping it again in the JSValue-Type. > > > Many thanks, > > Levi > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-C...@haskell.org > >http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-C...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe From lrpalmer at gmail.com Thu Jan 15 20:31:57 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Jan 15 20:23:02 2009 Subject: [Haskell-cafe] F# active patterns versus GHC's view In-Reply-To: References: Message-ID: <7ca3f0160901151731u7d4e831bh35d0617a2ca068d2@mail.gmail.com> 2009/1/15 Peter Verswyvelen > When I first read about active patterns in F#, I found it really cool idea, > since it allows creating fake data constructors that can be used for pattern > matching, giving many views to a single piece of data, and allowing > backwards compatibility when you completely change or hide a data structure. > So for example one could define a Polar pattern and a Rect pattern that > give different views of a Complex number, e.g (pseudo code follows) > > pattern Polar c = (mag c, phase c) > pattern Rect c = (real c, imag c) > > This seems handy: > > polarMul (Polar m1 p1) (Polar m2 p2) = mkComplexFromPolar (m1*m2) (p1+p2) > > However, I think it is flawed, since the following > > case c of > Polar _ _ -> "it's polar!" > Rect _ _ -> "it's rect!" > > seems like valid code but does not make any sense. > I think it's okay, given that we understand the meanings involved. To me it makes about as much sense as this; case c of x -> "it's x!" y -> "it's y!" Which is just wrong code. Maybe the capital letters on Polar and Rect are the confusing bit? Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/42d82b06/attachment.htm From jwlato at gmail.com Thu Jan 15 20:36:11 2009 From: jwlato at gmail.com (John Lato) Date: Thu Jan 15 20:27:17 2009 Subject: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt Message-ID: <9979e72e0901151736n3eba97efq3c23f254fe0949a9@mail.gmail.com> Manlio Perillo wrote: > > I'm fine with current names. > > However I would like to see better documentation, and examples. > > You can't just have in the documentation: > this is xxx from yyy branch of mathematics, see this paper. > > You should explain how (and why) to use xxx. > Absolutely this! I would rather have to look up Monoid than see Appendable used for operations that don't fit my notion of appending. I don't care much what things are called as long as it's accurate. Even so, I typically find Haskell's documentation to be not very helpful, because it's aimed towards category theorists. That is, Haskell documentation often seems to take the approach "The reader is familiar with [branch of abstract mathematics], so knows all these concepts. The job of the documentation is to show how standard terminology from [branch of abstract math] is written in Haskell". The problem with this is that most people aren't familiar with general abstract nonsense, and this documentation is useless for those, i.e. most, people. In fact, most people don't care about how abstract nonsense is written in Haskell. They care about solving their particular problems, and are only interested in abstract nonsense to the sense that it can be useful in solving those problems. Overwhelmingly the documentation does not show how particular concepts apply to actual programming problems, or any concrete problems at all. Here is the current complete documentation for Data.Monoid 'mappend', which happens to be a good example of which I speak: An associative operation That could mean anything. There are lots of associative operations. Should I believe the name that somehow this operation is append-like? If so, and I'm using a list instance, where are items appended to? Is it an append onto the tail of the list, or is it really a cons? I would expect the documentation to cover this, but it doesn't. Far too often the documentation fails to provide this sort of useful, practical information. This is the problem faced by an abstract-nonsense unaware user: I want to accomplish [some task]. Some blogger wrote that [monoids, functors, arrows, etc.] provide a good solution. But when I look up [monoids, functors, etc.] in [some academic paper], it doesn't show how these concepts apply to the problem at hand, or indeed any programming problem at all. In fact, I can't even understand what the doc says without first learning about [even more abstract stuff]. So now the user needs to develop a strong background in [some abstract topic] he/she doesn't care about just to figure out *if* that abstract topic could possibly be useful. At this point most users will give up. If instead they had access to documentation that says "[Monoids] are useful programming abstractions because they can solve problems A, B, and C in these manners, and incidentally they can do all this other stuff too", the same users would not only stick with Haskell longer, they would increase their theoretical awareness at the same time. I think even the most elitist Haskell users would think this is a good outcome. Of course this better documentation would need to be written. Somebody upthread (Duncan?) suggested that suitable individuals may not exist, and I agree with that. Of people who understand the material well enough to document it, many are busy doing other work, and many have no interest or are ideologically opposed to writing documentation of this type. This situation reminds me very much of a particularly well-known article by Milton Babbitt, "Who Cares If You Listen." I expect that many Haskellers would find it interesting at the least. John Lato From pbeadling at mail2web.com Thu Jan 15 20:41:25 2009 From: pbeadling at mail2web.com (Phil) Date: Thu Jan 15 20:33:25 2009 Subject: [Haskell-cafe] Multiple State Monads In-Reply-To: <7ca3f0160901151728y6d3ad668rf46a9c158eded6d5@mail.gmail.com> Message-ID: On 16/01/2009 01:28, "Luke Palmer" wrote: >> Compile-time constants could be handled by simple top-level bindings. This >> technique is specifically for the case you are after: >> >> mcSimulate :: Double -> Double -> Word64 -> [Double] >> mcSimulate startStock endTime seedForSeed = go seedForSeed >> where >> go = fst expiryStock : go newSeedForSeed >> where >> expiryStock = iterate evolveUnderlying (startStock, ranq1Init >> seedForSeed) >> !! truncate (endTime/timeStep) >> newSeedForSeed = seedForSeed + 246524 >> >> See what's going on there? >> >> I don't know about that nested where. In Real Life I would probably use a >> let instead for expiryStock and newSeedForSeed. >> >> Luke >> >> Ahh, I get it now, that?s pretty neat - ?go? is only updating the seedForSeed >> and the expiryStock, the inner ?where? clause keeps everything else constant >> each time it is called. Thanks again! Phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090116/bf070b81/attachment.htm From jgoerzen at complete.org Thu Jan 15 20:58:20 2009 From: jgoerzen at complete.org (John Goerzen) Date: Thu Jan 15 20:49:31 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <1232065035.5866.34.camel@derek-laptop> References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <20090115201140.GA7325@hustlerturf.com> <1232065035.5866.34.camel@derek-laptop> Message-ID: <496FE9BC.5000800@complete.org> Derek Elkins wrote: > No one doubts that there is room for improvement. However, the > direction is better documentation, not different names. Better names is > fine, but I have not heard any remotely convincing alternative for any > of the above terms. After thinking about it, I think you are right. But, there is a problem -- nobody is stepping up to write that documentation. If we can't get it, then perhaps we ought to fall back on better names. If we *can* get it, all the better, because these things need good docs, regardless of what they're called. I can see it now: a monoid by any other name would smell as sweet... -- John From lrpalmer at gmail.com Thu Jan 15 20:59:45 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Jan 15 20:50:54 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <496F6128.7080108@complete.org> References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> Message-ID: <7ca3f0160901151759j6dc7ec2bh203aea1ea0590ad0@mail.gmail.com> On Thu, Jan 15, 2009 at 9:15 AM, John Goerzen wrote: > If you're learning Haskell, which communicates the idea more clearly: > > * Appendable > > or > > * Monoid But Appendable is wrong. merge :: Ord a => [a] -> [a] -> [a] merge [] ys = ys merge xs [] = xs merge (x:xs) (y:ys) | x <= y = x : merge xs (y:ys) | otherwise = y : merge (x:xs) ys newtype MergeList a = MergeList [a] instance (Ord a) => Monoid (MergeList a) where mempty = MergeList [] mappend (MergeList xs) (MergeList ys) = MergeList (merge xs ys) This is a perfectly good monoid -- one I have used -- but in no sense would I call MergeList "appendable". Also, in what sense is mappend on Endo appending? I just realized that the name "mappend" sucks :-). (++) would be great! In any case, to me being a Monoid is about having an associative operator, not about "appending". The only fitting terms I can think of are equally scary ones such as "semigroup". Which is worse: naming things with scary category names, as in "monad" and "monoid", or naming things with approachable popular names that are wrong (wrt. to their popular usage), as in "class" and "instance". In the former case, the opinion becomes "Haskell is hard -- what the hell is a monad?"; in the latter it becomes "Haskell sucks -- it's class system is totally stupid" because we are *violating* people's intuitions, rather than providing them with none whatsoever. In a lot of cases there is a nice middle ground. Cases where (1) we can find an intuitive word that does not have a popular CS meaning, or (2) where the popular CS meaning is actually correct ("integer"?). But eg. programming with monads *changes the way you think*; we cannot rewire people's brains just-in-time with a word. I like the word Monad. It makes people know they have to work hard to understand them. ** Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/0f29fee1/attachment.htm From mgg at giagnocavo.net Thu Jan 15 21:02:43 2009 From: mgg at giagnocavo.net (Michael Giagnocavo) Date: Thu Jan 15 20:53:48 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <625b74080901151406m786c5ba1u8f5bde8e3a6e60ad@mail.gmail.com> References: <20090115153438.GA1340@hustlerturf.com> <1232054517.6800.9.camel@jcchost> <496FAAAA.9050609@btinternet.com> <625b74080901151406m786c5ba1u8f5bde8e3a6e60ad@mail.gmail.com> Message-ID: <6E8D2069C08AA84A83D336E996AE4C670235F10CF4@mse17be1.mse17.exchange.ms> >Your talk of undergraduate courses to concat two lists isn't grounded >in any kind of reality, muddies the waters, and probably scares people >away from Haskell by giving the impression that it's much harder than >it is. I've been studying Haskell a bit to understand and learn more about functional programming (I'm using F#). I have to say, the scariest thing I've faced was exactly what you say. Everything I read built "monads" up to be this ungraspable thing like quantum mechanics. Even after I actually understood it well enough, I kept thinking I must be missing something because there's so much fuss about it. -Michael From lrpalmer at gmail.com Thu Jan 15 21:07:54 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Jan 15 20:58:59 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <6E8D2069C08AA84A83D336E996AE4C670235F10CF4@mse17be1.mse17.exchange.ms> References: <20090115153438.GA1340@hustlerturf.com> <1232054517.6800.9.camel@jcchost> <496FAAAA.9050609@btinternet.com> <625b74080901151406m786c5ba1u8f5bde8e3a6e60ad@mail.gmail.com> <6E8D2069C08AA84A83D336E996AE4C670235F10CF4@mse17be1.mse17.exchange.ms> Message-ID: <7ca3f0160901151807l590c9cb0ke5cea7e141d3f0fe@mail.gmail.com> On Thu, Jan 15, 2009 at 7:02 PM, Michael Giagnocavo wrote: > >Your talk of undergraduate courses to concat two lists isn't grounded > >in any kind of reality, muddies the waters, and probably scares people > >away from Haskell by giving the impression that it's much harder than > >it is. > > I've been studying Haskell a bit to understand and learn more about > functional programming (I'm using F#). I have to say, the scariest thing > I've faced was exactly what you say. Everything I read built "monads" up to > be this ungraspable thing like quantum mechanics. Yeah, monad is on the same level as quantum mechanics. Both are equally simple and popularly construed as ungraspable. (However to grasp monads easily you need a background in FP; to grasp QM easily you need a background in linear algebra) Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090115/23ce13a7/attachment.htm From westondan at imageworks.com Thu Jan 15 21:30:27 2009 From: westondan at imageworks.com (Dan Weston) Date: Thu Jan 15 21:21:39 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <7ca3f0160901151807l590c9cb0ke5cea7e141d3f0fe@mail.gmail.com> References: <20090115153438.GA1340@hustlerturf.com> <1232054517.6800.9.camel@jcchost> <496FAAAA.9050609@btinternet.com> <625b74080901151406m786c5ba1u8f5bde8e3a6e60ad@mail.gmail.com> <6E8D2069C08AA84A83D336E996AE4C670235F10CF4@mse17be1.mse17.exchange.ms> <7ca3f0160901151807l590c9cb0ke5cea7e141d3f0fe@mail.gmail.com> Message-ID: <496FF143.5070702@imageworks.com> Richard Feinman once said: "if someone says he understands quantum mechanics, he doesn't understand quantum mechanics". But what did he know... Luke Palmer wrote: > On Thu, Jan 15, 2009 at 7:02 PM, Michael Giagnocavo > wrote: > > >Your talk of undergraduate courses to concat two lists isn't grounded > >in any kind of reality, muddies the waters, and probably scares people > >away from Haskell by giving the impression that it's much harder than > >it is. > > I've been studying Haskell a bit to understand and learn more about > functional programming (I'm using F#). I have to say, the scariest > thing I've faced was exactly what you say. Everything I read built > "monads" up to be this ungraspable thing like quantum mechanics. > > > Yeah, monad is on the same level as quantum mechanics. Both are equally > simple and popularly construed as ungraspable. > > (However to grasp monads easily you need a background in FP; to grasp QM > easily you need a background in linear algebra) > > Luke > From bertram.felgenhauer at googlemail.com Thu Jan 15 21:32:46 2009 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Thu Jan 15 21:23:56 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <496F927A.3060007@btinternet.com> <1232051895.28590.350.camel@localhost> <20090115205128.GE17581@scytale.galois.com> Message-ID: <496ff1d1.0baa660a.429d.5f43@mx.google.com> Andrew Wagner wrote: > I think perhaps the correct question here is not "how many instances of > Monoid are there?", but "how many functions are written that can use an > arbitrary Monoid". E.g., the fact that there are a lot of instances of Monad > doesn't make it useful. There are a lot of instances of Monad because it's > useful to have instances of Monad. Why? Because of > http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html ! > Look at all the cool stuff you can automagically do with your type just > because it's an instance of Monad! I think that's the point. What can you do > with arbitrary Monoids? Not much, as evidenced by > http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html One example where Monoids (in full generality) are useful is that of measurements in the Data.Sequence paper (which is sadly not implemented in the library, although it is used to maintain the length for efficient indexing), http://www.soi.city.ac.uk/~ross/papers/FingerTree.html The concept applies to any tree that represents an ordered list. The basic idea is that given a measurement for single elements, class Monoid v => Measured a v where measure :: a -> v we can annotate a tree with cached measurements of the corresponding sequences, data Tree a v = Empty | Leaf v a | Node v (Tree a v) (Tree a v) measureTree :: Measured a v => Tree a v -> v measureTree Empty = mzero measureTree (Leaf v _) = v measureTree (Node v _ _) = v which can be calculated easily by smart constructors: leaf :: Measured a v => a -> Tree a v leaf a = Leaf (measure a) a node :: Measured a v => Tree a v -> Tree a v -> Tree a v node l r = Node (measureTree l `mappend` measureTree r) l r Because v is a monoid, the construction satisfies the law measureTree = mconcat . map measure . toList where toList Empty = [] toList (Leaf _ a) = [a] toList (Node _ l r) = toList l ++ toList r All usually efficient tree operations, insertion, deletion, splitting, concatenation, and so on, will continue to work, if the cached values are ignored on pattern matching and the smart constructors are used for constructing the new trees. measure or `mappend` will be called for each smart constructor use - if they take constant time, the complexity of the tree operations doesn't change. Applications include: - finding and maintaining the sum of any substring of the sequence. - maintaining minimum and maximum of the list elements - maintaining the maximal sum of any substring of the sequence (this can be done by measuring four values for each subtree: 1. the sum of all elements of the sequence 2. the maximum sum of any prefix of the sequence 3. the maximum sum of any suffix of the sequence 4. the maximum sum of any substring of the sequence) I also found the idea useful for http://projecteuler.net/index.php?section=problems&id=220 starting out with -- L system basis class Monoid a => Step a where l :: a r :: a f :: a and then providing a few instances for Step, one of which was a binary tree with two measurements. Bertram From john at n-brain.net Thu Jan 15 21:57:59 2009 From: john at n-brain.net (John A. De Goes) Date: Thu Jan 15 21:49:09 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: <89ca3d1f0901151510i6f07c72bxba6cd7e90f3dfe5f@mail.gmail.com> References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <496F6982.9000002@complete.org> <16442B752A06A74AB4D9F9A5FF076E4B4DCB02@ELON17P32001A.csfb.cs-group.com> <89ca3d1f0901151510i6f07c72bxba6cd7e90f3dfe5f@mail.gmail.com> Message-ID: +1 to that Regards, John On Jan 15, 2009, at 4:10 PM, Cale Gibbard wrote: > 2009/1/15 Sittampalam, Ganesh : >> Lennart Augustsson wrote: >>> I think the documentation should be reasonably newbie-friendly too. >>> But that doesn't mean we should call Monoid Appendable. >>> Appendable is just misleading, since Monoid is more general than >>> appending. >> >> Then why does it have a member named 'mappend'? :-) >> >> Ganesh > > Good question. The names of the methods of the Monoid class are > inappropriate. > > My personal preference would be: > > class Monoid m where > zero :: m > (++) :: m -> m -> m > > (in the Prelude of course) > > - Cale > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From thestonetable at gmail.com Thu Jan 15 23:10:13 2009 From: thestonetable at gmail.com (Cory Knapp) Date: Thu Jan 15 23:01:26 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <496F6982.9000002@complete.org> <16442B752A06A74AB4D9F9A5FF076E4B4DCB02@ELON17P32001A.csfb.cs-group.com> <89ca3d1f0901151510i6f07c72bxba6cd7e90f3dfe5f@mail.gmail.com> Message-ID: <497008A5.2070903@gmail.com> Perhaps as a math/CS major I'm a bit biased here, but as a haskell neophyte, I think my opinion is at least somewhat relevant... The immediate problem is certainly documentation. No one would groan more than once after hearing a term from abstract math if there was sufficient Haskell-oriented language. I can say that a monad is an endo-functor (in this case on Hask) which is the composition of two natural transformations; the clever parrot I am, I can even understand most of this... but that doesn't mean anything to me in a Haskell context; until a new Haskell programmer can find a Hasktionary with relevant terms in a Haskell context, everything is meaningless-- even though I can understand (i.e. apply meaning to) the definition of a monad on Hask, I can't apply the sort of meaning required to program with a monad without either figuring it out through experience, or seeing it shown to me in a programmer-relevant way (Or rather, both need to happen.) On the other hand, I really, really like getting behind things and understanding the theory. In C, well, C is the theory-- if I want to go deeper, I need to learn as much as I can about the way a computer actually, physically works (why, why, then, even have higher level languages?) or I need to take a history lesson so I can figure out the math that helped out... With Haskell, the theory is right there, staring at me. If the documentation were better, I wouldn't *need* to learn it, but if my curiosity is piqued, it's right there. Naming monoid "appendable" kills that-- by trying to make things "warm and fuzzy", you've weakened one of my strongest motivators for programming (especially in Haskell), namely how much of a direct application of cool math it is. I know I'm not the only one. As far as I know, one of the draws of Haskell is the inherent mathematical nature of it-- in how many other languages do people write proofs of correctness because they don't want to write test-cases? The kind of people who are going to be drawn to a language which allows [(x,y)| x<-somelist, y<-someotherlist] are overall, a mathy set of people, and trying to make our terms fuzzy isn't going to change that. So why not embrace it? This leads to another point: monoids are probably called monoids for the same reason monads are monads: they came directly out of higher math. Someone did sit down trying to name this cool new Haskell idea he had and then say, "Oh, of course, it's just [insert "obscure" math word that's used in Haskell]! I'll keep that name." He sat down, and said, "Oh! Wait if I use [insert "obscure" math word that's used in Haskell] this problem is simpler." It's named for what it is: a monoid, a monad, a functor, existential quantification. But there's a deeper problem here, one that can't be resolved inside the Haskell community. The problem is that the "Math?! Scary! Gross!" attitude that's so pervasive in our society is hardly less pervasive in the computer subculture. I shouldn't be more able to discuss abstract math with a conservatory dropout theater student than with someone who plans, for a living, to put well-formed formulae onto a finite state machine. I am. I don't expect the average programmer to be able to give me a well-ordering of the reals (with choice, of course), or to prove that category C satisfying property P must also satisfy property Q; but for God's sake, they better have a good intuition for basic set theory, basic graph theory, and most importantly mathematical abstraction. What is "good coding style" if not making the exact same types of abstractions that mathematicians make? Again, I don't expect a CS major to write a good proof, to explain rings to a 13 year old, or actually "do" real math; but I expect one to be able to read "In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single, associative binary operation and an identity element. " and be able to get a basic intuitive idea for what a monad is; with some thought of course. I would go so far as to say that a programmer should be able to intuitively understand "a system of objects and associative arrows", even if they can't "do math" with that... Programmers shouldn't be allowed to get away with the absolute ignorance of math that at least 75% of the CS majors at my school pass with. This doesn't mean there isn't a serious problem with Haskell documentation; it also doesn't mean that everyone should have a minor in math to be a programmer, but isn't an introductory course in discrete math required for most CS programs? Then why are programmers so afraid of basic mathematical definitions? And why do so many wear their ignorance and fear of math as a badge of honor? Sorry that this came out as a bit of a rant, but I spend enough time trying to convince people that math isn't horrid and disgusting... Cory Knapp From jonathanccast at fastmail.fm Thu Jan 15 23:18:50 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Jan 15 23:10:04 2009 Subject: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <1232054517.6800.9.camel@jcchost> Message-ID: <1232079530.6876.12.camel@jonathans-macbook> On Thu, 2009-01-15 at 17:06 -0500, Steve Schafer wrote: > On Thu, 15 Jan 2009 13:21:57 -0800, you wrote: > > >Where, in the history of western civilization, has there ever been an > >engineering discipline whose adherents were permitted to remain ignorant > >of the basic mathematical terminology and methodology that their > >enterprise is founded on? > > Umm, all of them? Really. So the engineer who designed the apartment building I'm in at the moment didn't know any physics, thought `tensor' was a scary math term irrelevant to practical, real-world engineering, and will only read books on engineering that replace the other scary technical term `vector' with point-direction-value-thingy? I think I'm going to sleep under the stars tonight... > >No one may be a structural engineer, and remain ignorant of physics. No > >one may be a chemical engineer, and remain ignorant of chemistry. Why > >on earth should any one be permitted to be a software engineer, and > >remain ignorant of computing science? > > Do you know any actual working structural or chemical engineers? Um, no. I try to avoid people as much as possible; computers at least make sense. Also anything else to do with the real world :) > Most > engineering disciplines require a basic grasp of the underlying theory, > yes, but not much beyond that. Perhaps I should have said `completely ignorant'? Or do you think that join . join = join . fmap join is of the same level of theoretical depth as quantum orbital mechanics? > Pretty much everything else is covered by > rules (either rules of thumb or published standards). > Show me an electrical engineer who can explain the physics of a pn > junction and how it acts as a rectifier, or a civil engineer who can > explain why the stress/strain curve of a steel beam has the shape that > it does, Again, do engineers know *what* stress is? Do they understand terms like `tensor'? Those things are the rough equivalents of terms like `monoid'. jcc From artyom.shalkhakov at gmail.com Thu Jan 15 23:22:58 2009 From: artyom.shalkhakov at gmail.com (Artyom Shalkhakov) Date: Thu Jan 15 23:14:04 2009 Subject: [Haskell-cafe] some ideas for Haskell', from Python In-Reply-To: References: <496DFDD0.1010109@libero.it> Message-ID: <2076f2f90901152022jebf785te5e163695baae225@mail.gmail.com> Hi Immanuel, 2009/1/15 Immanuel Litzroth : > In Python importing a module has totally different semantics from importing > in Haskell. > I runs the initialization code for the module & makes the names in that > module > available to you code. In Haskell modules are just namespace control, and > you can always > refer to names imported through import X through the syntax X