- Glasgow-haskell-users

named pipes
by Serge D. Mechveliani 21 Jan '12

21 Jan '12

Dear GHC team, I am testing the IO operations of GHC with the Unix named pipes (in ghc-7.01 under Debian Linux). In the below example, the pipe pair are created by > mkfifo toA > mkfifo fromA, `main' in Main.hs opens toA for writing, opens fromA for reading, outputs "A1" to toA. The C program fifo2 opens toA for reading, opens fromA for writing, inputs a string from toA, prints "done" to the screen (fromA is not really used, but will be needed in future). The effect is that fifo2 (on terminal-2) hangs silent, while Main.hs (on terminal-1) does its part. If I remove the fopen(..fromA..) call in fifo2.c, then it runs as expected (after this example is fixed, fifo2 will need to write to fromA). Main.hs is built by ghc --make Main, The C program is built by gcc -o fifo2 fifo2.c First, ./fifo2 is run on terminal-2, then ./Main is run on terminal-1. The source is quite small: -- Main.hs --------------------------------------------------------- import System.IO (IOMode(..), IO(..), Handle, openFile, hPutStr, hFlush) dir = showString "/home/mechvel/ghc/notes/npipe/" toA_IO = openFile (dir "toA") WriteMode :: IO Handle fromA_IO = openFile (dir "fromA") ReadMode axiomIO :: Handle -> String -> IO() axiomIO h str = do hPutStr h str hFlush h putStr "hFlush done\n" main = do h <- toA_IO putStr "str1 --> " axiomIO h "A1\n" ----------------------- fifo2.c ------------------------------------- #include <stdio.h> #include <string.h> #define BOUND 64 static char str[BOUND]; main() { int l, i; FILE *toA, *fromA; toA = fopen("/home/mechvel/ghc/notes/npipe/toA", "r"); if (toA == NULL) {perror("fopen(toA, r) failed: "); return;}; fromA = fopen("/home/mechvel/ghc/notes/npipe/fromA", "w"); // ! if (fgets(str, BOUND, toA) == NULL) { perror("fgets(str, bound, toA) failed: "); return; }; printf("input = %s\n", str); printf("done\n"); return; } --------------------------------------------------------------------- Can you, please, explain the effect? Regards, ------ Sergei mechvel(a)botik.ru

2 3

strange behavior of let in ghci
by Kazu Yamamoto 20 Jan '12

20 Jan '12

Hello, I met strange behavior of let in ghci 7.0.4. The following works well. > :m Data.List > let compFst (n1,s1) (n2,s2) = compare n1 n2 > maximumBy compFst [(1, "boo"), (3, "foo"), (2, "woo")] (3,"foo") But if I bind "maximumBy compFst" to "chooseMax" with "let", it causes error: > let chooseMax = maximumBy compFst > chooseMax [(1,"boo"),(3,"foo"),(2,"woo")] <interactive>:1:33: No instance for (Num ()) arising from the literal `2' Possible fix: add an instance declaration for (Num ()) In the expression: 2 In the expression: (2, "woo") In the first argument of `chooseMax', namely `[(1, "boo"), (3, "foo"), (2, "woo")]' It's very strange to me. Why does this happen? ":t" says: > :t maximumBy compFst maximumBy compFst :: Ord a => [(a, t)] -> (a, t) > :t chooseMax chooseMax :: [((), t)] -> ((), t) I'm writing a tutorial of Haskell and I would like to define chooseMax in ghci with "let" without specifying its signature. --Kazu

3 3

PolyKinds: couldn't match kind `BOX' against `*'
by Reiner Pope 18 Jan '12

18 Jan '12

Hi all, I think I've found a GHC bug in PolyKinds, but I'm not sure if it's a bug, or whether I misunderstand GHC's kind system. Consider this module: > {-# LANGUAGE PolyKinds #-} > > module Test where > > data Proxy t = ProxyC > > test :: Proxy '[Int, Bool] > test = ProxyC -- doesn't compile > -- test = undefined -- compiles Under ghc-7.4.0.20111219, this fails to compile, with error message > /tmp/test3/Test.hs:8:8: > Couldn't match kind `BOX' against `*' > Kind incompatibility when matching types: > k0 :: BOX > [*] :: * > In the expression: ProxyC > In an equation for `test': test = ProxyC I think GHC is wrong in flagging an error here. Here's how I understand it. The type constructor Proxy has kind > Proxy :: forall (k :: BOX). k -> * The value constructor ProxyC has type > ProxyC :: forall (k :: BOX). forall (t :: k). Proxy t The type '[Int, Bool] has kind > '[Int, Bool] :: [*] But what is the sort of [*]? The GHC manual (http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/kind-polymorph…) says "all kinds have sort BOX", and so we should have > [*] :: BOX (1) However, the error message above seems to suggest that > [*] :: * (2) which disagrees with (1). To add to the confusion, note that the module compiles if the line "test = ProxyC" is replaced by "test = undefined". So it seems that (1) holds when checking the type signature, but (2) holds when checking the expression. As I said, I suspect this is simply a GHC bug, but I'm not sure. Should I post a bug report on GHC Trac? Cheers, Reiner

2 1

Composition operator [was: Re: Records in Haskell]
by Isaac Dupree 18 Jan '12

18 Jan '12

On 01/12/2012 07:06 AM, Matthew Farkas-Dyck wrote: > On 09/01/2012, Greg Weber <greg(a)gregweber.info> wrote: >> Note that a move to a different operator for function composition >> (discussed in dot operator section) would make things easier to parse: >> >> b<~ .a >> >> where the unicode dot might be even nicer. > > I told you so (^_^) > > Unicode dot (∘) would be optimal, since that's what it's for. If to > type '∘' is awkward, then one can use (Control.Category.<<<). We need > not (and, in my opinion, should not) define another operator. Is ∘ (U+2218 RING OPERATOR)* in Prelude yet? We should propose that.** I checked my compose-key (Linux) and it can produce middle-dot · (U+00B7 MIDDLE DOT) with "Compose . -", but not ∘ in any way***. If we use the proper Unicode operator ∘, then let's make a wiki page for all the common OSes/input methods, saying how to input it (aside from copy/paste). Is there anything on the Web somewhere already? Did Perl do this ( - I think they introduced some Unicode-based syntax)? There's http://www.haskell.org/haskellwiki/Unicode-symbols , which has some information (none of which let me write ∘ in an e-mail without using copy/paste). * found out using http://www.decodeunicode.org/ ** "(negate ∘ (+ 1)) 3" doesn't work in my ghci 7.0.3 with no command-line options (and a UTF-8 system locale and UTF-8-compatible terminal, as is typical these days). *** I checked the list in /usr/share/X11/locale/en_US.UTF-8/Compose

13 28

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 15 Jan '12

15 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