On 26/08/2013, at 9:58 PM, David Matthews <David.Matthews at prolingua.co.uk> wrote:
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.
Well, if I want to exploit the ContextProperty, don't I then have to write my own versions of PolyML.prettyPrint and PolyML.addPrettyPrinter, implementing Oppen all over again? Of course, in the case of addPrettyPrinter, I can't write that at all because of its magic polymorphism. I'm keen to have the standard REPL give me back pretty-printed values, complete with suitable contextual annotations, but I then have to rely on the built-in implementation of Oppen.
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.
Yes. I think Makarius has persuaded me that I don't need to worry too much about this.
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.