January 2009 - Haskell-Cafe

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

19 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 18 Jan '09

18 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 18 Jan '09

18 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 18 Jan '09

18 Jan '09

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

1 0