October 2006 - Glasgow-haskell-users

Bad interface file error with GHC RC2
by Krasimir Angelov 05 Oct '06

05 Oct '06

When I tried to build VSHaskell with the RC2 version of GHC I got the following error: src\lib\Registry.hsc:30:0: Bad interface file: C:\Program Files\Haskell\comlib-0.1\ghc-6.5.20061001/Com Dll.hi Something is amiss; requested module comlib-0.1:ComDll differs from nam e found in the interface file comlib:ComDll Am I doing something wrong or it is a bug? The COM library is built using Cabal. Cheers, Krasimir

4 6

testing 6.6-pre-2
by Serge D. Mechveliani 05 Oct '06

05 Oct '06

Concerning Ian's call for testing of ghc-6.6-pre-reslease-II: I have tested it on my projects DoCon-2.09 and Dumatel-1.06, it looks all right. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

GHC Under Wine
by Robert Marlow 05 Oct '06

05 Oct '06

Hi all I've succeeded in getting GHC to run under wine. I wrote a small guide on how to do it here: http://www.haskell.org/haskellwiki/GHCUnderWine So far it seems to work fairly well. I'll update the above page as I run into problems. (My interest in running GHC under wine is that I wanted to compile windows binaries but have no copy of MS Windows to do it under. Wine seems to be a viable solution for this). -- Robert Marlow <bobstopper(a)bobturf.org>

1 0

Re[2]: [Haskell-cafe] Re: [Haskell] Re: compiler-independent core libraries infrastructure
by Bulat Ziganshin 03 Oct '06

03 Oct '06

Hello John, (i'm moving thread to the ghc-users where this discussion continues in ghc-related aspects) Thursday, September 28, 2006, 3:30:09 AM, you wrote: >> So, just to confirm in my mind what you are proposing: >> >> Compiler/Version specific Core: >> >> Yhc.Core, Hugs.Core, GHC.Core .... >> >> With a different version for each compiler version. Tied intimately to >> the compiler. > A large issue with this, is that what needs to be tied intimately to the > complier is very different for different compilers. for instance > Data.Typeable and Data.Dynamic are fairly portableish haskell on ghc, > but are primitives provided by the compiler in jhc as a very simple > example. module JHC.Dynamic: .... module Data.Dynamic: #ifdef JHC import JHC.Dynamic #else -- make portable definitions #endif in general, compiler-specific code should go into *hc-core libraries while the "default implementations" into the common core package i have experience of multi-OS development. it is not the solution to write program tied to API of some OS or two and then make complex translation layer for all other OSes. instead, i select the common subset of APIs and try to use only it. if that's impossible, i make the translation layers that gives OS-neutral names to common functionality and masks OS-specific details > It leads to the current mess with the jhc libraries where it has bits > and pieces of base. I can't just use base as is, because it implements a > lot that jhc needs to implement natively or expects things that GHC.* > provides, but Jhc.* doesn't, or at least provides with a different > interface/semantics (and #ifdefs or tieing jhc's development with the > fptools repos are not acceptable solutions) However, a lot of stuff > depends on libraries provided by base, so I can't just ignore it. > so I end up syncing some code from base, modifying some, having a big > mess that is somewhat tricky to maintain. yes, jhc will get the largest benefit if this project succeeds - and even partial success will mean that jhc may get some better libraries than now. i don't imagine that i can develop some theoretical scheme in which each compiler will fit - vice versa, the plan is to look at all the compilers that are worth to support (now it's ghc, hugs, nhc, yhc and jhc) and realize what the common API for all them may be. if support for one more original compiler will be added in future to Core then API may need to change again. > In any case, haskell-prime will clean this up some by giving a more > complete compiler-provided set of libraries, and it looks like the > fptools repos are moving in the right direction with modularization. i don't understand how H' will help jhc - with any library report you will need to implement it yourself :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 2

Core package: attempt #1
by Bulat Ziganshin 03 Oct '06

03 Oct '06

Hello glasgow-haskell-users, i've uploaded my first attempt to define Core package as http://www.haskell.org/bz/core20061003.tar.gz you should use -fno-implicit-prelude to compile it with GHC. it also compiles with Hugs, although zeroInt and other constant definitions are definitely wrong :) it's impossible to define them before fromInteger arrived! as you can see, compiler-specific definitions are very short here, much of code is in compiler-independent modules. i hope that adding yhc and jhc support should be rather simple of course, it's just proof-of-concept implementation and it shows me that Igloo was not too wrong ;) - it's really hard to define anything in absence of type classes with at least Int/Integer instances of them so now i want to try another way, that is rather like GHC.* actual implementation - define rather large Core.Base module that will contain all the base classes together with Int/Integer implementations so that all the circular dependencies will be satisfied so while my original proposal was to use Core.* modules as "equalizer" which implements the same class-less interface for all compilers (Int, eqInt, addInt...) - now i will add to Core.* implementation of base classes which will make "equalizing" a much easier (look, for example, how i implemented now divInt in Core.Int) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 2

GHC on MacOS
by Simon Peyton-Jones 03 Oct '06

03 Oct '06

Folks Quite a few of you are using GHC on MacOS -- for example, there were lots of Macs at the GHC Hackathon earlier this month. However, we don't have access to a machine running MacOS, so it's pretty difficult for us to deal with bug reports. So this message is to ask: a) Can anyone give us remote access to a Mac? b) Does anyone feel able to help look after GHC's Mac port? Simon, Simon, and Ian

6 7

Problem with lexically scoped type variables.
by Mirko Rahn 03 Oct '06

03 Oct '06

Dear all, in http://www.haskell.org/pipermail/glasgow-haskell-users/2006-January/009565.… Simon Peyton-Jones asks for programs that are broken by the proposed change. Here is a nearly real world one: {-# OPTIONS_GHC -fglasgow-exts #-} import Control.Monad import Control.Monad.ST import Data.Array.MArray import Data.Array.ST import Data.STRef import Data.Set hiding (map,filter) -- a store that allows to mark keys class Mark m store key | store -> key m where new :: (key,key) -> m store mark :: store -> key -> m () markQ :: store -> key -> m Bool seen :: store -> m [ key ] -- implementation 1 instance Ord key => Mark (ST s) (STRef s (Set key)) key where new _ = newSTRef empty mark s k = modifySTRef s (insert k) markQ s k = liftM (member k) (readSTRef s) seen s = liftM elems (readSTRef s) -- implementation 2 instance Ix key => Mark (ST s) (STUArray s key Bool) key where new bnd = newArray bnd False mark s k = writeArray s k True markQ = readArray seen s = liftM (map fst . filter snd) (getAssocs s) -- traversing the hull suc^*(start) with loop detection trav suc start i = new i >>= \ c -> mapM_ (compo c) start >> return c where compo c x = markQ c x >>= flip unless (visit c x) visit c x = mark c x >> mapM_ (compo c) (suc x) -- sample graph f 1 = 1 : [] f n = n : f (if even n then div n 2 else 3*n+1) t1 = runST (trav f [1..10] (1,52) >>= \ (s::STRef s (Set Int)) -> seen s) t2 = runST (trav f [1..10] (1,52) >>= \ (s::STUArray s Int Bool) -> seen s) In ghc-6.4.2 this works as expected, but ghc-6.5.20061001 says B.hs:40:44: A pattern type signature cannot bind scoped type variables `s' unless the pattern has a rigid type context In the pattern: s :: STRef s (Set Int) In a lambda abstraction: \ (s :: STRef s (Set Int)) -> seen s In the second argument of `(>>=)', namely `\ (s :: STRef s (Set Int)) -> seen s' Unfortunately I cannot find an easy workaround but use similiar patterns somewhere deeply nested in my programs... Is there a simple workaround? Could we relax the rules for lexically scoped type variables a bit? Regards, Mirko Rahn -- -- Mirko Rahn -- Tel +49-721 608 7504 -- --- http://liinwww.ira.uka.de/~rahn/ ---

3 6

GHC on MacOS
by Aaron Tomb 03 Oct '06

03 Oct '06

Hello, I have an Intel Mac laptop which isn't reliably accessible remotely, but which I'm happy to use to test and (hopefully) help fix GHC builds. I'm not positive that I'll have tons of available time, but I suspect I'll have enough to do at least some good. Right now, I have the ghc-6.6 branch (as of 2006-10-01) built and running happily. Given a recent binary to bootstrap with, the standard configure/make/make install process just works. Everything I've tried to compile with it has worked, but there are a number of areas that I'm sure I haven't touched. I went to the GHC Hackathon, so I have some idea of how GHC works internally at this point, and I'd love a chance to poke around and try to fix things as they come up. Since I haven't come across any problems so far, does anyone else have experience they would like to share? Someone mentioned STM, but didn't say much. There are only three tickets in Trac that seem specific to OS X, though I may be missing something. I'll run the test suite tonight and see how it fares. Aaron

1 0

Map.genericSize
by Serge D. Mechveliani 02 Oct '06

02 Oct '06

Dear GHC developers, Can you, please, provide Map.genericSize :: Map -> Integer in addition to Map.size :: Map -> Int ? For I use `Map.size', a bit, and need its variant which is both O(1) and Integer (because Int is less reliable). Probably, this is not hard to arrange. The same request is for Data.Set. What do you think of this? ----------------- Serge Mechveliani mechvel(a)botik.ru

5 4

Re: FW: [GHC] #916: windows installer should play nice with otherHaskell tools
by Claus Reinke 01 Oct '06

01 Oct '06

Simon, Sigbjorn, we have updated the wiki page http://haskell.org/haskellwiki/Installers and would welcome your feedback. (only cc-ed to ghc-users for now, as ghc's is the next installer to be expected; once ghc is on board, we can ask others) Initially, we were tempted to try and specify some ideal installation world, but that turned out to be complicated and unlikely to be something all Haskellers could agree on. So we chose to tackle the issue from the other side instead, trying to pin down the issues on which different installers must not get in each other's way. An oversimplified micro-summary is "hands off, unless the user wants it" - installers should agree on a common file type, lest they disable each other inadvertedly, and they should permit users to bypass file name extension association, file type action registration (right-click menu), and setting of the default action (double-click). That should hopefully enable initial conformance with minimal changes, as the next release is imminent (though I'm led to believe that nothing is straightforward about creating Windows installers;-). Once the various installers no longer get in each other's way, things can grow from there, later. Over to you, Claus and Neil ----- Original Message ----- From: "Simon Peyton-Jones" <simonpj(a)microsoft.com> To: "Claus Reinke" <claus.reinke(a)talk21.com>; "Neil Mitchell" <ndmitchell(a)gmail.com> Cc: "Sigbjorn Finne" <sof(a)galois.com> Sent: Friday, September 29, 2006 11:38 AM Subject: RE: FW: [GHC] #916: windows installer should play nice with otherHaskell tools Claus, Neil This is all v helpful. Can you let Sigbjorn (and me) know when you have converged to a common mind, so that he can think about how to implement it? No point in doing work until there is an agreed spec! Thanks Simon

2 1