Re: [Haskell-cafe] Preview the new haddock look and take a short survey
On Fri, 6 Aug 2010, Ben Millwood wrote: On Thu, Aug 5, 2010 at 2:35 PM, Dino Morelli d...@ui3.info wrote: One thing I haven't seen anyone else comment on is the width of the new docs. I have a large (26) monitor and use the browser full-screen (with xmonad, so even more screen space). When I load these pages, particularly the non-frame one, something like 50% of my screen real-estate is empty whitespace on either side of the doc content. There is also wasted space in the frames version, just a little less of it. I wish the docs were using that space like the current Haddock does. Is the plan to use a fixed width like this? Please say no, it's a disappointing trend that you see everywhere. Like Twitter's web interface, for instance, very narrow. Yeah, I wrote about this in my survey response. It seems to me that if I find text in a narrow page more readable, I can easily just resize my browser window, this doesn't need to be enforced by the webpage itself. Agreed, it's like a premature optimization for the Haddock page build to decide and enforce width without knowing my needs, hardware or windowing situation. I'm also not so enthusiastic about tabbed synposis. I'm not convinced you can easily use the synopsis and doc text simultaneously, so I don't see any reason for it to be apart from the text body. Simplicity is a virtue :) The more I play with it, the more I'm not that thrilled with the sliding synopsys thing as well. I think moving away from static pages is making the docs less usable. There was a period of time when the simple static alphabetic function index was replaced with some dynamic JavaScript filtering that responded to keystrokes in the edit control. It performed really terribly on even my very modern systems with Firefox. I was happy when it went away. I appreciate the idea, but it pays to be very very conservative with reference material. I do think that in terms of colours, fonts etc. it's prettier, but the fixed max width and kind of gimmicky synopsis tab are steps backward in my opinion. I can agree with this too. I like the existing higher-contrast coloring more, which was also mentioned by a couple of the other responses in this thread. -- Dino Morelli email: d...@ui3.info web: http://ui3.info/d/ irc: dino- pubkey: http://ui3.info/d/dino-4AA4F02D-pub.gpg twitter: dino8352 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
On Wed, 4 Aug 2010, Mark Lentczner wrote: The Haddock team has spent the last few months revamping the look of the generated output. We're pretty close to done, but we'd like to get the community's input before we put it in the main release. Please take a look, and then give us your feedback through a short survey Sample pages: http://www.ozonehouse.com/mark/snap-xhtml/index.html Frame version: http://www.ozonehouse.com/mark/snap-xhtml/frames.html One thing I haven't seen anyone else comment on is the width of the new docs. I have a large (26) monitor and use the browser full-screen (with xmonad, so even more screen space). When I load these pages, particularly the non-frame one, something like 50% of my screen real-estate is empty whitespace on either side of the doc content. There is also wasted space in the frames version, just a little less of it. I wish the docs were using that space like the current Haddock does. Is the plan to use a fixed width like this? Please say no, it's a disappointing trend that you see everywhere. Like Twitter's web interface, for instance, very narrow. -- Dino Morelli email: d...@ui3.info web: http://ui3.info/d/ irc: dino- pubkey: http://ui3.info/d/dino-4AA4F02D-pub.gpg twitter: dino8352 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
On Thu, 5 Aug 2010, Johan Tibell wrote: On Thu, Aug 5, 2010 at 3:35 PM, Dino Morelli d...@ui3.info wrote: One thing I haven't seen anyone else comment on is the width of the new docs. I have a large (26) monitor and use the browser full-screen (with xmonad, so even more screen space). When I load these pages, particularly the non-frame one, something like 50% of my screen real-estate is empty whitespace on either side of the doc content. There is also wasted space in the frames version, just a little less of it. I wish the docs were using that space like the current Haddock does. Is the plan to use a fixed width like this? Yes. There's research suggesting that the line length should be between 65 and 75 characters per line. I understand, I've read that too in the context of publishing with long paragraph style material. But I think the majority of generated programming API docs are not done with fixed width. Here are several examples: JavaDoc at Sun: http://download.oracle.com/javase/7/docs/api/ Scala API docs, very recently redesigned for 2.8.x: http://www.scala-lang.org/api/current/index.html Google Android API docs: http://developer.android.com/reference/packages.html Erlang docs: http://www.erlang.org/doc/ Microsoft F# lang and API docs: http://msdn.microsoft.com/library/dd233154%28VS.100%29.aspx The Python Standard Library: http://docs.python.org/library/ Ruby-doc: http://www.ruby-doc.org/core/ I did find one that uses fixed width though, this Perl5 documentation site: http://perldoc.perl.org/perlapi.html -- Dino Morelli email: d...@ui3.info web: http://ui3.info/d/ irc: dino- pubkey: http://ui3.info/d/dino-4AA4F02D-pub.gpg twitter: dino8352___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Still stacking monad transformers
On Mon, 13 Oct 2008, Andrew Coppin wrote: Reid Barton wrote: It's not difficult: the operation is called mplus :: MyMonad a - MyMonad a - MyMonad a and already exists (assuming the author of ListT has not forgotten to write a MonadPlus instance). I see... I was under the impression that mplus is just any arbitrary binary operation over a given monad. How do you know what it does for a specific monad? I had imagined the definition of mplus to be similar in spirit to what bind is for a specific monad. i.e. it's part of that monad's strategy for achieving what it does. As for knowing what it does, trial and error, reading API docs and source. :) Something similar to this discussion had come up recently for me, list monad's MonadPlus implementation. We found ourselves doing something like this to model 'use default value if empty' for strings: let foo = case str of [] - default s - s Right away I was wishing I could do this: let foo = str `or-if-empty` default If it was a Maybe, this works with mplus: (Just foo) `mplus` (Just bar) == Just foo Nothing `mplus` (Just bar) == Just bar But not so much for list, mplus just ain't defined that way, instead doing concatination: foo `mplus` bar == foobar `mplus` bar == bar I ended up writing a special mplus' for this (thanks to #haskell!): mplus' :: (MonadPlus m, Eq (m a)) = m a - m a - m a mplus' x y | x == mzero = y | otherwise = x foo `mplus'` bar == foo `mplus'` bar == bar -- Dino Morelli email: [EMAIL PROTECTED] web: http://ui3.info/d/ irc: dino- pubkey: http://ui3.info/d/dino-4AA4F02D-pub.gpg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANN] Haskell Cheatsheet v1.0
On Fri, 10 Oct 2008, Justin Bailey wrote: I've created a cheat sheet for Haskell. It's a PDF that tries to summarize Haskell 98's syntax, keywords and other language elements. It's currently available on hackage[1]. Once downloaded, unpack the archive and you'll see the PDF. A literate source file is also included. .. The audience for this document is beginning to intermediate Haskell programmers. I found it difficult to look up some of the less-used syntax and other language stumbling blocks as I learned Haskell over the last few years, so I hope this document can help others in the future. .. Justin [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/CheatSheet [2] git://github.com/m4dc4p/cheatsheet.git ___ Justin (and everyone now contributing to this), thanks. This type of thing is very helpful. There is a well-known one-page cheat-sheet like this for Perl5 (and a newer one for Perl6 too). You can see it by typing `perldoc perlcheat` on a system with Perl. I wonder if we don't need something like that. On a related note, I had come up with this short list to help with how to read the Haskell symbols. I email this out when trying to get new people started: - Haskell symbology One thing that I found very difficult at first was how to read a lot of the symbols in the Haskell code. I made up a small cheat-sheet that explains how to read some of it: Some definitions of Haskell symbols: :: has type - to The type 'Integer - Integer' takes Integer as an argument and evaluates to an Integer. We say this type is Integer to Integer = evaluates or reduces to Used in function type signatures, read something like this: foo :: (Bar b) = b - c For all instances of type class Bar (here referred to as b), foo is a function from b to c. Or foo has type b to c. [a] list of a The family of types consisting of, for every type a, the type of lists of a. : cons List cons operator, adds first argument to the front of second, part of the List monad: (:) :: a - [a] - [a] Read: cons has type a to list of a to list of a !! List index operator [ 1, 2, 3 ] !! 1 = 2 (lists are 0-based) (!!) :: [a] - Int - a Read: (!!) has type list of a to Int to a | such that - drawn from = bind Part of class Monad then Part of class Monad - -- Dino Morelli email: [EMAIL PROTECTED] web: http://ui3.info/d/ irc: dino- pubkey: http://ui3.info/d/dino-4AA4F02D-pub.gpg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] k-minima in Haskell
On Thu, 12 Apr 2007, raghu vardhan wrote: What's the best way to implement the following function in haskell: Given a list and an integer k as input return the indices of the least k elements in the list. The code should be elegant and also, more importantly, must not make more than the minimum O(k*length(list)) number of operations. R M I don't know about performance, but trying this problem I was struck again by the gorgeous, terse code that can be created: import Data.List import Data.Ord kminima :: (Enum a, Num a, Ord b) = Int - [b] - [a] kminima k lst = take k $ map fst $ sortBy (comparing snd) $ zip [0 ..] lst commented: kminima k lst = take k -- We want k items off the front $ map fst -- Just the list of indices $ sortBy (comparing snd) -- Sort the pairs by their snd $ zip [0 ..] lst -- Preserve indices in tuples Prelude :l kminima.hs [1 of 1] Compiling Main ( kminima.lhs, interpreted ) Ok, modules loaded: Main. *Main kminima 3 [71,71,17,14,16,91,18,71,58,75,65,79,76,18,4,45,87,51,93,36] [14,3,4] *Main kminima 4 [10,9,8,7,6,5,4,3,2,1] [9,8,7,6] -- .~.Dino Morelli /V\email: [EMAIL PROTECTED] /( )\ irc: dino- ^^-^^ preferred distro: Debian GNU/Linux http://www.debian.org ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Data.ByteStream.Char8.words performance
I noticed something about ByteStream performance that I don't understand. I have a test text document: $ ls -sh test-text-file 956K test-text-file Running this program, using the Prelude's IO functions: module Main where main = do content - readFile test-text-file let l = length . words $ content print l I get: $ time ./a.out 174372 real0m0.805s user0m0.720s sys 0m0.008s Running a version of the same thing using Data.ByteStream.Char8: module Main where import qualified Data.ByteString.Char8 as B main = do content - B.readFile test-text-file let l = length . B.words $ content print l I see a time that is quite a bit slower: $ time ./a.out 174372 real0m1.864s user0m1.596s sys 0m0.012s Changing it to incorporate similar code to the implementation of B.words: module Main where import qualified Data.ByteString.Char8 as B import Data.Char (isSpace) main = do content - B.readFile test-text-file let l = length $ filter (not . B.null) $ B.splitWith isSpace content print l I see a similar time as with B.words: $ time ./a.out 174372 real0m1.835s user0m1.628s sys 0m0.012s And then if I change this to use B.split ' ' instead of isSpace: module Main where import qualified Data.ByteString.Char8 as B main = do content - B.readFile test-text-file let l = length $ filter (not . B.null) $ B.split ' ' content print l I get a time that's much more reasonable-looking, compared to the original Prelude.words version: $ time ./a.out 174313 real0m0.389s user0m0.312s sys 0m0.004s It seems like the B.splitWith isSpace code is really slow for some reason. Anybody have any idea what's going on? The actual implementation is using isSpaceWord8 which is a case statement looking for a pile of different whitespace characters. -- .~.Dino Morelli /V\email: [EMAIL PROTECTED] /( )\ irc: dino- ^^-^^ preferred distro: Debian GNU/Linux http://www.debian.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.ByteStream.Char8.words performance
On Fri, 30 Mar 2007, Jeremy Shaw wrote: Hello, Did you compile with -O2 ? That makes a huge difference when using ByteString. j. Ah, that was exactly it. I feel silly. module Main where import qualified Data.ByteString.Char8 as B main = do content - B.readFile test-text-file let l = length . B.words $ content print l $ ghc -O2 count-b.hs $ time ./a.out 174372 real0m0.198s user0m0.136s sys 0m0.012s Much faster. Thank you! dino- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
