January 2012 - Glasgow-haskell-users

DefaultSignatures and MultiParamTypeClasses
by Reiner Pope 17 Jan '12

17 Jan '12

Hi all, I just tried, and it appears that the new DefaultSignatures extension doesn't work with multi parameter type classes. For example, when I compile this file: ---- {-# LANGUAGE DefaultSignatures, MultiParamTypeClasses #-} module Test where class C a b where conv :: a -> b default conv :: D a b => a -> b conv = dconv class D a b where dconv :: a -> b ----- I get the error message: ----- /tmp/Test.hs:4:1: The multi-parameter class `C' cannot have generic methods In the class declaration for `C' Failed, modules loaded: none. ----- Is there a reason for this restriction, or is it merely an accident? Cheers, Reiner

4 4

ANNOUNCE: GHC 7.4.1 Release Candidate 1
by Ian Lynagh 17 Jan '12

17 Jan '12

We are pleased to announce the first release candidate for GHC 7.4.1: http://www.haskell.org/ghc/dist/7.4.1-rc1/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Please test as much as possible; bugs are much cheaper if we find them before the release! The release notes are not yet available, but here are some of the highlights of the 7.4 branch since 7.2 and 7.0: * There is a new feature Safe Haskell (-XSafe, -XTrustworthy, -XUnsafe): http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/safe-haskell.h… The design has changed since 7.2. * There is a new feature kind polymorphism (-XPolyKinds): http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/kind-polymorph… A side-effect of this is that, when the extension is not enabled, in certain circumstances kinds are now defaulted to * rather than being inferred. * There is a new feature constraint kinds (-XConstraintKinds): http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/constraint-kin… * It is now possible to give any sort of declaration at the ghci prompt: http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/interactive-ev… For example, you can now declare datatypes within ghci. * The profiling and hpc implementations have been merged and overhauled. Visible changes include renaming of profiling flags: http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/flag-reference… and the cost-centre stacks have a new semantics, which should in most cases result in more useful and intuitive profiles. The +RTS -xc flag now also gives a stack trace. * It is now possible to write compiler plugins: http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/compiler-plugi… * DPH support has been significantly improved. * There is now preliminary support for registerised compilation using LLVM on the ARM platform. Note: The release candidate accidentally includes the random, primitive, vector and dph libraries. The final release will not include them. Thanks Ian, on behalf of the GHC team

17 36

Re: Unexpected list non-fusion
by wren ng thornton 15 Jan '12

15 Jan '12

On 1/15/12 10:02 AM, Jan-Willem Maessen wrote: > On Sat, Jan 14, 2012 at 10:48 PM, wren ng thornton<wren(a)freegeek.org> > wrote: >> On 12/12/11 3:37 PM, wren ng thornton wrote: >>> >>> I've noticed that take and filter are good producers (and consumers) for >>> list fusion, but takeWhile, drop, and dropWhile are not. Is there any >>> reason for this discrepancy? >>> >>> If not, would I need to go through the libraries@ process for fixing it, >>> or should I just submit a patch? >> >> >> In working on a patch to fix this I've come upon a question. The fusion >> rules for take seem a bit odd in that they translate the take into a foldr >> which produces (Int# -> b), instead of passing the Int# in directly and >> using foldr to produce the b. >> >> Does anyone know why? > > This is the "turn any list traversal into a foldr using a higher-order > fold" trick. I know _what_ it's doing, I'm more curious about why. From looking through the code there didn't appear to be any reason to prefer this higher-order version instead of the straight-forward version. I'm curious if there's some performance quirk that I should beware of... Oh, right. The cons of the list algebra isn't fixed throughout the recursion. Duh. Should've tried to see if it was even possible the easy way. -- Live well, ~wren

1 0

Arrow Notation / GADT panic (GHC Trac #5777)
by Ben Moseley 15 Jan '12

15 Jan '12

The following code seems to trigger a panic (under 7.03, 7.2 and 7.4): {-# LANGUAGE Arrows, GADTs #-} import Control.Arrow data Value a where BoolVal :: Value Bool class ArrowInit f where arrif :: f b -> () instance ArrowInit Value where arrif = proc BoolVal -> returnA -< () -- this panics -- arrif = arr (\BoolVal -> ()) -- this works I've filed this as: http://hackage.haskell.org/trac/ghc/ticket/5777 --Ben

1 0

Arrow Notation - Command combinators don't work with higher rank types? (GHC 7.4)
by Ben Moseley 15 Jan '12

15 Jan '12

I have a quick question on the current (GHCi, version 7.4.0.20111219) implementation of arrow notation. Consider the code below: ---- {-# LANGUAGE Arrows,Rank2Types #-} import Control.Arrow -- cmdcomb :: Arrow a => (a (env,x) x) -> a (env,x) x -- cmdcomb aegg = aegg cmdcomb :: Arrow a => (forall x . a (env,x) x) -> a (env,x) x cmdcomb aegg = aegg myarr :: Arrow a => a (Int,Bool) Bool myarr = proc (i,b) -> do (|cmdcomb (\g -> returnA -< g) |) 'x' -- (| (cmdcomb (arr snd)) |) 'x' returnA -< False ---- This code generates the error below (but using either of the commented sections instead gets it to typecheck): ../MyDev/FPF3/saturday/dm.hs:13:13: Couldn't match expected type `t0 t1 t2' with actual type `forall x. a0 (env0, x) x' Expected type: t0 t1 t2 -> a (a1, t4) t3 Actual type: (forall x. a0 (env0, x) x) -> a0 (env0, x0) x0 In the expression: cmdcomb In the expression: proc (i, b) -> do { (|cmdcomb ((\ g -> returnA -< g))|) 'x'; returnA -< False } Failed, modules loaded: none. Is this a bug or a limitation in the current implementation? --Ben

2 4

Unexpected list non-fusion
by wren ng thornton 14 Jan '12

14 Jan '12

I've noticed that take and filter are good producers (and consumers) for list fusion, but takeWhile, drop, and dropWhile are not. Is there any reason for this discrepancy? If not, would I need to go through the libraries@ process for fixing it, or should I just submit a patch? -- Live well, ~wren

3 6

Why is ghc looking for version 2.1.0.1 of Parsec?
by Captain Freako 14 Jan '12

14 Jan '12

Hi all, Does anyone know what may be causing ghc to be looking for such an old version of Parsec, here? $ ghc -o libami.so -shared -dynamic -package parsec -package dsp -package arrows -lHSrts -L/usr/lib/ghc-7.0.3/ -lm -lffi -lrt AMIParse.o AMIModel.o ami_model.o AMIModel_stub.o ApplicativeParsec.o ExmplUsrModel.o MaybeT.o Filter.o /usr/bin/ld: cannot find -lHSparsec-2.1.0.1-ghc7.0.3 Thanks, -db

1 0

Re: [Haskell-cafe] named pipe interface
by Serge D. Mechveliani 14 Jan '12

14 Jan '12

On Fri, Jan 13, 2012 at 12:19:34PM -0800, Donn Cave wrote: > Quoth "Serge D. Mechveliani" <mechvel(a)botik.ru>, > ... > > Initially, I did the example by the Foreign Function Interface for C. > > But then, I thought "But this is unnatural! Use plainly the standard > > Haskell IO, it has everything". > > > > So, your advice is "return to FFI" ? > > Well, it turns out that the I/O system functions in System.Posix.IO > may work for your purposes. I was able to get your example to work > with these functions, which correspond to open(2), read(2), write(2). > > I would also use these functions in C, as you did in your C program. > Haskell I/O functions like hGetLine are analogous to C library I/O > like fgets(3) - in particular, they're buffered, and I would guess > that's why they don't work for you here. > > Specifically, > openFile "toA" WriteOnly Nothing defaultFileFlags > openFile "fromA" ReadOnly Nothing defaultFileFlags > > fdWrite toA str > (str, len) <- fdRead fromA 64 > return str Great! Thank you very much. As I find, Posix.IO is not of the standard, but it is of GHC. Anyway, it fits my purpose. By openFile you, probably, mean openFd. Another point is the number of open files, for a long loop. I put toA_IO = openFd "toA" WriteOnly Nothing defaultFileFlags fromA_IO = openFd "fromA" ReadOnly Nothing defaultFileFlags axiomIO :: String -> IO String axiomIO str = do toA <- toA_IO fromA <- fromA_IO fdWrite toA str (str, _len) <- fdRead fromA 64 return str When applying axiomIO in a loop of 9000 strings, it breaks: "too many open files". I do not understand why it is so, because toA_IO and fromA_IO are global constants (I have not any experience with `do'). Anyway, I have changed this to toA = unsafePerformIO toA_IO fromA = unsafePerformIO fromA_IO axiomIO :: String -> IO String axiomIO str = do fdWrite toA str (str, _len) <- fdRead fromA 64 return str And now, it works in loong loops too (I need to understand further whether my usage of unsafePerformIO really damages the project). Its performance is 9/10 of the C <-> C performance (ghc -O, gcc -O, Linux Debian). It is still slow: 120000 small strings/second on a 2 GHz machine. But this is something to start with. > I was able to get your example to work > with these functions, which correspond to open(2), read(2), write(2). > > I would also use these functions in C, as you did in your C program. > Haskell I/O functions like hGetLine are analogous to C library I/O > like fgets(3) - in particular, they're buffered, and I would guess > that's why they don't work for you here. Indeed. Initially, I tried C <-> C, and used fgets, fputs, fflush. And it did not work, it required to open/close files inside a loop; I failed with attempts. Again, do not understand, why (do they wait till the buffer is full?). Then, I tried read/write, as it is in fifoFromA.c which I posted. And it works. Now, Haskell <-> C gives a hope. Nice. Thanks, ------ Sergei mechvel(a)botik.ru

1 0

Re: [Haskell-cafe] named pipe interface
by Serge D. Mechveliani 13 Jan '12

13 Jan '12

On Fri, Jan 13, 2012 at 04:34:37PM +0100, Chadda?? Fouch?? wrote: > On Thu, Jan 12, 2012 at 7:53 PM, Serge D. Mechveliani <mechvel(a)botik.ru> wrote: > > [..] > > I need to organize a string interface for a Haskell function > > Main.axiom and a C program > > fifoFromA.c > > > > via a pair of named pipes (in Linux, UNIX). > > The pipes are created before running, by the commands > mkfifo toA > > > mkfifo fromA > > > > Main.axiom outputs a string to toA and inputs the respond string > > from fromA as the result. > > fifoFromA inputs a string from toA, > > converts it to the string resStr, outputs resStr to fromA. > > > Now that seems interesting, but just to be clear : did you choose > this solution (and why won't you use the FFI instead) or is this just > to see how to work it out ? I am trying to interface my large DoCon program for algebra to (a much larger algebra program) Axiom (the FriCAS license allows this). And for many reasons, there is no real way for this except the string interface. Further, the first candidate for the string interface is Unix named pipes. If the GHC IO cannot sufficiently work with named pipes, I would return to the attempt with the Foreign Function Interface and C <-> C exchange. Sergei. mechvel(a)botik.ru

1 0

Re: Records in Haskell
by Matthew Farkas-Dyck 12 Jan '12

12 Jan '12

Certainly not no conflicts: lambda expressions. On 30/12/2011, Colin Adams <colinpauladams(a)gmail.com> wrote: > On 30 December 2011 15:55, Matthew Farkas-Dyck <strake888(a)gmail.com> wrote: > >> On 30/12/2011, Andriy Polischuk <quuxity(a)gmail.com> wrote: >> > Yet another idea: >> > Consider using '\' as record access operator. No conflicts with anything >> at >> > all, and, >> > moreover, it really looks like hierarchical access. Reminds of >> filesystems >> > though. >> >> I hope this is a joke. >> > > Why? >

7 15