September 2009 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

Three patches for cabal
by Niklas Broberg 09 Nov '09

09 Nov '09

(Trying again since my previous patches were too big for the list.) While doing a survey[1] of the extensions registered with Cabal, I came across two warts in the list of constructors, and one constructor that should be deprecated. First there's the constructor called TransformListComp, which should really be named GeneralizedListComp, since the constructor should describe the extension and not the implementation scheme. Second there's the constructor NoMonoPatBinds, which actually describes the default Haskell 98 behavior, even if GHC has a different default. It's GHC's behavior that is the extension, so the constructor in cabal should really be named MonoPatBinds. Also, the PatternSignatures constructor has been deprecated in GHC and superceded by ScopedTypeVariables. The attached patches (three in one file) adds the proposed new constructors, deprecates the old ones, and adds documentation. Cheers, /Niklas

8 15

Snow Leopard GHC
by Barney Stratford 08 Oct '09

08 Oct '09

I've been trying to get GHC working for x86_64 on Snow Leopard, with a certain amount of success, but have got stuck. Maybe one of you could point me in the right direction. I now have a working compiler, but the linker in the runtime system seems to be missing some stuff. Specifically, in rts/Linker.c, there are references to X86_64_RELOC_UNSIGNED, X86_64_RELOC_SIGNED and so on, but it simply barfs when faced with a X86_64_RELOC_SIGNED_1 etc. I'd thought it would be a matter of adding a few lines of code, but everything I've tried has ended in tears. Trouble is, none of the documentation mentions X86_64_RELOC_SIGNED_1, although it does appear in C headers. It occurs only rarely in source examples, and it really isn't clear to me how I should proceed. Any ideas? Cheers, Barney.

4 14

Malformed class assertion with GHCi's output (a -> a ~ T a)
by Sean Leather 04 Oct '09

04 Oct '09

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

3 2

Re: [Haskell-cafe] Ghci dynamic linking (Was: C++ libraries and GHCI)
by Max Bolingbroke 02 Oct '09

02 Oct '09

(Moving to ghc-users) I'd never seen V in nm output before: """ The symbol is a weak object. When a weak defined symbol is linked with a normal defined symbol, the normal defined symbol is used with no error. When a weak undefined symbol is linked and the symbol is not defined, the value of the weak symbol becomes zero with no error. On some systems, uppercase indicates that a default value has been specified. """" Perhaps support needs to be added for this symbol type to the GHCi dynamic linker? (It would work in compiled programs b/c we call down to the system static linker in that case). Cheers, Max 2009/9/29 Paolo Losi <paolo.losi(a)gmail.com>: > Hi all, > > I would really appreciate if anyone could > give a look to the following problem. > > Thanks in advance!!! > Paolo > > > ---------- Forwarded message ---------- > From: Paolo Losi <paolo.losi(a)gmail.com> > Date: Mon, Sep 14, 2009 at 10:33 AM > Subject: C++ libraries and GHCI > To: glasgow-haskell-users(a)haskell.org > > > Hi all, > > I'm working on a tentative implementation of haskell binding to libsvm [1]: > > http://hackage.haskell.org/package/HSvm > > The package includes libsvm C++ sources. > While it works perfectly with ghc --make (try to install the package and > compile http://bitbucket.org/pao/hsvm/raw/6cf7ca91f1e5/test/test.hs) > it fails with ghci: > > (hsvm)(env)paolo@moltrasio:~/trash$ ghci test.hs > GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Ok, modules loaded: Main. > Prelude Main> main > Loading package syb ... linking ... done. > Loading package array-0.2.0.0 ... linking ... done. > Loading package containers-0.2.0.1 ... linking ... done. > Loading package HSvm-0.1.0.2.89 ... linking ... <interactive>: > /home/paolo/trash/hsvm/lib/HSvm-0.1.0.2.89/ghc-6.10.4/HSHSvm-0.1.0.2.89.o: > unknown symbol `_ZTV6Kernel' > ghc: unable to load package `HSvm-0.1.0.2.89' > > Please note that the symbol is available in libHSHSvm-0.1.0.2.89.a > > $ nm HSHSvm-0.1.0.2.89.o |grep _ZTV6Kernel > 00000000 V _ZTV6Kernel > $ nm libHSHSvm-0.1.0.2.89.a |grep _ZTV6Kernel > 00000000 V _ZTV6Kernel > > Can anyone give a look to the problem? > > Thanks > Paolo > > [1] http://www.csie.ntu.edu.tw/~cjlin/libsvm/ > > > > -- > Paolo Losi > e-mail: paolo(a)enuan.com > mob: +39 348 7705261 > > ENUAN Srl > Via XX Settembre, 12 - 29100 Piacenza > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

2 1

which difference...
by Luca Ciciriello 30 Sep '09

30 Sep '09

Hi all. I've recently changed my home machine (MacOS X 10.5.8 intel) and I've installed the GHC 6.10.4 using the pakage: GHC-6.10.4-i386.pkg. All works fine and I can continue all my research projects on my new machine. Then I've noticed that exists another kind of installation using the package: haskell-platform-2009.2.0.2-i386.dmg. What diferences exists between these two pakages? Am I missing something using the first pakage instead using the dmg distribution? Thanks in advance for any answer. Luca. Upgrade to Internet Explorer 8 Optimised for MSN. Download Now _________________________________________________________________ With Windows Live, you can organise, edit, and share your photos. http://clk.atdmt.com/UKM/go/134665338/direct/01/

2 1

Intel's Concurrent Collections for Haskell
by Don Stewart 29 Sep '09

29 Sep '09

http://softtalkblog.wordpress.com/2009/09/29/more-about-haskell-and-intel-c… Intel involved in work to port Concurrent Collections to Haskell. Might be interesting for benchmarks on 6.12 -- Don

1 0

Re: [Haskell-cafe] Status of GHC as a Cross Compiler
by Donnie Jones 24 Sep '09

24 Sep '09

Hello John, glasgow-haskell-users is a more appropriate list... http://www.haskell.org/mailman/listinfo/glasgow-haskell-users I went ahead and cc'd your message to the list. Any replies please include John's email address as I don't think he is subscribed to the list. Hope that helps... -- Donnie Jones On Wed, Sep 23, 2009 at 1:50 PM, John Van Enk <vanenkj(a)gmail.com> wrote: > Hi, > > This may be more appropriate for a different list, but I'm having a hard > time figuring out whether or not we're getting a cross compiler in 6.12 or > not. Can some one point me to the correct place in Traq to find this > information? > > /jve > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

2 1

ANNOUNCE: GHC 6.8.3 Release Candidate
by Ian Lynagh 22 Sep '09

22 Sep '09

We are pleased to announce the Release Candidate phase for GHC 6.8.3. Snapshots beginning with 6.8.2.20080527 are release candidates for 6.8.3 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.2.20080527-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src-extralib… 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

8 13

How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue.
by Karel Gardas 21 Sep '09

21 Sep '09

Hello, recently I've found out that my solaris-based GHC buildbot is completely unusable since it always (when it get to, which means it does not fail with usual magic number mismatch: old/corrupt interface file?) fails with: "inplace/bin/ghc-stage2" -H32m -O -DNEW_GHC_LAYOUT -hide-all-packages -i -iutils/haddock/src -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.7.4 -package array-0.2.0.1 -package base-4.2.0.0 -package containers-0.2.0.1 -package directory-1.0.0.2 -package filepath-1.1.0.1 -package ghc-6.11.20090915 -package pretty-1.0.1.0 -funbox-strict-fields -O2 -Wall -XForeignFunctionInterface -XCPP -XPatternGuards -XDeriveDataTypeable -XScopedTypeVariables -XMagicHash -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -hisuf hi -osuf o -hcsuf hc -c utils/haddock/src/Haddock/GhcUtils.hs -o utils/haddock/dist/build/Haddock/GhcUtils.o ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) make[1]: *** [utils/haddock/dist/build/Haddock/GhcUtils.o] Error 1 make: *** [all] Error 2 I've even tried to update my building GHC from 6.8.3 to 6.10.4, but it still does not help. Since I would really like to resurrect my GHC buildbot, do you have any idea how to fix this issue? Thanks, Karel PS: for reference, please have a look at http://darcs.haskell.org/buildbot/all/builders/kgardas%20head

5 9

Re: runghc failing sometimes on Linux/ppc?
by Christopher Lewis 20 Sep '09

20 Sep '09

> On Sun, May 03, 2009 at 03:02:50PM +1000, Jens Petersen wrote: > > 2009/5/2 Jens Petersen <petersen at haskell.org>: > > > So I tried doing an unregisterised ppc build with: > > > > > > echo "GhcUnregisterised=YES" >> mk/build.mk > > > echo "GhcWithNativeCodeGen=NO" >> mk/build.mk > > > echo "SplitObjs=NO" >> mk/build.mk > > > > Are these the right build config settings? > > Yes. > > > > but this failed with: > > : > > > Linking dist-stage2/build/ghc/ghc ... > > : > > > (.text+0x20): relocation truncated to fit: R_PPC_REL24 against symbol > > > `__libc_start_main@@GLIBC_2.0' defined in .glink section in > > > /usr/lib/gcc/ppc64-redhat-linux/4.4.0/../../../../lib/crt1.o > > > /usr/lib/gcc/ppc64-redhat-linux/4.4.0/crtbegin.o:(.fini+0x0): > > > relocation truncated to fit: R_PPC_REL24 against `.text' > > Does using -mlongcall help? e.g.: > > SRC_CC_OPTS += -mlongcall > SRC_HC_OPTS += -optc-mlongcall > > (you can probably get away with something rather more specific, but > hopefully this will work). I haven't seen a message confirming if the suggested solution worked, but I am experiencing a similar problem---failure to link GHC due to relocation truncation errors---on a different environment (Ubuntu, PowerPC 32 bit). I have tried the above workaround, but it did not solve my problem. Furthermore, based on this (http://osdir.com/ml/bug-binutils-gnu/2009-08/msg00068.html) binutils thread (sorry, there is probably a better source to reference), it appears this problem was not fixed until very recently. Any additional information or suggested workarounds would be much appreciated. {c}

1 0

Re: How to move code from GHC to libraries?
by Simon Marlow 17 Sep '09

17 Sep '09

On 17/09/2009 04:43, Norman Ramsey wrote: > > > While we're on this topic, I've had several requests to pull HOOPL > > > (the new dataflow optimization code) out as a library so that we can > > > make it into a Hackage package. I'd like to do this, but the > > > situation is complicated because HOOPL depends on UniqFM, which is > > > GHC-specific. I thought that there was a similar implementation out > > > in the wild (based on Okasaki-Gill rather than Adams), but I can't > > > find it on hackage. > > > > Isn't Data.IntMap ~= UniqFM? > > Yes, thanks --- I couldn't remember the module name, and search did > not help. > > > > Is there an established procedure for moving a part of GHC into a > > > library without breaking everybody's build? ... > > > > The architecture of our library setup is here: > > > > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Libraries > > > You'd be adding a new zero-boot package... > > OK, I would like to propose that I put Data.IntMap into a new > zero-boot package, and that I replace the existing UniqFM with a > compatibility layer over Data.IntMap, with the eventual goal of > expunging UniqFM from the GHC sources. > > Any comments or objections? You can assume that the bootstrapping compiler already has Data.IntMap, no need to put it in a 0-boot package. So in principle using Data.IntMap is a good thing, I wholeheartedly support using the standard libraries instead of in-house duplicates where possible. The only potential problem is performance: we rely heavily on UniqFM in GHC, so we'd have to make sure that any replacement is at least as fast. The only time to measure it is when making the changeover, when you can measure the change in isolation. Cheers, Simon

1 0

C++ libraries and GHCI
by Paolo Losi 14 Sep '09

14 Sep '09

Hi all, I'm working on a tentative implementation of haskell binding to libsvm [1]: http://hackage.haskell.org/package/HSvm The package includes libsvm C++ sources. While it works perfectly with ghc --make (try to install the package and compile http://bitbucket.org/pao/hsvm/raw/6cf7ca91f1e5/test/test.hs) it fails with ghci: (hsvm)(env)paolo@moltrasio:~/trash$ ghci test.hs GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Ok, modules loaded: Main. Prelude Main> main Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.1 ... linking ... done. Loading package HSvm-0.1.0.2.89 ... linking ... <interactive>: /home/paolo/trash/hsvm/lib/HSvm-0.1.0.2.89/ghc-6.10.4/HSHSvm-0.1.0.2.89.o: unknown symbol `_ZTV6Kernel' ghc: unable to load package `HSvm-0.1.0.2.89' Please note that the symbol is available in libHSHSvm-0.1.0.2.89.a $ nm HSHSvm-0.1.0.2.89.o |grep _ZTV6Kernel 00000000 V _ZTV6Kernel $ nm libHSHSvm-0.1.0.2.89.a |grep _ZTV6Kernel 00000000 V _ZTV6Kernel Can anyone give a look to the problem? Thanks Paolo [1] http://www.csie.ntu.edu.tw/~cjlin/libsvm/

1 0

Re: How to move code from GHC to libraries?
by Simon Marlow 14 Sep '09

14 Sep '09

On 12/09/2009 00:02, Norman Ramsey wrote: > > Incedentally, the reason I'd like us to make a decision on this now is > > because I'm about to add two new boot libraries... > > While we're on this topic, I've had several requests to pull HOOPL > (the new dataflow optimization code) out as a library so that we can > make it into a Hackage package. I'd like to do this, but the > situation is complicated because HOOPL depends on UniqFM, which is > GHC-specific. I thought that there was a similar implementation out > in the wild (based on Okasaki-Gill rather than Adams), but I can't > find it on hackage. Isn't Data.IntMap ~= UniqFM? > Is there an established procedure for moving a part of GHC into a > library without breaking everybody's build? If so, where will I find > it on the developers' wiki? If not, who can advise me so I can create > a page on the developers' wiki? :-) The architecture of our library setup is here: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Libraries Basically you'd be adding a new zero-boot package (that terminology isn't used in the build system, where they're called "boot packages"). The best way to find out how to add another one is to grep for an existing zero-boot package (e.g. Cabal) in the top-level ghc.mk to see the various things you need to add. The new package would need to have a repository created on darcs.haskell.org, and you'd need to add it to $(TOP)/packages too. When the changes are pushed, everyone has to "./darcs-all get" to get the new repository. Cheers, Simon

1 0

GHCi can't see 'atexit', can't load module
by Maurício CA 13 Sep '09

13 Sep '09

(I left this in cafe, but I think it is actually ghc related.) I just checked it seems not to be possible to load any module in GHCi that uses FFI to wrap the standard C function 'atexit'. When trying that, we get a message saying the symbol 'atexit' can't be found. (This is not a problem when building an executable with ghc, though.) It's easy to reproduce the problem. Just try something like this: ----- module XXX where import Foreign import Foreign.C foreign import ccall atexit :: FunPtr (IO ()) -> IO CInt ----- Load it in ghci (after ':set -XForeignFunctionInterface' to get FFI) and you will get the error. If we replace the line below for the above we don't get any error message: foreign import ccall exit :: CInt -> IO () Here, we just replaced 'atexit' by 'exit', which, according to 'nm' tool, is at the same 'libc' library that 'atexit' belongs to. Thanks, Maurício

2 2

Build error in users guide in HEAD of today
by "Philip K.F. Hölzenspies" 11 Sep '09

11 Sep '09

Dear GHC-ers, I'm trying to put together a virtual machine with a default development for GHC hacking. To test it, I was running "sh validate" in the build tree. There were build errors in the doc/users_guide, however. Google gave me an hpaste page with the error on it, but I couldn't find the referring message. Does this ring a bell for anyone: latex failed users_guide_tmp.tex:1380: Undefined control sequence \Documents. users_guide_tmp.tex:1380: leading text: } users_guide_tmp.tex:1380: Undefined control sequence \user. users_guide_tmp.tex:1380: leading text: } users_guide_tmp.tex:5782: Undefined control sequence \Documents. users_guide_tmp.tex:5782: leading text: ...kurl{C: \Documents~And~Settings\user\ghc} users_guide_tmp.tex:5782: Undefined control sequence \user. users_guide_tmp.tex:5782: leading text: ...kurl{C: \Documents~And~Settings\user\ghc} users_guide_tmp.tex:5782: Undefined control sequence \ghc. users_guide_tmp.tex:5782: leading text: ...kurl{C: \Documents~And~Settings\user\ghc} users_guide_tmp.tex: File ended while scanning use of \hyper@n@rmalise. users_guide_tmp.tex: Emergency stop. Error: latex compilation failed make[2]: *** [docs/users_guide/users_guide.ps] Error 1 make[1]: *** [all_docs/users_guide] Error 2 I understand the LaTeX errors, but I'm not so well versed in docbook. Should the path in the ghci.xml and packages.xml be forward slashed, instead of backslashed or does this indicate there's something wrong with my docbook/latex setup? Even when I change the backslashes to forward slashes, the last error (scanning use of \hyper@n@rmalise) remains. Any ideas? Regards, Philip

3 3

Libraries in the repo
by Simon Marlow 11 Sep '09

11 Sep '09

Simon and I have been chatting about how we accommodate libraries in the GHC repository. After previous discussion on this list, GHC has been gradually migrating towards having snapshots of libraries kept as tarballs in the repo (currently only "time" falls into this category), but I don't think we really evaluated the alternatives properly. Here's an attempt to do that, and to my mind the outcome is different: we really want to stick to having all libraries as separate repositories. Background: * Scope: libraries that are needed to build GHC itself (aka "boot libraries") * Boot libraries are of several kinds: - INDEPENDENT: Independently maintained (e.g. time, haskeline) - COUPLED: Tightly coupled to GHC, but used by others (base) - SPECIFIC: Totally specific to GHC (e.g. template-haskell, DPH) * Most boot libraries are INDEPENDENT. INDEPENDENT libraries have a master repository somewhere separate from the GHC repositories. * We need a branch of INDEPENDENT libraries, so that GHC builds don't break when the upstream package is modified. * Sometimes we want to make local modifications to INDEPENDENT libraries: - when GHC adds a new warning, we need to fix instances of the warning in the library to keep the GHC build warning-free. - to check that the changes work, before pushing upstream Choices for how we deal with libraries in the GHC repository: (+) is a pro, (-) is a con. (1) Check out the library from a separate repo, using the darcs-all script. The repo may either be a GHC-specific branch [INDEPENDENT], or the master copy of the package [SPECIFIC/COUPLED]. (+) we can treat every library this way, which gives a consistent story. Consistency is good for developers. (+) [INDEPENDENT] makes it easy to push changes upstream and sync with the upstream repo (unless upstream is using a different VCS). (-) [INDEPENDENT] we have to be careful not to let our branches get too far out of sync with upstream, and we must sync before releasing GHC. (2) Put a snapshot tarball of the library in libraries/tarballs, but allow you to checkout the darcs repo instead. (-) [SPECIFIC/COUPLED] this approach doesn't really make sense, because we expect to be modifying the library often. (-) updating the snapshot is awkward (-) workflow for making a change to the library is awkward: - checkout the darcs repo - make the change, validate it - push the change upstream (bump version?) - make a new snapshot tarball - commit the new snapshot to the GHC repo. (-) having tarballs in the repository is ugly (-) we have no revision history of the library (3) The GHC repo *itself* contains every library unpacked in the tree. You are allowed to check out the darcs repo instead. (+) atomic commits to both the library and GHC. (+) doing this consistently would allow us to remove darcs-all, giving a nice easy development workflow (-) [INDEPENDENT/COUPLED] still need a separate darcs repo. (-) [INDEPENDENT/COUPLED] pushing changes upstream is hard (-) [INDEPENDENT/COUPLED] manual syncing with upstream (-) [COUPLED] (particularly base) syncing with upstream would be painful. (3) works best for SPECIFIC libraries, whereas (1) works best for INDEPENDENT/COUPLED libraries. If we want to treat all libraries the same, then the only real option is (1). Experience with Cabal and bytestring has shown that (1) can work for INDPENDENT libraries, but only if we're careful not to get too out-of-sync (as we did with bytestring). In the case of Cabal, we never have local changes in our branch that aren't in Cabal HEAD, and that works well. Comments/thoughts? Cheers, Simon

8 20

Resolving overloading loops for circular constraint graph
by Stefan Holdermans 10 Sep '09

10 Sep '09

Manuel, Simon, I've spotted a hopefully small but for us quite annoying bug in GHC's type checker: it loops when overloading resolving involves a circular constraint graph containing type-family applications. The following program (also attached) demonstrates the problem: {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TypeFamilies #-} type family F a :: * type instance F Int = (Int, ()) class C a instance C () instance (C (F a), C b) => C (a, b) f :: C (F a) => a -> Int f _ = 2 main :: IO () main = print (f (3 :: Int)) My guess is that the loop is caused by the constraint C (F Int) that arises from the use of f in main: C (F Int) = C (Int, ()) <= C (F Int) Indeed, overloading can be resolved successfully by "black-holing" the initial constraint, but it seems like the type checker refuses to do so. Can you confirm my findings? I'm not sure whether this is a known defect. If it isn't, I'd be more than happy to issue a report. Since this problem arises in a piece of very mission-critical code, I would be pleased to learn about any workarounds. Thanks in advance, Stefan

3 5

Functor <constant>
by Serge D. Mechveliani 09 Sep '09

09 Sep '09

People, I have data DBit = Bit0 | Bit1 deriving (Eq, Ord, Enum) data BNatural = BNat [DBit] deriving (Eq) and want to apply things like fmap reverse (bn :: BNatural). GHC reports an error on this usage of fmap. It also does not allow instance Functor BNatural where fmap f (BNat ds) = BNat $ f ds, -- it reports that a type constructor for Functor must have kind * -> *. Probaly, GHC agrees with Haskell at this point (?). Now, I deceive the compiler by declaring instead newtype BNatAux a = BNat a deriving (Eq) type BNatural = BNatAux [DBit] instance Functor BNatAux where fmap f (BNat ds) = BNat $ f ds So, a parasitic BNatAux is introduced. I wonder: is there a simpler way to have fmap for BNatural ? Thank you in advance for advice, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

fromEnum (c :: Char)
by Serge D. Mechveliani 09 Sep '09

09 Sep '09

People, I need to convert Char <-> Int in a possibly _standard_ way for Haskell -- and also in an efficient way. In particular, it must not spend 100 comparisons in a look through the listing of Char. I use ord :: Char -> Int and chr :: Int -> Char. Is this all right? Thank you in advance for advice, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

no backspace, delete or arrow keys in ghci
by Gabriel Schwanen 08 Sep '09

08 Sep '09

Hello to everybody, I'm currently working with Haskell via the ghc interpreter (version 6.10.4 on Ubuntu 9.10). The problem, if it is really a problem and not a normal comportement, happens when I try, as example, to enter some characters after having execute getLine. Actually, if I make a mistake when typing the string, I can't use neither backspace, delete or even arrow keys to correct it before hitting enter to finish input. In fact, as example, if I hit backspace, I get "^?" in place of deleting the previous character ... :^( As I wrote above, I don't know if it is a "bug" or not. Maybe it is normal. Can someone help me ? Thanks in advance, Gabriel

3 3

ghc --help displays obsolete URL
by Ahn, Ki Yung 08 Sep '09

08 Sep '09

$ ghc --help ... The User's Guide has more information about GHC's *many* options. An online copy can be found here: http://www.haskell.org/ghc/documentation.html ------------------------------------------------------------------------ The above URL does not exist! Hope it gets fixed in 6.12.x

3 2

few questions about GHC RTS
by Peter Hercek 07 Sep '09

07 Sep '09

Hi, I thought I may look at the :next command for GHCi debugger again. If I do, I will not make it before 6.12.1 is out. I have few questions about RTS in relation to :next implementation. If they is easy to answer I would appreciate it, if not, don't bother since I'm not sure I'll do it ... and If I decide to do it I may just figure it out myself or fail again :) Why is stg_nofoceIO_info added as last argument to IO actions in unregistered mode? Do I still need to pass it in even when (I think) my IO action does not need it? E.g. is it required for every IO action by some stack walking code or something? Are there any Cmm functions in RTS with signature (IO()) or signature (Int->IO()) which I could check out as examples to see how they are done? ... and ideally also how they are called from the stack. Are there any special things to do when adding a new field (e.g. simulated stack size) to StgTSO? Thanks, Peter.

2 2