On 26/08/2013 13:09, Michael Norrish wrote:
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.
You would have to write your own version of PolyML.prettyPrint and your own REPL to use it. Neither of these are very complicated and I can point you at the existing code as a basis. PolyML.print and PolyML.makestring, if you actually use them, would use the original pretty-printer. You would not need your own PolyML.addPrettyPrinter. That just adds a function that generates a "pretty" data structure to a particular type and doesn't care whether the data structure includes your own ContextProperty values.
I can see the advantage of changing PrettyString to include an explicit length; it's just that doing that would involve changes to nearly all the existing pretty-print functions. That's not just in Poly/ML code but any user code as well. It might be simpler to add a new constructor to the pretty datatype. I'll give it some thought but just at the moment I want to get the current version released before making any more changes.
David