- Glasgow-haskell-users

Re: [patch] Don't detect libiconv/libcharset on Windows to avoid changing GHCs build behavior on windows with newer mingw installs
by Bill Tutt 18 Sep '11

18 Sep '11

After I made this change I got the following results from ghc-HEAD with the newer mingw and bootstrapping from 7.0.2. The only worrying failures were the rts/5250 (esp alignment) and the simplCore/should_compile cases. I'm hoping the simplCore cases should be related to those Integer changes folks have been talking about recently. OVERALL SUMMARY for test run started at now 2961 total tests, which gave rise to 9214 test cases, of which 0 caused framework failures 6571 were skipped 2561 expected passes 63 expected failures 3 unexpected passes 16 unexpected failures Unexpected passes: hsc2hs 3837 (normal) hsc2hs hsc2hs001 (normal) hsc2hs hsc2hs002 (normal) Cause: Testsuite still flags these as broken on Windows, but the trac bug was resolved ages ago in ghc-HEAD Unexpected failures: ../../libraries/random/tests rangeTest [bad exit code] (normal) Test case doesn't realize that wchar_t is Word16 on Windows instead of Int32 as it is on other Unix machines. (e.g. pgj's x86 FreeBSD builder output) ghci/linking ghcilink006 [bad exit code] (normal) (stdc++) stdc++.dll doesn't exist on Windows (shocker) ghci/scripts ghci038 [bad stdout] (ghci) New contents in .script file doesn't match .stdout content lib/IO 3307 [bad exit code] (normal) lib/IO environment001 [bad stdout] (normal) Windows consoles don't default to UTF-8. (i.e. fails when run from clean cmd.exe as well as the mingw window I launched it from) I wonder what happens if run from PowerShell ISE.... Can't tell atm, apparently I don't have that installed on my Win7 machine. I'll need to set the console window to UTF-8 and see what happens. perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T3294 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/compiler T5030 [stat not good enough] (normal) perf/compiler parsing001 [stat not good enough] (normal) All over memory threshold. plugins plugins04 [stderr mismatch] (normal) ./<filename> -> .\<filename> change in output caused by a newer mingw? rename/should_compile/T3103 T3103 [stderr mismatch] (normal) ./<filename> -> .\<filename> change in output caused by a newer mingw? rts 5250 [bad exit code] (normal) Wrong exit code (expected 0 , actual 1 ) Stdout: esp not aligned correctly: 22de44 Stderr: simplCore/should_compile T4908 [stderr mismatch] (optasm) simplCore/should_compile spec-inline [stderr mismatch] (optasm) Possible fallout from integer change?? diffs follow: simplCore/should_compile T4908: Is this part of the integer changes? Actual stderr output differs from expected: --- ./simplCore/should_compile/T4908.stderr 2011-09-15 11:03:34 -0400 +++ ./simplCore/should_compile/T4908.comp.stderr 2011-09-17 02:05:45 -0400 @@ -11,10 +11,10 @@ \ (sc :: GHC.Prim.Int#) (sc1 :: GHC.Types.Int) (sc2 :: GHC.Prim.Int#) -> - case sc of ds { + case sc2 of ds { __DEFAULT -> - case sc2 of ds1 { - __DEFAULT -> T4908.f_$s$wf (GHC.Prim.-# ds 1) sc1 ds1; + case sc of ds1 { + __DEFAULT -> T4908.f_$s$wf ds1 sc1 (GHC.Prim.-# ds 1); 0 -> GHC.Types.True }; 0 -> GHC.Types.True @@ -38,7 +38,7 @@ case w of _ { (a, b) -> case b of _ { GHC.Types.I# ds1 -> case ds1 of ds2 { - __DEFAULT -> T4908.f_$s$wf (GHC.Prim.-# ds 1) a ds2; + __DEFAULT -> T4908.f_$s$wf ds2 a (GHC.Prim.-# ds 1); 0 -> GHC.Types.True } } @@ -69,7 +69,7 @@ forall (sc :: GHC.Prim.Int#) (sc1 :: GHC.Types.Int) (sc2 :: GHC.Prim.Int#). - T4908.$wf sc (sc1, GHC.Types.I# sc2) + T4908.$wf sc2 (sc1, GHC.Types.I# sc) = T4908.f_$s$wf sc sc1 sc2 *** unexpected failure for T4908(optasm) simplCore/should_compile spec-inline: Is this part of the integer changes? Actual stderr output differs from expected: --- ./simplCore/should_compile/spec-inline.stderr 2011-09-15 11:03:34 -0400 +++ ./simplCore/should_compile/spec-inline.comp.stderr 2011-09-17 02:09:05 -0400 @@ -21,19 +21,19 @@ GHC.Prim.+# (GHC.Prim.+# (GHC.Prim.+# - (GHC.Prim.+# (GHC.Prim.+# (GHC.Prim.+# sc1 sc1) sc1) sc1) sc1) - sc1) - sc1 } in - case GHC.Prim.<=# sc 0 of _ { + (GHC.Prim.+# (GHC.Prim.+# (GHC.Prim.+# sc sc) sc) sc) sc) + sc) + sc } in + case GHC.Prim.<=# sc1 0 of _ { GHC.Types.False -> - case GHC.Prim.<# sc 100 of _ { + case GHC.Prim.<# sc1 100 of _ { GHC.Types.False -> - case GHC.Prim.<# sc 500 of _ { + case GHC.Prim.<# sc1 500 of _ { GHC.Types.False -> - Roman.foo_$s$wgo (GHC.Prim.-# sc 1) (GHC.Prim.+# a a); - GHC.Types.True -> Roman.foo_$s$wgo (GHC.Prim.-# sc 3) a + Roman.foo_$s$wgo (GHC.Prim.+# a a) (GHC.Prim.-# sc1 1); + GHC.Types.True -> Roman.foo_$s$wgo a (GHC.Prim.-# sc1 3) }; - GHC.Types.True -> Roman.foo_$s$wgo (GHC.Prim.-# sc 2) sc1 + GHC.Types.True -> Roman.foo_$s$wgo sc (GHC.Prim.-# sc1 2) }; GHC.Types.True -> 0 } @@ -69,7 +69,7 @@ ipv) ipv } in case w of _ { - Data.Maybe.Nothing -> Roman.foo_$s$wgo 10 a; + Data.Maybe.Nothing -> Roman.foo_$s$wgo a 10; Data.Maybe.Just n -> case n of _ { GHC.Types.I# x2 -> case GHC.Prim.<=# x2 0 of _ { @@ -78,10 +78,10 @@ GHC.Types.False -> case GHC.Prim.<# x2 500 of _ { GHC.Types.False -> - Roman.foo_$s$wgo (GHC.Prim.-# x2 1) (GHC.Prim.+# a a); - GHC.Types.True -> Roman.foo_$s$wgo (GHC.Prim.-# x2 3) a + Roman.foo_$s$wgo (GHC.Prim.+# a a) (GHC.Prim.-# x2 1); + GHC.Types.True -> Roman.foo_$s$wgo a (GHC.Prim.-# x2 3) }; - GHC.Types.True -> Roman.foo_$s$wgo (GHC.Prim.-# x2 2) ipv + GHC.Types.True -> Roman.foo_$s$wgo ipv (GHC.Prim.-# x2 2) }; GHC.Types.True -> 0 } @@ -140,15 +140,15 @@ Roman.foo = \ (n :: GHC.Types.Int) -> case n of _ { GHC.Types.I# ipv -> - case Roman.foo_$s$wgo ipv 6 of ww { __DEFAULT -> GHC.Types.I# ww } + case Roman.foo_$s$wgo 6 ipv of ww { __DEFAULT -> GHC.Types.I# ww } } ------ Local rules for imported ids -------- "SC:$wgo0" [ALWAYS] forall (sc :: GHC.Prim.Int#) (sc1 :: GHC.Prim.Int#). - Roman.$wgo (Data.Maybe.Just @ GHC.Types.Int (GHC.Types.I# sc)) - (Data.Maybe.Just @ GHC.Types.Int (GHC.Types.I# sc1)) + Roman.$wgo (Data.Maybe.Just @ GHC.Types.Int (GHC.Types.I# sc1)) + (Data.Maybe.Just @ GHC.Types.Int (GHC.Types.I# sc)) = Roman.foo_$s$wgo sc sc1 *** unexpected failure for spec-inline(optasm)

1 1

Re: Windows build problems
by Bill Tutt 16 Sep '11

16 Sep '11

>From Daniel Fischer: > I'm trying to set up a build/test environment on Windows. > Building ghc (sh validate) fails after a while due to flex and bison > crashing. Those two come with git and even > $ flex --version > (or bison) crashes, so they seem truly hosed. > Do I need flex/bison at all to build ghc? > It seems they're not used on linux for building ghc. > So, if not, how do I configure things that the build doesn't try to use > bison/flex? > If yes, would installing flex and bison from gnuwin32 work? I ran into this issue last night as well. See http://hackage.haskell.org/trac/ghc/ticket/5489 flex appears to be required from integer-gmp's ./configure for one of GMP's demo programs. (a calculator demo I think) I'm trying to see if a slightly newer msys installation process as listed in the Trac bug will take care of it. However, last night I got a stage 1 ghc seg fault while compiling some Haskell code further along in the build. I currently have a devel1 build in progress to see what I come up with next. I also ran into: http://hackage.haskell.org/trac/ghc/ticket/5488 about bootstrapping using the Windows 7.2.1 standalone bits to bootstrap ghc-HEAD. If the devel1 build doesn't give any useful symptoms to pass along I'll probably retry the build using the Haskell Platform compiler. Fyi, Bill

4 6

Use -V0 causes space to leak?
by Neil Davies 16 Sep '11

16 Sep '11

Hi I have some long running (multi-gigabit, multi-cpu hour) programs and as part of trying to speed up I thought I would set the -V0 flag - when I did this there was a slow space leak that caused it to blow the heap. Anyone out there have an explanation? Is there some garbage collection thing associated with something that -V0 suppresses? Cheers Neil

2 1

accessing compilation parameters from template haskell
by Ganesh Sittampalam 16 Sep '11

16 Sep '11

Hi, It would be useful to access the current compilation parameters or even an entire RunGhc monad from inside a Template Haskell splice. Is there any way to do this? The reason I want to do this is I'm using the ghc API at runtime to dynamically execute code, and I want both the dynamically loaded code and static code to use a shared runtime module that defines some types used for communication across the boundary. To guarantee the internal representations etc are the same, I store the object file of the runtime during compilation then load it dynamically at runtime - but to make this work I need to know where the object file is (-odir and -hidir) and I also need to know or be able to deduce the GHC DynFlags so I can replicate them at runtime. I could also achieve this goal by putting my runtime in a separate package and installing it first, but that's less self-contained and would be a pain during development. Cheers, Ganesh

2 3

RE: Records in Haskell
by Simon Peyton-Jones 15 Sep '11

15 Sep '11

J Garrett Morris asked me | I also rather like the TDNR proposal, as it's rather similar to the | approach we're taking in Habit (our pet language at Portland State). | However, I'm curious as to why you don't want to quantify over name | resolution constraints. For example, why shouldn't: | | x f = f.x | | be a reasonable function? Yes, it would, and of course any impl of TDNR would need an internal constraint similar to your Select. In my original proposal I was hiding that, but it has to be there in the implementation. But you are right that making it explicit might be a good thing. Esp with Julien's new kind stuff (coming soon) we should be able to say class Select (rec :: *) (fld :: String) where type ResTy rec fld:: * get :: rec -> ResTy rec fld data T = MkT { x,y :: Int } instance Select T "x" where get (MkT {x = v}) = v And now we desugar f.x as get @T @"x" f where the "@" stuff is type application, because get's type is ambiguous: get :: forall rec fld. Select rec fld => rec -> ResTy rec fld Just like what Hobbit does really. You probably don't use the idea of extending to arbitrary other functions do you? (Which Ian does not like anyway.) Something like getIndex :: T -> Int getIndex (MkT x y) = x+y Then I'd like to be able to say t.getIndex So there's an implicit instance instance Select T "getIndex" where type ResTy T "getIndex" = Int get = getIndex It's a little unclear what operations should be in class Select. 'get' certainly, but I propose *not* set, because it doesn't make sense for getIndex and friends. So that would mean you could write a polymorphic update: f v = f { x = v } Restricting to record fields only would, I suppose, allow polymorphic update, by adding a 'set' method to Select. Simon

2 1

Windows build problems
by Daniel Fischer 15 Sep '11

15 Sep '11

I'm trying to set up a build/test environment on Windows. Building ghc (sh validate) fails after a while due to flex and bison crashing. Those two come with git and even $ flex --version (or bison) crashes, so they seem truly hosed. Do I need flex/bison at all to build ghc? It seems they're not used on linux for building ghc. So, if not, how do I configure things that the build doesn't try to use bison/flex? If yes, would installing flex and bison from gnuwin32 work?

1 0

error building GHC Head
by Greg Weber 15 Sep '11

15 Sep '11

I just cloned GHC from github and tried to build it for the first time. I get the below result where the build tool says that existing object files are missing. I haven't touched a Makefile in a long time- help here is very appreciated. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -H32m -O -package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -split-objs -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -no-user-package-conf -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/./GHC/CString.hs -o libraries/ghc-prim/dist-install/build/GHC/CString.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__1.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/.o::CString(void) /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__3.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__4.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__5.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__6.o collect2: ld returned 1 exit status make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/CString.o] Error 1 make: *** [all] Error 2

1 1

Re: [Haskell-cafe] Undefined symbol error coming from shared, dynamic library.
by Captain Freako 14 Sep '11

14 Sep '11

Hi Sergiy, *>I thought having static library to solve my problem. And I'm looking for how to build static library, but no luck. * I was also, originally trying to build a shared *static* library. (I wanted to distribute a plug-in, which could be used by people knowing nothing about Haskell working on machines that did not have the Haskell Platform installed.) Then, I happened across this nugget in section 4.11.3 of the GHC 6.12.3 User's Guide<file:///usr/share/doc/ghc6-doc/html/users_guide/using-shared-libs.html#id2620284> : In principle you can use -shared without -dynamic in the link step. That > means to statically link the rts all the base libraries into your new shared > library. This would make a very big, but standalone shared library. Indeed > this is exactly what we must currently do on Windows where -dynamic is not > yet supported (see Section 11.6, “Building and using Win32 DLLs ”). On > most platforms however that would require all the static libraries to have > been built with -fPIC so that the code is suitable to include into a > shared library and we do not do that at the moment. > That is when I changed strategies and started trying to make a shared * dynamic* version of my library work. *A question to the group: *With regard to: "... that would require all the static libraries to have been built with -fPIC ...", is this something I can do myself by re-cabaling with the proper options set in my *~/.cabal/config* file, or is this more involved than that? Thanks, -db On Sun, Sep 11, 2011 at 8:55 AM, Sergiy Nazarenko < nazarenko.sergiy(a)gmail.com> wrote: > Hi, Captain, > > As far as I see you try to build static library. > If this correct, what did not work in static library? > Why do you decide compile with -dynamic option? > > I was trying to build shared library. Other python library has used > some functions from library which I had written using Haskell. But > some software which we use in my company had crached after attempts to > import python module. Under pure python it works OK, but software has > crached. I thought having static library to solve my problem. And I'm > looking for how to build static library, but no luck. > > Cheers, > Sergiy > > On 11 September 2011 17:56, Captain Freako <capn.freako(a)gmail.com> wrote: > > Sergiy, Tom, > > > > Thanks for your replies. > > > > Sergiy, I was able to get this working without having to recompile my > > installed Haskell libraries. > > > > Tom, you were correct; I needed to explicitly link against the Haskell > > run-time system, as well as a few other things: > > > > I changed my ghc link options from this: > > > > HC_LOPTS = -no-hs-main -shared -package parsec -package dsp -static > > > > to this: > > > > HC_LOPTS = -shared -dynamic -package parsec-3.1.1 -package dsp -lHSrts > > -L/usr/lib/ghc-6.12.3/ -lm -lffi -lrt > > > > and things are working. > > > > (The command that builds my mixed language, shared object library, > > `libami.so', is: > > > > ghc -o libami.so $(HC_LOPTS) {object files, compiled from both C and > Haskell} > > ) > > > > I can understand why I'd have to explicitly link against `libHSrts', > > since I'm asking ghc for a shared object library and not an > > executable. However, I'm not sure about the following: > > - Why do I need to give the `-L/usr/lib/ghc-6.12.3/' option? (It seems > > like ghc ought to know about that, implicitly.) > > - Why do I need to explicitly link against the 3 standard C libraries: > > `m', `ffi', and `rt'? (I've never needed to do this, previously, when > > I was building/testing this project statically.) > > > > Thanks, in advance, for any insights! > > > > -db > > > > > > On 9/10/11, Sergiy Nazarenko <nazarenko.sergiy(a)gmail.com> wrote: > >> I've recompiled my library again and now it works without any problem. > >> Probably I made mistake somewhere. > >> > >> Cheers, > >> Sergiy > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe(a)haskell.org > >> http://www.haskell.org/mailman/listinfo/haskell-cafe > >> > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > >

1 0

Type of a self build let expression
by Sven Urbanski 12 Sep '11

12 Sep '11

Hi ghc-users, I'm having trouble reconstructing a specific let expression. Let's assume we have the following file Main.hs: module Main where data HList b = Null | Node b (HList b) foo2 :: e -> Int foo2 n = len (pow Null (42::Int)) len :: HList a -> Int len Null = 0 pow :: HList a -> a -> HList a pow h x = h Now I can calculate the type in ghci: :t let (_,x) = (pow x (42::Int), Null) in x which prints: let (_,x) = (pow x (42::Int), Null) in x :: HList Int or short: HList Int This is exactly what I need. Note that this is not the same as :t let x = Null in x The type of x depends on the context. Or in other words: I want to know the most general type of a parameter of a function when all other parameters of that function are given. So I wrote a function to create such a LetExpr with the ghc api. Then I can calculate the type of the LetExpr. My function returns some let expr but the result of the calculation of the type is different. The resulting type of my function is always: HList b. The problem is, during construction I have to give the variable "x" a type, which in this case is "HList b". It seems that to create a HsVar I already need to know the type of the HsVar (but I don't, that's kind of the purpose of the function). How can i calculate the type like in ghci? I am using ghc 6.12.3. I would very much appreciate any help. The rest of this mail contains the functions that I use to create the LetExpr. Thanks, Sven makeLocalVar :: Type -> Unique -> OccName -> Id makeLocalVar t u occn = mkLocalVar VanillaId (mkSystemName u occn) t vanillaIdInfo replaceFirstParam :: HsExpr Id -> HsExpr Id -> HsExpr Id replaceFirstParam (HsApp (L noSrcSpan (HsApp l1 r1)) r2) param = HsApp (noLoc $ HsApp l1 (noLoc param)) r2 replaceFirstParam (HsApp l r) param = HsApp l (noLoc param) replaceFirstParam f x = error ("unknown type for replaceFirstParam!" ++ showOutputable f) makeLetExpr :: HsExpr Id -> HsExpr Id -> DsM (HsExpr Id) makeLetExpr e@(HsVar id) parent = trace ("let parent: " ++ showOutputable parent ++ "; expr: " ++ showOutputable e) $ do supply <- getUniqueSupplyM typeX <- hsExpr2TypeDo e let uniqName = uniqFromSupply supply :: Unique -- the let construct: hslet = HsLet locbinds lhsExpr lhsExpr = noLoc hsExpr :: LHsExpr Id -- the very right side of the let (the part after 'in') ... hsExpr = HsVar locVarX :: HsExpr Id -- is "the_x"! locVarX = makeLocalVar typeX uniqName occnX :: Id occnX = mkVarOcc "x" :: OccName locVarUndef= makeLocalVar typeUndef uniqName occn_ :: Id occn_ = mkVarOcc "underscore" :: OccName -- right side of the expr (e.g. '(pow x, bar Null)'): rhs_ = L noSrcSpan _expr :: LHsExpr Id rhsX = L noSrcSpan xexpr :: LHsExpr Id _expr = replaceFirstParam parent hsExpr :: HsExpr Id xexpr = e :: HsExpr Id -- the_x = xyz vbindUndef = VarBind locVarUndef rhs_ :: HsBindLR Id Id vbindX = VarBind locVarX rhsX :: HsBindLR Id Id locbinds = bt :: HsLocalBinds Id bt = HsValBinds lr :: HsLocalBindsLR Id Id recflag = NonRecursive :: RecFlag lhsbinds = listToBag [noLoc vbindX] :: LHsBinds Id lhsbinds2 = listToBag [noLoc vbindUndef] :: LHsBinds Id lr = ValBindsOut [(recflag, lhsbinds2), (recflag, lhsbinds)] [] :: HsValBindsLR Id Id typeUndef = error "dont know the type!" return $ trace ("let replace:" ++ showOutputable _expr ++ "\nlet res:" ++ showOutputable hslet) $ hslet hsExpr2TypeDo :: HsExpr Id -> DsM Type hsExpr2TypeDo hsexpr = do let ioCoreE = dsExpr hsexpr x <- ioCoreE return (exprType x)

1 0

Re: Undefined symbol error coming from shared, dynamic library.
by Captain Freako 11 Sep '11

11 Sep '11

Sergiy, Tom, Thanks for your replies. Sergiy, I was able to get this working without having to recompile my installed Haskell libraries. Tom, you were correct; I needed to explicitly link against the Haskell run-time system, as well as a few other things: I changed my ghc link options from this: HC_LOPTS = -no-hs-main -shared -package parsec -package dsp -static to this: HC_LOPTS = -shared -dynamic -package parsec-3.1.1 -package dsp -lHSrts -L/usr/lib/ghc-6.12.3/ -lm -lffi -lrt and things are working. (The command that builds my mixed language, shared object library, `libami.so', is: ghc -o libami.so $(HC_LOPTS) {object files, compiled from both C and Haskell} ) I can understand why I'd have to explicitly link against `libHSrts', since I'm asking ghc for a shared object library and not an executable. However, I'm not sure about the following: - Why do I need to give the `-L/usr/lib/ghc-6.12.3/' option? (It seems like ghc ought to know about that, implicitly.) - Why do I need to explicitly link against the 3 standard C libraries: `m', `ffi', and `rt'? (I've never needed to do this, previously, when I was building/testing this project statically.) Thanks, in advance, for any insights! -db On 9/10/11, Sergiy Nazarenko <nazarenko.sergiy(a)gmail.com> wrote: > I've recompiled my library again and now it works without any problem. > Probably I made mistake somewhere. > > Cheers, > Sergiy > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

2 1