- Glasgow-haskell-users

6.10.3 prerelease
by Ian Lynagh 06 May '09

06 May '09

Hi all, 6.10.3 is now ready to release. There have been very few changes relative to 6.10.2; the release notes are here: http://www.haskell.org/ghc/dist/stable/docs/users_guide/release-6-10-3.html This is just to give people a chance to report any regressions relative to 6.10.2, in particular, build failures or ghci problems. Source tarballs are here: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.2.20090430-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.2.20090430-src-extrali… Unless any major problems are uncovered, we expect to build the final release in a couple of days. Thanks Ian

2 3

GHC 6.10.2 the 'impossible' panic with type families
by Jan Jakubuv 06 May '09

06 May '09

Dear haskellers, with the following code: {-# OPTIONS -fglasgow-exts #-} class SUBST s where type STerm s class OBJECT o where type OTerm o apply :: (SUBST s, OTerm o ~ STerm s) => s -> o fce' f = fce . apply $ f fce f = fce' f I have the following message in both GHCi and GHC (tested on GHC 6.10.1 linux and win, and 6.10.2 linux): ghc: panic! (the 'impossible' happened) (GHC version 6.10.2 for i386-unknown-linux): idInfo co{v agz} [tv] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug The above is the smallest example I have found that behaves in this way. It is a striped version of an original and more complicated code. What seems interesting to me is that when one defines `fce` as follows (instead of the above): fce = fce' then everything is ok (= no panic message). In my original code `fce'` was a monad computation, something like: fce' f = fce f >>= \s → fce (apply s) and this produces the same result (= the panic message). Is this a bug or a known issue? Sincerely, Jan. -- Heriot-Watt University is a Scottish charity registered under charity number SC000278.

2 1

ghc-6.10.3-pre on OS X 10.5.6
by Gregory Wright 06 May '09

06 May '09

Hi, I built ghc-6.10.2.20090504 on OS X 10.5.6 (Intel). The build succeeded, and the results of running the 6.10.2 (release) testsuite were: OVERALL SUMMARY for test run started at Wed May 6 04:21:54 EDT 2009 2413 total tests, which gave rise to 12919 test cases, of which 0 caused framework failures 2489 were skipped 10033 expected passes 301 expected failures 0 unexpected passes 96 unexpected failures Unexpected failures: 2469(ghci) 2816(ghci) DoParamM(normal) jl_defaults(ghci) jules_xref(ghci) jules_xref2(ghci) launchbury(ghci) lex(ghci) mod133(normal) num009 (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) reify (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) rittri(ghci) signals002(ghci,ghci) signals004 (ghci ,threaded1,threaded2,profthreaded,ghci,threaded1,threaded2,profthreaded) tc183(normal,optc,hpc,optasm,profc,profasm) tc217(normal,optc,hpc,optasm,profc,profasm) tc220(normal,optc,hpc,optasm,profc,profasm) tc223(normal,optc,hpc,optasm,profc,profasm) tc232(normal,optc,hpc,optasm,profc,profasm) tcfail126(normal) tree (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) (I assume that I should be testing with the latest released testsuite in the absence of a snapshot. Is that true?) Best Wishes, Greg

2 1

6.10.3-pre
by Serge D. Mechveliani 06 May '09

06 May '09

Dear GHC team, I have tested ghc-6.10.2.20090430 under Debian Linux, processor = (GenuineIntel cpu family 6, Intel(R) Core(TM)2 CPU 6400). It looks all right. The test was: 1) making ghc-6.10.2.20090430 from source by ghc-6.10.2, 2) making DoCon and running its test, 3) making Dumatel-1.06-pre and running its test, also with -enable-library-profiling and a bit of time profiling (for any future occasion: profiling is important). Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

Last CFP: Trends in Functional Programming
by Simon Marlow 06 May '09

06 May '09

[ Forwarding on behalf of Horváth Zoltán <hz(a)inf.elte.hu> ] Last call for papers 10th SYMPOSIUM ON TRENDS IN FUNCTIONAL PROGRAMMING TFP 2009 SELYE JANOS UNIVERSITY, KOMARNO, SLOVAKIA June 2-4, 2009 http://www.inf.elte.hu/tfp_cefp_2009 *** Submission deadline extended until 10th of May! *** The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming languages, focusing on providing a broad view of current and future trends in Functional Programming. It aspires to be a lively environment for presenting the latest research results. Acceptance for the conference is based on full papers or extended abstracts, and a formal post-symposium refereeing process selects the best articles presented at the symposium for publication in a high-profile volume. TFP 2009 is hosted by the Selye Janos University, Komarno, Slovakia, and it is co-located with the 3rd Central-European Functional Programming School (CEFP 2009), which is held immediately before TFP 2009 (May 25-30). IMPORTANT DATES (ALL 2009) * Paper Submission: May 10 (extended) * Notification of Acceptance: May 12 * Camera Ready Symposium Proceedings Paper: May 14 * TFP Symposium: June 2-4, 2009 * Post Symposium Paper Submission: June 30 * Notification of Acceptance: September 7 * Camera Ready Revised Paper: September 21 SCOPE OF THE SYMPOSIUM As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: * Research: leading-edge, previously unpublished research. * Position: on what new trends should or should not be. * Project: descriptions of recently started new projects. * Evaluation: what lessons can be drawn from a finished project. * Overview: summarizing work with respect to a trendy subject. Articles must be original and not submitted for simultaneous publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience- oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Contributions on the following subject areas are particularly welcomed: * Dependently Typed Functional Programming * Validation and Verification of Functional Programs * Debugging for Functional Languages * Functional Programming and Security * Functional Programming and Mobility * Functional Programming to Animate/Prototype/Implement Systems from Formal or Semi-Formal Specifications * Functional Languages for Telecommunications Applications * Functional Languages for Embedded Systems * Functional Programming Applied to Global Computing * Functional GRIDs * Functional Programming Ideas in Imperative or Object-Oriented Settings (and the converse) * Interoperability with Imperative Programming Languages * Novel Memory Management Techniques * Parallel/Concurrent Functional Languages * Program Transformation Techniques * Empirical Performance Studies * Abstract/Virtual Machines and Compilers for Functional Languages * New Implementation Strategies * Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2009 program chairs, Zoltan Horvath and Viktoria Zsok at tfp2009(a)inf.elte.hu <mailto:tfp2009@inf.elte.hu> SUBMISSION AND DRAFT PROCEEDINGS Acceptance of articles for presentation at the symposium is based on the screening process of full papers (15 pages) and extended abstracts (at least 3 pages). TFP encourages PhD students to submit papers. PhD students may request the program committee to provide extensive feedback on their full papers at the time of submission. Full papers describing work accepted for presentation must be completed before the symposium for publication in the draft proceedings. Further details can be found at the TFP 2009 website. POST-SYMPOSIUM REFEREEING AND PUBLICATION In addition to the draft symposium proceedings, we continue the TFP tradition of publishing a high-quality subset of contributions in the Intellect series on Trends in Functional Programming. PROGRAM COMMITTEE * Peter Achten (symp-chair), Radboud University Nijmegen, NL * John Clements, California Polytechnic State University, USA * Cormac Flanagan, University of California at Santa Cruz, USA * Jurriaan Hage, Utrecht University, NL * Kevin Hammond, University of St. Andrews, UK * Michael Hanus, Christian-Albrechts University zu Kiel, DE * Ralf Hinze, University of Oxford, UK * Zoltan Horvath (PC co-chair), Eotvos Lorand University, HU * Graham Hutton, University of Nottingham, UK * Johan Jeuring, Utrecht University, NL * Pieter Koopman (symp-chair), Radboud University Nijmegen, NL * Hans-Wolfgang Loidl, Ludwig-Maximilians University Munchen, DE * Rita Loogen, Philipps-University Marburg, DE * Greg Michaelson, Heriot-Watt University, UK * Marco T. Morazan, Seton Hall University, USA * Rex L Page, University of Oklahoma, USA * Sven-Bodo Scholz, University of Hertfordshire, UK * Clara Segura, University Complutense de Madrid, ES * Mary Sheeran, Chalmers University of Technology, SE * Phil Trinder, Heriot-Watt University, UK * Marko van Eekelen, Radboud University Nijmegen, NL * Varmo Vene, University of Tartu, EE * Viktoria Zsok (PC co-chair), Eotvos Lorand University, HU LOCATION The Conference Centre of Selye University, Komarno, Slovakia (http://www.selyeuni.sk/) is a new and excellent conference centre with modern equipment, lecture rooms and computer labs. Komarno is on the north bank of river Danube, the northern part of the city Komarom / Komarno. It is a charming old city with about 30 000 inhabitants, 90 km away from Budapest (the capital of Hungary), with good highway and railway connections and 90 km away from Bratislava (the capital of Slovakia), about 100 km from Vienna International Airport.

1 0

Problems with Network.Socket.getAddrInfo under MacOS 10.5, GHC 6.10.2?
by Neil Davies 05 May '09

05 May '09

Hi, It does not appear that you can access the 'addrFlags' returned by getAddrInfo, you get the exception: *** Exception: unpackBits: unhandled bits set: 8 Is this just a MacOS issue? Should I raise a ticket for it? Cheers Neil GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :m Network.Socket Prelude Network.Socket> getAddrInfo Nothing (Just "localhost") Nothing Loading package syb ... linking ... done. Loading package base-3.0.3.1 ... linking ... done. Loading package parsec-2.1.0.1 ... linking ... done. Loading package network-2.2.1 ... linking ... done. [AddrInfo {addrFlags = *** Exception: unpackBits: unhandled bits set: 8 Prelude Network.Socket>

3 5

ghc 6.10.3-prerelease failed build log for freebsd7.2
by brad clawsie 05 May '09

05 May '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi after some trying, i was unable to get the 6.10.3 prerelease to build on freebsd 7.2. i was trying to use an existing 6.10.2 as my build ghc. i saved the output of the entire build from ./configure to the point of failure. it is too long too attach here, you can see it at: http://www.b7j0c.org/ghc-6.10.3.log.txt it is about 4.4mb thanks brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkn+hQMACgkQxRg3RkRK91PGgACfWYJy9sIt6Nx1QxM+nkqXYMl3 pLIAoIDf6yw25VymUFPpdIG5L0B/gF2K =lwwy -----END PGP SIGNATURE-----

2 2

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 01 May '09

01 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 30 Apr '09

30 Apr '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