April 2009 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

ANNOUNCE: GHC 6.8.3 Release Candidate
by Ian Lynagh 23 Sep '09

23 Sep '09

We are pleased to announce the Release Candidate phase for GHC 6.8.3. Snapshots beginning with 6.8.2.20080527 are release candidates for 6.8.3 You can download snapshots from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src-extralib… Only the first of these is necessary. The "extralibs" package contains various extra packages that are often supplied with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There is also currently an installer for i386/Windows and binary distributions for x86_64/Linux and i386/Linux. More may appear later. Please test as much as possible; bugs are much cheaper if we find them before the release! We expect to release in a few days, assuming no major issues are discovered. Thanks Ian, on behalf of the GHC team

8 13

runghc failing sometimes on Linux/ppc?
by Jens Petersen 24 May '09

24 May '09

I am seeing some strange failures of runghc on Linux/ppc (Fedora 11 specifically) with ghc-6.10.1 and ghc-6.10.2. For example "cabal install HTTP" works fine but "runghc Setup" failing to run. A workaround (other than using cabal-install) seems to be to compile Setup and then use the output of that to build the package. More strangely this only happens sometimes in the buildsystem, which makes me wonder if it is a fedora issue: most packages built ok in the fedora buildsystem except HTTP and haddock so far. http://koji.fedoraproject.org/koji/getfile?taskID=1319083&name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=1320158&name=build.log On the other hand in a ppc box I tested on runghc seemed to fail consistently. ghci also segfaulted there. Anyway I thought I would ask here if anyone else had experienced something like this. Jens

2 5

Extensible Exceptions and IO
by Alexander Dunlap 24 May '09

24 May '09

In the extensible exceptions paper[1], which I believe is the guide behind the current Control.Exception in GHC 6.10, a SomeIOException type is discussed so that it would be possible to use the nice interface for IOExceptions. Is this implemented anywhere? In the GHC libraries, all I see is the old interface just plugged into a simple wrapper, so you have to use guard . isDoesNotExistError (for example) with catchJust to catch a certain type of exception. If not, are there any plans to implement it? Alex

2 2

Functions for builtin operators (?)
by Colin Paul Adams 11 May '09

11 May '09

Where is a function with a name like the following defined in the ghc source code? .Classes.>_ ( tpl_B6 ) I've tried searching for such names - all I can find is a comment referring to tpl_B2. -- Colin Adams Preston Lancashire

2 4

Linking and constants problems with OpenAL under Windows
by Jared 02 May '09

02 May '09

The OpenAL binding's wiki page directs questions to Haskell-Cafe, but the more serious of my problems seems to be with GHC. My platform is GHC 6.10.1 under Windows XP. This post boils down to two questions. First, why would GHCi and GHC look for different symbol names when linking, and second, has anybody had any success working with the OpenAL binding on Windows? If I write a program that uses Sound.OpenAL, I can load and run it in GHCi. If I try to compile the same program with ghc --make -lopenal32 audio.hs, I get a raft of errors like this: Linking audio.exe ... C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.10.1/libHSOpenAL-1.3.1.1.a(BufferInternal.o):fake:(.text+0x5d): undefined reference to `alIsBuffer' C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.10.1/libHSOpenAL-1.3.1.1.a(Context.o):fake:(.text+0x7d): undefined reference to `alcGetContextsDevice' C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.10.1/libHSOpenAL-1.3.1.1.a(Context.o):fake:(.text+0xcd): undefined reference to `alcMakeContextCurrent' The names do not exist in openal32.lib. They should all be preceded by an underscore. GHC does the same thing if I convert the .lib file to a .a file. But why would GHCi do the right thing and GHC do the wrong thing? Am I missing a command line switch? I manually changed configure and configure.ac, per the patches (why weren't those applied to the library in Hackage?) to use ccall since OpenAL uses ccall instead of stdcall. Was there another change I should have made? The other problem is that several routines don't work properly because the constants don't get fixed up correctly during the build process. For example, the function marshalFormat in Sound.OpenAL.AL.Format should return 0x1100 when given Word8 as a parameter. It returns -1 instead; the code tells it to, but I assume some sed-like command was supposed to patch that with the right value. Has anybody had any luck getting this to work?

2 1

Re: type checking fails with a correct type
by Daniel Fischer 02 May '09

02 May '09

Am Donnerstag 30 April 2009 18:25:43 schrieb Jan Jakubuv: > Hello Daniel, > > On Thu, Apr 30, 2009 at 05:17:42PM +0200, Daniel Fischer wrote: > > In > > > > nonsense t = case nonsense t of > > Nothing -> Just empty > > > > , which type has the Nothing? > > It can have the type Maybe s1 for all s1 belonging to SUBST, that is the > > ambiguous type variable. > > thanks for the explanation. Maybe I'm starting to understand what is going > on. Now I understand it thus the call of `nonsense` inside the case > construct can potentially result in a different `SUBST`-type `s1` than the > top-level `nonsense`. That is why it has to be explicitly typed. > > But I am still not following why the type inference works fine without the > signature. Isn't it still ambiguous? Ah, that's a tricky one :) Without the type signature, the type of nonsense has to be inferred from scratch. We start with nonsense t = rhs so nonsense is a function, taking an argument of type argT, giving a result of type resT: nonsense :: argT -> resT Now we infer the type of the rhs, resT. case nonsense t of Nothing -> Just empty or, rewritten, let r = nonsense t in case r of Nothing -> Just empty now r is the result of applying nonsense to t, hence r :: resT. So Nothing has type resT. Since Nothing :: forall a. Maybe a, we can now deduce resT === Maybe b for some b we don't know anything about yet. In case r matches Nothing, the result is (Just empty), so b is the type of empty. empty has type (SUBST s => s), giving resT === SUBST s => Maybe s and nonsense :: SUBST s => argT -> Maybe s *Now* the free type variables are quantified, giving nonsense :: forall argT s. SUBST s => argT -> Maybe s Since in Haskell, type variables are implicitly universally quantified, the "forall argT s." part isn't necessary and not displayed. Here comes the snag: If you give the (implicitly universally quantified) type signature, you explicitly say that nonsense can return a value of type Maybe s, whatever s is, as long as it's a member of SUBST. But then the type-checker cannot assume that r and Just empty have the same type, thus it sees let r = nonsense t , from which it finds r :: forall s1. SUBST s1 => Maybe s1 on the other hand, it finds Just empty :: forall s2. SUBST s2 => Maybe s2, giving nonsense the ambiguous type nonsense :: forall t s1 s2. (SUBST s1, SUBST s2) => t -> Maybe s2 You can ask GHC by compiling the module without the type signature and with the flag -ddump-simpl , the relevant part of the core is: ================================================================== Nonsense.nonsense :: forall t_agD s_agJ. (Nonsense.SUBST s_agJ) => t_agD -> Data.Maybe.Maybe s_agJ [GlobalId] [Arity 2] Nonsense.nonsense = \ (@ t_agD) -- type of argument (@ s_agJ) -- type of result is (Maybe s_agJ) ($dSUBST_agL :: Nonsense.SUBST s_agJ) -- SUBST dictionary for s_agJ (eta_shh :: t_agD) -> letrec { nonsense1_agA :: t_agD -> Data.Maybe.Maybe s_agJ -- inner nonsense, the type is fixed as that at which the outer nonsense is called, -- there is *no* forall here! [Arity 1] nonsense1_agA = \ (t_afx :: t_agD) -> case nonsense1_agA t_afx of wild_Xk { Data.Maybe.Nothing -> Data.Maybe.Just @ s_agJ ($dSUBST_agL `cast` ((Nonsense.:Co:TSUBST) s_agJ :: (Nonsense.:TSUBST) s_agJ ~ s_agJ)); Data.Maybe.Just ipv_shd -> Control.Exception.Base.patError @ (Data.Maybe.Maybe s_agJ) "Nonsense.hs:(16,13)-(17,36)|case" }; } in nonsense1_agA eta_shh ================================================================== > > > {-# LANGUAGE ScopedTypeVariables #-} > > > > nonsense :: forall s. SUBST s => t -> Maybe s > > nonsense t = case nonsense t :: Maybe s of > > Nothing -> Just empty > > Great, ScopedTypeVariables is exactly what I was looking for. It solves all > my problems. Great :D > > Thank you, > Jan. Cheers, Daniel

2 1

Re: type checking fails with a correct type
by Jan Jakubuv 01 May '09

01 May '09

On Thu, Apr 30, 2009 at 10:20:44AM -0400, Brandon S. Allbery KF8NH wrote: > > http://www.haskell.org/pipermail/haskell-cafe/2008-April/041397.html > http://hackage.haskell.org/trac/ghc/ticket/1897 > Thanks for your answer and these links. Although the issue discussed there is more related to type families which were not used in my example, it was still helpful for me. At least now I know about the "show . read" problem ;-) Jan. -- Heriot-Watt University is a Scottish charity registered under charity number SC000278.

1 0

Re: type checking fails with a correct type
by Jan Jakubuv 01 May '09

01 May '09

Hello Daniel, On Thu, Apr 30, 2009 at 05:17:42PM +0200, Daniel Fischer wrote: > In > > nonsense t = case nonsense t of > Nothing -> Just empty > > , which type has the Nothing? > It can have the type Maybe s1 for all s1 belonging to SUBST, that is the ambiguous type > variable. > thanks for the explanation. Maybe I'm starting to understand what is going on. Now I understand it thus the call of `nonsense` inside the case construct can potentially result in a different `SUBST`-type `s1` than the top-level `nonsense`. That is why it has to be explicitly typed. But I am still not following why the type inference works fine without the signature. Isn't it still ambiguous? > > {-# LANGUAGE ScopedTypeVariables #-} > > nonsense :: forall s. SUBST s => t -> Maybe s > nonsense t = case nonsense t :: Maybe s of > Nothing -> Just empty > Great, ScopedTypeVariables is exactly what I was looking for. It solves all my problems. Thank you, Jan. -- Heriot-Watt University is a Scottish charity registered under charity number SC000278.

1 0

type checking fails with a correct type
by Jan Jakubuv 01 May '09

01 May '09

Hi, I have the following problem. Below is the smallest program I have found that shows the problem. That is why the program makes no sense (I have also meaningful but more complicated program). When I run this program in ghci: class SUBST s where empty :: s --nonsense :: SUBST s => t -> Maybe s nonsense t = case nonsense t of Nothing -> Just empty then everything is fine and I can see the type signature of `nonsense` inferred by ghci: *Main> :t nonsense nonsense :: (SUBST s) => t -> Maybe s But, when I put this signature into the code (that is, when the commented line above is uncommented) then type checking fails with the following error: Ambiguous type variable `s' in the constraint: `SUBST s' arising from a use of `nonsense' at problem-type.hs:6:18-27 Probable fix: add a type signature that fixes these type variable(s) Now, what is the problem here? Why does type checking fail with the signature that the type inference itself inferred? I am developing kind of generic interface and I don't want to fix the type `s`. I want `nonsense` to work possibly for any instance of SUBST and the concrete instance to be determined by the context where `nonsense` is used. In my original, meaningful but more complicated example I had the following error: Couldn't match expected type `STerm s' against inferred type `STerm s1' When generalising the type(s) for `refute' (this message does not provide any information where `s1` comes from) The original example shares with the above one the property that the type `s` is not mentioned in types of arguments, just in the type of a result (although, in the original example, some relation between types `t` and `s` is expressed in the type context via equality constrains on associated types (STerm from the error message) ). I tested this with ghc-6.6.1, ghc-6.10.1, ghc-6.10.2 obtaining the same result. BTW, I don't understand why but everything works fine with the following addition: nonsense' :: SUBST s => t -> Maybe s nonsense' t = case nonsense' t of Nothing -> Just empty x -> x I'll be grateful for any explanation of this issue. Sincerely, Jan. -- Heriot-Watt University is a Scottish charity registered under charity number SC000278.

4 3