Dictionaries and full laziness transformation

Hi, I'm using GHC 7.0.1. I found that recursive overloaded functions tend to leak memory when compiled with full-laziness optimization on. Here is a simple case. -- TestSub.hs {-# LANGUAGE BangPatterns #-} module TestSub where {-# NOINLINE factorial #-} factorial :: (Num a) = a - a - a

Behavior of the -H RTS option, possible doc/impl mismatch

Hi, I have questions regarding to the -H RTS option. I use GHC 7.0.1 on Linux x86-64. The User's Guide says: -Hsize [Default: 0] This option provides a “suggested heap size” for the garbage collector. The garbage collector will use about this much memory until the program residency grows and

Re: Behavior of the -H RTS option, possible doc/impl mismatch

Hi Simon, Thank you for explanation. I think I now understand why -H behaves that way. 2011/2/17 Simon Marlow marlo...@gmail.com: Anyway, with -N2 and above I don't recommend using -H, generally I've found it results in lower performance.  -A1m might be good if your CPUs have larger L2

Why are arrays retainers?

Hi, Recently I was surprised to see that GHC's retainer profiler treated boxed arrays as retainer objects. Why are they considered retainers? I was using the +RTS -hr to figure out why there were a lot of objects of type T in the heap. However, the T objects happened to be in a HashMap (from the

Re: Why are arrays retainers?

I see. Thank you very much for your explanation and fixing. - Akio ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Race-condition in alternative 'System.Timeout.timeout' implementation

I accidentally replied to Herbert privately. I'm forwarding the message to the list. - Takano Akio -- Forwarded message -- From: Akio Takano tkn.a...@gmail.com Date: Mon, Feb 25, 2013 at 6:15 PM Subject: Re: Race-condition in alternative 'System.Timeout.timeout' implementation

Re: Race-condition in alternative 'System.Timeout.timeout' implementation

Hi Bertram, Thank you for the explanation. My previous attempt obviously suffers from the race condition you mention. However it still seems to be possible to implement a compromise, using both the IO manager and a new thread, i.e. forking only when the computation is being timed out. The

'interrupted' when exiting

Hi, If I compile and run the attached program in the following way, it crashes on exit: $ ghc -threaded thr_interrupted.hs $ ./thr_interrupted thr_interrupted: Main_dtl: interrupted This is particularly bad when profiling, because the program terminates before writing to the .prof file. Is

Re: 'interrupted' when exiting

[Resending to the list] Thank you for your explanation. On Mon, Mar 4, 2013 at 10:32 PM, Simon Marlow marlo...@gmail.com wrote: The issue is this: when the main thread exits, the RTS starts shutting down, and it kills all the other threads. If any of these threads were the result of an

A type not inferred with RankNTypes

Hi, The attached program does not typecheck if I don't include a type signature for 'bar' (the line C). I can't figure out if this is a limitation in the type system or a bug in GHC. One thing that confuses me is that replacing the line (B) with (A) makes the program typecheck. Could anyone help

New restrictions to open type families

Hi, Looking at the ticket [1] and a draft paper linked there [2] , I learned that in GHC 7.8, two type family instances are considered overlapping if the argument lists unify in the presence of infinite types. My question is, why is this restriction necessary? A footnote in the paper states that

Fwd: New restrictions to open type families

(I forgot to send to the list, trying again) Thank you very much for your detailed explanation! On Fri, Aug 23, 2013 at 1:24 PM, Richard Eisenberg e...@cis.upenn.eduwrote: This is a good question. Happily, there are at least two decent answers. 1) We're not sure that this problem cannot

Re: New restrictions to open type families

...@haskell.org] *On Behalf Of *Akio Takano *Sent:* 23 August 2013 11:35 *To:* glasgow-haskell-users@haskell.org; Richard Eisenberg *Subject:* Fwd: New restrictions to open type families ** ** (I forgot to send to the list, trying again) Thank you very much for your detailed

Giving function a larger arity

Hi, I've been trying to get a certain type of programs compiled into efficient code, but I haven't been able to find a good way to do it, so I'm asking for help. Specifically, it involves a library that defines a newtype whose representation is a function. Attached Lib.hs is an example of such a

Re: Giving function a larger arity

Of *Akio Takano *Sent:* 11 November 2013 09:19 *To:* glasgow-haskell-users@haskell.org *Subject:* Giving function a larger arity Hi, I've been trying to get a certain type of programs compiled into efficient code, but I haven't been able to find a good way to do it, so I'm asking for help

Re: Optimization of IORefs and STRefs - comparison to g++

Hi Mateusz, IORef and STRef are boxed references. That is, they are a mutable cell that contains a pointer to some immutable Haskell value. When you increment a (STRef Int), you first dereference the pointer, allocate a new immutable heap object to represent the new integer value, then mutate the

Re: Proposal: ArgumentDo

Hi Christian, On 6 July 2016 at 16:08, C Maeder wrote: > Hi, > > allowing group A constructs (do, case, ...) and group B constructs (\, > let, if, ...) as parts of functions application (fexp) without extra > parentheses looks natural to me. The current state is an artificial

Re: Proposal: ArgumentDo

Hi Ryan, On 7 July 2016 at 19:40, Ryan Trinkle wrote: > I'm very on the fence on this topic, but one point i haven't seen mentioned > is the influence of syntax highlighting on this. My guess is that I would > like this extension when I have syntax highlighting available

Re: Proposal: ArgumentDo

Hi Henrik, On 9 July 2016 at 09:46, Henrik Nilsson wrote: > Hi all, > > On 07/09/2016 08:09 AM, C Maeder wrote: >> >> The asymmetry that you mention is already apparent for (Haskell98) infix >> expressions, i.e. when "composing" lambda- or if-expression: >> >>

ArgumentDo proposal updated

Hi glasgow-haskell-users, Thank you for all the feedback to the ArgumentDo proposal. Following the discussion, I made changes to the proposal and updated the wiki page [0]. Now the proposed grammar is greatly simplified: it doesn't add a new non-terminal anymore, indeed it removes one instead.

Proposal: ArgumentDo

Hi glasgow-haskell-users, I have written a wiki page about a proposed extension called ArgumentDo. It's a small syntactic extension that allows "do" expressions, lambdas and a few other kinds of expressions to be used as function arguments, without parentheses.