Re: problems with ghc-6.8.2-powerpc-apple-darwin.tar.bz2 from GHC home page
Hi Chris, It is my habit to compile the Setup.hs or Setup.lhs to setup with ghc --make Setup.hs -o setup. The ./setup configure ... is working. The ./setup build causes a segmentation fault. This is for every project I try (including ones with very default Setup.hs contents). The Cabal-1.2.3.0 used is supplied by the binary distribution of ghc 6.8.2 I tried the same thing and got the same result. Could it be a problem with how Cabal itself was built instead of GHC? So I sadly say there is still no working ghc 6.8.x for powerpc Leopard. I guess you're right. Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)
Chris Kuklewicz: I have not seen any announcement that GHC 6.8.x is working on OS X Leopard running on PPC. I would be pleased to be corrected. I have Christian Maeder's distribution of 6.8.2 for Tiger (as found on the the GHC download page) running on my PowerBook G4 with Leopard. No deviations from the instructions were necessary. Manuel M T Chakravarty wrote: If general compilation problems still persist, they will prevent you from constructing installer packages as well. (I haven't got a PPC, so I didn't keep track of that.) I'm planning on setting up the GHC source for building when I have time. If this happens, I will try to build the PPC package. Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC build failures on Mac OS X Leopard: ppc x86
Hi, I tried to build GHC stable on my two computers, a PowerBook G4 and a MacBook, both running 10.5.2. This is the first time I've ever tried, so I'm somewhat clueless about a lot of it. I went with the basic instructions (./configure; make) with no 'mk/build.mk' and no configure options other than '--prefix'. On each system, I ran into a different error, though both point to the linker, 'ld'. The PowerBook failure looks similar to ticket #1958 [1]; however, it doesn't appear to be building parsec at that point. I gather that it's building stage1 due to the -o stage1/ghc-6.8.2.20080213. The MacBook build apparently completed stage1 and failed in trying to build stage2 (i.e. -o stage2/ghc-inplace). I have included snippets below from the output of each build. I thought it might be useful to share and see if these are already known problems with/without workarounds. Also, I'm willing to help debug/test if there's anything specific you want me to try. Otherwise, I'll probably fiddle with the 'mk/build.mk' (as discussed in [1] and [2]) and/or changing which linker is used. Additionally, I have a somewhat unrelated question. What's the different between ghc-stable [3] and ghc-6.8 [4]? Thanks, Sean [1] http://hackage.haskell.org/trac/ghc/ticket/1958 [2] http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking [3] http://darcs.haskell.org/ghc-stable/ [4] http://darcs.haskell.org/ghc-6.8/ PPC build output /usr/local/ghc-6.8.2-ppc-tiger/bin/ghc -o stage1/ghc-6.8.2.20080213 -H16m -O -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include cutils.h' -DUSING_COMPAT -i../compat -ignore-package Cabal -package directory -package pretty -package containers-L../compat -lghccompat -no-link-chkstage1/basicTypes/BasicTypes.o stage1/basicTypes/DataCon.o snip collect2: ld terminated with signal 10 [Bus error] ghc: 28298448 bytes, 7 GCs, 507904/774144 avg/max bytes residency (2 samples), 16M in use, 0.01 INIT (0.00 elapsed), 0.12 MUT (19.61 elapsed), 0.06 GC (0.15 elapsed) :ghc make[1]: *** [stage1/ghc-6.8.2.20080213] Error 1 make: *** [stage1] Error 1 x86 build output ../compiler/stage1/ghc-inplace -no-user-package-conf -cpp stage2/ghc-inplace.c -o stage2/ghc-inplace ld: in /Users/leather/Projects/ghc-stable/ghc/libraries/haskell98/dist/build/libHShaskell98-1.0.1.0.a, archive has no table of contents collect2: ld returned 1 exit status make[2]: *** [stage2/ghc-inplace] Error 1 make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC build failures on Mac OS X Leopard: ppc x86
Hi, Manuel M T Chakravarty: I can't help you with the PPC, but on the MacBook try building with make EXTRA_AR_ARGS=-s It's a known bug with Cabal. Thanks, Manuel, it builds now. Afterwards, I ran 'make' in 'testsuite/tests/ghc-regress' and got this: OVERALL SUMMARY for test run started at Mon Feb 18 17:55:20 CET 2008 2084 total tests, which gave rise to 10640 test cases, of which 0 caused framework failures 2160 were skipped 7487 expected passes 372 expected failures 0 unexpected passes 621 unexpected failures That seems like a large number of unexpected failures; however, I haven't seen a summary from a build of Mac OS X on x86, so I don't know what to expect. At a glance, many of the failures refer to ghci (at least that's what I assume the (ghci) next to the name means). Here is a sample: = user001(ghci) cd ../../../libraries/unix/tests '/Users/leather/Projects/ghc-stable/ghc/compiler/stage1/ghc-inplace' -no-recomp -dcore-lint -dcmm-lint -Di386_apple_darwin user001.hs --interactive -v0 -ignore-dot-ghci -package unix user001.genscript 1user001.interp.stdout 2user001.interp.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stderr: *** unexpected failure for user001(ghci) Is this reasonable? In other words, is something broken? Another thing I need to tweak, perhaps? Thanks, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
Norman Ramsey wrote: At the time of the wonderful GHC Hackathon in Portland, where the GHC API was first introduced to the public, I urged Simon PJ to consider taking ghc --make and generalising it to support other languages. I still think this would be a good project. As well as supporting any mix of languages (and platforms, since it's often difficult to separate the two). I would love to see such a tool! As flexible as make if necessary, but as easy as doing nothing if possible. Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
How to disable warning for export item 'module ...' exports nothing?
Hi, I have a module A that re-exports module B, and module B contains only class instances. Since I'm using -Wall, I get this warning about module B exporting nothing. Is there a way to disable this particular warning, since it is unnecessary in this case? No mailing list messages or GHC documentation has told me what to do. Thanks, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to disable warning for export item 'module ...' exports nothing?
I have a module A that re-exports module B, and module B contains only class instances. Since I'm using -Wall, I get this warning about module B exporting nothing. Is there a way to disable this particular warning, since it is unnecessary in this case? No mailing list messages or GHC documentation has told me what to do. Well, the warning is right that you don't need to re-export module B: instances are implicitly exported. So you could just remove the export of module B, unless there's a reason to export it (such as, you might add some exported functions or data types to it later) Ah, got it. Thanks. I didn't realize instances of an imported module were also implicitly exported. I should have looked at the report, however. For the future reference of others: Instance declarations cannot be explicitly named on import or export lists. All instances in scope within a module are *always *exported and any import brings *all* instances in from the imported module. Thus, an instance declaration is in scope if and only if a chain of import declarations leads to the module containing the instance declaration. -- 5.4 Importing and Exporting Instance Declarations at http://www.haskell.org/onlinereport/modules.html It would definitely be nice to have a bit more control over importing/exporting instances. I noticed this idea has been discussed a few times already. Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to disable warning for export item 'module ...' exports nothing?
I have a module A that re-exports module B, and module B contains only class instances. Since I'm using -Wall, I get this warning about module B exporting nothing. Is there a way to disable this particular warning, since it is unnecessary in this case? No mailing list messages or GHC documentation has told me what to do. Well, the warning is right that you don't need to re-export module B: instances are implicitly exported. So you could just remove the export of module B, unless there's a reason to export it (such as, you might add some exported functions or data types to it later) Hmm, the disappointing result of removing module B from the export list is that now it doesn't show up in the Haddock-generated documentation for module A. Not that there was anything specific in B to document, because it's only instances. But I do want the user to know that importing A also imports B. Sigh... I suppose there's CPP if I really want it. Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haddocking exported instances [was Re: How to disable warning for export item 'module ...' exports nothing?]
Isaac Dupree wrote: Sean Leather wrote: I have a module A that re-exports module B, and module B contains only class instances. Since I'm using -Wall, I get this warning about module B exporting nothing. Is there a way to disable this particular warning, since it is unnecessary in this case? No mailing list messages or GHC documentation has told me what to do. Well, the warning is right that you don't need to re-export module B: instances are implicitly exported. So you could just remove the export of module B, unless there's a reason to export it (such as, you might add some exported functions or data types to it later) Hmm, the disappointing result of removing module B from the export list is that now it doesn't show up in the Haddock-generated documentation for module A. Not that there was anything specific in B to document, because it's only instances. But I do want the user to know that importing A also imports B. Sigh... I suppose there's CPP if I really want it. So, I tried to do the above with CPP, and I can't get Haddock to recognize that it should list this. Here's what it looks like: module A ( module Z, #ifdef __HADDOCK__ module B #endif ) where ... I added extensions: CPP to the .cabal file as I saw instructed in some Cabal thread from long ago. Building works such that I don't get the warning, but cabal haddock just acts as if it doesn't recognize __HADDOCK__. Assuming I'm not doing anything wrong, this might be a Cabal problem. You could put a link to the module in the intro-documentation that comes before the export list, possibly in a sentence saying e.g. deliberately exports instances from @module B@ (except I've forgotten Haddock syntax and might have used it wrong there :-) Yep, that is an option. I noticed it in the documentation for another package, the name of which escapes me right now. It's an interesting use-case though. I wonder if Haddock should automatically provide links to all instances exported from the module that are either (1) instances for datatypes or classes exported by the module, or (2) orphan (i.e. not defined in the same module as either the class or the datatype). (It would be too tedious to list *all* exported instances, but luckily it's not necessary for completeness.) Yeah, I think instances should be documented in general. But, I agree with Ross in the previous thread, that's a different story. Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to disable warning for export item 'module ...' exports nothing?
Ross Paterson wrote: On Thu, Aug 14, 2008 at 08:00:25PM +0200, Sean Leather wrote: Well, the warning is right that you don't need to re-export module B: instances are implicitly exported. So you could just remove the export of module B, unless there's a reason to export it (such as, you might add some exported functions or data types to it later) Hmm, the disappointing result of removing module B from the export list is that now it doesn't show up in the Haddock-generated documentation for module A. Not that there was anything specific in B to document, because it's only instances. But I do want the user to know that importing A also imports B. Sigh... I suppose there's CPP if I really want it. That shouldn't be necessary. Because instances are implicitly exported and imported, you'll really want to avoid orphan instances, so that the user can be sure that if both the class and the data type are in scope, so is the instance. But then the instance will be listed under both the class and the type in the Haddock documentation. It won't matter where the instance was defined, just as it doesn't matter where other stuff is defined, just where it is in scope. In my case, it does matter where instances are in scope. My library requires orphan instances by design. If the programmer imports the top-level module, then s/he gets a default set of instances. But the programmer has the option to import select modules and get a different set of classes and instances. My goal was to put the default set of instances into a separate module and re-export that from a higher-level module. That way, it is more clearly documented where things are located. Unfortunately Haddock does not allow doc comments to be attached to instances, but that's independent of whether the defining module is shown. Agreed. I am getting the impression that it would be nice if there were a lot of things that were more explicit about instances, both in Haskell and in Haddock. Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to disable warning for export item 'module ...' exports nothing?
Ross Paterson wrote: On Fri, Aug 15, 2008 at 02:21:33PM +0200, Sean Leather wrote: In my case, it does matter where instances are in scope. My library requires orphan instances by design. If the programmer imports the top-level module, then s/he gets a default set of instances. But the programmer has the option to import select modules and get a different set of classes and instances. With implicit import, it just doesn't work to have different instances in different places. Suppose two modules use your library in the different ways you envisage. Then those modules cannot be used together in the same program. Your library will not be re-usable. It is not true that those modules cannot be used in the same program. It is possibly true that they cannot both be imported by another module. (It depends on how the instances are used.) The issue is not that the library is not re-usable. It's simply a trade-off. One use of the library (the default) allows for simplicity. The second use allows for extensibility and specialization. The latter requires more work, but it is possible. Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to disable warning for export item 'module ...' exports nothing?
Ross Paterson wrote: On Fri, Aug 15, 2008 at 03:09:16PM +0200, Sean Leather wrote: Ross Paterson wrote: With implicit import, it just doesn't work to have different instances in different places. Suppose two modules use your library in the different ways you envisage. Then those modules cannot be used together in the same program. Your library will not be re-usable. It is not true that those modules cannot be used in the same program. It is possibly true that they cannot both be imported by another module. (It depends on how the instances are used.) If they're in the same program, there will be chains of imports from Main to each of them, so Main will implicitly import conflicting instances and will be rejected by the compiler. module A where class A t where a :: t module B where import A instance A Int where a = 0 a0 :: Int a0 = a module C where import A instance A Int where a = 1 a1 :: Int a1 = a module Main where import A import B import C main = do putStrLn $ a0= ++ show a0 putStrLn $ a1= ++ show a1 This works, because of the way the instances are used. While overlapping instances are imported into Main, they are not used in Main. Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Overlapping instances vs. Haskell98 Report [was: How to disable warning for export item 'module ...' exports nothing?]
Ross Paterson wrote: On Fri, Aug 15, 2008 at 04:17:44PM +0200, Sean Leather wrote: module A where class A t where a :: t module B where import A instance A Int where a = 0 a0 :: Int a0 = a module C where import A instance A Int where a = 1 a1 :: Int a1 = a module Main where import A import B import C main = do putStrLn $ a0= ++ show a0 putStrLn $ a1= ++ show a1 This works, because of the way the instances are used. While overlapping instances are imported into Main, they are not used in Main. Then that is a GHC bug. Haskell 98 Report 4.3.2: A type may not be declared as an instance of a particular class more than once in the program. That's interesting. So, maybe there should be some language extension or warning (with associated -fno-warn) for this in GHC. Personally, I prefer the way it's done now. (I guess that's obvious, considering I'm developing a library that will take advantage of it. ;) ) But it makes sense that instances are only looked up when needed, instead of globally tracked. Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Core questions
Hi Matthijs,
This is a shameless plug for EMGM, a library for generic programming that
we've been working on at Utrecht.
| However, there are two issues bothering me still. The first is that the
| Core types (in particular CoreExpr) are not instances of Show. They are
| instances of Outputable, which allows them to be pretty printed.
| However, this pretty printing is good to view the structure of the
| expression that the CoreExpr represents, but doesn't show the structure
| of the CoreExpr itself. For example, tuple construction is printed
| simply as (a, b), while the actual core expression is a nested
| application of two types, and a and b to the GHC.Tuple.(,) function
| (or datacon?). Also, the exact constructors used are not quite clear,
There's absolutely no reason why
CoreExpr
CoreBind
Type
should not be an instance of Show. It'd take you 10 mins to make it so,
with the aid of 'standalone deriving' (described in the GHC user manual).
There *is* a reason why TyCon and Class are not:
a TyCon
enumerates its DataCons
whose type mentions the TyCon
In short, the data structures are, by design, cyclic. Printing one of
these would take a long time.
But I bet you could get a long way with the three above, plus just printing
the *name* of a TyCon or Class or Id. Something like:
instance Show TyCon where
show tc = showSDoc (ppr tc)
Suppose you want to print a type with the exception of one constructor,
because it is mutually recursive with another or just prints out lots of
useless information. There are at least two ways to do it, one with EMGM,
and one with standalone deriving. I show both below.
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE OverlappingInstances #-}
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE StandaloneDeriving #-}
module Example where
import qualified Generics.EMGM as G
-
data A = A0 Int | A1 B
data B = B0 Char | B1 A
$(G.derive ''A)
$(G.derive ''B)
instance G.Rep G.Show B where
rep = G.Show (\_ _ - f)
where
f (B0 c) = showString (B0 . showChar c . showString )
f (B1 _) = showString (B1 some A)
valAB = A1 (B1 (A0 37))
showAB = G.show valAB
-
data C = C0 Int | C1 D
data D = D0 Char | D1 C
deriving instance Show C
instance Show D where
showsPrec _ = f
where
f (D0 c) = showString (D0 . showChar c . showString )
f (D1 _) = showString (D1 some C)
valCD = C1 (D1 (C0 37))
showCD = show valCD
-
The first one uses EMGM's Template Haskell-based derive function to generate
the type representation. I then give an overriding instance for the generic
Show function (where G.Show is a newtype used for all show/shows/showsPrec
generic functions). So, the constructor B1 will not print out the value of
its A-type argument.
The second uses standalone deriving and a handwritten instance for D that
does the same thing as the first solution did for B.
What's the difference? Well, between these instances of G.Show and Show,
there's not much. However, the EMGM approach gives you access to a lot of
other generic functions including Read, Crush, Collect, etc. See the
documentation for all of them [1].
One function you may be able to take advantage of is 'collect', perhaps to
collect the B values in valAB.
*Example G.show (G.collect valAB :: [B])
[(B1 some A)]
Moral of the story: you can do it either way, but EMGM gives you a lot
extra.
Apologies for the self-promotion, but we're looking for people who might
want to use EMGM. ;) If you have feedback, let us know! [2]
Regards,
Sean
[1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/emgm
[2] http://www.cs.uu.nl/wiki/GenericProgramming/EMGM
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Malformed class assertion with GHCi's output (a - a ~ T a)
I queried (:t) the type of something in GHCi, and it told me the value should have the constraint (a - a ~ T a) among others. When I tried to use this in code, I got a malformed class assertion. So, I put parentheses around the function type, ((a - a) ~ T a), and everybody is happy again. Is there something off about the precedence of (~) vs. (-)? Should GHCi print the parentheses? I'm using GHC 6.10.1, so this might already be fixed. Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Template-haskell] The template-hask...@haskell.org mailing list
On Tue, Oct 20, 2009 at 16:37, Simon Peyton-Jones wrote: Question: is the template-hask...@haskell.org mailing list still useful? My gut reaction: probably not. * It has 250 subscribers compared to 850 for ghc-users. * It has low traffic * template-haskell is the only GHC-specific mailing list associated with a particular language feature. Eg type functions, ghci, etc do not have their own list * The traffic on ghc-users is not dauntingly high. Also telling is the fact that so many threads are begun and left to rot (i.e. questions remain unanswered). My impression is that very few people actually pay attention to the template-haskell list. I suggest we abolish it in favour of ghc-users. Any dissenters? (I'd emit a warning, so that people could check they are subscribed to ghc-users.) Not here. Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Trac says database is locked
On Thu, Nov 19, 2009 at 16:58, Sean Leather wrote: I tried to submit a comment on #2530 and got this error. Well, it works now, 1.5 hours later. Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
:set -fbreak-on-exception in GHCi causes exception in readFile
Perhaps I don't quite get how this works, but when I :set -fbreak-on-exception in GHCi, I get an exception using readFile. It reads the entire file and then throws what appears to be an EOF exception. Prelude readFile blah.txt blah\nblah\nblah\nStopped at exception thrown _exception :: e = GHC.Exception.SomeException (GHC.Exception.:DException _ (GHC.Show.:DShow ...) ) (GHC.IOBase.IOError Nothing GHC.IOBase.EOF ) When I :set -fno-break-on-exception, I see no exception. I thought that lazy IO reads until it reaches the EOF, then closes the file. This happens with both 6.10.1 and 6.8.3, so perhaps this is standard stuff, and I'm missing something. Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: :set -fbreak-on-exception in GHCi causes exception in readFile
On Fri, Nov 20, 2009 at 18:31, Jose Iborra wrote: This is by design, -fbreak-on-exception breaks on any exception, be it captured or not, even on library code. Ah, that's what I missed. I would've guessed that it only breaks on uncaught exceptions. I am not sure how readFile is implemented internally, but it probably reads from the file until an eoferror is thrown and then captures it gracefully. That's what I expect, too. I went fishing, but didn't find the exact spot where that happens within a few minutes. There is another debugger flag, -fbreak-on-error, which only breaks on unhandled exceptions. Is this what you want ? Probably. Now I see the difference in [1]. Thanks! [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#interactive-mode-options Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: :set -fbreak-on-exception in GHCi causes exception in readFile
heh, the well known problem, i've seen it in Delphi. it even has a large list of exceptions to be ignored, but i think that better way will be to set this on a per-package and per-module basis Yes, that might be a better idea. In general though, it sounds as if -fbreak-on-error will be useful more often than -fbreak-on-exception. I was not aware of the former, and I had the latter in my .ghci. I think I'll remove it from there and just use the OPTIONS pragma when needed. Perhaps I don't quite get how this works, but when I :set -fbreak-on-exception in GHCi, I get an exception using readFile. It reads the entire file and then throws what appears to be an EOF exception. Prelude readFile blah.txt blah\nblah\nblah\nStopped at exception thrown _exception :: e = GHC.Exception.SomeException (GHC.Exception.:DException _ (GHC.Show.:DShow ...) ) (GHC.IOBase.IOError Nothing GHC.IOBase.EOF ) When I :set -fno-break-on-exception, I see no exception. I thought that lazy IO reads until it reaches the EOF, then closes the file. This happens with both 6.10.1 and 6.8.3, so perhaps this is standard stuff, and I'm missing something. Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Can't infer type (type family + element type)
Suppose I have a class C, class C a where type E a c :: E a - a - a a datatype T, data T a = T a and an instance of C for T instance C (T a) where type E (T a) = a c x (T _) = T x I would like to write a function such as f f t@(T x) = c x t without a type signature. Unfortunately, I can't because GHC tells me Couldn't match expected type `t' against inferred type `T (E t)' In the second argument of `c', namely `t' In the expression: c x t In the definition of `f': f (t@(T x)) = c x t There are at least three possible ways to write the above code such that it works. (1) Give a type signature for f f :: T a - T a (2) Define the class C using an equality constraint class C t where type E t c :: (E t ~ e) = e - t - t (3) Define the class C using functional dependencies class C t e | t - e where c :: e - t - t But the real question is why don't I get a type for f? This has been tested in GHC 6.10.1 and 6.12.1. Thanks, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't infer type (type family + element type)
Done: http://hackage.haskell.org/trac/ghc/ticket/3826 Regards, Sean On Tue, Jan 19, 2010 at 11:15, Simon Peyton-Jones simo...@microsoft.comwrote: Looks like a bug to me! I am currently elbows-deep in re-engineering GHC's entire constraint generation and solving mechanism, which will, I hope, simply solve your problem. But meanwhile can I ask a favour: submit a Trac report with the offending code in reproducible form? Then I'll be sure to test the new code against all such tickets. Thanks Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto: glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Sean Leather | Sent: 18 January 2010 16:59 | To: GHC Users List | Subject: Can't infer type (type family + element type) | | Suppose I have a class C, | | class C a where |type E a |c :: E a - a - a | | a datatype T, | | data T a = T a | | and an instance of C for T | | instance C (T a) where |type E (T a) = a |c x (T _) = T x | | I would like to write a function such as f | | f t@(T x) = c x t | | without a type signature. Unfortunately, I can't because GHC tells me | | Couldn't match expected type `t' against inferred type `T (E t)' | In the second argument of `c', namely `t' | In the expression: c x t | In the definition of `f': f (t@(T x)) = c x t | | There are at least three possible ways to write the above code such | that it works. | | (1) Give a type signature for f | | f :: T a - T a | | (2) Define the class C using an equality constraint | | class C t where |type E t |c :: (E t ~ e) = e - t - t | | (3) Define the class C using functional dependencies | | class C t e | t - e where |c :: e - t - t | | But the real question is why don't I get a type for f? | | This has been tested in GHC 6.10.1 and 6.12.1. | | Thanks, | Sean | ___ | 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
Re: Scriptable error messages
So we are now looking into the possibility of adding your own error messages to GHC as our project. We have about 8 weeks to implement, either all or some proof of concept. As such we are looking for comments, ideas and suggestions. Is this doable in GHC?, or what is needed. For related work, see the publications of Bastiaan Heeren, esp. his PhD thesis. Search the following page for error: http://people.cs.uu.nl/bastiaan/ Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Advice on Multiple GHC installations
I would like to have several versions of ghc installed simultaneously, on the handful of Ubuntu systems I work on. In the past, I have had just a single version of ghc installed on each system, usually the most recent stable generic Linux binary installation. I just recently announced multi-ghc to solve this problem (for me at least). http://github.com/spl/multi-ghc Three questions: 1. Does there exist an `experimental' apt repository for Ubuntu anywhere which packages versions of ghc more recent than 6.8? I don't know, but multi-ghc doesn't depend on (or use) any package manager. It's currently made up of a Bash script, a Makefile, and some directory naming conventions. This is both good (since it can be run on any system that has bash and make) and bad (since it means you have to configure your system to support building or using GHC yourself). 2. If I cannot install multiple ghc versions from a different apt repository, does anyone have advice for how to work with multiple simultaneous installations? A how-to guide or anything like that? multi-ghc has a README and the script has usage information. 3. Does having multiple installations break cabal at all? I'd like to be able to use ghc 6.12.* by default, but be able to selectively choose an older toolchain for compatibility purposes, bug hunting, etc. One of the main goals of multi-ghc was to allow for a different cabal-install configuration for each GHC. It uses symbolic links to switch between versions. If you're running Linux on x86, then you should be able to use many of the binary tarballs available at http://www.haskell.org/ghc/dist/ . I can't promise all of them work, because I haven't tested them all. If you try out multi-ghc, please let me know how it goes. I deem its current state good enough to let other people use, but I'm sure it can improve. I'm happy to take feedback and/or patches. Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Advice on Multiple GHC installations
Why not just use symbolic links? I too have multiple installations of ghc (at the moment, only two), and I choose between them using a symbolic link: book % ls -l /usr/local | grep ghc lrwxr-xr-x 1 root wheel10 Jan 12 00:05 ghc - ghc-6.12.1 drwxr-xr-x 7 dave wheel 238 Dec 25 10:46 ghc-6.10.4 drwxr-xr-x 7 dave wheel 238 Jan 8 21:52 ghc-6.12.1 (/usr/local/ghc/bin is on my PATH.) My install scripts use the --prefix flag. This sounds very similar to what I do with multi-ghc. I just use a Bash script to manage the symlinks for me and a Makefile to do the configure/make install. That's really all multi-ghc is at the moment. I also make the actual installations user-writeable, so that I DON'T have to use sudo at any point after setting up the directories. This gives me a nice proof that no script I then call is messing up other parts of my system. (One can still accidentally still do something locally, creating an unannounced subdirectory of $HOME e.g. using cabal-install.) To sudo or not to sudo: doesn't matter to me (or multi-ghc). :) GHC is way too important to be treated that way, so I follow (roughly) Nils' strategy. The use of stow also seems similar, though perhaps more general. I currently keep track of the current GHC, and it seems stow may not do that, though I doubt it should be difficult to extend. Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: three dots of :browse
If I use :browse a module with GHC 6.12, it sometimes displays
garbage. Here is an example:
Prelude :browse Data.IP
data AddrRange a
= iproute-0.2.0:Data.IP.Range.AddrRange {addr :: a,
mask :: a,
mlen :: Int}
(snip)
data AddrRange a
= iproute-0.2.0:Data.IP.Range.AddrRange {..., mask :: a, ...}
data AddrRange a
= iproute-0.2.0:Data.IP.Range.AddrRange {..., mlen :: Int}
... is the garbage. Due to this, I cannot parse the output of
:browse. This is not displayed with GHC 6.10.
Q1) What is the intention of ...?
I believe it's related to the module export list.
module Test (y) where
data R = R { x :: Char, y :: Int, z :: Float }
*Test :browse
data Test.R = Test.R {..., y :: Int, ...}
Q2) How to prevent it so that I can obtain output which I can parse?
Export all the labels, perhaps?
Regards,
Sean
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Deriviable type classes
2011/2/9 Simon Peyton-Jones: Friends Just a heads-up. Pedro is working on implementing Generic Defaults, as described in his Haskell Symposium 2010 paper www.dreixel.net/research/pdf/gdmh_nocolor.pdf It will replace (and improve on) the Derivable type classes stuff in GHC at the moment, which was originally presented in a paper of that title that Ralf and I wrote in the 2000 Haskell workshop http://research.microsoft.com/en-us/um/people/simonpj/papers/derive.htm. The Derivable type class extension is barely used, I believe, and isn't even documented in the manual. So I propose to switch from one to the other, rather than to try to support both. This change will happen in GHC 7.2 or 7.4, depending on when Pedro is done. Please yell if you are a secret user of derivable type classes, so this change would discombobulate you. The only time I came across a use of it was in James Cheney's FreshLib [1]. I don't know if the latest version still uses it, though. There was also this bug [2] that prevented FreshLib from being compiled, but that is apparently fixed now. [1] http://homepages.inf.ed.ac.uk/jcheney/programs/freshlib/ [2] http://hackage.haskell.org/trac/ghc/ticket/2824 Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-7.2.1 was: Re: ANNOUNCE: GHC 7.0.2 Release Candidate 2
On Tue, Mar 1, 2011 at 11:09, Christian Maeder wrote: Why are you talking about a 7.2.1 release [...]? What important achievement (apart from the tickets listed) should I expect from a 7.2.1 release compared to 7.0.2 (or 7.0.3)? http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/19604 Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to install GhC on a Mac without registering?
On Mon, Jun 6, 2011 at 16:47, Malcolm Wallace wrote: The ghc team already bundle a copy of gcc in their Windows distribution, precisely because it can be fiddly to get a working copy of gcc for that platform otherwise. I wonder if they would consider the possibility of shipping gcc on Mac too? (There may be good reasons not to do that, but let's have the discussion.) I would be in favor of this -- assuming it didn't create new problems -- especially if it meant the latest GHC installer could be used on older versions of Mac OS X. The Windows installer still works for Windows 2000, but the Mac installer requires the Snow Leopard. Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to install GhC on a Mac without registering?
On Fri, Jun 10, 2011 at 03:15, Manuel M T Chakravarty wrote: Ian Lynagh: On Mon, Jun 06, 2011 at 03:47:57PM +0100, Malcolm Wallace wrote: On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote: I would be fantastic if XCode wasn't a dependency. ... Not to detract at all from the work of the wonderful GHC and Haskell Platform contributors in any way. For me it would just make it that much easier to convince mac-using friends to give Haskell a try. The ghc team already bundle a copy of gcc in their Windows distribution, precisely because it can be fiddly to get a working copy of gcc for that platform otherwise. I wonder if they would consider the possibility of shipping gcc on Mac too? (There may be good reasons not to do that, but let's have the discussion.) I'm pretty sure we aren't allowed to redistribute XCode. As well as gcc and friends, I think XCode also includes various headers and/or libraries that we need. If there is an alternative - especially one that allows us to support multiple versions of OS X more easily - then using it may make sense. You are right, the Xcode install includes many tools as well as headers etc. What would be the advantage of including gcc and all these other things in GHC? To simplify the process of installing GHC and to support people with versions of Mac OS X older than the most current. We want to spread the Haskell love as far as possible. Anybody who is halfway serious about developing software on a Mac will have Xcode installed anyway. You could say the same about people halfway serious about developing software on Windows. But GHC doesn't require you to install MinGW, Cygwin, or Virtual Studio. Besides, as Xcode updates are now available from the Mac App Store, Not for older versions of Mac OS X. you don't even need to register as a developer with Apple anymore — yes, you need to pay the nominal $5 for the 4GB download. If you don't want to do that, install the (probably older) version of Xcode that came with the install DVDs of your Mac. This doesn't solve the problem if the GHC package only supports later versions of Xcode. There has already been at least one difference between Xcode 3 and 4 ( http://hackage.haskell.org/trac/ghc/ticket/5011 ) that caused a problem and there may be others in the future. I don't think you can compare this with the situation on Windows. Microsoft does not distribute a canonical set of Unix tools that all developers use. No, but Cygwin and MinGW are available for free and have been around for a long time. Why does GHC bundle MinGW instead of expecting the user to install it herself? Convenience? I think there is a clear benefit to supporting older versions of Mac OS X. Not everybody upgrades at the same rate that Apple releases new versions. Indeed, Apple's updates occasionally change architecture requirements or break applications, so some people cannot upgrade. Having a new package bundling GNU tools/libraries doesn't preclude the current package using Xcode. The only good arguments against a new package, that I can see, are the additional work to develop the packaging and the testing, release, and maintenance efforts. Perhaps there are some compatibility concerns, working with other OS X libraries/applications. Of course, these are not at all insignificant issues, but these are the main concerns. Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Evaluating type expressions in GHCi
I would like to ask GHCi for the type that a type expression will evaluate to, once all definitions of type synonyms and (when possible) type families have been inlined. It appears that I can do some part of this for type T by using :t undefined :: T: type family F a type instance F Int = Bool type instance F Bool = Int type instance F (a, b) = (F a, F b) ghci :t undefined :: F (Int, Bool) undefined :: F (Int, Bool) :: (Bool, Int) I also get what I expect here: ghci :t undefined :: F (a, Bool) undefined :: F (a, Bool) :: (F a, Int) Of course, this doesn't work on types of kinds other than *. Is it possible and worth having another GHCi command to perform this operation for any types? It could be the type analogue to :t such that it evaluates the type and gives its kind. Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Evaluating type expressions in GHCi
On Wed, Sep 21, 2011 at 04:00, Brent Yorgey wrote: On Tue, Sep 20, 2011 at 04:29:21PM -0700, J. Garrett Morris wrote: On Tue, Sep 20, 2011 at 3:44 PM, Simon Peyton-Jones wrote: What should the GHCi command be *called*? :simplify or :simplifytype. In GHCi at the moment, you could abbreviate that as short as :si. IMO Simon's suggestion of something like :normalizetype or :normalize or :normtype would be even better -- you could abbreviate it as just :n . It is also more accurate; the correct term for what the command should do is in fact normalize, and it may not in fact end up making the type any simpler. I like :normalize (without type since we don't need to distinguish it from term normalization), and the shorthand :n is perfect. And if you prefer :normalise, the location-agnostic :normtype, or other colors that start with :n, I don't mind, because I'll almost never type the whole thing. ;) Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Evaluating type expressions in GHCi
Hi Simon, *TF :kind F Int F Int :: * *TF :kind! F Int F Int :: * = Bool Does this also work with plain ol' type synonyms? I just noticed that the :t undefined :: T trick doesn't seem to work with type synonyms. Thanks, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Building GHC for Mac OS X 10.5
After many years, I have once again attempted to build GHC from source. The
experience went much easier than in the past.
This time, my system is running the now-old 10.5 (Leopard) using Xcode
3.1.4. I'm probably the only one who wants to build on 10.5, but I still
appreciate the fact that GHC can be built on a variety of systems, allowing
more people (like me) to hack on it.
I ran into a few minor issues when building.
(1) I had a problem with gmp. No surprise, and I didn't want to fight it, so
I built with integer-simple by adding INTEGER_LIBRARY=integer-simple to
./mk/build.mk .
(2) It appears that integer-simple has a copy-paste bug that was easy to
fix:
$ cd libraries/integer-simple/
$ git diff
diff --git a/GHC/Integer/Type.hs b/GHC/Integer/Type.hs
index 02eeef2..f620e67 100644
--- a/GHC/Integer/Type.hs
+++ b/GHC/Integer/Type.hs
@@ -97,8 +97,8 @@ integerToInt i = word2Int# (integerToWord i)
integerToWord64 :: Integer - Word64#
integerToWord64 i = int64ToWord64# (integerToInt64 i)
-{-# NOINLINE word64ToInteger:: #-}
-word64ToInteger:: Word64# - Integer
+{-# NOINLINE word64ToInteger #-}
+word64ToInteger :: Word64# - Integer
word64ToInteger w = if w `eqWord64#` wordToWord64# 0##
then Naught
else Positive (word64ToPositive w)
(3) A linker flag was added for Xcode 4 that is not available in 3.1.
$ git diff
diff --git a/compiler/main/DriverPipeline.hs
b/compiler/main/DriverPipeline.hs
index b655425..ec8024d 100644
--- a/compiler/main/DriverPipeline.hs
+++ b/compiler/main/DriverPipeline.hs
@@ -1682,10 +1682,12 @@ linkBinary dflags o_files dep_packages = do
-- like
-- ld: warning: could not create compact unwind
for .LFB3: non-standard register 5
-- on x86.
+{-
++ (if platformOS (targetPlatform dflags) ==
OSDarwin
platformArch (targetPlatform dflags) `elem`
[ArchX86, ArchX86_64]
then [-Wl,-no_compact_unwind]
else [])
+-}
-- '-Wl,-read_only_relocs,suppress'
-- ld gives loads of warnings like:
I think the fix to integer-simple should be applied, since it's an obvious
improvement.
I suspect the last issue might be controversial, since it seems to involve
an apparently incompatible difference between the older and newer Xcode
versions. Of course, I would like to see the older version still supported,
but, as I said, I may be among a very small minority in this vote.
Regards,
Sean
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
:kind broken in HEAD
It seems like :kind is broken in the HEAD ghci: *Main :kind Maybe Top level: Expecting an ordinary type, but found a type of kind * - * In a type expected by the context: Maybe *Main Simon, could this be related to your change for :kind! ? Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Should GHC default to -O1 ?
On Tue, Nov 8, 2011 at 15:31, Daniel Fischer wrote: Often this is because they compiled their programme without optimisations, simply recompiling with -O or -O2 yields a decently performing programme. So I wonder, should ghc compile with -O1 by default? What would be the downsides? Previous discussion on this topic: http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/18540 Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
On Thu, Dec 22, 2011 at 16:19, Brandon Allbery wrote: On Thu, Dec 22, 2011 at 05:44, Conor McBride wrote: under Leopard, and got this far bash-3.2$ sudo ./configure Password: checking for path to top of build tree... dyld: unknown required load command 0x8022 configure: error: cannot determine current directory Same thing here. I think it can be misleading to call the release i386-apple-darwin. Perhaps a more specific name is in order? I'd expect that on Leopard. Unless someone does a Leopard-specific build, I suspect you're out of luck. I don't really know what this means. I'm kind of expecting that I have Apple adds new stuff to its dynamic loader in every OS release, and the result usually isn't compatible with earlier releases by default, in my experience (that'd be from Tiger through Lion at this point). You need to specify an ABI compatibility level to build stuff that will run on older releases, including just being understood by dyld. Part of the problem here is that a default Xcode 4.x install only includes the 10.6 and 10.7 SDKs. I'm not seeing any way to customize the install, so it looks like Xcode 4 cannot be used to build for Leopard; someone will have to do the Leopard-compatible build on Leopard or on Snow Leopard with Xcode 3.6. I've built it from source (ghc-7.4.0.20111219-src.tar.bz2) on Leopard. I'd be happy to contribute my build if somebody tells me what to do. Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
On Thu, Dec 22, 2011 at 22:25, Conor McBride wrote: On 22 Dec 2011, at 16:08, Sean Leather wrote: I've built it from source (ghc-7.4.0.20111219-src.tar.**bz2) on Leopard. I'd be happy to contribute my build if somebody tells me what to do. I had a crack at this and got quite warm, literally and metaphorically. But, no, I didn't quite get there. And yes, it's some sort of libraries issue. Here's the barf... make -r --no-print-directory -f ghc.mk phase=final all inplace/bin/ghc-stage1 -fPIC -dynamic -H32m -O-package-name integer-gmp-0.4.0.0 -hide-all-packages -i -ilibraries/integer-gmp/. -ilibraries/integer-gmp/dist-**install/build -ilibraries/integer-gmp/dist- **install/build/autogen -Ilibraries/integer-gmp/dist-**install/build -Ilibraries/integer-gmp/dist-**install/build/autogen -Ilibraries/integer-gmp/.-optP-include -optPlibraries/integer-gmp/** dist-install/build/autogen/**cabal_macros.h -package ghc-prim-0.2.0.0 -package-name integer-gmp -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples -XNoImplicitPrelude -XForeignFunctionInterface -XUnliftedFFITypes -O2 -no-user-package-conf -rtsopts -odir libraries/integer-gmp/dist-**install/build -hidir libraries/integer-gmp/dist-**install/build -stubdir libraries/integer-gmp/dist-**install/build -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc libraries/integer-gmp/dist-**install/build/GHC/Integer.dyn_* *o libraries/integer-gmp/dist-**install/build/GHC/Integer/GMP/**Internals.dyn_o libraries/integer-gmp/dist-**install/build/GHC/Integer/GMP/**Prim.dyn_o libraries/integer-gmp/dist-**install/build/GHC/Integer/**Logarithms.dyn_o libraries/integer-gmp/dist-**install/build/GHC/Integer/**Logarithms/Internals.dyn_o libraries/integer-gmp/dist-**install/build/GHC/Integer/**Type.dyn_o libraries/integer-gmp/dist-**install/build/cbits/gmp-**wrappers.dyn_o libraries/integer-gmp/dist-**install/build/cbits/cbits.dyn_**o libraries/integer-gmp/gmp/**objs/*.o -shared -dynamic -dynload deploy -dylib-install-name /usr/local/lib/ghc-7.4.0.**20111219/`basename libraries/integer-gmp/dist-**install/build/libHSinteger-** gmp-0.4.0.0-ghc7.4.0.20111219.**dylib | sed 's/^libHS//;s/[-]ghc.*//'`/`* *basename libraries/integer-gmp/dist-**install/build/libHSinteger-** gmp-0.4.0.0-ghc7.4.0.20111219.**dylib` -no-auto-link-packages -o libraries/integer-gmp/dist-**install/build/libHSinteger-** gmp-0.4.0.0-ghc7.4.0.20111219.**dylib ld: duplicate symbol ___gmpz_abs in libraries/integer-gmp/gmp/**objs/add.o and libraries/integer-gmp/gmp/**objs/abs.o collect2: ld returned 1 exit status make[1]: *** [libraries/integer-gmp/dist-**install/build/libHSinteger-** gmp-0.4.0.0-ghc7.4.0.20111219.**dylib] Error 1 make: *** [all] Error 2 ...which makes me wonder just what I need to delete. I'm not sure, but gmp is often a problem. You can try using my configure arguments. I create a script configure.mine that calls configure with my preferred prefix and gmp library. $ cat configure.mine VERSION=7.4.0.20111219 ./configure \ --prefix=/Library/Frameworks/GHC.framework/Versions/$VERSION/usr \ --with-gmp-libraries=/Library/Frameworks/GMP.framework\ --with-gmp-includes=/Library/Frameworks/GMP.framework/Headers I use the GMP.framework that is installed with the Haskell Platform. The prefix is just a convenient location that allows me to change a symlink to switch between GHC versions. Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Finding the type of a hole
We're currently looking into so-called expression holes in GHC -- like the type goals of Agda -- and we've run into a problem of understanding. We have defined an expression, call it __ for now, for which we want to find the type after a program is type-checked. In tcExpr (TcExpr.lhs), we can see the type that arrives in the argument res_ty, but that does not appear to give the correct (or final?) type after applying zonkTcType. For example, if we have (__, __), then we find that both holes have some type t (as printed). We also see this in a module with declarations such as f = __ and g = __. When these are actually typed, they get unique type variables as expected. So, apparently, we're missing something in trying to find the proper type of a hole. Any suggestions on what we should do or look at? Note that we're currently working from 7.2.2, because we could not previously build HEAD. Thanks, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Mac OS X: compiling for 10.5 under 10.6
On Thu, Jun 7, 2012 at 4:59 PM, Ian Lynagh wrote: On Tue, Jun 05, 2012 at 03:07:09PM +0200, Soenke Hahn wrote: If not, does that mean, ghc-7.4.1 does not support OS X 10.5? As far as I know, if you build GHC 7.4.1 on OS X 10.5 then it will work, but I haven't tried it so I may be wrong. I've built 7.3.20111212 and 7.4.1.20120508 (both are release candidates, I think) from source on 10.5. I haven't built exactly 7.4.1, but I have no reason to believe it wouldn't work. Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC build linking error
Hi wren, On Tue, Jun 5, 2012 at 7:32 AM, wren ng thornton wrote: I'm working on creating some distribution bundles of GHC 7.4.1 and HP 2012.2.0.0 for OSX 10.5 to help rectify the lack of support on older Macs. In building GHC I've run into a linking error in stage1: ld: duplicate symbol ___gmpz_abs in libraries/integer-gmp/gmp/**objs/add.o and libraries/integer-gmp/gmp/**objs/abs.o Which looks like the same issue discussed in: http://www.haskell.org/**pipermail/glasgow-haskell-** users/2011-December/021339.**htmlhttp://www.haskell.org/pipermail/glasgow-haskell-users/2011-December/021339.html The only proposed solution was Sean mentioned explicitly passing the GMP.framework to ./configure via --with-gmp-libraries and --with-gmp-includes; however, I have no such GMP.framework (I'm building from the framework versions of GHC 6.12.1 and HP 2010.1.0.0). So, any ideas on how to fix this? I was hoping somebody else had a bright idea, but no takers, yet. I don't remember where I got my GMP.framework from, exactly. I thought it used to be bundled with the HP. But it's apparently not anymore. I did some digging and came across the old repository for building Mac frameworks: http://hackage.haskell.org/trac/ghc/browser/MacFrameworks?rev=83153fae8bfe23af0bd0bd5a8ea3e2776536a5fe Perhaps you can use the script that's in there to build GMP.framework. Alternatively, I can provide you with mine directly. Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Comments on current TypeHoles implementation
Hi Simon,
Thanks for all your work in getting TypeHoles into HEAD. We really
appreciate it.
I was playing around with HEAD today and wanted to share a few observations.
(1) One of the ideas we had was that a hole `_' would be like `undefined'
but with information about the type and bindings. But in the current
version, there doesn't appear to be that connection. This mainly applies
to ambiguous type variables.
Consider:
f = show _
The hole has type a0.
But with
f = show undefined
there is a type error because a0 is ambiguous.
We were thinking that it would be better to report the ambiguous type
variable first, rather than the hole. In that case, tou can use
-fdefer-type-errors to defer the error. Currently, you don't have that
option. I can see the argument either way, however, and I'm not sure which
is better.
(2) There is a strange case where an error is not reported for a missing
type class instance, even though there is no (apparent) relation between
the missing instance and the hole. (This also relates to the connection
to `undefined', but less directly.)
We have the following declaration:
data T = T Int {- no Show instance -}
With a hole in the field
g = show (T _)
we get a message that the hole has type Int.
With
g = show (T undefined)
we get an error for the missing instance of `Show T'.
(3) In GHCi, I see that the type of the hole now defaults. This is not
necessarily bad, though it's maybe not as useful as it could be.
ghci :t show _
reports that the hole has type ().
(4) In GHCi, sometimes a hole throws an exception, and sometimes it does
not.
ghci show _
throws an exception with the hole warning message
ghci show (T _)
and
ghci _ + 42
cause GHCi to panic.
(5) There are some places where unnecessary parentheses are used when
pretty-printing the code:
ghci :t _ _
interactive:1:1: Warning:
Found hole `_' with type t0 - t
Where: `t0' is a free type variable
`t' is a rigid type variable bound by
the inferred type of it :: t at Top level
In the expression: _
In the expression: _ (_)
interactive:1:3: Warning:
Found hole `_' with type t0
Where: `t0' is a free type variable
In the first argument of `_', namely `_'
In the expression: _ (_)
_ _ :: t
The argument `_' does not need to be printed as `(_)'.
There is also the small matter, in this example, of distinguishing which
`_' is which. The description works, but you have to think about it. I
don't have an immediate and simple solution to this. Perhaps the addition
of unique labels (e.g. _$1 _$2). But this is not a major problem. It can
even wait until some future development/expansion on TypeHoles.
Regards,
Sean
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
TypeHoles: unbound variables as named holes
(I'm again starting a new thread to focus on this issue. It's easier to track that way.) On Thu, Oct 4, 2012 at 11:40 AM, Simon Peyton-Jones wrote: There is also the small matter, in this example, of distinguishing which `_' is which. The description works, but you have to think about it. I don't have an immediate and simple solution to this. Perhaps the addition of unique labels (e.g. _$1 _$2). But this is not a major problem. It can even wait until some future development/expansion on TypeHoles. Just to clarify the small matter above, I was proposing a way to reference unnamed holes in the warning messages. This was only to solve the relatively minor problem of visually distinguishing the holes if there are multiple. I have a proposal. Someone has already suggested on hackage.haskell.org/trac/ghc/ticket/5910 that an un-bound variable behaves like a hole. Thus, if you say ** ** f x = y GHC says “Error: y is not in scope”. But (idea) with -XTypeHoles ** ** f x = y might generate **1. **(renamer) *Warning*: y is not in scope **2. **(type) *Error*: Hole “y” has type So that’s like a named hole, in effect. ** ** If you say f x = 4 GHC warns about the unused binding for x. But if you say f _x = 4 the unused-binding warning is suppressed. So (idea) if you say f x = _y maybe we can suppress warning (1). And, voila, named holes. ** ** Moreover if you add –fdefer-type-errors you can keep going and run the program. ** ** Any comments? This is pretty easy to do. I also like the proposal; however, I think it only makes sense if the set of unbound variables with the same name is treated as referring to the same identifier. This was, after all, the main reason for named holes. Roman expected this, and I think everybody who uses the feature will expect it. On Fri, Oct 5, 2012 at 9:24 AM, Roman Cheplyaka wrote: * Roman Cheplyaka [2012-10-05 10:22:23+0300] * Simon Peyton-Jones [2012-10-05 07:14:36+] | Sounds cool. I would also expect that if you have several occurences of | the same unbound identifier, then it gets a unified type. I thought about this, but I think not. Consider f x1 = _y g x2 = _y Do you want _y and _y to be unified, so that f and g are no longer polymorphic? I think not. Any more than the _ holes we have now are unified. Do you mean polymorphism in their argument? Why would it go away? I would expect the functions to get types `a - c` and `b - c` respectively, and `c` to be reported as the type of the hole. Ah, I see. Since `c` is universally quantified, it means different things for f and g. Good point. I would expect `_y' to be unified. I'm not sure how to write the type of `f' or `g' (maybe `forall a. a - c' and `forall b. b - c'?), but I would still expect `_y' to have some type `c'. It would be endlessly confusing to have identifiers that look the same but aren't. Here's a thought that just occurred to me, though I'm not yet sure if it makes sense. Treat all expression identifiers _x as unique but report them as one hole with all possible types. Then, you can visually identify the patterns between the types. So: f x = _y g x = _y 'a' with some warning like this: Found hole `_y' in multiple locations with the possible types File.hs:##:##: a0 File.hs:##:##: Char - b0 Now, I know by looking at it that `a0' and `b0' are universally quantified per location, but I can do some mental unification myself. Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Promoted types accepted without language extensions
We discovered that GHC and GHCi (7.4.1) accept promoted types without specifying language extensions (and even when specifying -XHaskell98). For example, promoted lists are accepted: Prelude type T = [Int,Char] Prelude :i T type T = (:) * Int ((:) * Char ([] *)) -- Defined at interactive:2:6 Also, promoted datatypes: data N = Z type T = 'Z I'm guessing you can't use these types anywhere (since they are not kind *), so they won't be very useful, but it seems like this should be disallowed. Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
On Thu, Dec 6, 2012 at 1:29 PM, Simon Peyton-Jones wrote: My own understanding is this: A GHC *user* is someone who uses GHC, but doesn't care how it is implemented. A GHC *developer* is someone who wants to work on GHC itself in some way. The current mailing lists: * glasgow-haskell-users: for anything that a GHC *user* cares about * glasgow-haskell-bugs: same, but with a focus on bug reporting * cvs-ghc: for GHC *developers* I don't think we want to confuse users with developers. If we flood users with dev-related conversations they'll get fed up. I don't see a very useful distinction between glasgow-haskell-users and glasgow-haskell-bugs. The distinction was very important before we had a bug tracker, but it doesn't seem useful now. I can see a perhaps-useful distinction between two *developer* lists (A) human email about implementation aspects of GHC (B) machine-generated email from buildbots etc I rather think that (A) could usefully include Trac ticket creation and Git commit messages, since both are really human-generated. I think the last two things (tickets and commit messages) should be separate from a mailing that is intended for (email-only) discussion. The content may be human-generated, but: (1) The number of messages is overwhelming. Alternatively stated, if you consider each ticket or commit message a different thread (which many email clients do), the number of different threads is large. (2) The commit messages do not all lead to conversations, and most of the discussion on tickets takes place on Trac with every message duplicated to the list. Consequently, any email-only discussion threads on the mailing list can easily get lost among all the other threads. So that would leave only buildbot logs on (B). So I would be content to * Abolish glasgow-haskell-bugs in favour of glasgow-haskell-users * Split out cvs-ghc into two in some way; details to be agreed. But for me the issue is not a pressing one. I identify the following different needs: (1) User email discussion (2) Developer email discussion (3) Buildbot reports (4) Trac reports (5) Commit messages Users will be interested in (1). Developers or followers of GHC development are probably interested in (1) and (2) but not necessarily (3 - 5). Maintainers or serious developers are probably interested in some combination of the above, including (1) and (2). People who track bugs (in general or for fun) would be interested in (4). Since Trac tickets have a CC option, many people probably don't need to subscribe to this list. Developers who police development would be interested in (3 - 5). By having a separate mailing list for each of (1) and (2), the email-only discussion does not get overwhelmed by the traffic of (3 - 5). And a separate mailing for each of (3 - 5) would allow the interested parties to subscribe to only what they want. Also, if you want to respond to an email on (3 - 5), then you are probably already subscribed to (2), so you can CC (2) in your response, thus bringing more developers into the conversation. (Personally, I've been using filters in Gmail to mark-read stuff that I'm not interested in, but I would be even happier to have the mailing lists further segmented.) Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
On Thu, Dec 6, 2012 at 5:55 PM, Ian Lynagh wrote: On Thu, Dec 06, 2012 at 06:25:49PM +0200, Roman Cheplyaka wrote: +1. I'd like to follow GHC development discussions, but getting all the commits is too much. I'm surprised by this, FWIW. I think skimming the commits is a good way to get an idea of what's going on, Indeed, it can be. But I can't keep up with the huge number of commits everyday, and I'm not interested in the large majority of them. while discussions between developers tend to be focussed on particular obscure points (e.g. discussing correctness of a murky corner in the intersection between 2 new type system extensions, or discussing the way PIC is handled on OSX/PowerPC) which I wouldn't have thought were of much interest to any party not involved in the discussion and familiar with the details. I find these things (both examples, actually) more interesting. I'm more likely to follow such threads than I am to skim the commits. Anyway, I'm not really too fussed about what mailing lists we have. I'll just subscribe to them all anyway :-) I'm not too fussed about it, either, but I wouldn't mind a restructuring. I might even subscribe to them all as well, but then it will be easier to follow the commits at a different pace from the rest (without having to create a new filter, which I've been so far too lazy to do). Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.6.2 Release Candidate 1
On Sun, Dec 9, 2012 at 10:39 PM, Ian Lynagh wrote: Please test as much as possible; bugs are much cheaper if we find them before the release! I tried to build the source tarball on Mac OS X 10.5.8. I used GHC 7.6.1, which I also built myself (without any problem) and installed in /Library/Frameworks/GHC.framework/Versions/7.6.1/usr. I got this: HC [stage 0] ghc/stage1/build/hschooks.o ghc/hschooks.c:36:0: error: conflicting types for ‘StackOverflowHook’ /Library/Frameworks/GHC.framework/Versions/7.6.1/usr/lib/ghc-7.6.1/include/rts/Hooks.h:21:0: error: previous declaration of ‘StackOverflowHook’ was here make[1]: *** [ghc/stage1/build/hschooks.o] Error 1 make: *** [all] Error 2 Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How do we best make sure {Int,Word,Float,Double} to {Int,Word,Float,Double} conversions stay efficient
On Fri, Dec 14, 2012 at 10:47 PM, Ian Lynagh wrote: On Fri, Dec 14, 2012 at 04:34:29PM -0500, Carter Schonwald wrote: A related question I have is that I've some code that will map the singleton Nats to Ints, and last time I looked into this/ had a chat on the ghc-users list, it sounded like sometimes having Integer values constructed in between are unavoidable. Is that still the case with post 7.6.1 ghc? (And or, how might I be able to help?) I don't know what a singleton Nat is, but if you mean Word then that's what Johan's been working on. I'm guessing Carter means Sing Nat: http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.6.0.0/src/GHC-TypeLits.html Regards, Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
