On 26/08/2013, at 9:58 PM, David Matthews <[email protected]> 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. _______________________________________________ polyml mailing list [email protected] http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
