- Glasgow-haskell-users

RE: Combining Module Interfaces
by Simon Peyton-Jones 10 Dec '01

10 Dec '01

No, GHC just does not support this. GHC tries to avoid duplicating information (which might become inconsistent with catastrophic results), so C.hi simply records the dependency on A.hi and B.hi. You must have both of the latter available. Simon | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org] | Sent: 07 December 2001 22:03 | To: GHC List | Subject: Combining Module Interfaces | | | Is there a way to combine interfaces into a single file? | | If I have modules A and B, I want to create a module C with all the | exported definitions of A and B such that I can compile | against C.hi file | without needing the A.hi and B.hi files. | | I tried this: | | module C (module A,module B) where | { | import A; | import B; | } | | ...but if I attempt to compile against C.hi using definitions | from A and | B, GHC complains if I don't have A.hi and B.hi. I want C.hi | to contain | everything that A.hi and B.hi do. | | -- | Ashley Yakeley, Seattle WA | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

like .ghci for ghc?
by Hal Daume III 08 Dec '01

08 Dec '01

I've read through most of the ghc docs, but haven't found anything like this. Almost all of my programs require -fglasgow-exts -package data -package text as well as -i(long paths here) but the latter three I cannot put in an OPTIONS line in the source code. In ghci I can have a ~/.ghci file, but the same doesn't appear to hold for ghc itself. Is there a way to do this? (If not, could one *please* be added?) Thanks - Hal p.s., yes, I know I could alias ghc or something, but this would be cleaner imo. -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

Re: Questions about sharing
by Jan-Willem Maessen 08 Dec '01

08 Dec '01

On Fri, 7 Dec 2001, Adrian Hey replied: > On Friday 07 December 2001 2:27 pm, D. Tweed wrote: > > > On Fri, 7 Dec 2001, Adrian Hey wrote: > > > The first is.. > > > Does the compiler keep a unique copy of expressions which consist of just > > > a single zero arity constructor (eg. [],True,Nothing..) as a CAF which is > > > referenced each time the constructor appears in an expression, or does it > > > duplicate the constructor (expression) each time it's used. > > Well I suppose if it's necessary to create a new indirection heap record > for each reference, then there's not really any point in having a single > copy of the value itself. But I don't see why that should be so. Even > if it is indirected for some reason it should still be possible to > share the indirection record I think. > > Maybe CAF is the wrong word to use here since there's no application > involved. What I mean is.. are zero arity constructors referenced the > same way as a top level constant would be? (Not that I know how > that's done, but I presume there's only 1 copy of top level > constants in memory at any one time.) My understanding is that GHC tries to have it both ways. Here's my understanding of how it works (implementors should probably chime in if my memory is faulty or out of date): 1) There is a single, canonical copy of every nullary constructor. This canonical copy is used wherever possible---just like a top-level constant. 2) Updating a thunk with an indirection makes it expensive to obtain the thunk's value. The extra indirection does not require allocation---the only reason we need indirections at all is to overwrite memory that previously held a thunk. The real problem is that it takes time to chase down indirections once they exist. Therefore when a thunk evaluates to a nullary constructor, it is overwritten directly. This effectively creates another copy of the nullary constructor. 3) When the GC runs, instead of copying these newly-created nullary constructors, it replaces them with the canonical copy. [The GC also eliminates indirections, and thus helps us no matter what we do in 2) above] Thus we get the best of both worlds---efficient thunk update and reasonable space consumption. -Jan-Willem Maessen

1 0

Questions about sharing
by Adrian Hey 08 Dec '01

08 Dec '01

Hello, I sometimes wonder just how far I should go in obfuscating code by manually implementing trivial optimisations that should (IMHO) be implemented by the compiler, but may not be. So I have a couple of specific questions.. The first is.. Does the compiler keep a unique copy of expressions which consist of just a single zero arity constructor (eg. [],True,Nothing..) as a CAF which is referenced each time the constructor appears in an expression, or does it duplicate the constructor (expression) each time it's used. Maybe I should define my own CAF at the top level and use it instead? (or perhaps they're unboxed somehow?) The second is.. If, following pattern matching, the matched pattern appears in an expression, is it shared or duplicated.. e.g. (a:as) -> f (a:as) Maybe I should write something like this.. x@(a:as) -> f x (I know that sometimes the type checker won't allow you to do this) Thanks -- Adrian Hey

2 2

RE: Questions about sharing
by Simon Marlow 08 Dec '01

08 Dec '01

> I sometimes wonder just how far I should go in obfuscating code by > manually implementing trivial optimisations that should (IMHO) be > implemented by the compiler, but may not be. > > So I have a couple of specific questions.. > > The first is.. > Does the compiler keep a unique copy of expressions which > consist of just > a single zero arity constructor (eg. [],True,Nothing..) as a > CAF which is > referenced each time the constructor appears in an > expression, or does it > duplicate the constructor (expression) each time it's used. > Maybe I should define my own CAF at the top level and use it instead? > (or perhaps they're unboxed somehow?) Nullary constructors are represented by a single static constructor, they are never built dynamically. So feel free to write [] wherever you like - it has the same cost as a variable. > The second is.. > If, following pattern matching, the matched pattern appears in an > expression, is it shared or duplicated.. > e.g. (a:as) -> f (a:as) > Maybe I should write something like this.. > x@(a:as) -> f x > (I know that sometimes the type checker won't allow you to do this) Yes, GHC will common these up (with -O). I'm not sure I understand the point about the type checker not letting you do this yourself, though: surely x and (a:as) have the same type? Cheers, Simon

3 2

Combining Module Interfaces
by Ashley Yakeley 07 Dec '01

07 Dec '01

Is there a way to combine interfaces into a single file? If I have modules A and B, I want to create a module C with all the exported definitions of A and B such that I can compile against C.hi file without needing the A.hi and B.hi files. I tried this: module C (module A,module B) where { import A; import B; } ...but if I attempt to compile against C.hi using definitions from A and B, GHC complains if I don't have A.hi and B.hi. I want C.hi to contain everything that A.hi and B.hi do. -- Ashley Yakeley, Seattle WA

1 0

RealWorld?
by Koen Claessen 07 Dec '01

07 Dec '01

Hi, I want to use the functions: hGetBufBA :: Handle -> MutableByteArray RealWorld a -> Int -> IO Int hPutBufBA :: Handle -> MutableByteArray RealWorld a -> Int -> IO () But as soon as I mention their types, 'RealWorld' is not in scope. In what module is this defined? /Koen.

2 1

RE: Questions about sharing
by Simon Peyton-Jones 07 Dec '01

07 Dec '01

| Does the compiler keep a unique copy of expressions which | consist of just a single zero arity constructor (eg. | [],True,Nothing..) as a CAF which is referenced each time the | constructor appears in an expression Yes, it does. | The second is.. | If, following pattern matching, the matched pattern appears | in an expression, is it shared or duplicated.. e.g. (a:as) -> | f (a:as) Maybe I should write something like this.. | x@(a:as) -> f x | (I know that sometimes the type checker won't allow you to do this) The compiler will share it if you are using -O; but only if the type checker would also allow it. (The internal language is typed!) Simon

1 0

RE: Problems creating a DLL with ghc-5.02.1
by Lehti, Patrick 07 Dec '01

07 Dec '01

Cool, that works! But now no import library is created. I thought this done during creating the dll? Patrick -----Original Message----- From: Sigbjorn Finne [mailto:sof@galois.com] Sent: Donnerstag, 6. Dezember 2001 16:35 To: Lehti, Patrick Cc: glasgow-haskell-users(a)haskell.org Subject: Re: Problems creating a DLL with ghc-5.02.1 Yes, if you're willing to do the following: - only use the --mk-dll option when linking together object files & archives (i.e., don't try compile a Haskell source file and create its DLL during the same invocation of GHC). (Remembering to include the _stub.o files too when linking). - modify your package.conf file, editing the entry for the 'rts' package to instead of having a library_dirs equal to ["$libdir"], have it be ["$libdir", "$libdir/gcc-lib"] Alternatively, add the command-line option "-Lc:/ghc/ghc-5.02.1/gcc-lib" to your ghc-5.02.1 (where c:/ghc/ghc-5.02.1 is wherever you've got GHC installed). hth --sigbjorn ----- Original Message ----- From: "Lehti, Patrick " <Patrick.Lehti(a)softwareag.com> To: <glasgow-haskell-users(a)haskell.org> Sent: Thursday, December 06, 2001 06:04 Subject: Problems creating a DLL with ghc-5.02.1 > Hi, > > I tried to wrap a Haskell application in a DLL using ghc-5.02.1. But this is > not working, with cygwin in path I got this error message: > /usr/lib/mingw/libmingw32.a(gccmain.o)(.text+0x88):gccmain.c: multiple > definition of `__main' > /usr/lib/libm.a(ds00023.o)(.text+0x0): first defined here > > ... and without cygwin in path, it could not find "dllwrap" and "dlltool". > > Is there any solution for this problem? > > Patrick >

2 1

Problems creating a DLL with ghc-5.02.1
by Lehti, Patrick 06 Dec '01

06 Dec '01

Hi, I tried to wrap a Haskell application in a DLL using ghc-5.02.1. But this is not working, with cygwin in path I got this error message: /usr/lib/mingw/libmingw32.a(gccmain.o)(.text+0x88):gccmain.c: multiple definition of `__main' /usr/lib/libm.a(ds00023.o)(.text+0x0): first defined here ... and without cygwin in path, it could not find "dllwrap" and "dlltool". Is there any solution for this problem? Patrick

2 1