[isabelle-dev] text_fold
Dmitriy Traytel
traytel at in.tum.de
Mon Feb 10 14:47:13 CET 2014
Am 10.02.2014 14:18, schrieb Makarius:
> On Mon, 25 Nov 2013, Dmitriy Traytel wrote:
>
>> Am 23.11.2013 19:42, schrieb Makarius:
>>> On Mon, 28 Oct 2013, Dmitriy Traytel wrote:
>>>
>>> > Concerning the error messages: at least you should always get >
>>> strictly more information than without coercion inference (i.e. the
>>> > error message of the standard type-inference will always come
>>> first, > only then coercion inference will give additional hints).
>>> Of course, > the additional information can be distracting---maybe
>>> it should be > hidden in a popup or so).
>>>
>>> Concerning the "popup or so" you could experiment with
>>> Pretty.text_fold (although the fold will be always open by default in
>>> currently published Isabelle versions).
>>>
>>> The Isabelle Pretty module started out as implementation of
>>> Oppen-style pretty-printing by Larry Paulson, but it has acquired more
>>> and more logical markup facilities over the years (e.g. Pretty.markup,
>>> Pretty.paragraph, Pretty.item).
>>>
>>> The full potential of this is still unused. (Display of advanced
>>> markup
>>> requires a proper PIDE front-end.)
>> Thanks for the hint. There result of my experiments are in the
>> development repository (2bbcbf8cf47e).
>
> This thread that originated from isabelle-users is still somehow open,
> see
> also
> https://lists.cam.ac.uk/pipermail/cl-isabelle-users/2013-October/msg00183.html
>
>
> In Isabelle/35354009ca25 I have sorted out some misunterstandings
> about Markup and Pretty.
>
> Pretty.text_fold is fine if you assemble pretty trees, but having
> already formatted strings means you can't go through a pretty tree
> again: Pretty.str assumes an atomic argument. (There used to be a
> mostly forgotten ML naming convention, to use "str" for unformatting
> strings and "string" for formatted ones, cf. Pretty.str vs.
> Pretty.str_of vs. Pretty.string_of.)
I see. Thanks for repairing this.
>
> The reason why that API mismatch was not immediately detected is that
> Isabelle/Scala does its own rendering of pretty trees, from the
> overall output produced by the prover. This occasionally hides
> Isabelle/ML programming mistakes concerning Pretty.T, until someone
> uses a historical Isabelle front-end, or does Isabelle latex pretty
> printing.
>
>
> Using Markup.text_fold and already formatted strings in 35354009ca25
> makes the situation formally more correct, and simpler. What I can't
> test here are all the individual error messages, because I don't know
> how to provoke them. I've merely done a sanity check with the
> original example from
> https://lists.cam.ac.uk/pipermail/cl-isabelle-users/2013-October/msg00208.html
There are (commented) test cases for some of them in
~~/src/HOL/ex/Coercion_Examples.thy . I've checked those now and they
seem fine.
Dmitriy
More information about the isabelle-dev
mailing list