- Glasgow-haskell-users

array-0.2.0.0 doesn't build with 6.12rc1
by Ganesh Sittampalam 02 Nov '09

02 Nov '09

[ 6 of 10] Compiling Data.Array.IO ( Data/Array/IO.hs, dist/build/Data/Array/IO.o ) Data/Array/IO.hs:73:13: `haFD' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:73:22: `haBuffer' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:73:36: `haIsStream' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:74:5: Not in scope: data constructor `Buffer' Data/Array/IO.hs:74:13: `bufBuf' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:74:25: `bufWPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:74:36: `bufRPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:75:4: Not in scope: `bufferEmpty' Data/Array/IO.hs:82:24: `bufWPtr' is not a (visible) constructor field name Data/Array/IO.hs:82:35: `bufRPtr' is not a (visible) constructor field name Data/Array/IO.hs:86:24: `bufRPtr' is not a (visible) constructor field name Data/Array/IO.hs:95:27: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:101:10: Not in scope: `readRawBuffer' Data/Array/IO.hs:125:22: `haFD' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:125:31: `haBuffer' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:125:45: `haIsStream' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:127:18: Not in scope: data constructor `Buffer' Data/Array/IO.hs:127:26: `bufBuf' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:127:42: `bufWPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:127:53: `bufSize' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:135:30: `bufWPtr' is not a (visible) constructor field name Data/Array/IO.hs:142:7: Not in scope: data constructor `Buffer' Data/Array/IO.hs:142:15: `bufBuf' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:142:27: `bufState' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:142:36: Not in scope: data constructor `WriteBuffer' Data/Array/IO.hs:143:8: `bufRPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:143:19: `bufWPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:143:34: `bufSize' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:151:22: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:151:43: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:153:22: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:153:35: Not in scope: type constructor or class `RawBuffer'

5 5

6.12.1 release
by Simon Marlow 02 Nov '09

02 Nov '09

The current dilemma we're facing with the 6.12.1 release is this: cabal-install still needs to be ported to the new version of Cabal, Duncan is snowed under and doesn't have time to work on it, but without cabal-install people can't easily test 6.12.1 RC and we can't test it with Hackage. We've come to rely on cabal-install quite a lot. So, one option is just to release 6.12.1 as is, with the caveat that cabal-install doesn't work, and large portions of Hackage probably do not work (but we don't know what exactly). The platform isn't due to release with GHC 6.12.x until February 2010, and by then we could make a 6.12.2 to fix any problems that we discover when cabal-install is working. One potential problem is that having made the 6.12.1 release we wouldn't be able to make any further API changes, only bug fixes. Or, we could just make a 6.12.1 RC2, and advertise it with the same caveats, putting out 6.12.1 when cabal-install works and we've had a chance to see the state of Hackage and alert package authors. Simon and I favour the RC2 option. What do others think? Cheers, Simon

7 9

call for organizing next AFP summerschool (2010)
by Simon Marlow 02 Nov '09

02 Nov '09

[ posting on behalf of Rinus Plasmeijer <rinus(a)cs.ru.nl> ] ** *Call for organizers: The Advanced Functional Programming School, 2010.* http://www.cs.uu.nl/~johanj/afp/ We solicit plans for organizing the next Advanced Functional Programming School. Since 1995 there have been six Schools on Advanced Functional Programming: * 2008, LNCS 5832, Nijmegen, The Netherlands * 2004, LNCS 3622, Tartu, Estonia * 2002, LNCS 2638, Oxford, UK * 1998, LNCS 1608, Braga, Portugal * 1996, LNCS 1129, Olympia, WA, USA * 1995, LNCS 925, Baastad, Sweden ------------------------------------------------------------------------ *The goals of this series of schools are* * Bring computer scientists, in particular young researchers and programmers, up to date with the latest AFP techniques. * Use AFP techniques in "programming in the real world". * Bridge the gap between results presented at programming conferences and material from introductory textbooks on functional programming. *The approach we take to achieve these goals in the schools is* * In depth lectures about AFP techniques, taught by experts in the field. * Lectures are accompanied by practical problems to be solved by the students at the school. The problems guide the students' learning to a great extent. This implies that there has to be a lab at the school site. * Group work is stimulated, especially because the practical problems will typically be too large for a single person. By functional programming we mean programming in a style that emphasizes the evaluation of expressions rather than the execution of commands. ------------------------------------------------------------------------ The lecture notes of the Advanced Functional Programming schools are published after the school. The organizers are responsible for publishing the lecture notes. Please submit a proposal for organizing the next advanced functional programming school. *Your proposal should include* * the name of the organizers (preferably more than one) * a programme: lecturers (a mix of young and bright, and old and wise lecturers is preferred) and topics (keep in mind that lectures have to be about "programming in the real world". Applications of functional programming are very important for the school) * the approximate dates (preferably somewhere in 2010) * a location * a budget, including an estimation of the registration and hotel costs per participant. The programme, dates, location and budget don't have to be completely fixed when you submit your proposal, but there should be sufficient information to review your proposal. Your proposal will be reviewed by the steering committee of the Advanced Functional Programming Schools, consisting of · Peter Achten (AFP6) * Pedro Henriques (AFP3) * Johan Jeuring (AFP4, AFP5) * Simon Peyton Jones (AFP4) * Pieter Koopman (AFP6) * Erik Meijer (AFP2) * Rinus Plasmeijer (Chairman, AFP6) * Tim Sheard (AFP2) * Doaitse Swierstra (AFP3, AFP6) * Tarmo Uustalu (AFP5) * Varmo Vene (AFP5) Submit your proposal to rinus(a)cs.ru.nl before December 15, 2009. Notification January 9, 2010.

1 0

Re: Type checker's expected and inferred types (reformatted)
by John Lato 31 Oct '09

31 Oct '09

> From: Isaac Dupree <ml(a)isaac.cedarswampstudios.org> > David Menendez wrote: >> On Sun, Oct 25, 2009 at 1:37 PM, Isaac Dupree >> <ml(a)isaac.cedarswampstudios.org> wrote: >>> David Menendez wrote: >>>> The expected type is what the context wants (it's *ex*ternal). The >>>> inferred type is what the expression itself has (it's *in*ternal). >>>> >>>> So inferring the type Maybe () for bar seems wrong. >>> well, maybe GHC just gets it wrong enough of the time, that I got confused. >>> >>> Or maybe ... When there are bound variables interacting, on the inside and >>> outside, it gets confusing. >>> >>> >>> ghci: >>> Prelude> \x -> (3+x) + (length x) >>> >>> <interactive>:1:15: >>> Couldn't match expected type `[a]' against inferred type `Int' >>> In the second argument of `(+)', namely `(length x)' >>> In the expression: (3 + x) + (length x) >>> In the expression: \ x -> (3 + x) + (length x) >>> >>> Your explanation of "expected" and "inferred" could make sense to me if the >>> error message followed the "Couldn't match" line with, instead, >>> "In the first argument of `length', namely `x'" >>> because 'length' gives the context of expected list-type, but we've found >>> out from elsewhere (a vague word) that 'x' needs to have type Int. >> >> This had me confused for a while, but I think I've worked out what's >> happening. (+) is polymorphic, ... > > Oh darn, it sounds like you're right. And polymorphism is so common. I > just came up with that example randomly as the first nontrivial > type-error-with-a-lambda I could think of... I think this is a great example of why the current type errors are not as helpful as they could be. The code where the type checker determines 'x' has type [a] is several steps removed from where the error arises. This is how I understand this process (I've probably left out some details): 1. checker infers x :: [a] from 'length x' 2. checker infers (3 + x) :: [a] from (+) and step 1 3. checker infers the second (+) :: [a] -> [a] -> [a] from step 2 4. conflict - checker expects (length x) :: [a] from step 3 and infers (length x) :: Int from definition of 'length'. Even with this simple example the error message given doesn't directly point to the problem. I don't think it's uncommon for there to be more steps in practice. I frequently find myself adding explicit type signatures to let-bound functions to debug these. This is a pain because it also usually involves enabling ScopedTypeVariables. I personally would find it useful if error messages showed the sequence of how the type checker determined the given context. Especially if it would also do so for infinite type errors, which don't provide much useful information to me. Cheers, John

3 3

GHC, CPP and stringize
by Neil Brown 30 Oct '09

30 Oct '09

Hi, The GHC manual says that if you pass -cpp to GHC, it runs the C preprocessor, "cpp" on your code before compilation (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html…) But why, in that case, does stringize not seem to work when the -cpp flag is given? In my example, test.hs is using the C preprocessor with a simple macro to trace functions with their name. Running GHC with -cpp gives an error, but if I run cpp on the file directly then feed it to GHC, I get no error: ===== *$ ghc --version* The Glorious Glasgow Haskell Compilation System, version 6.10.3 *$ cat test.hs* import Debug.Trace #define TR(f) (trace #f f) main :: IO () main = TR(putStrLn) "Hello!" *$ ghc -cpp --make test.hs* [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:6:14: Not in scope: `#' *$ cpp test.hs* # 1 "test.hs" # 1 "<built-in>" # 1 "<command-line>" # 1 "test.hs" import Debug.Trace main :: IO () main = (trace "putStrLn" putStrLn) "Hello!" *$ cpp test.hs > test-cpp.hs* *$ ghc -cpp --make test-cpp.hs* [1 of 1] Compiling Main ( test-cpp.hs, test-cpp.o ) Linking test-cpp ... *$ ./test-cpp* putStrLn Hello! ===== What am I missing? Thanks, Neil.

2 1

RE: [Template-haskell] How to extract name and type of exported functions in modules
by Simon Peyton-Jones 30 Oct '09

30 Oct '09

| First I thought I would examine the source code of template-haskell | (more specifically qLocation and qReify) to figure out how to do it | but got stuck. Obviously I have still much to learn when it comes to | Haskell. | | Could someone explain how Quasi works? Have you read the paper? Referred to from here http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.ht…, the particular bit you want is Section 10 of http://research.microsoft.com/~simonpj/papers/meta-haskell/notes2.ps | The only way this can work (as fast as I can see) is if where is | another instance of Quasi than Q and IO but I cannot find that | instance in the source code. Yes indeed there is -- the type checker monad! See TcSplice line 819. Simon

1 0

RE: Update on GHC 6.12.1
by Simon Peyton-Jones 29 Oct '09

29 Oct '09

| Bulat, that would not be in the ghc tradition of breaking existing | programs in every release. ;) Oh cruel, cruel, cruel! And unjustified to boot. My proposal (perhaps unclear) was exactly as Bulat suggests. However I'm sure we'll find some other way of breaking existing programs :-) Simon | -----Original Message----- | From: Lennart Augustsson [mailto:lennart.augustsson@gmail.com] | Sent: 29 October 2009 10:25 | To: Bulat Ziganshin | Cc: Simon Peyton-Jones; GHC users | Subject: Re: Update on GHC 6.12.1 | | Bulat, that would not be in the ghc tradition of breaking existing | programs in every release. ;) | | -- Lennart (iPhone) | | On 29 Oct 2009, at 03:33, Bulat Ziganshin <bulat.ziganshin(a)gmail.com> | wrote: | | > Hello Simon, | > | > Thursday, October 29, 2009, 1:55:00 AM, you wrote: | > | >> Currently 'mdo' is enabled by -XRecursiveDo. So we propose to | >> deprecate this flag, with another flag -XDoRec to enable the 'rec' | >> keyword. | > | > i think the best way is to support both in 6.12, marking mdo usage as | > deprecated, and remove it in one of next versions | > | > -- | > Best regards, | > Bulat mailto:Bulat.Ziganshin@gmail.com | > | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users(a)haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

ghc hung by FunctionalDependencies/UndecidableInstances
by Roland Zumkeller 29 Oct '09

29 Oct '09

Hi, ghc seems to hang and eat memory when fed the following code: {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, UndecidableInstances #-} class C a b | a -> b where f :: a -> b newtype T a = T a instance (C a b, Eq b) => Eq (T a) where (==) = undefined g x = (undefined :: a -> a -> a -> ()) (T x) (f x) (undefined :: Eq a => a) Is this a bug? Best, Roland -- http://alacave.net/~roland/

2 1

Coinductive proofs of type class instances
by Louis Wasserman 28 Oct '09

28 Oct '09

Hey all, There was a discussion<http://www.nabble.com/Resolving-overloading-loops-for-circular-constraint-g…>a while back about coinductive proofs of type class instances, discussing a problem I'd encountered independently, and worked out a rough solution to. I wanted to see if that solution had been reached by other people, and throw it into the mix. My problem is slightly different, though, so it may not generalize. First consider the problem that GHC doesn't allow type equality constraints in class definitions, so for example, > class (F a ~ b) => Foo a b In particular, if I wanted F a to be *uniquely* associated with A, I might say that > class (F a ~ b) => Foo a b | b -> a where > type F a As a result, F would be a *bijective type family*, enforced by the type system. Interestingly, the GHC docs suggest something like this as an implementation for functional dependencies in general: > class Foo a b | a -> b is equivalent to > class (F a ~ b) => Foo a b where > type Foo a except, of course, the latter isn't implemented in 6.10.4. All of this is idealized though: if GHC allowed equality constraints in superclass contexts, then this would be nice. Here was my workaround: a type class Foo is essentially a list of methods foo1 :: Foo a => ..... foo2 :: Foo a => ..... Of course, if there are superclass constraints on Foo a, those are implicitly included here. My thought was that > class (F a ~ b) => Foo a b where > foo1 :: (constraints1) => ... is essentially equivalent to > class Foo a b where > foo1 :: (F a ~ b, contraints1) => ... save that everywhere we encounter a (Foo a b) constraint, we replace it with (Foo a b, F a ~ b). Now, of course, we might have a (Foo a b) constraint in another superclass context, and have to recurse. That might even be fine, though I haven't worked it out. For this particular example, though, (Foo a (F a)) is equivalent to (F a ~ b, Foo a b). This approach actually, I think, works out some coinductive issues, if we apply this approach to issues besides type equality constraints. Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

1 0

ghc search paths (like CPATH for gcc)
by Misha Aizatulin 28 Oct '09

28 Oct '09

Hello, is there a mechanism for ghc similar to setting the CPATH variable for gcc? I'd like ghc to look in the given list of paths every time it compiles something, without me having to retype the flags. For ghci there is .ghci, but it gets ignored when I run ghc. Best, Misha

2 2