- Glasgow-haskell-users

Compiling 6.6 repos on Mac OS X
by C.M.Brown 03 Jan '07

03 Jan '07

Hi, I have recently tried to compile the 6.6 version of ghc from the darcs repository. I followed the intructions to pull ghc from the repository: darcs get --partial http://darcs.haskell.org/ghc-6.6/ghc cd ghc chmod +x darc-add ./darcs-add -extra pull The build process seems to get past stage 1, but fails at the beginning of stage 2: ../compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-fno-strict-aliasing -H16m -O -optc-O2 -static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -c Linker.c -o Linker.o Linker.c: In function 'loadObj': Linker.c:1383:0: error: 'misalignment' undeclared (first use in this function) Linker.c:1383:0: error: (Each undeclared identifier is reported only once Linker.c:1383:0: error: for each function it appears in.) make[1]: *** [Linker.o] Error 1 make: *** [stage1] Error 1 I am compiling this with ghc-6.6 (the latest version from darcs) and gcc 4.0. Kind regards, Chris.

1 0

Dumping context reduction steps
by Misha Aizatulin 02 Jan '07

02 Jan '07

hi, is there some command line switch in GHC that would allow me to see context reduction steps during the compilation? Thanks, Misha

2 1

Coverage Condition fails
by Adrian Hey 02 Jan '07

02 Jan '07

Hello folks, Could somebody explain what a coverage condition is and what this error message means.. "Illegal instance declaration for 'GT (GT2 map1 map2) (k1,k2)' (the Coverage Condition fails for one of the functional dependencies) In the instance declaration for 'GT (GT2 map1 map2) (k1,k2)'" The offending code looks like this.. > -- Generalsed Trie map class > class Ord k => GT map k | map -> k , k -> map where > -- Map type for pairs > newtype (GT2 map1 map2 a) = GT2 (map1 (map2 a)) > -- Which is an instance of GT > instance (GT map1 k1, GT map2 k2) => GT (GT2 map1 map2) (k1,k2) where This is with ghc 6.6. The strange thing is this code used to compile fine with earlier versions (but I don't know if it actually worked because I never tested it). Thanks -- Adrian Hey

2 2

Second Call for Papers: TFP 2007, New York, USA
by TFP 2007 31 Dec '06

31 Dec '06

CALL FOR PAPERS Trends in Functional Programming 2007 New York, USA April 2-4, 2007 http://cs.shu.edu/tfp2007/ 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 through acceptance by extended abstracts. A formal post-symposium refereeing process then selects the best articles presented at the symposium for publication in a high-profile volume. TFP 2007 is co-hosted by Seton Hall University and The City College of New York (CCNY) and will be held in New York, USA, April 2-4, 2007 at the CCNY campus. The TFP symposium is the successor to the successful series of Scottish Functional Programming Workshops. Previous TFP symposia were held in Edinburgh, Scotland in 2003 (co-located with IFL), in Munich, Germany in 2004, in Tallinn, Estonia in 2005 (co-located with ICFP and GPCE), and in Nottingham, UK in 2006 (co-located with Types). For further general information about TFP please see the TFP homepage at http://cs.shu.edu/tfp2007/ . SCOPE OF THE SYMPOSIUM The symposium recognizes that new trends may arise through various routes. 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 Articles leading-edge, previously unpublished research work Position Articles on what new trends should or should not be Project Articles descriptions of recently started new projects Evaluation Articles what lessons can be drawn from a finished project Overview Articles 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. Articles on the following subject areas are particularly welcomed: o Dependently Typed Functional Programming o Validation and Verification of Functional Programs o Debugging for Functional Languages o Functional Programming and Security o Functional Programming and Mobility o Functional Programming to Animate/Prototype/Implement Systems from Formal or Semi-Formal Specifications o Functional Languages for Telecommunications Applications o Functional Languages for Embedded Systems o Functional Programming Applied to Global Computing o Functional GRIDs o Functional Programming Ideas in Imperative or Object-Oriented Settings (and the converse) o Interoperability with Imperative Programming Languages o Novel Memory Management Techniques o Parallel/Concurrent Functional Languages o Program Transformation Techniques o Empirical Performance Studies o Abstract/Virtual Machines and Compilers for Functional Languages o New Implementation Strategies o 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 2007 program chair, Marco T. Morazan, at tfp2007(a)shu.edu. BEST STUDENT PAPER AWARD TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A prize for the best student paper is awarded each year. SUBMISSION AND DRAFT PROCEEDINGS Acceptance of articles for presentation at the symposium is based on the review of extended abstracts (6 to 10 pages in length) by the program committee. Accepted abstracts are to be completed to full papers before the symposium for publication in the draft proceedings and on-line. The submission must clearly indicate to which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate whether the main author or authors are research students. Formatting details can be found at the TFP 2007 website. Submission procedures will be posted on the TFP 2007 website as the submission deadline is reached. The papers in the draft proceedings will also be made available on-line under the following conditions, with which all authors are asked to agree: The documents distributed by this server have been provided by the contributing authors as a means to ensure timely dissemination of scholarly and technical work on a noncommercial basis. Copyright and all rights therein are maintained by the authors or by other copyright holders, notwithstanding that they have offered their works here electronically. It is understood that all persons copying this information will adhere to the terms and constraints invoked by each author's copyright. These works may not be reposted without the explicit permission of the copyright holder. POST-SYMPOSIUM REFEREEING AND PUBLICATION In addition to the draft symposium proceedings, we intend to continue the TFP tradition of publishing a high-quality subset of contributions in the Intellect series on Trends in Functional Programming. All TFP authors will be invited to submit revised papers after the symposium. These will be refereed using normal conference standards and a subset of the best papers, over all categories, will be selected for publication. Papers will be judged on their contribution to the research area with appropriate criteria applied to each category of paper. Student papers will be given extra feedback by the Program Committee in order to assist those unfamiliar with the publication process. IMPORTANT DATES Abstract Submission: February 1, 2007 Notification of Acceptance: February 20, 2007 Registration Deadline: March 2, 2007 Camera Ready Full Paper Due: March 9, 2007 TFP Symposium: April 2-4, 2007 PROGRAMME COMMITTEE John Clements California Polytechnic State University, USA Marko van Eekelen Radboud Universiteit Nijmegen, The Netherlands Benjamin Goldberg New York University, USA Kevin Hammond University of St. Andrews, UK Patricia Johann Rutgers University, USA Hans-Wolfgang Loidl Ludwig-Maximilians Universität München, Germany Rita Loogen Philipps-Universität Marburg, Germany Greg Michaelson Heriot-Watt University, UK Marco T. Morazán (Chair) Seton Hall University, USA Henrik Nilsson University of Nottingham, UK Chris Okasaki United States Military Academy at West Point, USA Rex Page University of Oklahoma, USA Ricardo Pena Universidad Complutense de Madrid, Spain Benjamin C. Pierce University of Pennsylvania, USA John Reppy University of Chicago, USA Ulrik P. Schultz University of Southern Denmark, Denmark Clara Segura Universidad Complutense de Madrid, Spain Jocelyn Sérot Université Blaise Pascal, France Zhong Shao Yale University, USA Olin Shivers Georgia Institute of Technology, USA Phil Trinder Heriot-Watt University, UK David Walker Princeton University, USA ORGANIZATION Symposium Chair: Henrik Nilsson, University of Nottingham, UK Programme Chair: Marco T. Morazan, Seton Hall University, USA Treasurer: Greg Michaelson, Heriot-Watt University, UK Local Arrangements: Marco T. Morazan, Seton Hall University, USA SPONSORS The Department of Mathematics and Computer Science, Seton Hall University The Department of Computer Science, The City College of New York The Center for Algorithms and Interactive Scientific Software of The City College of New York The Grove School of Engineering of The City College of New York We are actively looking for additional TFP sponsors, who may, for example, help to subsidise attendance by research students. If you or your organisation might be willing to sponsor TFP, or if you know someone who might be willing to do so, please do not hesitate to contact the Program Chair, Marco T. Morazan, or the Symposium Chair, Henrik Nilsson. Your students will be grateful! ************************************************************************************ Dr. Marco T. Morazan TFP 2007 Program Committee Chair http://cs.shu.edu/tfp2007/

1 0

Building GHC on Mac OS 10.2.1
by Kirsten Chevalier 30 Dec '06

30 Dec '06

Hi all, I'm trying to build the HEAD on a somewhat old PowerBook G4 running Mac OS 10.2.1. It would seem that I don't have a new enough version of gcc: % gcc --version gcc (GCC) 3.1 20020420 (prerelease) and I can't seem to build a newer version of gcc (3.3) due to missing system include files which I assume (though that assumption may be wrong) are due to running 10.2 instead of 10.4. (For the full tale of woe, see http://hackage.haskell.org/trac/ghc/wiki/KirstenSandbox) Am I right in thinking that building GHC on Mac OS 10.2.1 is more or less impossible, or has anyone managed to do it? I'm pretty close to just giving up and buying a PC (various things make it difficult for me to upgrade to Tiger). Thanks, Kirsten -- Kirsten Chevalier* chevalier(a)alum.wellesley.edu *Often in error, never in doubt "Are you aware that rushing toward a goal is a sublimated death wish? It's no coincidence we call them 'deadlines'." -- Tom Robbins

4 6

Ticket 1031 workaround?
by Adrian Hey 30 Dec '06

30 Dec '06

Hello folks, I seem to have hit this problem.. http://hackage.haskell.org/trac/ghc/ticket/1031 (I think, at least I'm getting a very similar incomprehensible error message :-) I tried using bang patterns instead of `seq` like this: > let a0_ = f a0 a in a0_ `seq` (# l,hl,a0_,r,hr #) becomes .. > let !a0_ = f a0 a in (# l,hl,a0_,r,hr #) but I still get the same error. Could someone who knows explain exactly what the problem is and what the workaround is (if there is one)? Thanks -- Adrian Hey

1 0

Curious behaviour of irrefutable pattern.
by Bertram Felgenhauer 22 Dec '06

22 Dec '06

Hi, consider this program: > module Main (f, main) where > > f ~(a:as) = 1 + f as > > main = print $ f (error "Foobar!") Obviously, the program should result in an error - the irrefutable pattern of f always succeeds, so f calls itself recursively ad infinitum and the result is <<Loop>> or nontermination. Or so I thought. Running this program after compiling with ghc -O (with 6.4.2, 6.6 and 6.7) results in: a.out: Foobar! So the 'error "Foobar!"' got evaluated. The compiler somehow replaced one 'bottom' with another which is arguably allowed. I wasn't able to come up with an example where it turned a bottom into a value or vice versa. Anyway, this looks suspicious to me, so what's happening here? regards, Bertram

4 8

inlining higher-order-functions?
by nr＠eecs.harvard.edu 22 Dec '06

22 Dec '06

I've just discovered the {-# INLINE #-} pragma, but it's not doing as much for me as I had hoped. My example is complicated, so let me present a simpler analogy. Suppose I defined compose :: (b -> c) -> (a -> b) -> (a -> c) compose f g = \x -> f (g x) I can easily persuade GHC to inline 'compose'. But when 'compose' is applied to known arguments, I wish f and g to be inlined in the body of 'compose'. Is there a pragma that will do the trick? (I attempted to put an INLINE pragma in a where clause, but GHC was not amused.) Norman

3 2

RE: [Haskell] GHC Error question
by Simon Peyton-Jones 18 Dec '06

18 Dec '06

[redirecting to ghc users] It looks like a splendid error to me. The call of compile1 is obliged to pass to compile1 a dictionary of type (Builder b box), *for any type box*. There are no further constraints on box, so compile1 can make no assumptions about how the caller chooses to instantiate 'box'. But in the body you'll need a dictionary of type (Builder b box1), but there is nothing to ensure that the caller chooses the "right" box. Maybe you want the Builder class to have a functional dependency (b -> box), so that fixing b fixes box. I can't say more without seeing the code. can you give a small repo case? Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Norman | Ramsey | Sent: 05 December 2006 21:21 | To: haskell(a)haskell.org | Cc: nr(a)eecs.harvard.edu | Subject: [Haskell] GHC Error question | | Without going too deep into the details of my type classes, I have | written the following code (focusing on compile1): | | {-# OPTIONS -fglasgow-exts #-} | | compile1 :: (Builder b box) => t -> Name -> Ir.ANF -> b t | compile1 f x body = do env <- compile body empty | wire (Arg W) (env x) | return f | | compile :: (Builder b box) => Ir.ANF -> Env box -> b (Env box) | | class (Monad b) => Builder b box where | wire :: Source box -> Sink box -> b () | ... | | type Env box = Name -> Sink box | | This program is rejected by GHC with the following message: | | Ccomp.hs:54:23: | Could not deduce (Builder b box1) from the context (Builder b box) | arising from use of `wire' at Ccomp.hs:54:23-42 | Possible fix: | add (Builder b box1) to the type signature(s) for `compile1' | In the expression: wire (Arg W) (env x) | In a 'do' expression: wire (Arg W) (env x) | In the expression: | do env <- compile body empty | wire (Arg W) (env x) | return f | | Note that compile1 has an explicit type signature much along the lines | suggested by GHC. If I *remove* this type signature, the function | compiles successfully, and ghci reporets this type for compile1: | | compile1 :: (Builder t box) => t1 -> Name -> Ir.ANF -> t t1 | | I believe this signature is isomorphic to the explicit signature I had | attempted to use. | | Am I misusing the type-class system in some way, or should I be | reporting a bug in GHC? | | | Norman | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

11 29

Network.Socket endian problem?
by Rich Neswold 15 Dec '06

15 Dec '06

Hello, I've written a program that uses UDP as its communication with other processes. It was built with GHC 6.4.1 on MacOS 10.4 (PowerPC) and works fine. When I moved the code to a Linux box (i386) and built it with GHC 6.6, it didn't work. The problems turns out to be, apparently, an endian problem. The socket is created with the following snippet: allocSocket :: IO Socket allocSocket = do { s <- socket AF_INET Datagram 0 ; handle (\e -> sClose s >> throwIO e) $ do { connect s (SockAddrInet 6802 0x7f000001) ; return s } } On the Macintosh, the socket only receives packets from 127.0.0.1:6802, which is correct (and works). On the Linux machine, the socket only accepts packets from 1.0.0.127:6802. The data constructor SockAddrInet doesn't swap the bytes of the address (although it correctly swaps the bytes of the port number!) Changing the data constructor call to (SockAddrInet 6802 0x0100007f) makes it work on Linux, but not on MacOS 10.4. (You can see what the socket is bound to, on Linux, with "netstat -aun".) I don't have access to GHC 6.4.1 on a Linux box to determine whether this is a regression in 6.6 or simply an overlooked detail. Should I file a PR? Am I doing something wrong? -- Rich AIM : rnezzy ICQ : 174908475

6 10