From ganesh at earth.li Sat Dec 1 18:08:56 2007 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat Dec 1 18:04:36 2007 Subject: fundeps help Message-ID: Hi, I'm trying to understand what fundeps do and don't let me do. One particular source of confusion is why the following program doesn't typecheck: {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-} module Fundeps where class Dep a b | a -> b, b -> a conv :: (Dep a b1,Dep a b2) => b1 -> b2 conv = id {- end of program -} It seems as if inferring that b1 = b2 is precisely what "improvement" is about, but I'm not really sure when GHC actually applies that. Is there any documentation of that? I've read Mark Jones' paper, the haskell-prime wiki entry about Fundeps and the GHC manual but am still rather lost. Cheers, Ganesh From bulat.ziganshin at gmail.com Sun Dec 2 09:11:42 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Dec 2 09:08:19 2007 Subject: win32&ghc: using more than 2gb of memory Message-ID: <1333179170.20071202171142@gmail.com> Hello is it possible to use more than 2gb of memory for win32 ghc-compiled programs? does anyone checked this? i've found that the following switch should be added to cmdline: ghc ... -optl --large-address-aware but can't check compiled executable if this question was never considered, here is some possible problems which may arise: http://blogs.msdn.com/oldnewthing/archive/2004/08/12/213468.aspx -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Mon Dec 3 03:10:42 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Dec 3 03:06:20 2007 Subject: GHC generated dll makes Excel crash on exit. In-Reply-To: References: Message-ID: Better still, could you add a section to that page about DLLs and Excel? That'd be useful for others. Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Olivier Boudry Sent: 30 November 2007 18:09 To: glasgow-haskell-users@haskell.org Subject: Re: GHC generated dll makes Excel crash on exit. Sorry if I'm talking to myself, but I found a solution and thought it could be interesting for other people who need to call GHC created DLLs from Excel. The solution is based on the information found in : http://haskell.org/haskellwiki/GHC/Using_the_FFI#Debugging_Haskell_DLLs. As suggested, I added two extra functions in my dllMain.c file (adder_Begin, adder_End) and removed the startupHaskell call from the dllMain function. adder_Begin contains the startupHaskell call and adder_End the shutdownHaskell. dllMain just returns true. I also adapted the Excel VBA code to call adder_Begin on a WorkBook_Open event and adder_End on a WorkBook_BeforeClose event. The VBA looks like this: Public functions in a new "Module1" module (cannot declare Public functions in the ThisWorkbook module): Public Declare Function adder Lib " adder.dll" Alias "adder@8" (ByVal x As Long, ByVal y As Long) As Long Public Declare Function adder_Begin Lib "adder.dll" () As Boolean Public Declare Sub adder_End Lib "adder.dll" () Private functions the the "ThisWorkbook" module: Private Sub Workbook_BeforeClose(Cancel As Boolean) adder_End End Sub Private Sub Workbook_Open() adder_Begin End Sub The GHC dllMain.c looks like this: #include #include #define __ADDER_DLL_EXPORT #define ADDER_API _declspec(dllexport) extern void __stginit_Adder(void); static char* args[] = { "ghcDll", NULL }; /* N.B. argv arrays must end with NULL */ BOOL STDCALL DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ){ return TRUE; } ADDER_API BOOL adder_Begin(){ startupHaskell(1, args, __stginit_Adder); return HS_BOOL_TRUE; } ADDER_API void adder_End(){ shutdownHaskell(); } If somebody wants the code and Excel file, just ask, I'll be happy to provide it. Thanks, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20071203/e7ae3b59/attachment.htm From simonpj at microsoft.com Mon Dec 3 03:56:26 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Dec 3 03:52:05 2007 Subject: win32&ghc: using more than 2gb of memory In-Reply-To: <1333179170.20071202171142@gmail.com> References: <1333179170.20071202171142@gmail.com> Message-ID: GHC definitely does not assume that the top bit is of an address is clear. But I don't know that anyone has explicitly tested it on a 3Gb program. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of | Bulat Ziganshin | Sent: 02 December 2007 14:12 | To: glasgow-haskell-users@haskell.org | Subject: win32&ghc: using more than 2gb of memory | | Hello | | is it possible to use more than 2gb of memory for win32 ghc-compiled | programs? does anyone checked this? i've found that the following | switch should be added to cmdline: | | ghc ... -optl --large-address-aware | | but can't check compiled executable | | if this question was never considered, here is some possible problems | which may arise: | http://blogs.msdn.com/oldnewthing/archive/2004/08/12/213468.aspx | | -- | Best regards, | Bulat mailto:Bulat.Ziganshin@gmail.com | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Mon Dec 3 04:02:45 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Dec 3 03:58:23 2007 Subject: fundeps help In-Reply-To: References: Message-ID: | I'm trying to understand what fundeps do and don't let me do. One | particular source of confusion is why the following program doesn't | typecheck: | | {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-} | module Fundeps where | | class Dep a b | a -> b, b -> a | | conv :: (Dep a b1,Dep a b2) => b1 -> b2 | conv = id | {- end of program -} GHC implements "improvement" by *identifying* the two equal types. Here they cannot be identified because they are separate type variables. A good way to think of this is to imagine translating the program into System F: you can't do it. Functional dependencies guide type inference by adding extra unifications, resolving types that would otherwise be under-constrained and ambiguous -- but fundeps (or at least GHC's implementation thereof) does not deal with the case where the types become *over*-constrained. GHC's new intermediate language, System FC, is specifically designed to do this. Currently we're in transition: equality constraints are starting to work, but fundeps are implemented as they always were. I hope we can eventually switch over to implementing fundeps using equality constraints, and then the above program will work. Meanwhile, in the HEAD you can write conv :: (a~b) => a -> b conv = id Which, IHMO, is a much clearer way to say it! You may also like to try the paper that Martin and I and others wrote about fundeps: http://research.microsoft.com/%7Esimonpj/papers/fd-chr Simon From simonmarhaskell at gmail.com Mon Dec 3 06:40:14 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Dec 3 06:35:56 2007 Subject: GHC porting to FreeBSD-amd64 progress report In-Reply-To: References: <1196333910.825973@vestein.arb-phys.uni-dortmund.de> <474FED7B.9060104@gmail.com> Message-ID: <4753EB1E.8030806@gmail.com> Wilhelm B. Kloke wrote: > Simon Marlow schrieb: >> Perhaps you compiled mkDerivedConstants as a 32-bit executable? > > Yes. I was not attentive enough. > > But now I have got a working compiler on FreeBSD-amd64-7.0. If anybody is > interested, I shall prepare a package of the installed binaries. If you can build a binary distribution, we'll happily upload it to haskell.org and make it available for download. Just 'make binary-dist' should produce a suitable distribution. However, you might want to wait for 6.8.2 in the next few days, as we fixed several important bugs. > The compiler is good enough to compile itself now. Though there are > problems remaining. One the programs I tested the computation of > Meertens numbers from Bird/Wadler's book. This program segfaults on > amd64, but not on i386. You'll probably find that the testsuite shows up this (and maybe other) bugs. Start with a full testsuite run, is my advice. Cheers, Simon From simonmarhaskell at gmail.com Mon Dec 3 06:55:05 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Dec 3 06:50:49 2007 Subject: ghc vs ghci: why can't ghci do everything ghc can do? In-Reply-To: <017101c831cc$3f7ee7b0$c60a7ad5@cr3lt> References: <017101c831cc$3f7ee7b0$c60a7ad5@cr3lt> Message-ID: <4753EE99.8070809@gmail.com> Claus Reinke wrote: > 3) suggestions: > > a) could we have a :make command in ghci that does a 'ghc > --make' while reusing the information from the current session? Doesn't :set -fobject-code :reload do that? > b) could we have a --prefer-source option for ghci, > so that 'ghc --make; ghci --prefer-source' will > try to load all modules from source, but will fall back to > the existing object files if necessary > (instead of failing, as -fforce-recomp does)? > c) allow selective switching between source and > object files loaded into ghci (:prefer source M,N,..; > :prefer object O,P,Q,..). one important restriction (I'm not sure if you forgot this, but I'll point it out anyway), is that native-code modules can only depend on other native-code modules. So "falling back to native-code compilation" might mean throwing away multiple modules already compiled to bytecode. I don't like the sound of that - it would be better to put a flag in the module's OPTIONS pragma to indicate object code is required. There are other proposals for specifying which modules get loaded as bytecode btw. One is that the modules you name by filename get loaded as bytecode, the others get loaded as normal. This seems the lightest solution to me, you would say :load M.hs N.hs > the application i have in mind is trying to use ghci on > non-trivial projects, such as darcs, or even ghc itself: > > - it isn't possible to load all sources into ghci > - loading all object files is possible, but prevents > use of ghci features such as ':m *Module', > ':browse *Module', breakpoints, tags, .. > - ghci -fforce-recomp fails because it applies to all modules > - there is substantial setup to do before one can > call ghc or ghci, so dropping out of a session and trying to > figure out dependencies and flags > for compiling individual modules by hand isn't > practical :set -fobject-code :load GHC.hs (with the above extension) Cheers, Simon From daniel.is.fischer at web.de Mon Dec 3 07:38:03 2007 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Mon Dec 3 07:32:26 2007 Subject: Haddocumentation of 6.8.1 In-Reply-To: <200711301804.54118.g9ks157k@acme.softbase.org> References: <200711301523.04142.daniel.is.fischer@web.de> <200711301804.54118.g9ks157k@acme.softbase.org> Message-ID: <200712031338.03941.daniel.is.fischer@web.de> Am Freitag, 30. November 2007 18:04 schrieb Wolfgang Jeltsch: > Am Freitag, 30. November 2007 15:23 schrieb Daniel Fischer: > > Question 2: When I build a package via Cabal, is there a way to merge the > > documentation into the installed library docs (and if yes, how do I do > > it)? > > I think, if you do > > runhaskell Setup.[l]hs haddock > > before > > runhaskell Setup.[l]hs install > > then the latter installs the Haddock-generated API documentation and this > documentation will be linked to by future Haddock-generated documentations > when using Cabel to make them. > > Best wishes, > Wolfgang Yes, thanks, that's what cabal always did, I just thought it would be nice to have all installed libraries together because that would facilitate deciding whether I use something from the containers package, or the collections package or edison. But that's less important, really important is, how do I get proper haddock docs built for my 6.8.x in the first place? Currently, haddock doesn't find anything to link the docs for additional packages against. Thanks, Daniel From wb at arb-phys.uni-dortmund.de Mon Dec 3 08:28:51 2007 From: wb at arb-phys.uni-dortmund.de (Wilhelm B. Kloke) Date: Mon Dec 3 08:24:49 2007 Subject: GHC porting to FreeBSD-amd64 progress report References: <1196333910.825973@vestein.arb-phys.uni-dortmund.de> <474FED7B.9060104@gmail.com> <4753EB1E.8030806@gmail.com> Message-ID: Simon Marlow schrieb: > Wilhelm B. Kloke wrote: >> > However, you might want to wait for 6.8.2 in the next few days, as we fixed > several important bugs. I have found a couple of small bugs regarding FreeBSD. Changing the configure process would be helpful. FreeBSD-amd64 is identified as x86_64-unknown-freebsd, but the entry in configure uses amd64-*-freebsd*r; this should be made consistent. The FreeBSD cc needs -L/usr/local/lib and -I/usr/local/lib to find the native gmp (and possibly others, too) library. I tried to find out a way to use the FreeBSD-i386 ghc, which runs fine on FreeBSD-amd64, for bootstrap. The problem in this case is to substitute the 32bit assembler and linker instead of the 64bit versions. In case of the assembler the script as32 was usable like this one: #!/bin/sh /usr/bin/cc -Xassembler -32 $* But I failed to figure out the right ld32 script. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key From jmaessen at alum.mit.edu Mon Dec 3 08:59:57 2007 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Mon Dec 3 08:55:40 2007 Subject: fundeps help In-Reply-To: References: Message-ID: On Dec 3, 2007, at 4:02 AM, Simon Peyton-Jones wrote: > GHC's new intermediate language, System FC, is specifically designed > to do this. Currently we're in transition: equality constraints are > starting to work, but fundeps are implemented as they always were. > I hope we can eventually switch over to implementing fundeps using > equality constraints, and then the above program will work. > > Meanwhile, in the HEAD you can write > conv :: (a~b) => a -> b > conv = id > > Which, IHMO, is a much clearer way to say it! Is it really a good idea to permit a type signature to include equality constraints among unifiable types? Does the above type signature mean something different from a ->a? Does the type signature: foo :: (a~Bar b) => a -> Bar b mean something different from: foo :: Bar b -> Bar b ? I know that System FC is designed to let us write stuff like: foo :: (Bar a ~ Baz b) => Bar a -> Baz b Which is of course what we need for relating type functions. But I'm wondering if there's a subtlety of using an equality constraint vs just substitution that I've missed---and if not why there are so many ways of writing the same type, many of them arguably unreadable! Hoping this will give me a bit of insight into SystemFC, -Jan-Willem Maessen > You may also like to try the paper that Martin and I and others > wrote about fundeps: > http://research.microsoft.com/%7Esimonpj/papers/fd-chr > > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Mon Dec 3 09:21:12 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Dec 3 09:16:49 2007 Subject: fundeps help In-Reply-To: References: Message-ID: | Is it really a good idea to permit a type signature to include | equality constraints among unifiable types? Does the above type | signature mean something different from a ->a? Does the type signature: | foo :: (a~Bar b) => a -> Bar b | mean something different from: | foo :: Bar b -> Bar b | ? I know that System FC is designed to let us write stuff like: | foo :: (Bar a ~ Baz b) => Bar a -> Baz b | Which is of course what we need for relating type functions. But I'm | wondering if there's a subtlety of using an equality constraint vs | just substitution that I've missed No, you didn't miss anything. I wouldn't expect anyone to write these types directly. But it can happen: class C a b | a->b instance C Int Bool class D x where op :: forall y. C x y => x -> y instance D Int where op = ... In the (D Int) instance, what's the type of op? Well, it must be op :: forall y. C Int y => Int -> y And here we know that y=Bool; yet since we don't write the type sig directly we can't say it. So GHC's implementation of fundeps rejects this program; again it can't be translated into System F. Simon From olivier.boudry at gmail.com Mon Dec 3 09:27:47 2007 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Mon Dec 3 09:23:31 2007 Subject: GHC generated dll makes Excel crash on exit. In-Reply-To: References: Message-ID: On 12/3/07, Simon Peyton-Jones wrote: > > Better still, could you add a section to that page about DLLs and Excel? > That'd be useful for others. > > > > Simon > Simon, As the page is part of the GHC documentation I cannot edit it. I put my notes in a new wiki page : http://haskell.org/haskellwiki/How_to_use_a_Haskell_Dll_from_Excel I hope this is appropriate. Best regards, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20071203/cec4325d/attachment.htm From simonpj at microsoft.com Mon Dec 3 10:07:34 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Dec 3 10:03:14 2007 Subject: GHC generated dll makes Excel crash on exit. In-Reply-To: References: Message-ID: It's not part of the Haskell documentation! The FFI page http://haskell.org/haskellwiki/GHC/Using_the_FFI is part of the "contributed documentation", linked from here: http://haskell.org/haskellwiki/GHC So it absolutely is a Wiki, and should be editable by you (assuming you log into the wiki). If not, let's see why not. It'd be better to put your new material in with the other FFI stuff; it'll be easier to find that way. THanks SImon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Olivier Boudry Sent: 03 December 2007 14:28 To: Simon Peyton-Jones Cc: glasgow-haskell-users@haskell.org Subject: Re: GHC generated dll makes Excel crash on exit. On 12/3/07, Simon Peyton-Jones > wrote: Better still, could you add a section to that page about DLLs and Excel? That'd be useful for others. Simon Simon, As the page is part of the GHC documentation I cannot edit it. I put my notes in a new wiki page : http://haskell.org/haskellwiki/How_to_use_a_Haskell_Dll_from_Excel I hope this is appropriate. Best regards, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20071203/7c24635a/attachment.htm From olivier.boudry at gmail.com Mon Dec 3 10:14:14 2007 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Mon Dec 3 10:09:58 2007 Subject: GHC generated dll makes Excel crash on exit. In-Reply-To: References: Message-ID: On Dec 3, 2007 10:07 AM, Simon Peyton-Jones wrote: > It's not part of the Haskell documentation! The FFI page > > http://haskell.org/haskellwiki/GHC/Using_the_FFI > > is part of the "contributed documentation", linked from here: > > http://haskell.org/haskellwiki/GHC > > > > So it absolutely is a Wiki, and should be editable by you (assuming you > log into the wiki). > > > > If not, let's see why not. It'd be better to put your new material in > with the other FFI stuff; it'll be easier to find that way. > > > > THanks > > > > SImon > Simon, I was talking about this page: http://www.haskell.org/ghc/dist/current/docs/users_guide/win32-dlls.htmlwhich is more Win32/Excel specific and is part of the GHC documentation. But I agree it's easier to keep everything in one place so I will move my stuff to the link you mentioned. Best regards, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20071203/a2bf38fe/attachment-0001.htm From igloo at earth.li Mon Dec 3 10:23:06 2007 From: igloo at earth.li (Ian Lynagh) Date: Mon Dec 3 10:18:43 2007 Subject: HUnit 1.2.0.0 on 6.8.1 vs 1.1.1 on 6.6.1 In-Reply-To: <1f3dc80d0711211113j412b9abctfa6bfe2280d41f9e@mail.gmail.com> References: <1f3dc80d0711211113j412b9abctfa6bfe2280d41f9e@mail.gmail.com> Message-ID: <20071203152306.GA12568@matrix.chaos.earth.li> On Wed, Nov 21, 2007 at 11:13:26AM -0800, Greg Fitzgerald wrote: > On Windows, HUnit's assertions are not working - trace below in ghci 6.8.1and > 6.6.1. Can others reproduce? Is this the right place to report bugs? > Should I confirm a bug here and then create a ticket, create a ticket and > that's it, or just mention it here and someone else creates a ticket? > > > GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > > :m Test.HUnit > > "abc" @=? "efg" > Loading package HUnit-1.2.0.0 ... linking ... done. > *** Exception: (unknown) > > / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. > > > "abc" @=? "efg" > Loading package HUnit-1.1.1 ... linking ... done. > *** Exception: user error (HUnit:expected: "abc" > but got: "efg") This is caused by a change in the HUnit library, from assertFailure msg = ioError (userError (hunitPrefix ++ msg)) to assertFailure msg = E.throwDyn (HUnitFailure msg) We don't really have a good answer for where non-bootlib library bugs should go at the moment. I don't know if Dean uses the sourceforge bug tracker or not. Thanks Ian From olivier.boudry at gmail.com Mon Dec 3 11:53:33 2007 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Mon Dec 3 11:49:12 2007 Subject: GHC generated dll makes Excel crash on exit. In-Reply-To: References: Message-ID: I moved my stuff to: http://haskell.org/haskellwiki/GHC/Using_the_FFI#Beware_of_dllMain.28.29_-_Excel Cheers, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20071203/5057ba1b/attachment.htm From g9ks157k at acme.softbase.org Mon Dec 3 13:52:23 2007 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Dec 3 13:48:24 2007 Subject: Haddocumentation of 6.8.1 In-Reply-To: <200712031338.03941.daniel.is.fischer@web.de> References: <200711301523.04142.daniel.is.fischer@web.de> <200711301804.54118.g9ks157k@acme.softbase.org> <200712031338.03941.daniel.is.fischer@web.de> Message-ID: <200712031952.23303.g9ks157k@acme.softbase.org> Am Montag, 3. Dezember 2007 13:38 schrieben Sie: > [?] > I just thought it would be nice to have all installed libraries together > because that would facilitate deciding whether I use something from the > containers package, or the collections package or edison. Do you mean you want a combined contents page and a combined index? Then have a look at libraries/gen_contents_index in the GHC 6.8.1 source tarball. You might want to reuse this script. > [?] Best wishes, Wolfgang From jb162 at brighton.ac.uk Mon Dec 3 15:24:34 2007 From: jb162 at brighton.ac.uk (Jim Burton) Date: Mon Dec 3 15:20:16 2007 Subject: Type Families and enhanced constraints (at run-time) In-Reply-To: <1196472825.30820.1224196477@webmail.messagingengine.com> References: <1196334742.5586.11.camel@unicorn> <1196439420.5555.48.camel@unicorn> <1196472825.30820.1224196477@webmail.messagingengine.com> Message-ID: <1196713474.5692.36.camel@unicorn> On Sat, 2007-12-01 at 11:33 +1000, Matthew Brecknell wrote: [...] > Seems impossible. With GADTs, you can of course go the other way: > > > data A > > data B > > > > data Chr a where > > AChr :: Chr A > > BChr :: Chr B > > > > toChar :: Chr a -> Char > > toChar AChr = 'A' > > toChar BChr = 'B' > > So perhaps insert should have a type something more like: > > > type family ChrSetIns a t :: * > > > > insert :: Chr a -> ChrSet t -> ChrSet (ChrSetIns a t) > > I'm not sure how to make the set type parametric in the element type, > though. > Thanks -- I think I see your point but I'm not sure how to make use of it...(perhaps I'm trying to run before I can walk). The way I was picturing things, the A, B ... types would need to take a parameter so they can be collected/consed, so my next attempt tries to incorporate both ideas: data A data B data Nil data t ::: ts -- consing the phantom types data Chr a where AChr :: Chr A BChr :: Chr B toChar :: Chr a -> Char toChar AChr = 'A' toChar BChr = 'B' data TInfo t where Nil :: TInfo Nil InsA :: TInfo t -> TInfo (A ::: t) InsB :: TInfo t -> TInfo (B ::: t) data ChrSet t = ChrSet (TInfo t) [Char] type family ChrSetIns c s :: * type instance ChrSetIns (Chr a) (TInfo t) = TInfo (a ::: t) insert :: Chr a -> ChrSet t -> ChrSet (ChrSetIns a t) insert c (ChrSet tinfo cs) = case c of AChr -> ChrSet (InsA tinfo) ((toChar c):cs) _ -> error "not a label" `insert' is still the problem -- how to form the 1st param of ChrSet. (InsA tinfo) isn't an instance of ChrSetIns, but I don't see how to fix that...? The error: ------------------------------------------- Couldn't match expected type `ChrSetIns A t' against inferred type `A ::: t' Expected type: TInfo (ChrSetIns A t) Inferred type: TInfo (A ::: t) In the first argument of `ChrSet', namely `(InsA tinfo)' In the expression: ChrSet (InsA tinfo) ((toChar c) : cs) Failed, modules loaded: none. Thanks, Jim From jb162 at brighton.ac.uk Mon Dec 3 16:15:01 2007 From: jb162 at brighton.ac.uk (Jim Burton) Date: Mon Dec 3 16:10:51 2007 Subject: Type Families and enhanced constraints (at run-time) In-Reply-To: References: <1196334742.5586.11.camel@unicorn> Message-ID: <1196716502.5692.73.camel@unicorn> On Fri, 2007-11-30 at 13:37 +1100, Manuel M T Chakravarty wrote: > Whenever you want to maintain type-level assertions of properties of > you functions, you need to decide *how much* of the value-level > information do you need on the type level to express and check the > properties that you are interested in. Hope you don't mind me going back to this point Manuel; given that I want to maintain enough type-level information to provide correctness checks on the implementations of set operations and on their inputs, is this _impossible_ except at the extreme end of the spectrum? As you say below, I was hoping this would not be the case and that it would be possible to create something with those properties that could be used in an interactive setting. Your SNat example is a simpler case, but it pulls off that feat, which made me think it was a question of finding the right combination of types. Jim > My SNat example was at one > extreme end of the spectrum: *complete* value-level information is > reflected at the type level. In other case, it is only necessary to > reflect partial information; eg, when reasoning about bounds-checks of > bounded lists or arrays, only the length, but not the exact elements > need to be reflected. > > In other words, first you need to decide what properties you want to > enforce and what information you need to decide those properties. > Coming back to your set example, what properties do you want to > enforce/check and what information do you need to do that? In the > extreme case, you could reflect the entire contents of each set at the > type-level using a singleton set type (and corresponding singleton > types for the set elements). However, that also would mean that all > your value-level set operations will already have to be completely > executed by the type checker at compile time, which is probably not > what you want. > > Does this make sense? > > Manuel > > Jim Burton: > > Hi, I hope this is the right place to ask about working with type > > families...I want to make a library of Set operations that carries > > proofs at the type level, e.g. to make things like this possible, > > > >> insert :: Member e s' T => e -> Set s -> Set s' > >> union :: Union s t u => Set s -> Set t -> Set u > > > > The trouble is designing the Set datatype so it can be used in type > > constraints *and* in run-time functions....Something similar is of > > course possible with fun deps, and I knocked something up following > > the > > example of Conrad Parker's 'Instant Insanity' but, crucially, that > > code > > is 'trapped' in the type system with no populated types. I want > > term-level/run-time functions with enhanced constraints, such as in > > the > > example Manuel posted in haskell-cafe: > > > >> data Z > >> data S a > >> > >> data SNat n where > >> Zero :: SNat Z > >> Succ :: SNat n -> SNat (S n) > >> > >> zero = Zero > >> one = Succ zero > >> > >> type family (:+:) n m :: * > >> type instance Z :+: m = m > >> type instance (S n) :+: m = S (n :+: m) > >> > >> add :: SNat n -> SNat m -> SNat (n :+: m) > >> add Zero m = m > >> add (Succ n) m = Succ (add n m) > > > > This seems like "the best of both worlds" -- maybe it could be a > > general > > strategy for making for making these enhanced constraints at the > > term-level? Make a (populated) GADT and parameterise it with a phantom > > type (perhaps amongst other things). Make a type operator that can be > > used to express the constraint on the phantom types carried around by > > the "regular" populated type. When the type operator appears in the > > codomain of the function it's a compile-time check on the > > implementation > > of that function and when in the domain it checks the user at run- > > time. > > > > However, (SNat n) can be put very succinctly because it doesn't need > > to > > carry a value around other than the Peano number in the phantom type. > > What about Sets? In my case the values in the sets are just labels and > > could well be empty: > > > >> data A ; data B ; data C > > > > And I also need to express the cons-ness -- I don't think that needs > > fancy constraints so it can be done with terms, e.g., an underlying > > sequence such as in the Collects example. Generally I need to work out > > what needs to be run-time and what compile-time but I think that would > > follow from getting the combinations of types and terms in the Set > > abstraction right...could someone give me a pointer with this? > > > > Many thanks, > > > > Jim > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From ganesh at earth.li Mon Dec 3 17:18:16 2007 From: ganesh at earth.li (Ganesh Sittampalam) Date: Mon Dec 3 17:13:54 2007 Subject: fundeps help In-Reply-To: References: Message-ID: On Mon, 3 Dec 2007, Simon Peyton-Jones wrote: > No, you didn't miss anything. I wouldn't expect anyone to write these > types directly. But it can happen: > class C a b | a->b > instance C Int Bool > > class D x where > op :: forall y. C x y => x -> y > > instance D Int where > op = ... > > In the (D Int) instance, what's the type of op? Well, it must be > op :: forall y. C Int y => Int -> y > > And here we know that y=Bool; yet since we don't write the type sig > directly we can't say it. So GHC's implementation of fundeps rejects > this program; again it can't be translated into System F. Conveniently, this is a good example of my other problem with fundeps :-) I can work around the problem from my first email with an unsafeCoerce, but is there any way I can get around the issue above at the moment in either 6.8 or the HEAD? I actually plan to recast the code in question using associated type synomyms once they're working properly, but would like to be able to make some progress now. Cheers, Ganesh From daniel.is.fischer at web.de Mon Dec 3 18:30:26 2007 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Mon Dec 3 18:24:51 2007 Subject: Problems building and using ghc-6.9 Message-ID: <200712040030.26360.daniel.is.fischer@web.de> Hi, so today I built ghc-6.9.20071124. First, make died because HsColour version >= 1.8 was needed, couldn't determine the version. I had HsColour 1.6, got myself 1.8, built and installed. make died again, same problem. I added ("v", Version) to the optionTable in HsColour.hs and it worked :) Then I tried to build zlib-0.4.0.1: $ runghc ./Setup.hs configure --user --prefix=$HOME Configuring zlib-0.4.0.1... Setup.hs: At least the following dependencies are missing: base >=2.0&&<2.2 ??? okay, there was something with flag bytestring-in-base, removed that, so that build-depends was base < 2.0 || >= 2.2, bytestring >= 0.9, then $ runghc ./Setup.hs configure --user --prefix=$HOME Configuring zlib-0.4.0.1... Setup.hs: At least the following dependencies are missing: base <2.0||>=2.2, bytestring >=0.9 but: $ ghc-pkg list /home/dafis/lib/ghc-6.9.20071124/package.conf: ALUT-2.1.0.0, Cabal-1.3, GLUT-2.1.1.1, HUnit-1.2.0.0, OpenAL-1.3.1.1, OpenGL-2.2.1.1, QuickCheck-1.1.0.0, array-0.1, base-3.0, bytestring-0.9, cgi-3001.1.5.1, containers-0.1, directory-1.0, fgl-5.4.1.1, filepath-1.1, (ghc-6.9.20071124), haskell-src-1.0.1.1, haskell98-1.0.1, hpc-0.5, html-1.0.1.1, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0, old-time-1.0, packedstring-0.1, parallel-1.0.0.0, parsec-2.1.0.0, pretty-1.0, process-1.0, random-1.0, readline-1.0.1, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.0, template-haskell-2.2, time-1.1.2.0, unix-2.2, xhtml-3000.0.2.1 and in stringsearch-0.2: $ runghc ./Setup.lhs configure --user --prefix=$HOME Configuring stringsearch-0.2... Setup.lhs: At least the following dependencies are missing: base -any What's going on?? How can I build packages with ghc-6.9? Or do I have to go back to 6.8.1? Thanks, Daniel From haskell at brecknell.org Mon Dec 3 22:52:37 2007 From: haskell at brecknell.org (Matthew Brecknell) Date: Mon Dec 3 22:48:12 2007 Subject: Type Families and enhanced constraints (at run-time) In-Reply-To: <1196713474.5692.36.camel@unicorn> References: <1196334742.5586.11.camel@unicorn> <1196439420.5555.48.camel@unicorn> <1196472825.30820.1224196477@webmail.messagingengine.com> <1196713474.5692.36.camel@unicorn> Message-ID: <1196740357.6919.1224649245@webmail.messagingengine.com> Jim Burton said: > Thanks -- I think I see your point but I'm not sure how to make > use of it...(perhaps I'm trying to run before I can walk). > The way I was picturing things, the A, B ... types would > need to take a parameter so they can be collected/consed, > so my next attempt tries to incorporate both ideas: > > [...] I was imagining something more along the lines of this: > data A > data B > > data Chr a where > AChr :: Chr A > BChr :: Chr B > > toChar :: Chr a -> Char > toChar AChr = 'A' > toChar BChr = 'B' > > data Nil > data t ::: ts > > data ChrSet t where > Nil :: ChrSet Nil > Ins :: Chr a -> ChrSet t -> ChrSet (a ::: t) > > insert :: Chr a -> ChrSet t -> ChrSet (a ::: t) > insert = Ins That, by itself, doesn't require type families. I imagine you'll need type families if you want to do things like implement a tree structure, perform membership tests, deletions, etc. Note that if you want to reason about the correctness of code in this way, your data structures need to carry proofs. For example, the ChrSet data type I've given above enforces the correspondence between the value-level representation and the type-level representation, so given any ChrSet, I know the type-level decomposition will reflect the value-level decomposition, regardless of where that ChrSet came from. On the other hand, the ChrSet you proposed in your previous post doesn't have this property: data ChrSet t = ChrSet (TInfo t) [Char] Given one of these, I can't be confident that the type reflects the value, without inspecting all of the code that might have contributed to its construction. And that defeats the purpose of your endeavours. So you should defer the call to toChar until the last possible moment, if you call it at all. Another thought occurred to me: you might want to construct a ChrSet from user input, which brings us back to the problem I described in my previous post. All is not lost, though. You'll just need to keep your Chr and ChrSet values inside existential boxes: > data ChrBox = forall a . ChrBox (Chr a) > > fromChar :: Char -> ChrBox > fromChar 'A' = ChrBox AChr > fromChar 'B' = ChrBox BChr > fromChar _ = error "fromChar: bad Char" > > data ChrSetBox = forall t . ChrSetBox (ChrSet t) > > insertChar :: Char -> ChrSetBox -> ChrSetBox > insertChar c (ChrSetBox s) = case fromChar c of > ChrBox c -> ChrSetBox (insert c s) BTW, I think you might get more interesting responses to theses questions in haskell-cafe. From chak at cse.unsw.edu.au Mon Dec 3 23:31:19 2007 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Dec 3 23:27:12 2007 Subject: fundeps help In-Reply-To: References: Message-ID: <922A299C-2873-4E55-BA4F-317B4619C930@cse.unsw.edu.au> Jan-Willem Maessen: > Is it really a good idea to permit a type signature to include > equality constraints among unifiable types? Does the above type > signature mean something different from a ->a? Does the type > signature: > foo :: (a~Bar b) => a -> Bar b > mean something different from: > foo :: Bar b -> Bar b > ? I know that System FC is designed to let us write stuff like: > foo :: (Bar a ~ Baz b) => Bar a -> Baz b > Which is of course what we need for relating type functions. But > I'm wondering if there's a subtlety of using an equality constraint > vs just substitution that I've missed---and if not why there are so > many ways of writing the same type, many of them arguably unreadable! Simon answered most of your question, but let me make a remark regarding "why there are so many ways of writing the same type, many of them arguably unreadable!" Equalities of the form "a ~ someType" are essentially a form of let-bindings for types - you can give a type a name and then use the name in place of the type. Just like with value-level let bindings, you can abuse the notation and write unreadable terms. However, this is no reason to remove let-bindings from the value level, so why should it be different at the type level? Manuel From simonpj at microsoft.com Tue Dec 4 03:27:15 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Dec 4 03:22:50 2007 Subject: fundeps help In-Reply-To: References: Message-ID: | > And here we know that y=Bool; yet since we don't write the type sig | > directly we can't say it. So GHC's implementation of fundeps rejects | > this program; again it can't be translated into System F. | | Conveniently, this is a good example of my other problem with fundeps :-) | I can work around the problem from my first email with an unsafeCoerce, | but is there any way I can get around the issue above at the moment in | either 6.8 or the HEAD? I actually plan to recast the code in question | using associated type synomyms once they're working properly, but would | like to be able to make some progress now. I think that if you use the HEAD, much of this will work, if you use the type-equality notation. But you will probably encounter bugs too. And in so doing, and reporting them, you'll be doing us a service. Simon From ganesh.sittampalam at credit-suisse.com Tue Dec 4 03:34:06 2007 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Tue Dec 4 03:30:58 2007 Subject: fundeps help Message-ID: <8C984B4799C04D4B8F80F746537145E116F4F334@elon12p32001.csfp.co.uk> > I think that if you use the HEAD, much of > this will work, if you use the type-equality > notation. But you will probably encounter bugs > too. And in so doing, and reporting them, you'll > be doing us a service. I did originally intend to try all this with the HEAD, but one obstacle to this is the lack of recent linux binaries in http://www.haskell.org/ghc/dist/current/dist/ I tried building it myself, but something or another failed, and in general I think keeping up by that route would be a rather high overhead process. Cheers, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From simonpj at microsoft.com Tue Dec 4 03:48:11 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Dec 4 03:43:46 2007 Subject: fundeps help In-Reply-To: <8C984B4799C04D4B8F80F746537145E116F4F334@elon12p32001.csfp.co.uk> References: <8C984B4799C04D4B8F80F746537145E116F4F334@elon12p32001.csfp.co.uk> Message-ID: | I did originally intend to try all this with the | HEAD, but one obstacle to this is the lack of recent linux | binaries in http://www.haskell.org/ghc/dist/current/dist/ Ian is fixing that. We'd missed the fact that the bindists weren't being built. Hold on a day or two. Simon From simonmarhaskell at gmail.com Tue Dec 4 05:38:08 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Dec 4 05:33:46 2007 Subject: Leopard: ghc 6.8.1 and the case of the missing _environ In-Reply-To: References: Message-ID: <47552E10.4060203@gmail.com> Joel Reymont wrote: > Symptoms: > > You build 6.8.1 from source on Leopard (x86 in my case) and then > > junior:ghc-6.8.1 joelr$ ghci > GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help > ghc-6.8.1: > /usr/local/lib/ghc-6.8.1/lib/base-3.0.0.0/HSbase-3.0.0.0.o: unknown > symbol `_environ' > Loading package base ... linking ... ghc-6.8.1: unable to load package > `base' > > Problem: > > ghc binaries are being stripped upon installation which eliminates > _environ, e.g. > > junior:tmp joelr$ nm x|grep environ > 00002ff0 T ___hscore_environ > 0004d004 D _environ > > junior:tmp joelr$ strip x > junior:tmp joelr$ nm x|grep environ > > Solution: > > Need to make sure install-sh does _not_ use the -s option. Haven't found > out where this needs to be done yet. A temporary workaround is to ask > Manuel for the pre-built binaries. MacOS folks: is this still an issue? If so, could someone create a ticket? Cheers, Simon From simonmarhaskell at gmail.com Tue Dec 4 05:42:33 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Dec 4 05:38:11 2007 Subject: GHC generated dll makes Excel crash on exit. In-Reply-To: References: Message-ID: <47552F19.4020004@gmail.com> Olivier Boudry wrote: > On Dec 3, 2007 10:07 AM, Simon Peyton-Jones > wrote: > > It's not part of the Haskell documentation! The FFI page > > http://haskell.org/haskellwiki/GHC/Using_the_FFI > > is part of the "contributed documentation", linked from here: > > http://haskell.org/haskellwiki/GHC > > > > So it absolutely is a Wiki, and should be editable by you (assuming > you log into the wiki). > > > > If not, let's see why not. It'd be better to put your new material > in with the other FFI stuff; it'll be easier to find that way. > > > > THanks > > > > SImon > > > Simon, > > I was talking about this page: > http://www.haskell.org/ghc/dist/current/docs/users_guide/win32-dlls.html > which is more Win32/Excel specific and is part of the GHC documentation. > > But I agree it's easier to keep everything in one place so I will move > my stuff to the link you mentioned. Yes, I moved some of the wiki documentation into the user's guide before 6.8.1, but didn't delete the wiki at the time because 6.8.1 wasn't released yet. Now we have duplication, and I guess I (or someone at least) should sort it out... Cheers, Simon From claus.reinke at talk21.com Tue Dec 4 07:36:30 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Dec 4 07:32:09 2007 Subject: ghc vs ghci: why can't ghci do everything ghc can do? References: <017101c831cc$3f7ee7b0$c60a7ad5@cr3lt> <4753EE99.8070809@gmail.com> Message-ID: <00d401c83672$4d003510$68298351@cr3lt> btw, it would still be nice to have ghci limitations (vs ghc) summarized on a wiki page. i've seen fragments here and there, but no complete list answering my questions. > :set -fobject-code > :reload ah, thanks! i had forgotten about that one. it doesn't solve my main problem but i guess what i'm asking for could be rephrased as: an _implied_ {-# OPTIONS_GHC -fobject-code #-} for only those modules which ghci can't handle itself. > :load M.hs N.hs i also liked the suggestion that ':m *M' should always use the source, from the same thread. take darcs stable as a medium sized example that already has a 'make ghci' target. by default, that target loads object code built by 'make' and it falls over at various places if one adds '-fforce-recomp' to the ghci call. using a general '-fobject-code' doesn't help, and having to figure out which modules cause ghci headaches is no fun, either. what i'm looking for is a way to let ghci pretend as far as possible that it has no limitations (compared with ghc), so that i can simply load a project's main module, have no failures because of ffi, etc. while still having as many of the dependencies as possible loaded in source form. is there a way to do that that works with the darcs stable repo example? claus From haskell at list.mightyreason.com Tue Dec 4 07:41:36 2007 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Tue Dec 4 07:37:10 2007 Subject: Leopard: ghc 6.8.1 and the case of the missing _environ In-Reply-To: <47552E10.4060203@gmail.com> References: <47552E10.4060203@gmail.com> Message-ID: <47554B00.7080202@list.mightyreason.com> > MacOS folks: is this still an issue? If so, could someone create a ticket? > > Cheers, > Simon The issue for MacOS (10.5 Leopard) on powerpc is still http://hackage.haskell.org/trac/ghc/ticket/1843 But we suspect that there is more than one issue, since my patch for the "unknown scattered relocation type 4" does not, in fact, fix everything. -- Chris From simonmarhaskell at gmail.com Tue Dec 4 08:18:19 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Dec 4 08:13:59 2007 Subject: Leopard: ghc 6.8.1 and the case of the missing _environ In-Reply-To: <47554B00.7080202@list.mightyreason.com> References: <47552E10.4060203@gmail.com> <47554B00.7080202@list.mightyreason.com> Message-ID: <4755539B.8020307@gmail.com> Chris Kuklewicz wrote: >> MacOS folks: is this still an issue? If so, could someone create a ticket? >> >> Cheers, >> Simon > > The issue for MacOS (10.5 Leopard) on powerpc is still > http://hackage.haskell.org/trac/ghc/ticket/1843 > > But we suspect that there is more than one issue, since my patch for the > "unknown scattered relocation type 4" does not, in fact, fix everything. Yes, I've been following that discussion. But what I'm asking about is whether the issue that Joel raised about _environ is something that we need to track/fix separately - I don't remember seeing any further discussion about it. Cheers, Simon From simonmarhaskell at gmail.com Tue Dec 4 08:23:47 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Dec 4 08:19:26 2007 Subject: ghc vs ghci: why can't ghci do everything ghc can do? In-Reply-To: <00d401c83672$4d003510$68298351@cr3lt> References: <017101c831cc$3f7ee7b0$c60a7ad5@cr3lt> <4753EE99.8070809@gmail.com> <00d401c83672$4d003510$68298351@cr3lt> Message-ID: <475554E3.1050608@gmail.com> Claus Reinke wrote: > btw, it would still be nice to have ghci limitations (vs ghc) summarized > on a wiki page. i've seen fragments here and > there, but no complete list answering my questions. > >> :set -fobject-code >> :reload > > ah, thanks! i had forgotten about that one. it doesn't solve my main > problem but i guess what i'm asking for could be rephrased as: > an _implied_ {-# OPTIONS_GHC -fobject-code #-} > for only those modules which ghci can't handle itself. > >> :load M.hs N.hs > > i also liked the suggestion that ':m *M' should always > use the source, from the same thread. > > take darcs stable as a medium sized example that already > has a 'make ghci' target. by default, that target loads object > code built by 'make' and it falls over at various places if > one adds '-fforce-recomp' to the ghci call. using a general > '-fobject-code' doesn't help, and having to figure out which > modules cause ghci headaches is no fun, either. > > what i'm looking for is a way to let ghci pretend as far as possible > that it has no limitations (compared with ghc), so that i can simply > load a project's main module, have no failures because of ffi, etc. > while still having as many of the dependencies as possible loaded in > source form. > > is there a way to do that that works with the darcs stable > repo example? Not right now. But I think the right way would be to allow `-fobject-code` to be used in an OPTIONS_GHC pragma to indicate that the module *must* be loaded as object code. That way GHC can take it into account during the planning stage before starting to compile anything, because it might force other modules to be compiled to .o too. http://hackage.haskell.org/trac/ghc/ticket/1365 Cheers, Simon From olivier.boudry at gmail.com Tue Dec 4 08:36:54 2007 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Tue Dec 4 08:32:30 2007 Subject: GHC generated dll makes Excel crash on exit. In-Reply-To: <47552F19.4020004@gmail.com> References: <47552F19.4020004@gmail.com> Message-ID: Simon, While we're at it, I found a typo in the http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.htmldocumentation page. In ghc-6.6 the flag to build DLLs was --mk-dll (two leading minus signs), the new one is -shared (one leading minus sign) but in the doc it's written "--shared" ghc ??shared -o foo.dll bar.o baz.o wibble.a -lfooble should be ghc ?shared -o foo.dll bar.o baz.o wibble.a -lfooble There are 6 occurences of what smells like a copy/paste bug ;-) Cheers, Olivier. On Dec 4, 2007 5:42 AM, Simon Marlow wrote: > Olivier Boudry wrote: > > On Dec 3, 2007 10:07 AM, Simon Peyton-Jones > > wrote: > > > > It's not part of the Haskell documentation! The FFI page > > > > http://haskell.org/haskellwiki/GHC/Using_the_FFI > > > > is part of the "contributed documentation", linked from here: > > > > http://haskell.org/haskellwiki/GHC > > > > > > > > So it absolutely is a Wiki, and should be editable by you (assuming > > you log into the wiki). > > > > > > > > If not, let's see why not. It'd be better to put your new material > > in with the other FFI stuff; it'll be easier to find that way. > > > > > > > > THanks > > > > > > > > SImon > > > > > > Simon, > > > > I was talking about this page: > > http://www.haskell.org/ghc/dist/current/docs/users_guide/win32-dlls.html > > which is more Win32/Excel specific and is part of the GHC documentation. > > > > But I agree it's easier to keep everything in one place so I will move > > my stuff to the link you mentioned. > > Yes, I moved some of the wiki documentation into the user's guide before > 6.8.1, but didn't delete the wiki at the time because 6.8.1 wasn't > released > yet. Now we have duplication, and I guess I (or someone at least) should > sort it out... > > Cheers, > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20071204/ef0f47d2/attachment.htm From isaacdupree at charter.net Tue Dec 4 10:59:04 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Dec 4 10:56:16 2007 Subject: type equality symbol In-Reply-To: References: Message-ID: <47557948.1070907@charter.net> >> conv :: (a~b) => a -> b >> conv = id is there any particular reason that '~' is the symbol for type equality constraints? I would think '=' would be the obvious choice, (although perhaps it is already over-used, and is normally asymmetric in Haskell!)? Isaac From ravi at bluespec.com Tue Dec 4 22:45:02 2007 From: ravi at bluespec.com (Ravi Nanavati) Date: Tue Dec 4 22:40:33 2007 Subject: Profiling and class methods Message-ID: <7b977d860712041945k4444e376q41aa3c008abfd408@mail.gmail.com> One of the smaller nits I noticed when looking at profiles generated by 6.8.1 (using -prof -auto-all) is that class methods show up as cost centers named something like "$f5". I can look at the call stack and figure out that $f5 is probably the call to a particular class method in a particular location, but I was wondering what it might take to make that more user-friendly (I'd want to see the class name, method name and the instance being used in some format, ideally). Is that information readily available and it is just a matter of making -auto-all smarter, or is there a reason this would be tricky? Thanks, - Ravi From dbueno at gmail.com Tue Dec 4 23:02:07 2007 From: dbueno at gmail.com (Denis Bueno) Date: Tue Dec 4 22:57:38 2007 Subject: Profiling and class methods In-Reply-To: <7b977d860712041945k4444e376q41aa3c008abfd408@mail.gmail.com> References: <7b977d860712041945k4444e376q41aa3c008abfd408@mail.gmail.com> Message-ID: <6dbd4d000712042002o7e6791dr6565f6568e8dc613@mail.gmail.com> On Dec 4, 2007 10:45 PM, Ravi Nanavati wrote: > One of the smaller nits I noticed when looking at profiles generated > by 6.8.1 (using -prof -auto-all) is that class methods show up as cost > centers named something like "$f5". I can look at the call stack and > figure out that $f5 is probably the call to a particular class method > in a particular location, but I was wondering what it might take to > make that more user-friendly (I'd want to see the class name, method > name and the instance being used in some format, ideally). Is that > information readily available and it is just a matter of making > -auto-all smarter, or is there a reason this would be tricky? You can know for sure which method in a class $f5 denotes using -ddump-simpl (and grep '$f5' on the output). Also note that this issue is currently filed as a bug. http://hackage.haskell.org/trac/ghc/ticket/1641 -- Denis From zhen.sydow at gmail.com Wed Dec 5 07:43:10 2007 From: zhen.sydow at gmail.com (Luis Cabellos) Date: Wed Dec 5 07:38:42 2007 Subject: About -Wall option Message-ID: <3f3964000712050443u576370eft558b41c6334a5da0@mail.gmail.com> Hi, I have a question, what's the best way to program? - put all the signatures in the Haskell Code? - Only put the type signatures needed to compile (like monomorphism errors or ambiguous signature)? Until now, I prefer the second one, but when I use the -Wall option, there's a lot of complains about type signature. Maybe the type signature is something that not need to be checked as a warning. But if the best practice is to put all the signatures, I found that Cabal generated code need to be fixed, because -Wall complains about it also. -- Thanks, Luis Cabellos, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20071205/878eb3b5/attachment.htm From olivier.boudry at gmail.com Wed Dec 5 09:43:42 2007 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Wed Dec 5 09:39:27 2007 Subject: About -Wall option In-Reply-To: <3f3964000712050443u576370eft558b41c6334a5da0@mail.gmail.com> References: <3f3964000712050443u576370eft558b41c6334a5da0@mail.gmail.com> Message-ID: On Dec 5, 2007 7:43 AM, Luis Cabellos wrote: > Hi, > > I have a question, what's the best way to program? > - put all the signatures in the Haskell Code? > - Only put the type signatures needed to compile (like monomorphism > errors or ambiguous signature)? > > Until now, I prefer the second one, but when I use the -Wall option, > there's a lot of complains about type signature. Maybe the type signature is > something that not need to be checked as a warning. > > But if the best practice is to put all the signatures, I found that Cabal > generated code need to be fixed, because -Wall complains about it also. > > Hi Luis, I don't know what the best way to program is, but I usually put signatures on all functions. I think it often helps get smarter error messages from the compiler. ;-) So I like the warning about missing signatures. If you don't like it you can disable it like this: -Wall -fno-warn-missing-signatures or maybe use -W instead of -Wall, apparently the warn-missing-signatures is not comprised in the -W flag. Cheers, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20071205/7c3aa1af/attachment-0001.htm From simonpj at microsoft.com Wed Dec 5 10:53:19 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Dec 5 10:48:49 2007 Subject: type equality symbol In-Reply-To: <47557948.1070907@charter.net> References: <47557948.1070907@charter.net> Message-ID: Nothing deep. Just that "=" means so many things that it seemed better to use a different notation. S | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of | Isaac Dupree | Sent: 04 December 2007 15:59 | To: Jan-Willem Maessen | Cc: Glasgow-haskell-users@haskell.org; Simon Peyton-Jones | Subject: type equality symbol | | >> conv :: (a~b) => a -> b | >> conv = id | | is there any particular reason that '~' is the symbol for type equality | constraints? I would think '=' would be the obvious choice, (although | perhaps it is already over-used, and is normally asymmetric in Haskell!)? | | Isaac | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From flippa at flippac.org Wed Dec 5 10:56:53 2007 From: flippa at flippac.org (Philippa Cowderoy) Date: Wed Dec 5 10:52:37 2007 Subject: type equality symbol In-Reply-To: References: <47557948.1070907@charter.net> Message-ID: On Wed, 5 Dec 2007, Simon Peyton-Jones wrote: > Nothing deep. Just that "=" means so many things that it seemed better > to use a different notation. > How about ==? Only one meaning so far, and that both on the term level and equivalent to the constraint. -- flippa@flippac.org Ivanova is always right. I will listen to Ivanova. I will not ignore Ivanova's recomendations. Ivanova is God. And, if this ever happens again, Ivanova will personally rip your lungs out! From simonpj at microsoft.com Wed Dec 5 11:05:22 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Dec 5 11:00:52 2007 Subject: type equality symbol In-Reply-To: References: <47557948.1070907@charter.net> Message-ID: | > Nothing deep. Just that "=" means so many things that it seemed better | > to use a different notation. | > | | How about ==? Only one meaning so far, and that both on the term level and | equivalent to the constraint I'm quite happy with "~"! It's sufficiently different from "=" that someone meeting it for the first time is going to thing "hmm, better read the manual"; and they'd be right. Anyway, while on this subject, I am considering making the following change: make all operator symbols into type constructors (currently they are type variables) That would allow you to write data a * b = Prod a b data a + b = Left a | Right b and write natural-looking types like f :: a*b -> a When we have indexed type families working, this will be even more natural. As things stand, only operators starting with a ":" are type constructors, thus data a :*: b = Prod a b etc. By analogy with the term language, operators are currently classified as "type variables", so you could write (oddly) data T (+) x = MkT (+) x [this may not even work today, but it should] to mean the same as data T y x = MkT y x But this is pretty useless! Very occasionally one might want a type variable with kind (*->*->*), but much much more often you want a type *constructor* with that kind. I thought I'd mention this here in case people have ideas. Simon From isaacdupree at charter.net Wed Dec 5 11:32:21 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Dec 5 11:29:35 2007 Subject: type equality symbol In-Reply-To: References: <47557948.1070907@charter.net> Message-ID: <4756D295.7070301@charter.net> Simon Peyton-Jones wrote: > | > Nothing deep. Just that "=" means so many things that it seemed better > | > to use a different notation. > | > > | > | How about ==? Only one meaning so far, and that both on the term level and > | equivalent to the constraint > > I'm quite happy with "~"! It's sufficiently different from "=" that someone > meeting it for the first time is going to thing "hmm, better read the manual"; > and they'd be right. I think this is the most important distinction: whether they will need to read the manual. I suppose it usually doesn't need to be written explicitly, so when it is, manual-reading (or a comment in the code) would be more likely to be important. (also (==) is generally a non-reserved symbol, though that could perhaps be changed like forall's (.)) > Anyway, while on this subject, I am considering making the following change: > > make all operator symbols into type constructors > (currently they are type variables) > > That would allow you to write > data a * b = Prod a b > data a + b = Left a | Right b > and write natural-looking types like > f :: a*b -> a > > When we have indexed type families working, this will be even more natural. > > As things stand, only operators starting with a ":" are type constructors, thus > data a :*: b = Prod a b > etc. By analogy with the term language, operators are currently classified as "type variables", so you could write (oddly) > data T (+) x = MkT (+) x > [this may not even work today, but it should] to mean the same as > data T y x = MkT y x > But this is pretty useless! Very occasionally one might want a type variable > with kind (*->*->*), but much much more often you want a type *constructor* with that kind. I've seen "~>" after (Arrow (~>)) =>, as a type variable... and find it confusing! for the (unimplementable) reverseArrow :: (Arrow a) => a b c -> a c b sometimes written as reverseArrow :: (Arrow (~>)) => (b ~> c) -> (c ~> b) , I'd prefer, if infix notation is going to be used, the backtick version for variables (as well as being allowed for types e.g. (b `SF` c)) reverseArrow :: (Arrow a) => (b `a` c) -> (c `a` b) Also, '->' doesn't start with a colon. (and is currently lowest-precedence, the way (::) in expressions is? or do we know what we're doing with precedences/associativity? To give infix declaration explicitly, must define (+)-type in a different module than (+)-value if it's different fixity...) I support that (+)-etc-as-type-constructor change! (hmm, is there any additional difficulty in it if experimenting with language features mixing type and term expressions - which already has lexical ambiguity anyway?) Isaac From bulat.ziganshin at gmail.com Wed Dec 5 11:56:58 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Dec 5 11:53:34 2007 Subject: type equality symbol In-Reply-To: References: <47557948.1070907@charter.net> Message-ID: <128873334.20071205195658@gmail.com> Hello Simon, Wednesday, December 5, 2007, 7:05:22 PM, you wrote: > Anyway, while on this subject, I am considering making the following change: > make all operator symbols into type constructors > (currently they are type variables) i like it. will the same apply to the type functions? i.e. will it be possible to define +, *, etc type functions? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From g9ks157k at acme.softbase.org Wed Dec 5 17:47:40 2007 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Dec 5 17:43:25 2007 Subject: About -Wall option In-Reply-To: <3f3964000712050443u576370eft558b41c6334a5da0@mail.gmail.com> References: <3f3964000712050443u576370eft558b41c6334a5da0@mail.gmail.com> Message-ID: <200712052347.40762.g9ks157k@acme.softbase.org> Am Mittwoch, 5. Dezember 2007 13:43 schrieb Luis Cabellos: > Hi, > > I have a question, what's the best way to program? > - put all the signatures in the Haskell Code? > - Only put the type signatures needed to compile (like monomorphism errors > or ambiguous signature)? > > Until now, I prefer the second one, but when I use the -Wall option, > there's a lot of complains about type signature. Maybe the type signature > is something that not need to be checked as a warning. > > But if the best practice is to put all the signatures, I found that Cabal > generated code need to be fixed, because -Wall complains about it also. Inserting all type signatures is definitely best practice. Best wishes, Wolfgang From g9ks157k at acme.softbase.org Wed Dec 5 18:34:48 2007 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Dec 5 18:30:31 2007 Subject: type equality symbol In-Reply-To: References: Message-ID: <200712060034.48481.g9ks157k@acme.softbase.org> Am Mittwoch, 5. Dezember 2007 17:05 schrieb Simon Peyton-Jones: > [?] > Anyway, while on this subject, I am considering making the following > change: > > make all operator symbols into type constructors > (currently they are type variables) This would be highly problematic! Concerning syntax, everything that holds for values should also hold for types. For values, identifiers starting with a capital letter and operators starting with a colon denote ?constants?, everything else denotes variables. Exactly the same should hold for types since otherwise we would get a very confusing result. So we should keep things as they are concerning type constructors and type variables. And we should think about type functions being denoted by lower case identifiers and operators not starting with a colon because they are similar to non-constructor functions on the value level. We should strive for a systematic language and therefore not make ad-hoc decisions which for the moment seem to serve a purpose in some specific cases. > [?] Best wishes, Wolfgang From chak at cse.unsw.edu.au Wed Dec 5 19:06:16 2007 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Dec 5 19:02:05 2007 Subject: type equality symbol In-Reply-To: References: <47557948.1070907@charter.net> Message-ID: <11346127-075D-4358-AEC1-6FF14739E05A@cse.unsw.edu.au> Simon Peyton-Jones: > Nothing deep. Just that "=" means so many things that it seemed > better to use a different notation. > Also, using "=" would have entailed significant changes to GHC's parser. Type constraints are in the same syntactic category as types and types can appear as part of expressions in type annotations (such as "e::t") and on the lhs of let-bindings (such as "let x::t = e in e'"). Especially, considering the later, imagine "t" can now also contain the symbol "=" which in the grammar serves as a separator between the lhs and the rhs of a let bindings. I actually did try using "=", but it got too messy. Manuel > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org > ] On Behalf Of > | Isaac Dupree > | Sent: 04 December 2007 15:59 > | To: Jan-Willem Maessen > | Cc: Glasgow-haskell-users@haskell.org; Simon Peyton-Jones > | Subject: type equality symbol > | > | >> conv :: (a~b) => a -> b > | >> conv = id > | > | is there any particular reason that '~' is the symbol for type > equality > | constraints? I would think '=' would be the obvious choice, > (although > | perhaps it is already over-used, and is normally asymmetric in > Haskell!)? > | > | Isaac > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From isaacdupree at charter.net Wed Dec 5 19:20:41 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Dec 5 19:20:01 2007 Subject: type equality symbol In-Reply-To: <11346127-075D-4358-AEC1-6FF14739E05A@cse.unsw.edu.au> References: <47557948.1070907@charter.net> <11346127-075D-4358-AEC1-6FF14739E05A@cse.unsw.edu.au> Message-ID: <47574059.4030207@charter.net> Manuel M T Chakravarty wrote: > Simon Peyton-Jones: >> Nothing deep. Just that "=" means so many things that it seemed >> better to use a different notation. >> > Also, using "=" would have entailed significant changes to GHC's > parser. Type constraints are in the same syntactic category as types > and types can appear as part of expressions in type annotations (such as > "e::t") and on the lhs of let-bindings (such as "let x::t = e in e'"). > Especially, considering the later, imagine "t" can now also contain the > symbol "=" which in the grammar serves as a separator between the lhs > and the rhs of a let bindings. > > I actually did try using "=", but it got too messy. oh, because it doesn't require parentheses: f :: a ~ b => a -> b f = id and also because, it sounds like you say, current parser looks at "type-class" and "type" expressions the same, so one doesn't really want to distinguish them just for this. x :: a = b => c = x really is too confusing, even if I can't see any way to make it ambiguous given current set of available language extensions. okay! Isaac From chak at cse.unsw.edu.au Wed Dec 5 21:35:51 2007 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Dec 5 21:31:37 2007 Subject: type equality symbol In-Reply-To: <47574059.4030207@charter.net> References: <47557948.1070907@charter.net> <11346127-075D-4358-AEC1-6FF14739E05A@cse.unsw.edu.au> <47574059.4030207@charter.net> Message-ID: <7A6B77C0-B41F-4C98-BB1E-25B7CD8188F3@cse.unsw.edu.au> Isaac Dupree: > Manuel M T Chakravarty wrote: >> Simon Peyton-Jones: >>> Nothing deep. Just that "=" means so many things that it seemed >>> better to use a different notation. >>> >> Also, using "=" would have entailed significant changes to GHC's >> parser. Type constraints are in the same syntactic category as >> types and types can appear as part of expressions in type >> annotations (such as "e::t") and on the lhs of let-bindings (such >> as "let x::t = e in e'"). Especially, considering the later, >> imagine "t" can now also contain the symbol "=" which in the >> grammar serves as a separator between the lhs and the rhs of a let >> bindings. >> I actually did try using "=", but it got too messy. > > oh, because it doesn't require parentheses: > f :: a ~ b => a -> b > f = id > and also because, it sounds like you say, current parser looks at > "type-class" and "type" expressions the same, so one doesn't really > want to distinguish them just for this. > x :: a = b => c = x > really is too confusing, even if I can't see any way to make it > ambiguous given current set of available language extensions. For example, let {x :: t1 = t2 = e} in ... Now, this is not type correct, as x cannot have a type "t1 = t2", but the parser cannot know that. For the parser, a type constraint is a type like any other. Manuel From bbr at informatik.uni-kiel.de Thu Dec 6 04:43:30 2007 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Thu Dec 6 04:49:09 2007 Subject: C Preprocessor Message-ID: <4757C442.4080103@informatik.uni-kiel.de> Is it already a known problem that the preprocessor cannot cope with the whole set of possible string declarations? $ cat long1.hs {-# OPTIONS -cpp #-} s = "abc\ \defg" main = putStrLn s $ ghc long1.hs long1.hs:3:14: lexical error in string/character literal at character 'e' $ cat long2.hs s = "abc\ \defg" main = putStrLn s $ ghc long2.hs $ a.out abcdefg From g9ks157k at acme.softbase.org Thu Dec 6 05:36:32 2007 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Dec 6 05:32:17 2007 Subject: C Preprocessor In-Reply-To: <4757C442.4080103@informatik.uni-kiel.de> References: <4757C442.4080103@informatik.uni-kiel.de> Message-ID: <200712061136.32655.g9ks157k@acme.softbase.org> Am Donnerstag, 6. Dezember 2007 10:43 schrieb Bernd Brassel: > Is it already a known problem that the preprocessor cannot cope with the > whole set of possible string declarations? Yes, it is. There is cpphs () as an alternative. > [?] Best wishes, Wolfgang From simonmarhaskell at gmail.com Thu Dec 6 08:26:03 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Dec 6 08:21:34 2007 Subject: C Preprocessor In-Reply-To: <200712061136.32655.g9ks157k@acme.softbase.org> References: <4757C442.4080103@informatik.uni-kiel.de> <200712061136.32655.g9ks157k@acme.softbase.org> Message-ID: <4757F86B.3010503@gmail.com> Wolfgang Jeltsch wrote: > Am Donnerstag, 6. Dezember 2007 10:43 schrieb Bernd Brassel: >> Is it already a known problem that the preprocessor cannot cope with the >> whole set of possible string declarations? > > Yes, it is. There is cpphs () as an > alternative. Yes, or just don't use string gaps. ++ works just as well, and GHC will optimise it away when applied to constant strings. Cheers, Simon From ndmitchell at gmail.com Thu Dec 6 08:49:30 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Dec 6 08:44:55 2007 Subject: C Preprocessor In-Reply-To: <4757F86B.3010503@gmail.com> References: <4757C442.4080103@informatik.uni-kiel.de> <200712061136.32655.g9ks157k@acme.softbase.org> <4757F86B.3010503@gmail.com> Message-ID: <404396ef0712060549y38e7727pa4e45bcd6e8198d1@mail.gmail.com> Hi > Yes, or just don't use string gaps. ++ works just as well, and GHC will > optimise it away when applied to constant strings. There are also other issues, such as ' in variable names (can cause bits to be skipped in that line), /* as an operator, unboxed varids in #define's Thanks Neil From simonmarhaskell at gmail.com Thu Dec 6 09:43:33 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Dec 6 09:39:03 2007 Subject: C Preprocessor In-Reply-To: <404396ef0712060549y38e7727pa4e45bcd6e8198d1@mail.gmail.com> References: <4757C442.4080103@informatik.uni-kiel.de> <200712061136.32655.g9ks157k@acme.softbase.org> <4757F86B.3010503@gmail.com> <404396ef0712060549y38e7727pa4e45bcd6e8198d1@mail.gmail.com> Message-ID: <47580A95.1010104@gmail.com> Neil Mitchell wrote: >> Yes, or just don't use string gaps. ++ works just as well, and GHC will >> optimise it away when applied to constant strings. > > There are also other issues, such as ' in variable names (can cause > bits to be skipped in that line), /* as an operator, unboxed varids in > #define's Yes, sure. (although the ' thing doesn't bite us - perhaps it doesn't apply with -traditional?) Cheers, Simon From ndmitchell at gmail.com Thu Dec 6 09:47:28 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Dec 6 09:42:53 2007 Subject: C Preprocessor In-Reply-To: <47580A95.1010104@gmail.com> References: <4757C442.4080103@informatik.uni-kiel.de> <200712061136.32655.g9ks157k@acme.softbase.org> <4757F86B.3010503@gmail.com> <404396ef0712060549y38e7727pa4e45bcd6e8198d1@mail.gmail.com> <47580A95.1010104@gmail.com> Message-ID: <404396ef0712060647o123d98b7l57ce864c98e7f33f@mail.gmail.com> Hi Simon, > Yes, sure. (although the ' thing doesn't bite us - perhaps it doesn't > apply with -traditional?) I think it bit me last week. I had something like: #define a b foo'bar a In this case it did because "a" wasn't changed to "b". It may have been other complex things going on as well, but removing the ' fixed the issue. It's less likely to bite, but still hiding out :-) Thanks Neil From ganesh.sittampalam at credit-suisse.com Thu Dec 6 09:52:51 2007 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Dec 6 09:50:34 2007 Subject: C Preprocessor Message-ID: <8C984B4799C04D4B8F80F746537145E116F4F343@elon12p32001.csfp.co.uk> > > Yes, sure. (although the ' thing doesn't bite us - perhaps it doesn't > > apply with -traditional?) > I think it bit me last week. I had something like: It bites me too - something like this goes wrong with ghc -cpp: #define C(x) x foo' :: foo C(x) Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From antti-juhani at kaijanaho.fi Thu Dec 6 09:59:48 2007 From: antti-juhani at kaijanaho.fi (Antti-Juhani Kaijanaho) Date: Thu Dec 6 09:55:15 2007 Subject: C Preprocessor In-Reply-To: <4757C442.4080103@informatik.uni-kiel.de> References: <4757C442.4080103@informatik.uni-kiel.de> Message-ID: <20071206145948.GD5146@kukkaseppele.kaijanaho.fi> On Thu, Dec 06, 2007 at 10:43:30AM +0100, Bernd Brassel wrote: > Is it already a known problem that the preprocessor cannot cope with the > whole set of possible string declarations? The cpp is a *C* preprocessor, and if it has been written to adhere to the C standard, it is required to diagnose tokens that are not valid C preprocessing tokens (such as string literals that do not end before the end of a line). As such, this is unsurprising. It would probably make most sense to make cpphs the (only) preprocessor used with -cpp instead of using whatever *C* preprocessor happens to be in the path. -- Antti-Juhani Kaijanaho, Jyv?skyl?, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20071206/0c48d949/attachment.bin From isaacdupree at charter.net Thu Dec 6 10:01:53 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Dec 6 09:59:17 2007 Subject: C Preprocessor In-Reply-To: <47580A95.1010104@gmail.com> References: <4757C442.4080103@informatik.uni-kiel.de> <200712061136.32655.g9ks157k@acme.softbase.org> <4757F86B.3010503@gmail.com> <404396ef0712060549y38e7727pa4e45bcd6e8198d1@mail.gmail.com> <47580A95.1010104@gmail.com> Message-ID: <47580EE1.9050206@charter.net> Simon Marlow wrote: > Neil Mitchell wrote: > >>> Yes, or just don't use string gaps. ++ works just as well, and GHC will >>> optimise it away when applied to constant strings. >> >> There are also other issues, such as ' in variable names (can cause >> bits to be skipped in that line), /* as an operator, unboxed varids in >> #define's > > Yes, sure. (although the ' thing doesn't bite us it seems to have bitten at least at one time: there is a workaround in Data.Bits (see "wsib") : (I# x#) `rotate` (I# i#) = I# (word2Int# ((x'# `uncheckedShiftL#` i'#) `or#` (x'# `uncheckedShiftRL#` (wsib -# i'#)))) where x'# = int2Word# x# i'# = word2Int# (int2Word# i# `and#` int2Word# (wsib -# 1#)) wsib = WORD_SIZE_IN_BITS# {- work around preprocessor problem (??) -} Isaac From gwright at comcast.net Thu Dec 6 10:49:14 2007 From: gwright at comcast.net (Gregory Wright) Date: Thu Dec 6 10:44:54 2007 Subject: Which ghc versions can build ghc-6.8.1? Message-ID: <5FF8B973-F828-431C-913D-6380BAE72A5F@comcast.net> Hi, I'm the process of updating MacPort's ghc to 6.8.1 and adding support for Leopard (OS X 10.5) and have been having] some trouble. The first task is just to get 6.8.1 running on Tiger (10.4). On PPC, I use ghc 6.4 as a bootstrap compiler and on Intel ghc 6.6. I am traveling with only a PPC PowerBook G4/OS X 10.4, so that's all I've been able to test with. The problem is that ghc 6.4 can not build 6.8.1. It seems related to Cabal. Using the 6.4 bootstrap compiler (with the version of Cabal that it shipped with) I get: ranlib libHSrts_thr_debug.a ------------------------------------------------------------------------ == Finished recursively making `all' for ways: p debug thr thr_p thr_debug ... PWD = /opt/local/var/macports/build/_Users_gwright_src_macports- trunk_dports_lang_ghc/work/ghc-6.8.1/rts ------------------------------------------------------------------------ make -C libraries boot rm -f -rf bootstrapping.Cabal cp -R Cabal bootstrapping.Cabal /usr/bin/find bootstrapping.Cabal \( -name "*.o" -o -name "*.hi" \) \ -exec rm -f -f {} \; touch stamp/bootstrapping.Cabal rm -f -rf bootstrapping.filepath cp -R filepath bootstrapping.filepath /usr/bin/find bootstrapping.filepath \( -name "*.o" -o -name "*.hi" \) \ -exec rm -f -f {} \; touch stamp/bootstrapping.filepath rm -f -rf ifBuildable mkdir ifBuildable cp ifBuildable.hs ifBuildable/ cd ifBuildable && /opt/local/var/macports/build/ _Users_gwright_src_macports-trunk_dports_lang_ghc/work/ghc-bootstrap/ bin/ghc -Wall --make ifBuildable -o ifBuildable Chasing modules from: ifBuildable Compiling Main ( ifBuildable.hs, ifBuildable.o ) Linking ... ld: warning prebinding disabled because dependent library: /opt/local/ lib/libgmp.3.dylib is not prebound rm -f -rf base/setup mkdir base/setup cp base/Setup.*hs base/setup cd base/setup && /opt/local/var/macports/build/ _Users_gwright_src_macports-trunk_dports_lang_ghc/work/ghc-bootstrap/ bin/ghc -Wall -cpp --make Setup.*hs -o Setup \ -DCABAL_VERSION=1,2,2,0 -i../../ bootstrapping.Cabal -i../../bootstrapping.filepath Chasing modules from: Setup.hs Compiling System.FilePath.Posix ( ../../bootstrapping.filepath/System/ FilePath/Posix.hs, ../../bootstrapping.filepath/System/FilePath/ Posix.o ) Compiling System.FilePath ( ../../bootstrapping.filepath/System/ FilePath.hs, ../../bootstrapping.filepath/System/FilePath.o ) Compiling Main ( Setup.hs, Setup.o ) Setup.hs:19:18: Not in scope: `buildHook' Setup.hs:21:30: Not in scope: `buildHook' Setup.hs:22:18: Not in scope: `makefileHook' Setup.hs:24:33: Not in scope: `makefileHook' Setup.hs:25:18: Not in scope: `instHook' Setup.hs:26:29: Not in scope: `instHook' Setup.hs:33:12: Not in scope: `compilerFlavor' Setup.hs:33:45: Not in scope: data constructor `GHC' make[1]: *** [base/setup/Setup] Error 1 make: *** [stage1] Error 2 If I upgrade the bootstrap compiler's Cabal to 1.1.6.2, the build still fails. (The old version of Cabal was unregistered according the instructions for working with older versions of ghc & Cabal.) ranlib libHSrts_thr_debug.a ------------------------------------------------------------------------ == Finished recursively making `all' for ways: p debug thr thr_p thr_debug ... PWD = /Users/gwright/Desktop/ghc-6.8.1/rts ------------------------------------------------------------------------ make -C libraries boot rm -f -rf bootstrapping.Cabal cp -R Cabal bootstrapping.Cabal /usr/bin/find bootstrapping.Cabal \( -name "*.o" -o -name "*.hi" \) \ -exec rm -f -f {} \; touch stamp/bootstrapping.Cabal rm -f -rf bootstrapping.filepath cp -R filepath bootstrapping.filepath /usr/bin/find bootstrapping.filepath \( -name "*.o" -o -name "*.hi" \) \ -exec rm -f -f {} \; touch stamp/bootstrapping.filepath rm -f -rf ifBuildable mkdir ifBuildable cp ifBuildable.hs ifBuildable/ cd ifBuildable && /opt/local/bin/ghc -Wall --make ifBuildable -o ifBuildable Chasing modules from: ifBuildable Compiling Main ( ifBuildable.hs, ifBuildable.o ) Linking ... rm -f -rf base/setup mkdir base/setup cp base/Setup.*hs base/setup cd base/setup && /opt/local/bin/ghc -Wall -cpp --make Setup.*hs -o Setup \ -DCABAL_VERSION=1,2,2,0 -i../../ bootstrapping.Cabal -i../../bootstrapping.filepath Chasing modules from: Setup.hs Compiling System.FilePath.Posix ( ../../bootstrapping.filepath/System/ FilePath/Posix.hs, ../../bootstrapping.filepath/System/FilePath/ Posix.o ) Compiling System.FilePath ( ../../bootstrapping.filepath/System/ FilePath.hs, ../../bootstrapping.filepath/System/FilePath.o ) Compiling Main ( Setup.hs, Setup.o ) Setup.hs:22:18: Not in scope: `makefileHook' Setup.hs:24:33: Not in scope: `makefileHook' make[1]: *** [base/setup/Setup] Error 1 make: *** [stage1] Error 2 With my installed 6.6.1 (and the Cabal 1.1.6.2 shipped with it) I was able to build 6.8.1. I tried adding "-ignore-package Cabal" to the lines BOOTSTRAP_INC_1_UP = -DCABAL_VERSION=1,2,2,0 $(addprefix -i../ bootstrapping.,$(BOOTSTRAP_LIBS)) BOOTSTRAP_INC_2_UP = -DCABAL_VERSION=1,2,2,0 $(addprefix -i../../ bootstrapping.,$(BOOTSTRAP_LIBS)) in libraries/Makefile and was able to compile all of the Setup files, but the "setup configure" failed in libraries/base, complaining that Setup could not determine the version of ghc-inplace. (It also printed a message that to build libraries/base the ghc version needs to be at least 6.2. This at the least is different than the distribution web page, which only mentions that ghc => 6.0 is needed.) For comparison, the same part of the build log building 6.8.1 using the 6.6.1 installed by MacPorts: ranlib libHSrts_thr_debug.a ------------------------------------------------------------------------ == Finished recursively making `all' for ways: p debug thr thr_p thr_debug ... PWD = /Users/gwright/Desktop/ghc-6.8.1/rts ------------------------------------------------------------------------ make -C libraries boot rm -f -rf bootstrapping.Cabal cp -R Cabal bootstrapping.Cabal /usr/bin/find bootstrapping.Cabal \( -name "*.o" -o -name "*.hi" \) \ -exec rm -f -f {} \; touch stamp/bootstrapping.Cabal rm -f -rf bootstrapping.filepath cp -R filepath bootstrapping.filepath /usr/bin/find bootstrapping.filepath \( -name "*.o" -o -name "*.hi" \) \ -exec rm -f -f {} \; touch stamp/bootstrapping.filepath rm -f -rf ifBuildable mkdir ifBuildable cp ifBuildable.hs ifBuildable/ cd ifBuildable && /opt/local/bin/ghc -Wall --make ifBuildable -o ifBuildable [1 of 1] Compiling Main ( ifBuildable.hs, ifBuildable.o ) Linking ifBuildable ... rm -f -rf base/setup mkdir base/setup cp base/Setup.*hs base/setup cd base/setup && /opt/local/bin/ghc -Wall -cpp --make Setup.*hs -o Setup \ -DCABAL_VERSION=1,2,2,0 -i../../ bootstrapping.Cabal -i../../bootstrapping.filepath [ 1 of 42] Compiling Distribution.Simple.GHC.Makefile ( ../../ bootstrapping.Cabal/Distribution/Simple/GHC/Makefile.hs, ../../ bootstrapping.Cabal/Distribution/Simple/GHC/Makefile.o ) [ 2 of 42] Compiling Distribution.Simple.PreProcess.Unlit ( ../../ bootstrapping.Cabal/Distribution/Simple/PreProcess/Unlit.hs, ../../ bootstrapping.Cabal/Distribution/Simple/PreProcess/Unlit.o ) [ 3 of 42] Compiling Distribution.System ( ../../bootstrapping.Cabal/ Distribution/System.hs, ../../bootstrapping.Cabal/Distribution/ System.o ) [ 4 of 42] Compiling Distribution.Verbosity ( ../../ bootstrapping.Cabal/Distribution/Verbosity.hs, ../../ bootstrapping.Cabal/Distribution/Verbosity.o ) [ 5 of 42] Compiling Distribution.Compat.ReadP ( ../../ bootstrapping.Cabal/Distribution/Compat/ReadP.hs, ../../ bootstrapping.Cabal/Distribution/Compat/ReadP.o ) [ 6 of 42] Compiling Distribution.Compat.RawSystem ( ../../ bootstrapping.Cabal/Distribution/Compat/RawSystem.hs, ../../ bootstrapping.Cabal/Distribution/Compat/RawSystem.o ) [ 7 of 42] Compiling Distribution.Compat.Exception ( ../../ bootstrapping.Cabal/Distribution/Compat/Exception.hs, ../../ bootstrapping.Cabal/Distribution/Compat/Exception.o ) [ 8 of 42] Compiling Distribution.Compat.Directory ( ../../ bootstrapping.Cabal/Distribution/Compat/Directory.hs, ../../ bootstrapping.Cabal/Distribution/Compat/Directory.o ) [ 9 of 42] Compiling Distribution.Compat.Map ( ../../ bootstrapping.Cabal/Distribution/Compat/Map.hs, ../../ bootstrapping.Cabal/Distribution/Compat/Map.o ) [10 of 42] Compiling Distribution.GetOpt ( ../../bootstrapping.Cabal/ Distribution/GetOpt.hs, ../../bootstrapping.Cabal/Distribution/ GetOpt.o ) [11 of 42] Compiling Language.Haskell.Extension ( ../../ bootstrapping.Cabal/Language/Haskell/Extension.hs, ../../ bootstrapping.Cabal/Language/Haskell/Extension.o ) [12 of 42] Compiling Distribution.Version ( ../../bootstrapping.Cabal/ Distribution/Version.hs, ../../bootstrapping.Cabal/Distribution/ Version.o ) [13 of 42] Compiling Distribution.Configuration ( ../../ bootstrapping.Cabal/Distribution/Configuration.hs, ../../ bootstrapping.Cabal/Distribution/Configuration.o ) [14 of 42] Compiling Distribution.Package ( ../../bootstrapping.Cabal/ Distribution/Package.hs, ../../bootstrapping.Cabal/Distribution/ Package.o ) [15 of 42] Compiling Distribution.License ( ../../bootstrapping.Cabal/ Distribution/License.hs, ../../bootstrapping.Cabal/Distribution/ License.o ) [16 of 42] Compiling Distribution.Compiler ( ../../ bootstrapping.Cabal/Distribution/Compiler.hs, ../../ bootstrapping.Cabal/Distribution/Compiler.o ) [17 of 42] Compiling Distribution.ParseUtils ( ../../ bootstrapping.Cabal/Distribution/ParseUtils.hs, ../../ bootstrapping.Cabal/Distribution/ParseUtils.o ) [18 of 42] Compiling Distribution.InstalledPackageInfo ( ../../ bootstrapping.Cabal/Distribution/InstalledPackageInfo.hs, ../../ bootstrapping.Cabal/Distribution/InstalledPackageInfo.o ) [19 of 42] Compiling Distribution.Simple.Compiler ( ../../ bootstrapping.Cabal/Distribution/Simple/Compiler.hs, ../../ bootstrapping.Cabal/Distribution/Simple/Compiler.o ) [20 of 42] Compiling System.FilePath.Posix ( ../../ bootstrapping.filepath/System/FilePath/Posix.hs, ../../ bootstrapping.filepath/System/FilePath/Posix.o ) [21 of 42] Compiling System.FilePath ( ../../bootstrapping.filepath/ System/FilePath.hs, ../../bootstrapping.filepath/System/FilePath.o ) [22 of 42] Compiling Distribution.Compat.TempFile ( ../../ bootstrapping.Cabal/Distribution/Compat/TempFile.hs, ../../ bootstrapping.Cabal/Distribution/Compat/TempFile.o ) [23 of 42] Compiling Distribution.Simple.Utils ( ../../ bootstrapping.Cabal/Distribution/Simple/Utils.hs, ../../ bootstrapping.Cabal/Distribution/Simple/Utils.o ) [24 of 42] Compiling Distribution.PackageDescription ( ../../ bootstrapping.Cabal/Distribution/PackageDescription.hs, ../../ bootstrapping.Cabal/Distribution/PackageDescription.o ) [25 of 42] Compiling Distribution.Simple.Program ( ../../ bootstrapping.Cabal/Distribution/Simple/Program.hs, ../../ bootstrapping.Cabal/Distribution/Simple/Program.o ) [26 of 42] Compiling Distribution.Simple.Setup ( ../../ bootstrapping.Cabal/Distribution/Simple/Setup.hs, ../../ bootstrapping.Cabal/Distribution/Simple/Setup.o ) [27 of 42] Compiling Distribution.Simple.InstallDirs ( ../../ bootstrapping.Cabal/Distribution/Simple/InstallDirs.hs, ../../ bootstrapping.Cabal/Distribution/Simple/InstallDirs.o ) [28 of 42] Compiling Distribution.Simple.LocalBuildInfo ( ../../ bootstrapping.Cabal/Distribution/Simple/LocalBuildInfo.hs, ../../ bootstrapping.Cabal/Distribution/Simple/LocalBuildInfo.o ) [29 of 42] Compiling Distribution.Simple.JHC ( ../../ bootstrapping.Cabal/Distribution/Simple/JHC.hs, ../../ bootstrapping.Cabal/Distribution/Simple/JHC.o ) [30 of 42] Compiling Distribution.Simple.NHC ( ../../ bootstrapping.Cabal/Distribution/Simple/NHC.hs, ../../ bootstrapping.Cabal/Distribution/Simple/NHC.o ) [31 of 42] Compiling Distribution.Simple.PreProcess ( ../../ bootstrapping.Cabal/Distribution/Simple/PreProcess.hs, ../../ bootstrapping.Cabal/Distribution/Simple/PreProcess.o ) [32 of 42] Compiling Distribution.Simple.Hugs ( ../../ bootstrapping.Cabal/Distribution/Simple/Hugs.hs, ../../ bootstrapping.Cabal/Distribution/Simple/Hugs.o ) [33 of 42] Compiling Distribution.Simple.SrcDist ( ../../ bootstrapping.Cabal/Distribution/Simple/SrcDist.hs, ../../ bootstrapping.Cabal/Distribution/Simple/SrcDist.o ) [34 of 42] Compiling Distribution.Simple.Haddock ( ../../ bootstrapping.Cabal/Distribution/Simple/Haddock.hs, ../../ bootstrapping.Cabal/Distribution/Simple/Haddock.o ) [35 of 42] Compiling Distribution.Simple.GHC.PackageConfig ( ../../ bootstrapping.Cabal/Distribution/Simple/GHC/PackageConfig.hs, ../../ bootstrapping.Cabal/Distribution/Simple/GHC/PackageConfig.o ) [36 of 42] Compiling Distribution.Simple.GHC ( ../../ bootstrapping.Cabal/Distribution/Simple/GHC.hs, ../../ bootstrapping.Cabal/Distribution/Simple/GHC.o ) [37 of 42] Compiling Distribution.Simple.Install ( ../../ bootstrapping.Cabal/Distribution/Simple/Install.hs, ../../ bootstrapping.Cabal/Distribution/Simple/Install.o ) [38 of 42] Compiling Distribution.Simple.Register ( ../../ bootstrapping.Cabal/Distribution/Simple/Register.hs, ../../ bootstrapping.Cabal/Distribution/Simple/Register.o ) [39 of 42] Compiling Distribution.Simple.Configure ( ../../ bootstrapping.Cabal/Distribution/Simple/Configure.hs, ../../ bootstrapping.Cabal/Distribution/Simple/Configure.o ) [40 of 42] Compiling Distribution.Simple.Build ( ../../ bootstrapping.Cabal/Distribution/Simple/Build.hs, ../../ bootstrapping.Cabal/Distribution/Simple/Build.o ) [41 of 42] Compiling Distribution.Simple ( ../../bootstrapping.Cabal/ Distribution/Simple.hs, ../../bootstrapping.Cabal/Distribution/ Simple.o ) [42 of 42] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... Can 6.4 build 6.8.1? Or is a later version required? If possible, I want to use the existing bootstrap compiler for OS X < 10.5, since building a new one is a lot of work, especially to root out unnecessary dependencies. And it would mean terminating support for Panther (10.3). We only promise support for the most recent two OS version, so dropping Panther is not a big deal, but I try not to gratuitously drop support for older version if I can avoid it. If a later version bootstrap compiler is needed, we should take the opportunity to update the documentation. Best Wishes, Greg From zhen.sydow at gmail.com Thu Dec 6 11:08:21 2007 From: zhen.sydow at gmail.com (Luis Cabellos) Date: Thu Dec 6 11:03:49 2007 Subject: About -Wall option In-Reply-To: <2608b8a80712060407s2b3a157dof65df0ec64298319@mail.gmail.com> References: <3f3964000712050443u576370eft558b41c6334a5da0@mail.gmail.com> <200712052347.40762.g9ks157k@acme.softbase.org> <2608b8a80712060407s2b3a157dof65df0ec64298319@mail.gmail.com> Message-ID: <3f3964000712060808q6ebeadc8o94eaccafeafe1500@mail.gmail.com> I think that put signatures is a good practice. I will switch to that. Maybe I preferred to not put signatures because is cooler than other languages type systems :-D Wolfgang Jeltsch wrote: > Inserting all type signatures is definitely best practice. Yitzchak Gale wrote: >My personal style is: >o Put signatures on everything at the top-level >o Inside let and where, only where necessary, BUT: From simonmarhaskell at gmail.com Thu Dec 6 11:46:29 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Dec 6 11:42:02 2007 Subject: Problems building and using ghc-6.9 In-Reply-To: <200712040030.26360.daniel.is.fischer@web.de> References: <200712040030.26360.daniel.is.fischer@web.de> Message-ID: <47582765.2090605@microsoft.com> Daniel Fischer wrote: > Then I tried to build zlib-0.4.0.1: > $ runghc ./Setup.hs configure --user --prefix=$HOME > Configuring zlib-0.4.0.1... > Setup.hs: At least the following dependencies are missing: > base >=2.0&&<2.2 > ??? okay, there was something with flag bytestring-in-base, removed that, so > that build-depends was base < 2.0 || >= 2.2, bytestring >= 0.9, then > $ runghc ./Setup.hs configure --user --prefix=$HOME > Configuring zlib-0.4.0.1... > Setup.hs: At least the following dependencies are missing: > base <2.0||>=2.2, bytestring >=0.9 This turns out to be something that broke when we changed the command-line syntax for ghc-pkg in the HEAD. I've just posted a patch for Cabal on cvs-ghc@haskell.org. Cheers, Simon From haskell at list.mightyreason.com Thu Dec 6 17:17:09 2007 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Thu Dec 6 17:12:35 2007 Subject: Which ghc versions can build ghc-6.8.1? In-Reply-To: <5FF8B973-F828-431C-913D-6380BAE72A5F@comcast.net> References: <5FF8B973-F828-431C-913D-6380BAE72A5F@comcast.net> Message-ID: <475874E5.8060309@list.mightyreason.com> Gregory Wright wrote: > > Hi, > > I'm the process of updating MacPort's ghc to 6.8.1 and adding support for > Leopard (OS X 10.5) and have been having] some trouble. Great. I am using 10.5 on a PPC You ought to read the ongoing saga at http://hackage.haskell.org/trac/ghc/ticket/1843 In general, we cannot yet make ghc-6.8.1 on a powerpc running OS X 10.5 (XCode 3.0). My guess is that there is more than one fatal issue. > The first task is just to get 6.8.1 running on Tiger (10.4). On PPC, I use > ghc 6.4 as a bootstrap compiler and on Intel ghc 6.6. I am traveling with > only a PPC PowerBook G4/OS X 10.4, so that's all I've been able to > test with. There are two binaries of ghc 6.8.1 for Tiger (10.4) posted on the site, so if you are _really_ hard up for a bootstrap.... > The problem is that ghc 6.4 can not build 6.8.1. It seems related to > Cabal. The latest Cabal is 1.2 (well, 1.2.2.0) and allows for packages to compile under 6.8 and 6.6 and hopefully 6.4. Any attempt to support more than one of those ghc versions ought to be equipped with Cabal 1.2 > Using the 6.4 bootstrap compiler (with the version of Cabal that it shipped > with) I get: snip > If I upgrade the bootstrap compiler's Cabal to 1.1.6.2, the build still > fails. Why only upgrade to 1.1.6.2 and not 1.2.whatever ? > > Can 6.4 build 6.8.1? Or is a later version required? If possible, I want > to use the existing bootstrap compiler for OS X < 10.5, since building a > new one is a lot of work, especially to root out unnecessary dependencies. > And it would mean terminating support for Panther (10.3). We only promise > support for the most recent two OS version, so dropping Panther is not a > big deal, > but I try not to gratuitously drop support for older version if I can > avoid it. > > If a later version bootstrap compiler is needed, we should take the > opportunity to update the documentation. You might ask on the #haskell IRC channel... Cheers, Chris From lennart at augustsson.net Thu Dec 6 17:53:18 2007 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Dec 6 17:48:44 2007 Subject: type equality symbol In-Reply-To: <200712060034.48481.g9ks157k@acme.softbase.org> References: <200712060034.48481.g9ks157k@acme.softbase.org> Message-ID: I don't think it's highly problematic. I agree that it would be nice to have the type and value levels have a similar structure, but if there are compelling reasons to do otherwise that fine too. You could still allow symbol type variables if they have an explicit binding occurence, which you can always(?) do with type variables. -- Lennart On Dec 5, 2007 11:34 PM, Wolfgang Jeltsch wrote: > Am Mittwoch, 5. Dezember 2007 17:05 schrieb Simon Peyton-Jones: > > [?] > > > Anyway, while on this subject, I am considering making the following > > change: > > > > make all operator symbols into type constructors > > (currently they are type variables) > > This would be highly problematic! > > Concerning syntax, everything that holds for values should also hold for > types. For values, identifiers starting with a capital letter and > operators > starting with a colon denote "constants", everything else denotes > variables. > Exactly the same should hold for types since otherwise we would get a very > confusing result. So we should keep things as they are concerning type > constructors and type variables. And we should think about type functions > being denoted by lower case identifiers and operators not starting with a > colon because they are similar to non-constructor functions on the value > level. > > We should strive for a systematic language and therefore not make ad-hoc > decisions which for the moment seem to serve a purpose in some specific > cases. > > > [?] > > Best wishes, > Wolfgang > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20071206/0302562e/attachment-0001.htm From chak at cse.unsw.edu.au Thu Dec 6 20:36:19 2007 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Dec 6 20:31:48 2007 Subject: type equality symbol In-Reply-To: <200712060034.48481.g9ks157k@acme.softbase.org> References: <200712060034.48481.g9ks157k@acme.softbase.org> Message-ID: <49D7BB69-A5C3-4CC9-8685-54404EC513F9@cse.unsw.edu.au> Wolfgang Jeltsch: > Am Mittwoch, 5. Dezember 2007 17:05 schrieb Simon Peyton-Jones: >> [?] > >> Anyway, while on this subject, I am considering making the following >> change: >> >> make all operator symbols into type constructors >> (currently they are type variables) > > This would be highly problematic! > > Concerning syntax, everything that holds for values should also hold > for > types. For values, identifiers starting with a capital letter and > operators > starting with a colon denote ?constants?, everything else denotes > variables. > Exactly the same should hold for types since otherwise we would get > a very > confusing result. So we should keep things as they are concerning > type > constructors and type variables. And we should think about type > functions > being denoted by lower case identifiers and operators not starting > with a > colon because they are similar to non-constructor functions on the > value > level. The problem is that Haskell 98 already messed that up. If type functions are to use lower-case letters, vanilla type synonyms should use lower case-letters; eg, type string = [Char] Unfortunately, such a change would break about every single Haskell program. So, unless we make some rather drastic changes breaking backwards compatibility, we will not be able to get an entirely clean solution. Manuel From waldmann at imn.htwk-leipzig.de Fri Dec 7 07:45:41 2007 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Fri Dec 7 07:41:11 2007 Subject: type equality symbol Message-ID: <47594075.60408@imn.htwk-leipzig.de> On Fri, 7 Dec 2007, Manuel M T Chakravarty wrote: > The problem is that Haskell 98 already messed that up. > If type functions are to use lower-case letters, [...] Yes. The broken thing is that the upper/lower case distinction has syntactic importance in the language definition at all. I guess this was introduced to avoid writing out some declarations. This is a bad design goal, especially so for a declarative language. Reminds me of ancient Fortran using the first letter of an identifier for implicit typing (I .. N for integer, others for real). Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ ------- From igloo at earth.li Fri Dec 7 07:58:27 2007 From: igloo at earth.li (Ian Lynagh) Date: Fri Dec 7 07:53:52 2007 Subject: ANNOUNCE: GHC 6.8.2 Release Candidate Message-ID: <20071207125827.GA24302@matrix.chaos.earth.li> We are pleased to announce the Release Candidate phase for GHC 6.8.2. Snapshots beginning with 6.8.1.20071206 are release candidates for 6.8.2 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.1.20071206-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.1.20071206-src-extralibs.tar.bz2 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 From alfonso.acosta at gmail.com Fri Dec 7 09:18:25 2007 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Fri Dec 7 09:13:48 2007 Subject: ANNOUNCE: GHC 6.8.2 Release Candidate In-Reply-To: <20071207125827.GA24302@matrix.chaos.earth.li> References: <20071207125827.GA24302@matrix.chaos.earth.li> Message-ID: <6a7c66fc0712070618x61c5bcabseb1c6e8ea581049c@mail.gmail.com> I know there are some problems with Leopard (OSX 10.5) but, before bothering compile the release, should it be expected to work on Leopard/PPC or Leopard/Intel? On Dec 7, 2007 1:58 PM, Ian Lynagh wrote: > > We are pleased to announce the Release Candidate phase for GHC 6.8.2. > > Snapshots beginning with 6.8.1.20071206 are release candidates for 6.8.2 > > 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.1.20071206-src.tar.bz2 > http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.1.20071206-src-extralibs.tar.bz2 > > 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 > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From joelr1 at gmail.com Fri Dec 7 09:30:06 2007 From: joelr1 at gmail.com (Joel Reymont) Date: Fri Dec 7 09:25:32 2007 Subject: ANNOUNCE: GHC 6.8.2 Release Candidate In-Reply-To: <6a7c66fc0712070618x61c5bcabseb1c6e8ea581049c@mail.gmail.com> References: <20071207125827.GA24302@matrix.chaos.earth.li> <6a7c66fc0712070618x61c5bcabseb1c6e8ea581049c@mail.gmail.com> Message-ID: <524BCCD9-3A31-4F3E-83DE-29199A65C0CA@gmail.com> I don't have any problems with ghc 6.8.x on Leopard x86. I believe the problems are confined to Leopard PPC. On Dec 7, 2007, at 2:18 PM, Alfonso Acosta wrote: > I know there are some problems with Leopard (OSX 10.5) but, before > bothering compile the release, should it be expected to work on > Leopard/PPC or Leopard/Intel? -- http://wagerlabs.com From garious at gmail.com Fri Dec 7 17:04:24 2007 From: garious at gmail.com (Greg Fitzgerald) Date: Fri Dec 7 16:59:46 2007 Subject: HUnit 1.2.0.0 on 6.8.1 vs 1.1.1 on 6.6.1 In-Reply-To: <20071203152306.GA12568@matrix.chaos.earth.li> References: <1f3dc80d0711211113j412b9abctfa6bfe2280d41f9e@mail.gmail.com> <20071203152306.GA12568@matrix.chaos.earth.li> Message-ID: <1f3dc80d0712071404y189dc65eg1f04dfbc3888a130@mail.gmail.com> >> > "abc" @=? "efg" >> Loading package HUnit-1.2.0.0 ... linking ... done. >> *** Exception: (unknown) On Dec 3, 2007 7:23 AM, Ian Lynagh wrote: > This is caused by a change in the HUnit library, from > assertFailure msg = ioError (userError (hunitPrefix ++ msg)) > to > assertFailure msg = E.throwDyn (HUnitFailure msg) > > We don't really have a good answer for where non-bootlib library bugs > should go at the moment. I don't know if Dean uses the sourceforge bug > tracker or not. Could this change be reverted for 6.8.2? HUnit is mostly useless in its current state. Thanks, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20071207/15e1dd5f/attachment.htm From garious at gmail.com Fri Dec 7 17:24:18 2007 From: garious at gmail.com (Greg Fitzgerald) Date: Fri Dec 7 17:19:41 2007 Subject: GHC 6.8.2, Haddock not finding std libs Message-ID: <1f3dc80d0712071424p52f70ef9of4dc8a08c39fcde4@mail.gmail.com> > Please test as much as possible One difference between 6.8.1 and 6.8.2 that I see is in running "runhaskell Setup.hs haddock" with Haddock 0.8 on Windows XP. Haddock is no longer able to resolve the names from the standard libraries. Running Haddock for Xyz-0.1... Warning: Xyz: the following names could not be resolved: FilePath Show Eq String Maybe Bool Char Int Thanks, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20071207/a4c4c95b/attachment.htm From igloo at earth.li Fri Dec 7 17:48:26 2007 From: igloo at earth.li (Ian Lynagh) Date: Fri Dec 7 17:43:54 2007 Subject: HUnit 1.2.0.0 on 6.8.1 vs 1.1.1 on 6.6.1 In-Reply-To: <1f3dc80d0712071404y189dc65eg1f04dfbc3888a130@mail.gmail.com> References: <1f3dc80d0711211113j412b9abctfa6bfe2280d41f9e@mail.gmail.com> <20071203152306.GA12568@matrix.chaos.earth.li> <1f3dc80d0712071404y189dc65eg1f04dfbc3888a130@mail.gmail.com> Message-ID: <20071207224826.GA657@matrix.chaos.earth.li> Hi Greg, On Fri, Dec 07, 2007 at 02:04:24PM -0800, Greg Fitzgerald wrote: > >> > "abc" @=? "efg" > >> Loading package HUnit-1.2.0.0 ... linking ... done. > >> *** Exception: (unknown) > > On Dec 3, 2007 7:23 AM, Ian Lynagh wrote: > > This is caused by a change in the HUnit library, from > > assertFailure msg = ioError (userError (hunitPrefix ++ msg)) > > to > > assertFailure msg = E.throwDyn (HUnitFailure msg) > > > > We don't really have a good answer for where non-bootlib library bugs > > should go at the moment. I don't know if Dean uses the sourceforge bug > > tracker or not. > > Could this change be reverted for 6.8.2? HUnit is mostly useless in its > current state. HUnit is not part of GHC, and can be installed and upgraded separately. For convenience, some binary distributions, installers and the extralibs tarball do include it. They just use the latest version in the darcs repositories at the time that they are built, so if it is fixed in the HUnit repo before 6.8.2 is built then the fix will be in the bindists etc. The HUnit cabal file lists Dean Herington as the author, but without giving an e-mail address for him. Thanks Ian From lennart at augustsson.net Fri Dec 7 19:59:39 2007 From: lennart at augustsson.net (Lennart Augustsson) Date: Fri Dec 7 19:55:01 2007 Subject: type equality symbol In-Reply-To: <47594075.60408@imn.htwk-leipzig.de> References: <47594075.60408@imn.htwk-leipzig.de> Message-ID: I agree. There are other ways that to solve the same problem as the case distinction does. On Dec 7, 2007 12:45 PM, Johannes Waldmann wrote: > On Fri, 7 Dec 2007, Manuel M T Chakravarty wrote: > > > The problem is that Haskell 98 already messed that up. > > If type functions are to use lower-case letters, [...] > > Yes. > > The broken thing is that the upper/lower case distinction > has syntactic importance in the language definition at all. > > I guess this was introduced to avoid writing out > some declarations. This is a bad design goal, > especially so for a declarative language. > > Reminds me of ancient Fortran using the first letter of an identifier > for implicit typing (I .. N for integer, others for real). > > Best regards, > -- > -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- > ---- http://www.imn.htwk-leipzig.de/~waldmann/------- > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20071208/362591e5/attachment-0001.htm From duncan.coutts at worc.ox.ac.uk Sat Dec 8 19:14:03 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Dec 8 19:09:07 2007 Subject: GHC 6.8.2, Haddock not finding std libs In-Reply-To: <1f3dc80d0712071424p52f70ef9of4dc8a08c39fcde4@mail.gmail.com> References: <1f3dc80d0712071424p52f70ef9of4dc8a08c39fcde4@mail.gmail.com> Message-ID: <1197159243.22469.52.camel@localhost> On Fri, 2007-12-07 at 14:24 -0800, Greg Fitzgerald wrote: > > Please test as much as possible > > One difference between 6.8.1 and 6.8.2 that I see is in running > "runhaskell Setup.hs haddock" with Haddock 0.8 on Windows XP. Haddock > is no longer able to resolve the names from the standard libraries. Really? I get the opposite. In 6.8.1 the ghc-pkg entries for the haddock files were messed somehow so Cabal would always ignore those packages and not ask haddock to try and generate links to them. From my testing that's fixed in the 6.8.2 snapshots. > Running Haddock for Xyz-0.1... > Warning: Xyz: the following names could not be resolved: > FilePath Show Eq String Maybe Bool Char Int Did Cabal earlier give warnings like: The documentation for package base-3.0.0.0 is not installed. No links to it will be generated. That's what I was getting previously. Perhaps you can investigate further and give some more details. Duncan From igloo at earth.li Sat Dec 8 19:34:30 2007 From: igloo at earth.li (Ian Lynagh) Date: Sat Dec 8 19:29:51 2007 Subject: GHC 6.8.2, Haddock not finding std libs In-Reply-To: <1f3dc80d0712071424p52f70ef9of4dc8a08c39fcde4@mail.gmail.com> References: <1f3dc80d0712071424p52f70ef9of4dc8a08c39fcde4@mail.gmail.com> Message-ID: <20071209003430.GA1971@matrix.chaos.earth.li> Hi Greg, On Fri, Dec 07, 2007 at 02:24:18PM -0800, Greg Fitzgerald wrote: > > Please test as much as possible > > One difference between 6.8.1 and 6.8.2 that I see is in running "runhaskell > Setup.hs haddock" with Haddock 0.8 on Windows XP. Haddock is no longer able > to resolve the names from the standard libraries. > > Running Haddock for Xyz-0.1... > Warning: Xyz: the following names could not be resolved: > FilePath Show Eq String Maybe Bool Char Int Thanks for the report! The problem is that the bindists are made with a haddock that makes platform independent haddock files (which means we treat Int as being 64-bit), but the current release doesn't understand that (on 32-bit platforms it tries to read Ints as 32-bit). There should be a new haddock release shortly, which fixes that as well as an HTML link bug. Or you can get the latest source with darcs from http://darcs.haskell.org/haddock/ Thanks Ian From scm at iis.sinica.edu.tw Sat Dec 8 21:50:40 2007 From: scm at iis.sinica.edu.tw (Shin-Cheng Mu) Date: Sat Dec 8 21:46:09 2007 Subject: Encoding Lists with Lengths by Type Family Message-ID: <06847852-EA64-4FB7-A848-30C63BE6FEAE@iis.sinica.edu.tw> Hi, I understand that the type family is still an experimental feature in GHC. This is just a confirmation whether it is a bug, or is what the designers intended. I am curious how much "dependent type" programming I can emulate using GADT and type family. Therefore I started with the typical "list with length" example. List a n is a list of elements a and length n encoded by singleton types Zero and Suc, as was done in the paper Towards Open Type Functions for Haskell: > data Zero = Zero > data Suc a = Suc a > data List a n where > Nil :: List a Zero > Cons :: a -> List a n -> List a (Suc n) Concatenation effortlessly type checks! > cat :: List a m -> List a n -> List a (Plus m n) > cat Nil y = y > cat (Cons a x) y = Cons a (cat x y) However, I was not able to convince GHC that the following function revcat, list reversal using an accumulating parameter, is type correct: > revcat :: List a m -> List a n -> List a (Plus m n) > revcat Nil y = y > revcat (Cons a x) y = > subst incAssocL (revcat x (Cons a y)) In the recursive case, (Cons a x) has type List a (Suc m) and y has type List a n. The recursive call to revcat is supposed to yield a list of type: List a (Plus m (Suc n)) while we want the return type to be List a (Plus (Suc m) n) Therefore I shall provide a conversion proving that they are actually the same thing. Currently I give the types only and will think about how to implement them later: > subst :: (m -> n) -> List a m -> List a n > subst = undefined > incAssocL :: Plus m (Suc n) -> Plus (Suc m) n > incAssocL = undefined However, GHCi (run with options -XTypeFamilies -XGADTs) gave me the following error message: Couldn't match expected type `Plus n3 n2' against inferred type `Plus m n1' Expected type: Plus m (Suc n1) -> Plus (Suc n3) n2 Inferred type: Plus m (Suc n1) -> Plus (Suc m) n1 In the first argument of `subst', namely `incAssocL' In the expression: subst incAssocL (revcat x (Cons a y)) For some reason GHC wanted me to return the more general type Plus (Suc n3) n2 where n2 and n3 are fresh, rather than unifying n2 with m and n2 with n. Why is that? sincerely, Shin From chad.scherrer at gmail.com Sun Dec 9 18:29:53 2007 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Sun Dec 9 18:25:08 2007 Subject: Strange compilation behavior Message-ID: Hello, I'm using ghc 6.6.1 under Ubuntu Gutsy on a Pentium 4 machine, and I was working to get some code running in an acceptable time. I was surprised to find that turning on profil