On 26/08/2013 13:09, Michael Norrish wrote:
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.
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
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
