On 23/08/2013 13:39, Michael Norrish wrote:
First a feature request: could we please have a version of the basic function for adding a string that takes an optional argument indicating how wide the Oppen algorithm should treat the string? At the moment, the infrastructure just seems to count the bytes emitted, and this causes premature line breaks if I'm emitting UTF-8 characters. Of course, if the infrastructure could magically become aware of UTF-8 or wide characters that would solve this particular use-case, but I'd still ask for this feature because I also want to emit byte-sequences that are terminal control codes. (On appropriate terminals, I emit vt100 codes to colour certain substrings, for example.)
Can you explain exactly how you use the resulting "pretty" structure. Do you have your own pretty printer or printing functions? If so you can always use PolyML.ContextProperty to pass your own data around. That's probably the way to do colouring rather than to use control codes within the strings.
Secondly, 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.
Exactly how big is the Pretty structure likely to be? Is it very likely to survive a garbage collection? If you build the Pretty structure and then immediately display it, it is very likely that it will be collected away. There's then no real difference when compared with processing it lazily. The cost of allocation will be the same either way.
David