Really, the patch is fine just as it is probably. Earlier me and Herbert were wondering if anyone would actually be affected by the O(n) lookup, but the only reason *I* really cared to know that is just so we don't have to inline part of `containers` if we don't have to. But at the end of the day it's barely 100 lines of extra code. So maybe not that big a deal (but kinda lame).
To be on the conservative side and not regress (and this could easily be considered a regression from a performance POV) we can certainly just commit this and see if we can make the code smaller later, I'd say. On Fri, Apr 25, 2014 at 8:33 AM, Richard Eisenberg <[email protected]> wrote: > > On Apr 25, 2014, at 4:16 AM, Herbert Valerio Riedel <[email protected]> > wrote: > >> Hello Richard, >> >> On 2014-04-24 at 15:04:55 +0200, Richard Eisenberg wrote: >>> That map seems to store the set of variables during printing TH, for >>> the purposes of disambiguating identifiers with the same name but >>> different uniques. If blatting out a whole lot of program text, I >>> could imagine the Map getting somewhat sizeable. >> >> When does printing TH actually occur? If it doesn't occur during regular >> compilation, do we ever need to pretty print large amounts of TH? > > I guess it depends on who “we” are. In the process of routine TH hackery, I > would say that printing is uncommon -- normally the TH is processed and then > just spliced, without user interaction. But, I can conceive of a library that > does some processing and then prints. > >> >>> But, it seems to only need the lookup and insert operations... > > Good observation. > >> >> actually, it uses a specific combination of lookup+insert, so that it >> would suffice to have the single operation in the style of Python's >> dict.setdefault(), i.e. >> >> findWithDefaultInsert :: Ord k => k -> v -> Map k v -> (v, Map k v) >> findWithDefaultInsert k default m >> | Just v <- Map.lookup k m = (v, m) >> | otherwise = default `seq` (default, Map.insert k default m) >> >>> is there a simpler data structure that has only these operations >>> efficiently? >> > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
