- Haskell-Cafe - Haskell.org

Expect module?
by Erik de Castro Lopo 20 Jan '09

20 Jan '09

Hi all, Is there a Haskell-Expect module? Something that would allow me to control an external Unix program via its stdin/stdout/stderr? Cheers, Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- Seen on comp.lang.c : klaushuot : C rocks the world. Plain and simple. It's the ultimate solution, period. user923005 : Every tool should be a screwdriver. You can hammer with it, if you pound hard enough. You can pry with it -- just like a crowbar. Or, perhaps, there are room for other tools in the bag.

4 4

plugins can not be installed in ghc 6.10.1
by Alberto G. Corona 20 Jan '09

20 Jan '09

Do really pluigins needs Cabal (>=1.4 && <1.5) ??? C:\Documents and Settings\Administrator>cabal install plugins Resolving dependencies... cabal: dependencies conflict: ghc-6.10.1 requires Cabal ==1.6.0.1 however Cabal-1.6.0.1 was excluded because plugins-1.3.1 requires Cabal ==1.4.*

3 2

ANN: hledger 0.3 released
by Simon Michael 20 Jan '09

20 Jan '09

I'm pleased to announce another hledger release. Happy new year, all! hledger is a partial haskell clone of John Wiegley's "ledger" text-based accounting tool. It generates transaction & balance reports from a plain text ledger file, and demonstrates a functional implementation of ledger. For more information, see hledger's home page: http://joyful.com/hledger News for 0.3 ------------ Fixes: * count timelog sessions on the day they end, like ledger, for now * when options are repeated, use the last instead of the first * builds with ghc 6.10 as well as 6.8 * runs much faster than 0.2:: $ bench hledger-0.2 hledger ledger || hledger-0.2 | hledger | ledger ==================================++=============+=========+======= -f 2008.ledger -s balance || 2.59 | 0.26 | 0.11 -f 10000entries.ledger -s balance || 566.68 | 2.72 | 0.96 Features: * a simple ui for interactive report browsing: hledger ui * accept smart dates everywhere (YYYYMMDD, Y/M/D, Y, M/D, D, jan, today, last week etc.) * --period/-p flag accepting period expressions like "in 2008", "weekly from last month".. * -W/-M/-Y convenience flags to summarise register weekly, monthly, yearly * --depth and -E flags also affect summarised register reports (including depth=0) * --display/-d flag supporting date predicates (like "d<[DATE]", "d>=[DATE]") * !include directive to include additional ledger files * !account directive to set a default parent account * Added support for reading historical prices from files * timelog and ledger entries can be intermixed in one file * modifier and periodic entries can appear anywhere (but are still ignored) * help and readme improvements Contributors: * Simon Michael * Nick Ingolia * Tim Docker * Corey O'Connor & the vty team Stats: * Known errors: 1 * Tests: 58 * Lines of non-test code: 2123 Installation ------------ hledger requires GHC. It is known to build with 6.8 and 6.10. If you have cabal-install, do:: cabal update cabal install hledger Otherwise, unpack the latest tarball from http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hledger and do:: runhaskell Setup.hs configure runhaskell Setup.hs build sudo runhaskell Setup.hs install This will complain about any missing libraries, which you can download and install manually from hackage.haskell.org. (The Build-Depends: in hledger.cabal has the full package list.) To get the latest development code do:: darcs get http://joyful.com/repos/hledger

2 5

Fwd: [Haskell-cafe] runghc Setup.hs doitall
by Alberto G. Corona 20 Jan '09

20 Jan '09

I finally installed cabal-install in windows.. I had a copy of sh.exe for windows time ago so I could use bootstrap. The only additional thing needed is wget(http://users.ugent.be/~bpuype/wget/). finally I moved the resulting cabal.exe to ghc/bin 2009/1/19 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> On Mon, 2009-01-19 at 01:36 +0100, Alberto G. Corona wrote: > > The problem with Windows can be solved once and for all when CygWIN > > will be considered for Windows instead of MinGW. Is that possible? > > The standard Windows build of GHC does not use Cygwin. So all the > programs built with GHC (like cabal) are native Windows programs and do > not understand Cygwin paths etc. > > If you want to build GHC for Cygwin then there is quite a bit of work > for you to do to update GHC to build that way. > > I get the general impression that most users would prefer not to have to > install Cygwin or MinGW at all. > > Duncan > >

1 1

ANNOUNCE: Coadjute 0.0.1, generic build tool
by Matti Niemenmaa 19 Jan '09

19 Jan '09

Announcing the release of Coadjute, version 0.0.1! Web site: http://iki.fi/matti.niemenmaa/coadjute/ Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Coadjute Coadjute is a generic build tool, intended as an easier to use and more portable replacement for make. It’s not tailored toward any particular language, and is not meant to replace tools which target a specific environment (such as ghc --make or Cabal, taking Haskell as an example). I've been sitting on this for a couple of months now and figured I might as well push it out since it seems to be in relative working order. I've used it on my web site since July and it hasn't resulted in data loss yet. Still, it's a 0.0 version so no guarantees. ;-) A bit of advertising: Portability is striven towards in two ways: * You don’t have to deal with the idiosyncrasies of many make implementations (well, people don’t, but they call their GNU Make files makefiles instead of GNUmakefiles, which causes misunderstandings). * You have Haskell at your disposal, and are encouraged to use that whenever possible instead of system-specific binaries like the POSIX commands we all know and love. Comes with support for: * Parallel task performing. * Advanced out-of-dateness detection: o Choice between timestamps and hashes. o Keeping track of what arguments have been passed. * Haskell! Have a look at the Haddock documentation for a few simple examples and do feel free to comment over at haskell-cafe—or privately, if that's your preference. Any kind of discussion is welcome!

7 12

Re: Bug in Text.Regex.PCRE - do not accept national symbol in pattern
by ChrisK 19 Jan '09

19 Jan '09

Alexandr, Thanks for sending me this question about unicode and regex-pcre. I will share with the mailing list. This is an encoding issue. From the haddock documentation for regex-pcre: http://hackage.haskell.org/packages/archive/regex-pcre/0.94.1/doc/html/Text… "Using the provided CompOption and ExecOption values and if configUTF8 is True, then you might be able to send UTF8 encoded ByteStrings to PCRE and get sensible results. This is currently untested." This is a literate Haskell post so you can save with file extension ".lhs" and pass this to ghci. The answer is a combination of "man 3 pcre" and the haddock documentation for haskell-pcre and using makeRegexOpts. I show one possible way to use utf8 below, via the 'utf8-string' package from hackage. There are other ways to use the same package and other packages available. > {-# LANGUAGE FlexibleContexts #-} > import Text.Regex.PCRE hiding ((=~)) > --import Text.Regex.PCRE.Wrap(configUtf8) > import qualified Data.ByteString.UTF8 as U > import qualified System.IO.UTF8 as U > import Data.Bits((.|.)) > Here I copied the original source for (=~) from http://hackage.haskell.org/packages/archive/regex-pcre/0.94.1/doc/html/Text… I then editied it to create a custom (=~) that defines its own options. You can add compNoUTF8Check for performance/safety tradeoff (see man 3 pcre). > makeRegexUtf8 :: (RegexMaker Regex CompOption ExecOption source) => source -> Regex > makeRegexUtf8 r = let co = defaultCompOpt .|. compUTF8 -- need compUTF8 flag when using makeRegexOpts > -- co = defaultCompOpt .|. compUTF8 .|. compNoUTF8Check -- > in makeRegexOpts co defaultExecOpt r > (=~) :: (RegexMaker Regex CompOption ExecOption source,RegexContext Regex source1 target) > => source1 -> source -> target > (=~) x r = let q = makeRegexUtf8 r > in match q x If you are going to use the same pattern against many different texts then you should NOT use (=~). Instead you should call makeRegexUtf8 and reuse the resulting Regex value. Otherwise you have to recompile the pattern for each match performed. Below, 're_test' was changed internally to convert the [Char] into a ByteString holding a utf8 encoded representation. The 'makeRegexOpts' and 'match' calls will then run the libpcre routines directly on the the memory that backs the ByteString. This is an optimal was to use the library. > re_test :: String -> String -> Bool > re_test re str = (U.fromString str) =~ (U.fromString re) > > -- test for national symbols > main = do > putStrLn $ "If this line ends with True then your libpcre has UTF8 support: " ++ show configUTF8 > let pattern1,pattern2,pattern3,text :: String > pattern1 = "^п.*" > pattern2 = "^..ив.*" > pattern3 = "^......$" > text = "привет" > U.putStrLn $ "The 3 patterns are: " ++ pattern1 ++ ", " ++ pattern2 ++ ", and "++pattern3 > U.putStrLn $ "The text to be matched is " ++ text > putStrLn $ "The length of the text to be matched is "++show (length text) > putStrLn "All three lines below should print True" > print $ re_test pattern1 text > print $ re_test pattern2 text > print $ re_test pattern3 text The output when I run this on my machine is If this line ends with True then your libpcre has UTF8 support: True The 3 patterns are: ^п.*, ^..ив.*, and ^......$ The text to be matched is привет The length of the text to be matched is 6 All three lines below should print True True True True

1 0

Different return type?
by John Ky 19 Jan '09

19 Jan '09

Hi, Possibly a silly question but is it possible to have a function that has a different return type based on it's first argument? For instance data Person = Person { name :: String, ... } data Business = Business { business_number :: Int, ...} key person = name person key business = business_number business Thanks -John

5 5

Graham-Scan Algorithm exercise from Chapter 3 Real World Haskell
by Michael Litchard 19 Jan '09

19 Jan '09

I have started the Graham Scan Algorithm exercise. I'm getting tripped up by the sortByCotangent* function. Here's what I have so far data Direction = DStraight | DLeft | DRight deriving (Eq,Show) type PointXY = (Double,Double) calcTurn :: PointXY -> PointXY -> PointXY -> Direction calcTurn a b c | crossProduct == 0 = DStraight | crossProduct > 0 = DLeft | otherwise = DRight where crossProduct = ((fst b - fst a) * (snd c - snd a)) - ((snd b - snd a) * (fst c - fst a)) calcDirectionList :: [PointXY] -> [Direction] calcDirectionList (x:y:z:zs) = (calcTurn x y z) : (calcDirectionList (y:z:zs)) calcDirectionList _ = [] sortListByY :: [PointXY] -> [PointXY] sortListByY [] = [] sortListByY [a] = [a] sortListByY (a:as) = insert (sortListByY as) where insert [] = [a] insert (b:bs) | snd a <= snd b = a : b : bs | otherwise = b : insert bs sortListByCoTangent :: [PointXY] -> [PointXY] sortListByCoTangent [] = [] sortListByCoTangent [a] = [a] sortListByCoTangent (a:as) = a : insert (sortListByCoTangent as) where insert :: [PointXY] -> [PointXY] insert [] = [a] insert [b] = [b] insert (b:c:cs) | (myCoTan a b) >= (myCoTan a c) = b : c : cs | otherwise = c : b : insert cs where myCoTan :: PointXY -> PointXY -> Double myCoTan p1 p2 = (fst p2 - fst p1) / (snd p2 - snd p1) test data *Main> sortListByCoTangent (sortListByY [(1,2),(2,6),(3,10),(4,9),(5,10),(2,20),(6,15)]) [(1.0,2.0),(5.0,10.0),(2.0,6.0),(4.0,9.0),(6.0,15.0),(3.0,10.0),(2.0,20.0)] (1,0,2.0) is correct. That's the pivot point. It screws up from there. I suspect my insert is hosed, but I'm having difficulty analyzing the logic of the code. I'd like hints/help but with the following boundaries. (1) I want to stick with the parts of the language that's been introduced in the text so far. I know there are solutions that make this problem trivial, however using those misses the point. (2) I'd prefer going over the logic of my code, versus what is supposed to happen. I'm trying to learn how to troubleshoot haskell code, more than implement the graham scan algorithm. I appreciate any help/hints Michael Litchard *It seems the wikipedia page on the graham scan algorithm is wrong concerning the following part of the algorithm. "...instead, it suffices to calculate the tangent of this angle, which can be done with simple arithmetic." Someone from #haskell said that it's the cotangent I want, and my math tutor confirmed. If this is the case, I suppose we should submit a correction.

2 2

Re: Re: [Haskell-cafe] walking a directory tree efficiently
by Massimiliano Gubinelli 19 Jan '09

19 Jan '09

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-tp21446337p21475… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

2 1

Stupid question, re: overloaded type classes
by Brian Hurt 19 Jan '09

19 Jan '09

So, I'm working with this simplistic S-expression library of my own design (yes, I know, reinventing the wheel). Basically, I have the type: data Sexp = List of [ Sexp ] | Atom of String with the associated parsers and printers which really aren't relevent to the question at hand. Then, I want to define the type class of types I can convert to and from s-expressions, like: class Sexpable a where toSexp :: a -> Sexp fromSexp :: Sexp -> Maybe a here, fromSexp can return Nothing is the s-expression isn't the right form to be parsed into a whatever. Now, here's the problem. I want to define a bunch of default instances, and two in particular I want to define are: instance Sexpable String where toSexp s = Atom s fromSexp (Atom s) = Just s fromSexp _ = Nothing instance Sexpable a => Sexpable [ a ] where toSexp lst = List $ map toSexp lst fromSexp (List lst) = mapM fromSexp lst fromSexp _ = Nothing Note that I am not implementing Sexpable Char anywhere, so the only valid transform for [Char] should be the String one. But this still causes a compiler error due to the overloaded instances on [Char]. There are two solutions to this that I already know of. One is to play games with newtype, which I don't like because it simply adds complexity in my case and doesn't help anything else. The second possibility is to compile with -fallow-incoherent-instances, which I'm slightly afraid of because I'm not sure what (if any) possible errors adding this option might allow. So my question is twofold: 1) what errors might be allowed if I add -fallow-incoherent-instances, and 2) is there some third choice that avoids both solutions I already know about? Thanks. Brian

4 5

Anybody in Savannah?
by Ketil Malde 19 Jan '09

19 Jan '09

Hi, I arrived in Savannah yesterday (to attend PADL), and have spent the most part of the day drifting aimlessly around. Thrilling as that may be, I thought perhaps there might be other members of the Haskell community around, and that perhaps we could arrange to meet informally for coffee, beer, dinner? -k -- If I haven't seen further, it is by standing in the footprints of giants

3 3

real haskell difficulties (at least for me)
by Regis Saint-Paul 19 Jan '09

19 Jan '09

Hi, Ive 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...) - Im 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, Ive 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), Id 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.

20 39

meeep
by Louis Wasserman 19 Jan '09

19 Jan '09

apologies for the old-digest copy spam. >.< Louis Wasserman wasserman.louis(a)gmail.com

1 0

Re: Functors [Comments from OCaml Hacker Brian Hurt]
by Louis Wasserman 19 Jan '09

19 Jan '09

The point of concepts like functors, monoids, and monads is not because they provide functionality that wouldn't normally be accessible, but for the following reasons: 1. The concept encapsulates a huge number of common programming idioms. Indicating that a concept fits the functor, monad, or monoid paradigm provides the advantages that a) significant repeated code can be scrapped in favor of general library code. Writing "mconcat" is much nicer than writing "foldr (++) []", though perhaps lists aren't the best example (due to the presence of just plain "concat").** b) Using fully general, well-known (within the Haskell community) abstractions provides other programmers with easily read hints about the behavior of your code, such as the indication that a Foo can be composed with another Foo in an associative fashion, so parentheses are irrelevant. (So foldl mappend mzero ls is equivalent to foldr mappend mzero ls, but the latter fuses more powerfully without stream fusion.) 2. Very abstract, very general typeclasses in libraries come with very general combinators and functions in libraries, with the bonus that GHC's optimizer is almost always capable of optimizing code using these general structures into code just as, or very nearly as, good as equivalent code that would take you hours to write and would considerably obfuscate the programmer's actual intention. 3. Writing code in a very general, abstract fashion can considerably improve the *developer*'s thinking about the program. As an example, this weekend I was playing with (very, very custom-tuned) monads to fill up the contents of an array in several different fashions, and taught myself monad transformers as a very elegant way to encapsulate a shared, universal array, a mutable index state, and successive (associative and commutative) operations on a State; this went through several permutations (and is still in progress). As an additional observation, using the Sum, Product, Any, and other similar monoids, when done appropriately and mconcat'd, gives no actual overhead due to standard optimizations (in particular, each of them is a newtype). That's to say that I'm almost positive that mconcat (map Product ls) is equivalent to foldMap Louis Wasserman wasserman.louis(a)gmail.com On Sat, Jan 17, 2009 at 10:46 AM, <haskell-cafe-request(a)haskell.org> wrote: > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. Re: Comments from OCaml Hacker Brian Hurt (david48) > 2. Re: Re: Comments from OCaml Hacker Brian Hurt (david48) > 3. Re: Comments from OCaml Hacker Brian Hurt (Andrew Coppin) > 4. Re: some ideas for Haskell', from Python (Artyom Shalkhakov) > 5. Re: Comments from OCaml Hacker Brian Hurt (Andrew Coppin) > 6. Re: Re: Comments from OCaml Hacker Brian Hurt (Eugene Kirpichov) > 7. Re: Comments from OCaml Hacker Brian Hurt (Eugene Kirpichov) > 8. Functors [Comments from OCaml Hacker Brian Hurt] (Andrew Coppin) > 9. Re: Functors [Comments from OCaml Hacker Brian Hurt] > (Eugene Kirpichov) > 10. Re: Functors [Comments from OCaml Hacker Brian Hurt] (Luke Palmer) > 11. Re[2]: [Haskell-cafe] Functors [Comments from OCaml Hacker > Brian Hurt] (Bulat Ziganshin) > 12. Re: Re[2]: [Haskell-cafe] Comments from OCaml Hacker Brian > Hurt (David Leimbach) > 13. OS X build failure of Gtk2Hs from MacPorts (Jeff Heard) > 14. Re: Comments from OCaml Hacker Brian Hurt (Lennart Augustsson) > 15. Re: Comments from OCaml Hacker Brian Hurt (David Leimbach) > 16. Re: ANN: HTTPbis / HTTP-4000.x package available (Tim Newsham) > 17. Efficient Factoring Out of Constants (Phil) > 18. Re: Efficient Factoring Out of Constants (Luke Palmer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 17 Jan 2009 10:47:56 +0100 > From: david48 <dav.vire%2Bhaskell(a)gmail.com <dav.vire%252Bhaskell(a)gmail.com>> > Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt > To: "Jonathan Cast" <jonathanccast(a)fastmail.fm> > Cc: haskell-cafe(a)haskell.org > Message-ID: > <4c88418c0901170147u3e0a3d65r2ab72d9bbc8cb1e6(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Fri, Jan 16, 2009 at 4:04 PM, Jonathan Cast > <jonathanccast(a)fastmail.fm> wrote: > > > On Fri, 2009-01-16 at 14:16 +0100, david48 wrote: > >> Part of the problem is that something like a monoid is so general that > >> I can't wrap my head around why going so far in the abstraction. > >> For example, the writer monad works with a monoid; using the writer > >> monad with strings makes sense because the mappend operation for lists > >> is (++), now why should I care that I can use the writer monad with > >> numbers > >> which it will sum ? > > > > To accumulate a running count, maybe? A fairly common pattern for > > counting in imperative languages is > > > > int i = 0; > > while (<get a value>) i+= <count of something in value> > > > > Using the writer monad, this turns into > > > > execWriter $ mapM_ (write . countFunction) $ getValues > > well thank you for the example, if I may ask something: why would I > need to write a running count this way instead of, for example, a non > monadic fold, which would probably result in clearer and faster code > (IMHO) ? > > > ------------------------------ > > Message: 2 > Date: Sat, 17 Jan 2009 11:08:25 +0100 > From: david48 <dav.vire%2Bhaskell(a)gmail.com <dav.vire%252Bhaskell(a)gmail.com>> > Subject: Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt > To: "Apfelmus, Heinrich" <apfelmus(a)quantentunnel.de> > Cc: haskell-cafe(a)haskell.org > Message-ID: > <4c88418c0901170208i74358328ycaa10359fb639873(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Fri, Jan 16, 2009 at 10:28 PM, Apfelmus, Heinrich > <apfelmus(a)quantentunnel.de> wrote: > > > david48 wrote: > > >> I don't care about the name, it's ok for me that the name > >> mathematicians defined is used, but there are about two categories of > >> people using haskell and > >> I would love that each concept would be adequately documented for > everyone: > >> - real-world oriented programming documentation with usefulness and > >> examples for the non mathematician > >> - the mathematics concepts and research papers for the mathematicians > >> for those who want/need to go further > > >> As someone mentionned, the documentation can't really be done by > >> someone that doesn't fully grok the concepts involved. > > > Good account of the current documentation situation. > > > Hm, what about the option of opening Bird's "Introduction on Functional > > Programming using Haskell" in the section about fold? Monoid is on page > > 62 in the translated copy I've got here. > > I don't have this book. I have real world haskell and purely > functional data structures though. > > > Does Hutton's book mention them? Real World Haskell? > > the first time it is mentionned in RWH according to the index is page > 266 where we read > "We forgot to test the Monoid instance" > ... > "...of Monoid, which is the class of types that support appending and > empty elements:" > > Appending.... :) > > On the other hand, on page 320 there is a nice explanation of Monoid, > and on page 380, which isn't mentionned in the index, there might be > the first time one can understand why the writer monad works with > monoids instead of lists: to be able to use better suited data types > for appending. > > All of this is still lacking the great why : why/how an abstraction so > generic can be useful. > I'm starting to believe that the only reason to make a datatype an > instance of Monoid is... why not ! since it's not hard to find an > associative operation and a neutral element. > > > I don't think that I would try to learn a programming language, for > > example Python, without obtaining a paper book on it. > > I would, if the online documentation makes it possible, and then I > would buy a paper book later, to go further or for reference. > That's how I learned Haskell, and much later I've bought my first book. > > > ------------------------------ > > Message: 3 > Date: Sat, 17 Jan 2009 11:07:03 +0000 > From: Andrew Coppin <andrewcoppin(a)btinternet.com> > Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt > To: haskell-cafe(a)haskell.org > Message-ID: <4971BBD7.504(a)btinternet.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Anton van Straaten wrote: > > Niklas Broberg wrote: > >>> I still think existential quantification is a step too far though. :-P > >> > >> Seriously, existential quantification is a REALLY simple concept, that > >> you would learn week two (or maybe three) in any introductory course > >> on logic. In fact, I would argue that far more people probably know > >> what existential quantification is than that know what a monoid is. > >> :-) > > > > Andrew's core objection here seems reasonable to me. It was this: > > > > > {-# 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. > > > > But I suspect I part company from Andrew in thinking that something > > like ExistentiallyQuantifiedTypes would be a perfectly fine alternative. > > I would suggest that ExistentiallyQuantifiedTypeVariables would be an > improvement on just ExistentialQuantification - but I'd still prefer the > less cryptic HiddenTypeVariables. (Since, after all, that's all this > actually does.) > > Either way, nobody is going to change the name, so why worry? > > > > PS. There exist courses on logic? That could be potentially interesting... > > > > ------------------------------ > > Message: 4 > Date: Sat, 17 Jan 2009 17:12:14 +0600 > From: Artyom Shalkhakov <artyom.shalkhakov(a)gmail.com> > Subject: Re: [Haskell-cafe] some ideas for Haskell', from Python > To: Immanuel Litzroth <immanuel203(a)gmail.com>, > haskell-cafe(a)haskell.org > Message-ID: > <2076f2f90901170312y7e6dfa36jf61ab2f67f1c454a(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hello, > > 2009/1/16 Immanuel Litzroth <immanuel203(a)gmail.com>: > > I don't understand your comment. > > 1) If XMonad already uses it the problem is solved, without giving > Haskell > > import new semantics? > > Right, but there are some restrictions. > > > 2) These guys refer to a method to do plugin work in Haskell > > http://www.cse.unsw.edu.au/~dons/hs-plugins/<http://www.cse.unsw.edu.au/%7Edons/hs-plugins/> > > So the problem of dynamically loading plugins should already be solved? > > Well, mostly yes, but I think that it should be added to the language. > > Cheers, > Artyom Shalkhakov. > > > ------------------------------ > > Message: 5 > Date: Sat, 17 Jan 2009 11:17:12 +0000 > From: Andrew Coppin <andrewcoppin(a)btinternet.com> > Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt > To: haskell-cafe(a)haskell.org > Message-ID: <4971BE38.9060002(a)btinternet.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Cory Knapp wrote: > > Actually, that was part of my point: When I mention Haskell to people, > > and when I start describing it, they're generally frightened enough by > > the focus on pure code and lazy evaluation-- add to this the > > inherently abstract nature, and we can name typeclasses > > "cuddlyKitten", and the language is still going to scare J. R. > > Programmer. By "inherently mathematical nature", I didn't mean names > > like "monoid" and "functor", I meant *concepts* like monoid and > > functor. Not that either of them are actually terribly difficult; the > > problem is that they are terribly abstract. That draws a lot of people > > (especially mathematicians), but most people who aren' drawn by that > > are hugely put off-- whatever the name is. So, I guess my point is > > that the name is irrelevant: the language is going to intimidate a lot > > of people who are intimidated by the vocabulary. > > Oh, I don't know. I have no idea what the mathematical definition of > "functor" is, but as far as I can tell, the Haskell typeclass merely > allows you to apply a function simultaneously to all elements of a > collection. That's pretty concrete - and trivial. If it weren't for the > seemingly cryptic name, nobody would think twice about it. (Not sure > exactly what you'd call it though...) > > A monoid is a rather more vague concept. (And I'm still not really sure > why it's useful on its own. Maybe I just haven't had need of it yet?) > > I think, as somebody suggested about "monad", the name does tend to > inspire a feeling of "hey, this must be really complicated" so that even > after you've understood it, you end up wondering whether there's still > something more to it than that. > > But yes, some people are definitely put off by the whole "abstraction of > abstractions of abstraction" thing. I think we probably just need some > more concrete examples to weight it down and make it seem like something > applicable to the real world. > > (Thus far, I have convinced exactly *one* person to start learning > Haskell. This person being something of a maths nerd, their main > complaint was not about naming or abstraction, but about the > "implicitness" of the language, and the extreme difficulty of visually > parsing it. Perhaps not surprising comming from a professional C++ > programmer...) > > > At the same time, I think everyone is arguing *for* better > > documentation. And you're probably right: better documentation will > > bring the abstract nonsense down to earth somewhat. > > Amen! > > > > ------------------------------ > > Message: 6 > Date: Sat, 17 Jan 2009 14:27:02 +0300 > From: "Eugene Kirpichov" <ekirpichov(a)gmail.com> > Subject: Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt > To: david48 <dav.vire%2Bhaskell(a)gmail.com <dav.vire%252Bhaskell(a)gmail.com>> > Cc: "Apfelmus, Heinrich" <apfelmus(a)quantentunnel.de>, > haskell-cafe(a)haskell.org > Message-ID: > <5e0214850901170327t13bd62ds75167a28f68ed39c(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > The great "that's why" is as follows: when you have an abstraction, > then it is sufficient to hold the abstraction in mind instead of the > whole concrete implementation. That's the whole purpose of > abstraction, after all, be it maths or programming. > > Let me illustrate this. > > Suppose you are developing a library that, for instance, has a notion > of "settings" and is able to combine two "settings" with several > strategies for resolving conflicts between settings with duplicate > keys: take the first setting, the second, none, or make a setting with > multiple values. For example, an alternative GetOpt. > > Suppose you don't know what a monoid is and don't even know that such > an abstraction exists. > Now, when you're reasoning about the library, you have to think "If I > combine 3 settings, should the order of combination matter? Hmm, would > be nice if it didn't. Also, what should I return if someone queries > for a non-existent key in the settings? Should I return an empty list, > or a Nothing, or throw an error, or what? Do empty settings make > sense?" etc. If you're smart and lucky, you will most probably get > most things right and inconsciously create a settings monoid. > > Now, if you know what a monoid is, you immediately recognize that your > settings should be a monoid by nature, and now you have absolutely no > doubt that you should make the combining operation associative and > provide a unit; and you use this monoid abstraction all the time you > are designing this library. Now, you don't think about whether you > should throw an error or return a Nothing for an empty key; but > instead you think about which result would behave like a unit for the > monoid, being motivated by mathematical principles rather than pure > intuition. > > You end up designing a mathematically sound library whose principles > make sence and has no design flaws, at least in the mathematically > sound part, even if you never actually use the word "monoid" in the > documentation. > > Also, read this post by sigfpe that motivated me to learn abstract > algebra in depth (I am yet in the beginning, however), and, overall, > this is a breathtaking post: > > http://sigfpe.blogspot.com/2008/11/approach-to-algorithm-parallelisation.ht… > - this is where I started to appreciate the power of mathematical > abstractions even more. > > 2009/1/17 david48 <dav.vire%2Bhaskell(a)gmail.com<dav.vire%252Bhaskell(a)gmail.com> > >: > > All of this is still lacking the great why : why/how an abstraction so > > generic can be useful. > > I'm starting to believe that the only reason to make a datatype an > > instance of Monoid is... why not ! since it's not hard to find an > > associative operation and a neutral element. > > > > -- > Eugene Kirpichov > > > ------------------------------ > > Message: 7 > Date: Sat, 17 Jan 2009 14:34:25 +0300 > From: "Eugene Kirpichov" <ekirpichov(a)gmail.com> > Subject: Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt > To: "Andrew Coppin" <andrewcoppin(a)btinternet.com> > Cc: haskell-cafe(a)haskell.org > Message-ID: > <5e0214850901170334u27f17902nc56d0002f4702f06(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > 2009/1/17 Andrew Coppin <andrewcoppin(a)btinternet.com>: > > Cory Knapp wrote: > >> > >> Actually, that was part of my point: When I mention Haskell to people, > and > >> when I start describing it, they're generally frightened enough by the > focus > >> on pure code and lazy evaluation-- add to this the inherently abstract > >> nature, and we can name typeclasses "cuddlyKitten", and the language is > >> still going to scare J. R. Programmer. By "inherently mathematical > nature", > >> I didn't mean names like "monoid" and "functor", I meant *concepts* like > >> monoid and functor. Not that either of them are actually terribly > difficult; > >> the problem is that they are terribly abstract. That draws a lot of > people > >> (especially mathematicians), but most people who aren' drawn by that are > >> hugely put off-- whatever the name is. So, I guess my point is that the > name > >> is irrelevant: the language is going to intimidate a lot of people who > are > >> intimidated by the vocabulary. > > > > Oh, I don't know. I have no idea what the mathematical definition of > > "functor" is, but as far as I can tell, the Haskell typeclass merely > allows > > you to apply a function simultaneously to all elements of a collection. > > That's pretty concrete - and trivial. If it weren't for the seemingly > > cryptic name, nobody would think twice about it. (Not sure exactly what > > you'd call it though...) > > > > No, a functor is a more wide notion than that, it has nothing to do > with collections. > An explanation more close to truth would be "A structure is a functor > if it provides a way to convert a structure over X to a structure over > Y, given a function X -> Y, while preserving the underlying > 'structure'", where preserving structure means being compatible with > composition and identity. > > Collections are one particular case. > > Another case is just functions with fixed domain A: given a > "structure" of type [A->]X and a function of type X -> Y, you may > build an [A->]Y. > > Yet another case are monads (actually, the example above is the Reader > monad): given a monadic computation of type 'm a' and a function a -> > b, you may get a computation of type m b: > > instance (Monad m) => Functor m where > fmap f ma = do a <- ma; return (f a) > > There are extremely many other examples of functors; they are as > ubiquitous as monoids and monads :) > > -- > Eugene Kirpichov > > > ------------------------------ > > Message: 8 > Date: Sat, 17 Jan 2009 12:04:01 +0000 > From: Andrew Coppin <andrewcoppin(a)btinternet.com> > Subject: [Haskell-cafe] Functors [Comments from OCaml Hacker Brian > Hurt] > To: haskell-cafe(a)haskell.org > Message-ID: <4971C931.2070202(a)btinternet.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Eugene Kirpichov wrote: > > No, a functor is a more wide notion than that, it has nothing to do > > with collections. > > An explanation more close to truth would be "A structure is a functor > > if it provides a way to convert a structure over X to a structure over > > Y, given a function X -> Y, while preserving the underlying > > 'structure'", where preserving structure means being compatible with > > composition and identity. > > > > As far as I'm aware, constraints like "while preserving the underlying > structure" are not expressible in Haskell. > > > instance (Monad m) => Functor m where > > fmap f ma = do a <- ma; return (f a) > > > > While that's quite interesting from a mathematical point of view, how is > this "useful" for programming purposes? > > > > ------------------------------ > > Message: 9 > Date: Sat, 17 Jan 2009 15:12:26 +0300 > From: "Eugene Kirpichov" <ekirpichov(a)gmail.com> > Subject: Re: [Haskell-cafe] Functors [Comments from OCaml Hacker Brian > Hurt] > To: "Andrew Coppin" <andrewcoppin(a)btinternet.com> > Cc: haskell-cafe(a)haskell.org > Message-ID: > <5e0214850901170412j12536846r91f7dc58d8b8f806(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > 2009/1/17 Andrew Coppin <andrewcoppin(a)btinternet.com>: > > Eugene Kirpichov wrote: > >> > >> No, a functor is a more wide notion than that, it has nothing to do > >> with collections. > >> An explanation more close to truth would be "A structure is a functor > >> if it provides a way to convert a structure over X to a structure over > >> Y, given a function X -> Y, while preserving the underlying > >> 'structure'", where preserving structure means being compatible with > >> composition and identity. > >> > > > > As far as I'm aware, constraints like "while preserving the underlying > > structure" are not expressible in Haskell. > > Yes, but they are expressible in your mind so that you can recognize a > functor and design you program so that it does satisfy this > constraint, thus removing a large faulty piece of the design space. > > Also, you can write a QuickCheck test for fmap (f . g) = fmap f . fmap > g and fmap id = id. > > > > >> instance (Monad m) => Functor m where > >> fmap f ma = do a <- ma; return (f a) > >> > > > > While that's quite interesting from a mathematical point of view, how is > > this "useful" for programming purposes? > > In the same sense as monoids are, see my previous message. > > If you mean the usefulness of a Functor typeclass in Haskell, it's in > the fact that everywhere where you'd like to convert a structure over > X to a structure over Y (for example, the result of a monadic > computation), you simply write 'fmap f structure' and it works the > right way, if the structure has an instance for Functor (many > structures do). I know I'm being a bit abstract, but that's the way I > percept it. > > do filename <- toLowerCase `fmap` readLine > .... > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > ------------------------------ > > Message: 10 > Date: Sat, 17 Jan 2009 05:16:06 -0700 > From: Luke Palmer <lrpalmer(a)gmail.com> > Subject: Re: [Haskell-cafe] Functors [Comments from OCaml Hacker Brian > Hurt] > To: Andrew Coppin <andrewcoppin(a)btinternet.com> > Cc: haskell-cafe(a)haskell.org > Message-ID: > <7ca3f0160901170416n28e822c1t5cd693d61f9446a3(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > On Sat, Jan 17, 2009 at 5:04 AM, Andrew Coppin > <andrewcoppin(a)btinternet.com>wrote: > > > Eugene Kirpichov wrote: > > > >> No, a functor is a more wide notion than that, it has nothing to do > >> with collections. > >> An explanation more close to truth would be "A structure is a functor > >> if it provides a way to convert a structure over X to a structure over > >> Y, given a function X -> Y, while preserving the underlying > >> 'structure'", where preserving structure means being compatible with > >> composition and identity. > >> > >> > > > > As far as I'm aware, constraints like "while preserving the underlying > > structure" are not expressible in Haskell. > > > Well, they're expressible *about* Haskell. I.e., for functors we require: > > fmap id = id > fmap (f . g) = fmap f . fmap g > > The first property is how we write "preserving underlying structure", but > this has a precise, well-defined meaning that we can say a given functor > obeys or it does not (and if it does not, we say that it's a bad instance). > But you are correct that Haskell does not allow us to require proofs of > such > properties. > > And indeed, some people break those properties in various ways, which some > consider okay if the breakage is not observable from outside a given > abstraction barrier. I'm on the fence about that... > > Luke >

1 0

runghc Setup.hs doitall
by Alberto G. Corona 19 Jan '09

19 Jan '09

Hi guys: I don´t know how difficult really is, but it seens that it could be done because all the necessary elements are there (except perhaps the mapping package name-hackage url): Why hasn´t been done yet Is unknown to me. It would be very useful and a big save of time to have a cabal commad "chech-dependencies-and-install-them-by-downloading-them-from-hackage-then-configure-build-and-install-this-package?. The unix installers do is t from binaries and are obsolete, so I have to do it manually with cabal everytime when i download a new compiler version from haskell.org. Cheers Alberto.

8 15

Optimistic evaluation
by Andrew Coppin 19 Jan '09

19 Jan '09

Hi folks. I just read a rather interesting paper about a fork of GHC that performs "optimistic evaluation". This shows big wins in some cases. The authors claim to have implemented this in a fork of GHC and promised that it would be integrated into the production compiler "in the near future". Curios, I investigated the GHC wiki... Well, let's see now. The front page has links to "out release plans for 6.8.3" and "what will be in 6.10". The latter page, http://hackage.haskell.org/trac/ghc/wiki/Status/Releases mentions that a beta has just been released... and seems oblivious to the fact that 6.10.1 is production now. Clearly, any hopes I might have had of getting a handle on the current status of GHC from this wiki were dashed somewhat. ;-) Does anybody have any suggestions for a more reliable way of figuring out what the current activities and plans for GHC are?

2 1

ANN: leapseconds-announced-2009
by Bjorn Buckwalter 19 Jan '09

19 Jan '09

Dear all, I'm pleased to announce the upload of the leapseconds-announced package[1] to Hackage. leapseconds-announced contains a single module and a single function implementing the Data.Time.Clock.TAI.LeapSecondTable interface (type). The documentation[2] for Data.Time.Clock.TAI.LeapSecondTable says "No table is provided, as any program compiled with it would become out of date in six months" and with that I have no objections. However, I frequently find myself needing a LeapSecondTable for a quick-and-dirty one-off analysis or simulation of the present or past. In these cases I've lazily used "(const 33)" (or more recently: "(const 34)") as my LeapSecondTable. leapseconds-announced is a pragmatic, if imperfect, improvement over my past practices. It provides a LeapSecondTable with all leap seconds announced to date (hence the name). Once the IERS announces[3] another leap second the package will need an update and all code using it a recompile. While this precludes its use in long-running production applications it is eminently adequate for my one-off uses or for applications that can afford to recompile infrequently. While, in the words of the Data.Time.Clock.TAI documentation, "most people won't need this module" I hope it can be of utility to someone. Thanks, Bjorn Buckwalter [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/leapseconds-anno… [2] http://www.haskell.org/ghc/docs/latest/html/libraries/time/Data-Time-Clock-… [3] http://hpiers.obspm.fr/eoppc/bul/bulc/bulletinc.dat

2 4

Slow Text.JSON parser
by Levi Greenspan 18 Jan '09

18 Jan '09

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)); } }

8 15

Re: Comments from OCaml Hacker Brian Hurt
by John Lato 18 Jan '09

18 Jan '09

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

2 1

walking a directory tree efficiently
by Manlio Perillo 18 Jan '09

18 Jan '09

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-hask… 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

6 6

ANN: language-sh-0.0.3.1
by Stephen Hicks 18 Jan '09

18 Jan '09

Hi everyone, I'm pleased to announce a new package I've just uploaded to hackage: language-sh. It's a set of modules for parsing, manipulating, and printing sh-style shell scripts. It's being developed alongside shsh, the Simple Hakell Shell (available at http://code.haskell.org/shsh/, but it's still missing a few features before I'm ready to release it). I have two goals with this project (shsh, that is - I don't actually have plans for Language.Sh by itself, except that some people suggested it could be useful on its own). First, making possible portable test suits that run on Windows as well as on Unix. The second is a bit more difficult, but ultimately I hope shsh can become a viable command-line shell for Windows. I would love any comments, suggestions, criticisms, and especially patches! Please let me know what you think! http://hackage.haskell.org/cgi-bin/hackage-scripts/package/language-sh-0.0.… Cheers, steve hicks

1 0

Hackage about to reach 1000 releases
by Don Stewart 18 Jan '09

18 Jan '09

Hackage is about to reach the 1000 release mark, 2 years after it went live. That's right: in 2 years we've gone from having only a handful of released projects, to one thousand! Well done everyone! I did some quick visualisation of the rate of new releses, diversity of packages, and community growth over the period: http://archhaskell.wordpress.com/2009/01/18/open-source-haskell-releases-an… I'm very happy about the diversity of hackage apps, and the pleasing rate of growth of new releases. None of this would have been possible with out thousands of hours of work from the Cabal and Hackage hackers, the compiler teams, and the developers themselves. Keep churning out new and intresting code everyone! -- Don P.S. cabal install

1 0

OS X build failure of Gtk2Hs from MacPorts
by Jeff Heard 18 Jan '09

18 Jan '09

/opt/local/bin/ghc +RTS -RTS -c tools/hierarchyGen/TypeGen.hs -o tools/hierarchyGen/TypeGen.o -O -itools/hierarchyGen -package-conf package.conf.inplace -hide-all-packages -package base package.conf.inplace: openBinaryFile: does not exist (No such file or directory) /opt/local/bin/ghc +RTS -RTS -c tools/callbackGen/HookGenerator.hs -o tools/callbackGen/HookGenerator.o -O -I. -itools/callbackGen -package-conf package.conf.inplace -hide-all-packages -package base package.conf.inplace: openBinaryFile: does not exist (No such file or directory) rm -rf glib/System/Glib.o glib/System/Glib_split/; mkdir -p glib/System/Glib_split /opt/local/bin/ghc +RTS -RTS -split-objs -c glib/System/Glib.hs -o glib/System/Glib.o -O -fffi -iglib -package-conf package.conf.inplace -hide-all-packages -ignore-package glib -package base -package-name glib-0.9.13 '-#include<glib-object.h>' -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include on the commandline: Warning: -fffi is deprecated: use -XForeignFunctionInterface or pragma {-# LANGUAGE ForeignFunctionInterface#-} instead package.conf.inplace: openBinaryFile: does not exist (No such file or directory) make[1]: *** [glib/System/Glib.o] Error 1 make: *** [all] Error 2

3 3

Multiple State Monads
by Phil 18 Jan '09

18 Jan '09

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

5 17

Re: Compiling regex-posix-0.93.2 on windows
by Chris Kuklewicz 18 Jan '09

18 Jan '09

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? Parnell Flynn wrote: > I am having a terrible time compiling the 0.93.2 version of the > regex-posix library on windows XP. > > I have Cygwin and MinGW installed and I have a version of the regex.h > header in C:/cygwin/usr/include what shared libraries do I need? > > Here is a copy of the error it finds the include but is unable to link. > > This links to the standard c library version of regular expressions. > > The corresponding c header file is regex.h and there is a chance you > > will need to edit the end of the regex-posix.cabal file to find the > > include directory and/or library. > > Preprocessing library regex-posix-0.93.2... > > dist/build/Text/Regex/Posix/Wrap_hsc_make.o(.text+0x85):Wrap_hsc_make.c: > undefined reference to `_impure_ptr' > > dist/build/Text/Regex/Posix/Wrap_hsc_make.o(.text+0xc9):Wrap_hsc_make.c: > undefined reference to `_impure_ptr' > > dist/build/Text/Regex/Posix/Wrap_hsc_make.o(.text+0xf1):Wrap_hsc_make.c: > undefined reference to `_impure_ptr' > > dist/build/Text/Regex/Posix/Wrap_hsc_make.o(.text+0x125):Wrap_hsc_make.c: > undefined reference to `_impure_ptr' > > dist/build/Text/Regex/Posix/Wrap_hsc_make.o(.text+0x159):Wrap_hsc_make.c: > undefined reference to `_impure_ptr' > > dist/build/Text/Regex/Posix/Wrap_hsc_make.o(.text+0x18d):Wrap_hsc_make.c: > more undefined references to `_impure_ptr' follow > > collect2: ld returned 1 exit status > > linking dist\build\Text\Regex\Posix\Wrap_hsc_make.o failed > > command was: y:\ghc\ghc-6.8.2\bin\ghc.exe -optl-LC:/cygwin/lib > dist\build\Text\Regex\Posix\Wrap_hsc_make.o -o > dist\build\Text\Regex\Posix\Wrap_hsc_make.exe > > bash-3.2$ > > Thanks, > > Parnell > > Parnell Flynn • 230 South Lasalle Street • Suite 400 • Chicago, IL 60604 > • 312.244.5317 (o) • parnell___.flynn@ronin-capital.com_ > <mailto:parnell.flynn@ronin-capital.com> >

4 7

New blog on Haskell and Haskell in Visualization
by Jeff Heard 18 Jan '09

18 Jan '09

Just started up a blog on my own random lumberings through Haskell and the visualizations I've produced in Haskell. Have plenty of content on backlog, so I should be updating regularly. That's about all! http://vis.renci.org/jeff/ -- Jeff

1 0

Network CGI : outputFPS ByteString problem
by Pieter Laeremans 18 Jan '09

18 Jan '09

Hello, When I try to render a byteString template using outputFPS like this : outputBsTemplate :: StringTemplate ByteString -> CGI CGIResult outputBsTemplate template = let bs = renderFPS template in outputFPS bs I get this error : Couldn't match expected type `Data.ByteString.Lazy.Internal.ByteString' against inferred type `ByteString' Is this a library problem? Is the CGI bound with a too specific ByteString ? Or am I doing something terrible wrong ? thanks in advance, Pieter -- Pieter Laeremans <pieter(a)laeremans.org> "The future is here. It's just not evenly distributed yet." W. Gibson

2 1

Re: [Haskell-cafe] some ideas for Haskell', from Python
by Artyom Shalkhakov 17 Jan '09

17 Jan '09

Hello, 2009/1/16 Immanuel Litzroth <immanuel203(a)gmail.com>: > I don't understand your comment. > 1) If XMonad already uses it the problem is solved, without giving Haskell > import new semantics? Right, but there are some restrictions. > 2) These guys refer to a method to do plugin work in Haskell > http://www.cse.unsw.edu.au/~dons/hs-plugins/ > So the problem of dynamically loading plugins should already be solved? Well, mostly yes, but I think that it should be added to the language. Cheers, Artyom Shalkhakov.

1 0

Simplification of this function?
by Andrew Wagner 17 Jan '09

17 Jan '09

I've been playing around with this, but haven't been able to come up with anything. myFunc f (a,b) (c,d) = (f a c, f b d) It feels as if there should be a nice simple version of this using some combination of {un,}curry, "on", &&&, ***, or something else. Any thoughts?

4 4

Mathematics for Uninterested
by Andrzej Jaworski 17 Jan '09

17 Jan '09

Hi, After recent rant "to Hell with Monoids and Mathematics" I felt like Galileo awaiting execution. I splashed toilet several times but the rant was still there, so I decided to find a scapegoat for this malfunctioning. Of cours your mathematic teachers are to blame. They are the product of negative selection, guys useless for research, mathematics was hard for them so like ancient Egyptian priests used it as an edge over unenlightened crowd, right? I leave this to your conscience;-) Whatever the reason is, they have obviously failed to convince you that MATHEMATICS_IS_ABOUT_SIMPLIFYING_THINGS. MATHEMATICS = MATHEMATICAL_KNOWLEDGE + FORMAL_METHODS_of_THINKING You need only the second part for Haskell. - Then why Monoids and the rest? Isn't that knowledge? - It is knowledge without flesh as it is not tighten to any specific domain. Hence its simplicity and universality. Category Theory generalizes our mathematical experience along the line that we know more that we can prove. - Why generalizations derived along mathematical experience are superior to yours the hacker? - Because the time span between your one mistake or success and another mistake or success is too long for your brain to infer any structural relationship. Mathematicians using general concepts and powerful notation go way beyond human experience. - Why stick with mathematical names? - To have ample reference on them and to make people in different domains speak the same language. Still not convinced that abstraction is your friend? Let me give you a hint, the only prerequisite is to have 10 fingers:-) (0) Try to do some arithmetic without the concept of infinite set. Don't tell me that you can program calculator to do this. You would need axioms of arithmetic which you would never discover without your brain imagining infinite concatenation. (1) The same way you need Cartesian product for tuples as their ultimate holder. (2) The same way you need relational algebra to collect all manipulations of tables (and much more to map them in XML). (3) The same way you need Monoid to contain all Appendable and more. One of you asked if mathematical precision is good enough for programming. My friend, you used words that outside your body experience mean nothing. Take Topology which cannot tell the difference between the fork in your beefburger from that in your compost. You would not use it to calculate N-body problem, would you? But exactly such imprecise (qualitative) methods underpin recent dramatic improvements of precision in Mechanics. Totally imprecise improves precision! Without the high of mathematics our cognition is very misleading. Another of you shrugged over unimportant for him book on abstract algebra. Fine, but the book contains piece of flesh that brought to light methods for your Haskell. If you enjoy Haskell and want stronger feel of the methods this flesh will be your Holy Sacrament. Amen. Students at engineering have functional analysis in their curriculum which takes over 10 times longer to learn than your prerequisites for Haskell. But one of you made an excuse that engineers actually don't know this stuff. If that is so I will leave you with this thought experiment: suppose then that Dr.Wolfram goes crazy (e.g. falling sales) and decides to terminate this civilization by introducing a virus to his Mathematica upgrade... Be happy!

1 0

ANN: dataenc 0.12
by Magnus Therning 17 Jan '09

17 Jan '09

I've just uploaded version 0.12 of dataenc to HackageDB[1]: Data encoding library currently providing Uuencode, Base64, Base64Url, Base32, Base32Hex, Base16, Base85, and yEncoding. Versions 0.9, 0.10.1, 0.10.2, 0.11, 0.11.1, 0.12 Dependencies base License BSD3 Copyright Magnus Therning, 2007 Author Magnus Therning Maintainer magnus(a)therning.org Category Codec Home page http://www.haskell.org/haskellwiki/Library/Data_encoding Upload date Fri Jan 16 20:40:16 UTC 2009 Uploaded by MagnusTherning The changes since 0.11.1 are: * Re-license under BSD3. * Implementation of yEncoding. Enjoy! /M [1]: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dataenc -- 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

1 0

Re: Comments from OCaml Hacker Brian Hurt
by John Lato 17 Jan '09

17 Jan '09

> On Fri, 16 Jan 2009, Duncan Coutts wrote: > >> If you or anyone else has further concrete suggestions / improvements >> then post them here now! :-) Show various examples of how monoids apply to programming concepts/problems, e.g. monoids to combine configuration parameters/flags, monoids in writers, etc. Show how using the abstract monoid class is an advantage over a less abstract class/type with concrete examples. > Jonathan Cast wrote: > > > To accumulate a running count, maybe? A fairly common pattern for counting in imperative languages is > int i = 0; > while (<get a value>) i+= <count of something in value> > Using the writer monad, this turns into > > execWriter $ mapM_ (write . countFunction) $ getValues > This should be in the documentation for Writer. It shows how a writer can usefully and simply perform a specific function, and that function is different from what most users would consider using a Writer for. Hence, it's a specific example of both the advantages that generality provides* and a programming use for a monoid. John Lato *) just being more general isn't always an advantage. As abstractions progress, iIt becomes increasingly difficult to apply abstract concepts to the task at hand. This essay, http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12, has a pretty good description of taking this too far.

2 1

Re: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
by John A. De Goes 17 Jan '09

17 Jan '09

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

5 8

What could be considered "standard Haskell" these days?
by Mauricio 17 Jan '09

17 Jan '09

Hi, I would like to take some time to study Haskell properly, so that I could help others and pay my debt for the many times I had to bother with my syntax questions. And, of course, make better use of the language. My first attempt was to read the syntax description in Haskell 98 report, and that helped a lot. But I've realized that it's far from the language as used today. But just adding all available extensions would not be good, as some are very experimental e others are obsolete. I saw Haskell-prime page and a few features are marked as accepted. That mean I can trust them to be part of the next Haskell standard? So: if someone wants to learn the details of the language, what could be the subset of extensions one should learn and make regular use, and also include in code supposed to be used by others in the long term? Thanks, Maurício

3 2

Re: [Haskell-cafe] Maintaining laziness
by Jan Christiansen 17 Jan '09

17 Jan '09

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

2 4

F# active patterns versus GHC's view
by Peter Verswyvelen 17 Jan '09

17 Jan '09

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?

5 8

about documentation improvements
by Manlio Perillo 16 Jan '09

16 Jan '09

About latest thread on better naming and documentation improvement, why don't organize an interactive session where: 1) normal users tell what's wrong about a package/module documentation 2) the package/module author/maintainer fix the documentation in real time, so that users can review it again Manlio Perillo

4 4

ANNOUNCE: gitit 0.2 release - wiki using HAppS, git, pandoc
by John MacFarlane 16 Jan '09

16 Jan '09

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

8 20

[ANNOUNCE] Darcs 2.2.0.
by Petr Rockai 16 Jan '09

16 Jan '09

Hi all! I am happy to announce general availability of darcs 2.2.0. Getting the release ------------------- For this release, we have decided to provide two flavours, depending on the build system used: 1) The source tarball, <http://www.darcs.net/darcs-2.2.0.tar.gz>, which can be built using the traditional autoconf-based system. This is the fully supported version. After downloading and unpacking, you can issue: $ ./configure $ make and possibly # make install More detailed instructions inside the tarball (file README). Please note that we had at least one report of build failure, with quickcheck-related message. The currently best workaround, if this happens to you, is to use the cabal version of the package instead, see below. 2) Cabalised source. You can either download a tarball from <http://hackage.haskell.org/packages/archive/darcs/2.2.0/darcs-2.2.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: $ cabal update $ cabal install darcs This will give you a darcs binary in ~/.cabal/bin -- you should probably add that to your PATH. In addition to source tarballs, we expect binary packages for various UNIX platforms will be available in due time. For Windows users, Salvatore Insalaco has prepared a binary build, available from <http://homepage.mac.com/kirby81_it/darcs/darcs-2.2.0-win1.zip>. You just need to unpack the directory somewhere and add it to your path (if you like). Moreover, an experimental TortoiseDarcs release for darcs 2 has been made available by Kari Hoijarvi <hoijarvi-at-seas-dot-wustl-dot-edu> and is looking for home. It can be found at <http://datafed.net/darcs> (unfortunately, at the time of this writing, the site seemed unreachable... If you can help with hosting, please mail Kari.) What's New ---------- The summary of changes since version 2.1.2 (released last November) follows: * 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. And a summary of issues that have been fixed in darcs since version 2.1.2 (compiled by Thorkil Naur): 525 amend-record => darcs patches show duplicate additions 971 darcs check fails (case sensitivity on filenames) 1006 darcs check and repair do not look for adds 1043 pull => mergeAfterConflicting failed in geteff (2.0.2+) 1101 darcs send --cc recipient not included in success message 1117 Whatsnew should warn on non-recorded files 1144 Add darcs send --in-reply-to or --header "In-Reply-To: <x@y.z>" 1165 get should print last gotten tag 1196 Asking for changes in /. of directory that doesn't exist gives changes in entire repo 1198 Reproducible "mergeConflictingNons failed in geteff with ix" 1199 Backup files darcs added after external merge 1223 sporadic init.sh test failure (2.1.1rc2+472) 1238 wish: darcs help setpref should list all prefs 1247 make TAGS is broken 1249 2.1.2 (+ 342 patches) local drive detection on Windows error 1272 amend-record not the same as unrecord + record 1273 renameFile: does not exist (No such file or directory) 1223 sporadic init.sh test failure (2.1.1rc2+472) I would like to thank all contributors for making this release possible. Future ------ The next release will be 2.2.1, fixing low-risk issues found in 2.2.0, or those that have been excluded for 2.2.0 due to freeze. This release will appear in two or three weeks time, depending on circumstances. The next major release will be 2.3, due in June or July this year. The focus of this release will be new features and further work on performance. Moreover, we expect that it will use Cabal as its default build system and will make first steps towards sustainable libdarcs API. Yours, Petr. -- Peter Rockai | me()mornfall!net | prockai()redhat!com http://blog.mornfall.net | http://web.mornfall.net "In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton on the subject of C program indentation

1 0

Re: [Haskell-cafe] some ideas for Haskell', from Python
by Manlio Perillo 16 Jan '09

16 Jan '09

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 <manlio_perillo(a)libero.it>: >> 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" <interactive>: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

3 4

Names in Haskell (Was: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt)
by roconnor＠theorem.ca 16 Jan '09

16 Jan '09

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 <http://r6.ca/> ``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.''

6 5

3 applications of "indexed composition" as a language design principle
by Greg Meredith 16 Jan '09

16 Jan '09

Haskellians, i've found a way to generalize the LogicT transformer and calculated it's application to three fairly interesting examples. The approach -- with some sample codes as scala+lift web apps -- is described here<http://biosimilarity.blogspot.com/2009/01/3-applications-of-indexed-composi…>. Comments welcome. Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com

1 0

Type errors, would extensions help?
by Mauricio 16 Jan '09

16 Jan '09

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

4 7

How to simplify this code?
by Levi Greenspan 16 Jan '09

16 Jan '09

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

4 5

Type Family Relations
by Thomas DuBuisson 16 Jan '09

16 Jan '09

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

7 8

Monads aren't evil
by Ertugrul Soeylemez 16 Jan '09

16 Jan '09

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/

22 36

GHCi debugger question
by Galchin, Vasili 16 Jan '09

16 Jan '09

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

2 1

version information in the documentation
by Manlio Perillo 16 Jan '09

16 Jan '09

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

1 0

about System.Posix.Files.fileAccess
by Manlio Perillo 16 Jan '09

16 Jan '09

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.h… is not very good. Is it possible to design (in theory) a better interface? Thanks Manlio Perillo

3 4

ANN: monad-interleave 0.1
by Patrick Perry 16 Jan '09

16 Jan '09

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

1 0