October 2004 - Glasgow-haskell-users

RE: -K
by Simon Marlow 11 Oct '04

11 Oct '04

On 11 October 2004 05:37, Serge D. Mechveliani wrote: > I am not sure but have such an impression that the -K option > (for the stack size) appears and disappears between the GHC > versions. Nope, the -K option has always been there. > ghc-6.2.2-September-26 requires -K to be set independently of -M > (when the stack is exhausted). > > Is not this more nice and flexible to take from the given memory as > much stack as it is needed, without asking the user? We have a default limit on the stack size because it's very easy in Haskell to write a program with an infinite loop that eats up all your memory. On some systems, eating up all the memory can lead to severe consequences (random processing getting terminated, etc.). A while back we removed the default limit on the heap size, because many people felt that the benefit of not having to explicitly increase the heap size was worth the potential pain of a space leak using up all the memory. In retrospect, I think that was probably the right choice, although I argued against it at the time. Nowadays platforms have per-process or per-user memory limits, and are generally more robust in low-memory situations. So, perhaps we should set the default stack size to be unlimited. I'm prepared to be persuaded. Anyway, to answer your question: yes, I think it would make sense when the user has specified -M for the stack size to be limited only by the maximum heap size given with the -M option. But, this would be an extra thing to document with the -M option, and you can already get this behaviour by saying -M<size> -K<size>. > It is natural for the user think of some abstract Haskell machine > which performs the program in the given memory size (-M..). > Whether the given memory is divided to `stack' and other parts -- > this is a technical detail, an internal matter of implementation, > and the user need not to know about stack. That is already the case. > On the other hand, the final report of kind > "xxx bytes used for stack" > is helpful (in profiling?), for it helps to detect the unneeded > `laziness' cases and such. You can see the stack size when profiling with the -xt option. Cheers, Simon

1 0

factoring `if'
by Serge D. Mechveliani 11 Oct '04

11 Oct '04

Dear Haskell implementors, How do you think, is the program (1) equivalent to (2) in the meaning of Haskell-98 ? (1) (\ x -> (if p x then foo (g x) else foo (h x)) where p ... g ... h ... foo ... ) (2) (\ x -> foo ((if p x then g x else h x) where p ... g ... h ... foo ... ) ) If it is equivalent, then does it make sense for a compiler to convert (1) to (2): to separate a common `factor' of the if-branches ? The reason for this may be, for example, that the result printing of (f x) is more `lazy' in (2) than in (1): the part of foo may print immediately and (g x) or (h x) may print long after. This is a difference in behavior, it does not effect the computation meaning. I have a large program which is easily written in the style of (1), (and in many places it sets `case' instead of `if'). Annoyingly, it prints out in a not a lazy manner. It can be rewritten in the form of (2), but with effort, and it will look less plain. So, maybe, this is a business of a compiler? Copy, please, the possible answer to mechvel(a)botik.ru ----------------- Serge Mechveliani mechvel(a)botik.ru

4 3

-K
by Serge D. Mechveliani 11 Oct '04

11 Oct '04

Dear GHC developers, I am not sure but have such an impression that the -K option (for the stack size) appears and disappears between the GHC versions. ghc-6.2.2-September-26 requires -K to be set independently of -M (when the stack is exhausted). Is not this more nice and flexible to take from the given memory as much stack as it is needed, without asking the user? It is natural for the user think of some abstract Haskell machine which performs the program in the given memory size (-M..). Whether the given memory is divided to `stack' and other parts -- this is a technical detail, an internal matter of implementation, and the user need not to know about stack. On the other hand, the final report of kind "xxx bytes used for stack" is helpful (in profiling?), for it helps to detect the unneeded `laziness' cases and such. Im I missing something? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Performance-loss of accessing data through class?
by Peter Simons 10 Oct '04

10 Oct '04

Hi, in a module I am writing, I am using a 'StateT st IO' monad with a state like this: data MyState st = ST !Int !st My own monad is yet-another wrapper for ... another state monad. And that's getting inconvenient. So I wondered whether it would be good to define a class that unified all those StateTs into _one_ state, like: > class KnowsMyStuff a where > foo :: a -> Int > bar :: a -> Float > etc :: a -> [String] Then I could write my functions so that they'd work on any MonadIO which has some way of getting those instances defined. If I did that, how much performance would I lose? Accessing those values would probably require one more level of indirection, that can't be as fast as having a specific data type, right? Or is there some optimizer magic at work here? Peter P. S.: Right now the code is _very_ fast, and I'd rather have that than an convenient interface, that's why I ask.

1 0

RE: deriving
by Simon Peyton-Jones 08 Oct '04

08 Oct '04

It's all done by the module TcDeriv, which exports one function, tcDeriving, which does all the work. It generates source-code syntax for derived classes. You can grep for where tcDeriving is called (one place in TcInstDcls). Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of MR K P SCHUPKE | Sent: 08 October 2004 14:26 | To: glasgow-haskell-users(a)haskell.org | Subject: deriving | | | How is deriving coded in ghc. For example the "Typeable" class, when in | the compilation sequence is this expanded? Which modules do this, and | which functions? | | Keean. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

deriving
by MR K P SCHUPKE 08 Oct '04

08 Oct '04

How is deriving coded in ghc. For example the "Typeable" class, when in the compilation sequence is this expanded? Which modules do this, and which functions? Keean.

1 0

RE: Bools are not unboxed
by Simon Marlow 06 Oct '04

06 Oct '04

On 06 October 2004 11:36, Josef Svenningsson wrote: > Simon Marlow wrote: > >> On 06 October 2004 00:53, John Meacham wrote: >> >> >> >>> This seems like it could be nicely generalized such that all >>> enumeration types unbox to the unboxed integer of their offset. so >>> >>> data Perhaps = Yes | Maybe | No >>> >>> can unbox to an Int# with 0# == Yes 1# == Maybe and 2# == No. >>> >>> >> >> Yes, a strict enumeration should be implemented as an Int#, both in >> the strictness analyser and also when you {-# UNPACK #-} a >> constructor field. This is something we'd like to try, but haven't >> got around to it yet. Maybe a good bite-sized project for a budding >> GHC hacker? :-) >> >> >> > Would it really be correct to translate it to Int#? AFAIK, unboxed > values may not contain bottom while a data type most certainly can. I > would imagine translating it to Int, and then relying on GHC's > optimiser to optimize this into Int# whenever possible. Note I said a *strict* enumeration. You're right that in general it wouldn't be correct to implement Bool by Int#. Only when the strictness analyser has determined that a function argument of enumeration type is strict, or the programmer has added a strictness annotation to a constructor field. Certainly right now you can use Int everywhere instead of enumeration types, and perhaps get better performance because GHC will unbox the Int whenever possible. Cheers, Simon

1 0

RE: Bools are not unboxed
by Simon Marlow 06 Oct '04

06 Oct '04

On 06 October 2004 00:53, John Meacham wrote: > On Tue, Oct 05, 2004 at 01:48:30PM +0100, Simon Marlow wrote: >> It would probably be better to return 0#/1# instead of a Bool from >> the comparison primops, because this would expose slightly more >> detail to the simplifier and might result in slightly better code in >> some cases (but no dramatic improvements). It would also let us >> remove a bit of complexity from the code generator. > > This seems like it could be nicely generalized such that all > enumeration types unbox to the unboxed integer of their offset. so > > data Perhaps = Yes | Maybe | No > > can unbox to an Int# with 0# == Yes 1# == Maybe and 2# == No. Yes, a strict enumeration should be implemented as an Int#, both in the strictness analyser and also when you {-# UNPACK #-} a constructor field. This is something we'd like to try, but haven't got around to it yet. Maybe a good bite-sized project for a budding GHC hacker? :-) > Then we get the Bool optimization for free. The original question was about the primitive comparisons, so I think we'd still have to change the types of these primitives. Furthermore we'd probably have to teach the compiler that the result of the comparison primops is compatible with a strict Bool. It wouldn't be entirely free. Cheers, Simon

2 1

RE: Bools are not unboxed
by Simon Marlow 05 Oct '04

05 Oct '04

On 03 October 2004 14:07, Tomasz Zielonka wrote: > Then I noticed the cause: > GHC.Prim.<# returns a boxed, heap allocated Bool, and so do other > primitive comparison operators. > > Would it be difficult to add Bool unboxing to GHC? > Maybe it would suffice to use preallocated False and True? Just to clarify a little more: although the raw primitive operations do appear to return fully boxed True & False values, in practice they rarely do, because the code genrator optimises case a >=# b of True -> e1 False -> e2 to if (a >=# b) { .. code for e1 ... } else { .. code for e2 .. } (well, more or less). Only if the result of the comparison is actually being returned from a function does it get turned into a real Bool. It would probably be better to return 0#/1# instead of a Bool from the comparison primops, because this would expose slightly more detail to the simplifier and might result in slightly better code in some cases (but no dramatic improvements). It would also let us remove a bit of complexity from the code generator. Cheers, Simon

2 1

RE: AIX 5.1L Build of GHC 6.2.1
by Simon Marlow 05 Oct '04

05 Oct '04

On 04 October 2004 17:19, John Goerzen wrote: > On 2004-10-02, John Goerzen <jgoerzen(a)complete.org> wrote: >> to help from people here, I have built a working GHC 6.2.1 for >> AIX5.1L. (The last GHC I could find for AIX was GHC 2.09!) > > As a follow-up question: what does it take to get this listed at > http://www.haskell.org/ghc/download_ghc_621.html? I bet there is > someone else out there that would find it useful. Done. Cheers, Simon

1 0