On 26/08/2013, at 9:08 PM, Makarius <[email protected]> wrote: > On Fri, 23 Aug 2013, Michael Norrish wrote: > >> I'm a bit concerned that the new, recommended approach to pretty-printing >> requires me to translate into the Pretty structure before anything happens. >> I'd feel more comfortable if the structure could be produced and consumed >> lazily so that I don't end up with a large (strictly unnecessary) Pretty >> structure in memory. > > What is "large" here? 64KB? 64MB? 64GB? As far as I know, the original Oppen > paper was optimizing for some situation < 64KB. BTW Poly/ML does implicit > sharing of subtree structures whenever you run short of heap space.
It's certainly true that I may be wincing unnecessarily about memory. Nonetheless, there will be both a memory *and* time cost with this approach that Haskell, for example, probably wouldn't incur. (I believe Haskell's laziness (and deforestation optimisations?) should in theory ensure that the intermediate data structure doesn't get built or really even traversed. With what we have in SML, we will end up traversing the original term, building something almost isomorphic to that original, and then traversing that copy to actually do the printing. Two traversals, a whole bunch of allocations eventually followed by collections, and then the actual printing. Probably insignificant but it makes me wince. Anyway, being able to lie about a string's size for the benefit of the Oppen algorithm is definitely more important. Michael ________________________________ The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments. _______________________________________________ polyml mailing list [email protected] http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
