- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Non-technical Haskell question
by Henning Thielemann 07 Dec '04

07 Dec '04

On Tue, 7 Dec 2004, Brian Smith wrote: > FWIW, I use a directory structure like: > src/ source code > build// intermediate files (.hi, .o) > dist/ deliverables > I execute GHC using: > ghc --make Main -isrc -hidir build -odir build -o dist/program > As a result, I never have any non-source files mixed in with the > source files. So, I think what you want is possible today. The difference is that for Modula-3 the same effect is achieved by e.g. m3build or cm3 that is, I never called the compiler but always used the M3 build system. Would be nice to have this with Haskell, too. Maybe 'hmake' and Cabal can help here?

1 0

RE: [Haskell-cafe] Re: Non-technical Haskell question
by Simon Marlow 07 Dec '04

07 Dec '04

On 06 December 2004 14:39, John Goerzen wrote: > On 2004-12-06, Keith Wansbrough <Keith.Wansbrough(a)cl.cam.ac.uk> wrote: >> The static vs dynamic linking question has been discussed many times. >> The summary is: GHC is a highly-optimising compiler, and the binary >> interface _necessarily_ changes with every minor revision (even >> patchlevel revision) of the compiler and each library. So you can't > > We already have a way to deal with that using sonames. It's not that > hard, and is routinely used. > > BTW, is this a problem even if no -O options are given when building a > library? Certainly it's possible to get a more stable library ABI by not compiling with -O. The question is, do you want to? You certainly don't want to do this for the Prelude and other essential libraries. For example, GHC wouldn't be able to see the definition of 'instance Num Int', and hence (x + 1 :: Int) would be compiled as (+) dNumInt x (I# 1) instead of (after inlining (+) and dNumInt): case x of I# x# -> I# (x# +# 1#) which can then be further optimised: the compiler can see that it is strict in x, so might be able to unbox x, and so on. This is pretty essential to get any kind of reasonable performance, but it might be less important for higher-level libraries, as long as you don't have any important monads that need to be inlined, for example. Dynamic linking is (almost) a separate issue. GHC 6.4 will have some support for dynamic linking in the native code generator thanks to Wolfgang Thaller, but it needs someone to push it the final mile on x86/Linux and Windows. Dynamically linked libraries will work (albeit slightly slower than statically linked ones), but you still have the versioning issue. Since libraries are getting really big nowadays (eg. wxHaskell) making dynamic linking work even without worrying about versioning seems like it would be worthwhile. Cheers, Simon

4 4

RE: [Haskell-cafe] Re: Non-technical Haskell question
by Simon Marlow 07 Dec '04

07 Dec '04

On 06 December 2004 21:54, Sven Panne wrote: > And just a remark: We don't need a new technique for a "no inline > barrier": Just compile the library optimized and use a facade which > re-exports your public API compiled without optimizations. That probably won't work. GHC goes to the .hi file for the module which originally defined a function to get its definition. Cheers, Simon

2 1

RE: [Haskell-cafe] Classes in type declarations in Hugs
by Simon Peyton-Jones 07 Dec '04

07 Dec '04

http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions. html#NEWTYPE-DERIVING | -----Original Message----- | From: Graham Klyne [mailto:GK@ninebynine.org] | Sent: 07 December 2004 10:46 | To: Simon Peyton-Jones; haskell-cafe(a)haskell.org | Subject: RE: [Haskell-cafe] Classes in type declarations in Hugs | | At 10:15 06/12/04 +0000, Simon Peyton-Jones wrote: | >| This is where I find ghc's newtype deriving to be incredibly useful. | >| | >| newtype CPError a = CPError (Either Error a) | >| deriving(Monad,MonadError) | >| | >| now CPError is a monad and an instance of MonadError and you are free | >to | >| override or inherit more interesting instances at will without | >| conflicting with the basic types for Either :) | > | >Aha! I've always wondered whether anyone uses this feature, which I | >implemented at John Hughes's suggestion. I'd be interested to know if | >you are alone, or whether others do so too. | | Not a user, but sounds maybe interesting. Can you point to documentation? | | #g | | | ------------ | Graham Klyne | For email: | http://www.ninebynine.org/#Contact

1 0

RE: [Haskell-cafe] Classes in type declarations in Hugs
by Graham Klyne 07 Dec '04

07 Dec '04

At 10:15 06/12/04 +0000, Simon Peyton-Jones wrote: >| This is where I find ghc's newtype deriving to be incredibly useful. >| >| newtype CPError a = CPError (Either Error a) >| deriving(Monad,MonadError) >| >| now CPError is a monad and an instance of MonadError and you are free >to >| override or inherit more interesting instances at will without >| conflicting with the basic types for Either :) > >Aha! I've always wondered whether anyone uses this feature, which I >implemented at John Hughes's suggestion. I'd be interested to know if >you are alone, or whether others do so too. Not a user, but sounds maybe interesting. Can you point to documentation? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: [Haskell-cafe] Classes in type declarations in Hugs
by Simon Peyton-Jones 07 Dec '04

07 Dec '04

| This is where I find ghc's newtype deriving to be incredibly useful. | | newtype CPError a = CPError (Either Error a) | deriving(Monad,MonadError) | | now CPError is a monad and an instance of MonadError and you are free to | override or inherit more interesting instances at will without | conflicting with the basic types for Either :) Aha! I've always wondered whether anyone uses this feature, which I implemented at John Hughes's suggestion. I'd be interested to know if you are alone, or whether others do so too. Simon

2 1

RE: [Haskell-cafe] Classes in type declarations in Hugs
by David Menendez 07 Dec '04

07 Dec '04

Simon Peyton-Jones writes: > | This is where I find ghc's newtype deriving to be incredibly useful. ... > Aha! I've always wondered whether anyone uses this feature, which I > implemented at John Hughes's suggestion. I'd be interested to know if > you are alone, or whether others do so too. I think there were a few times where I would have used it, had I known about it. -- David Menendez <zednenem(a)psualum.com> | "In this house, we obey the laws <http://www.eyrie.org/~zednenem> | of thermodynamics!"

1 0

Select.hs in GHC 6.2.1+ Windows 2000
by Henning Sato von Rosen 06 Dec '04

06 Dec '04

Hi! My friend wants to do a haskell lab assignment on windows 2000, but the code depends on Select.hs , is there a workaround in windows one can use instead? Is Cygwin (a / the only) solution Thankful for any info on where to look! /Regards Henning

2 1

Force evaluation
by Michael Walter 06 Dec '04

06 Dec '04

Hi, is there a way to force the "full" evaluation of a value (unless seq, which only brings the term to WHNF)? In my case, I have an algebraic data type Foo, and I would like to catch the exceptions that will occur during the evaluation of a value of Foo, for something like: foo <- force makeFoo `catch` \e -> defaultFoo Thanks, Michael PS: Ooops, posted this to haskell-ml first.

2 1

Practical Question: Large memory items
by GoldPython 06 Dec '04

06 Dec '04

In another thread's discussion, we touched on the implementation of a text editor. It invariably comes up, in building a text editor, as to whether to allow editing of things larger than will fit in memory, etc. And so, practical concerns enter in that, in my mind at least, take us away from solving the conceptual problem at hand, and now the focus shifts to implementation details that we'd rather not be bothered with. One approach is to let the OS's virtual memory take care of it. Sometimes this is fine, sometimes not, often times around issues of performance, where a completely general purpose swapping device can't perform as well as a more specifically targeted design. Question: Should the Haskell runtime enviroment provide swapping services for large objects?

2 1