Ian

What's the deal with LazyUniqFM?  It is imported all over the place -- but 
actually, UniqFM is lazy.  Relevant patches are below (ages ago).

Currently I think we may be adding a redundant 'Lazy' wrapper around every 
element in a UniqFM, because many things that looks as if they are called 
"UniqFM" are actually "LazyUniqFM.UniqFM".  Not good!

I suggest we nuke the module LazyUniqFM altogether.  If we want a strict one at 
some later point we can re-do it.  What do you think?

Simon

Mon Feb 25 17:13:05 GMT 2008  Ian Lynagh <[email protected]>
  * Make UniqFM non-strict again while we work out what we're doing.
  This "fixes" the very-slow problem we have when compiling dictionaries.

    M ./compiler/utils/UniqFM.lhs -1 +1

Wed Feb  6 14:16:20 GMT 2008  Ian Lynagh <[email protected]>
  * Make UniqFM strict in its elements

    M ./compiler/basicTypes/NameEnv.lhs -1 +1
    M ./compiler/basicTypes/VarEnv.lhs -1 +1
    A ./compiler/utils/LazyUniqFM.lhs
    M ./compiler/utils/UniqFM.lhs -2 +2


| -----Original Message-----
| From: [email protected] [mailto:[email protected]] On Behalf Of Max
| Bolingbroke
| Sent: 30 October 2009 20:47
| To: Simon Peyton-Jones
| Cc: Roman Leshchinskiy; Tristan Allwood; Manuel M T Chakravarty
| Subject: Re: SpecConstr
| 
| 2009/10/30 Simon Peyton-Jones <[email protected]>:
| > | I still don't understand the difference between UniqFM.UniqFM and
| > | LazyUniqFM.UniqFM. (AnnEnv uses the latter). Is this left over from an
| > | experiment with making UniqFMs strict?
| >
| > Max, Tristan?
| 
| I'm afraid that I have absolutely no idea. I don't think the
| functionality would change if you used UniqFM instead. I certainly had
| nothing to do with the UniqFM implementation :)
| 
| Cheers,
| Max

_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to