[m-dev.] Pretty printing non-canonical types

[Mark Brown]

On 05-Oct-2007, Ralph Becket <rafe at csse.unimelb.edu.au> wrote:
> I'm trying to debug the new LP interface.
> The debugger uses the new pretty_printer module.
> The pretty_printer module uses deconstruct(..., canonicalize, ...) to
> decide what to do with each subterm.
> The canonicalize form just returns the type name for non-canonical
> values, rather than any structural information.
> This is most unhelpful for debugging.
> Using deconstruct(..., include_details_cc, ...) does the right thing,
> but is cc_multi.
> I want the include_details_cc behavious, but I don't want to propagate
> the cc_multi aspect into the interface to the pretty printer, because
> that could make using it rather awkward in many circumstances.
> 
> Is there any objection to me using include_details_cc wrapped in a
> promise_equivalent_solutions scope, even though the promise is a lie?

As long as it's far enough up, it should be okay.  That is, at the level
of calling deconstruct you can't really say that the different constructors
and arguments returned are equivalent.  But it think it is okay to produce
two different docs that, when rendered on the screen, would be interpreted
equivalently, and promise that they are equivalent.

If users aren't prepared to interpret the docs this way, they should provide
user-defined formatting functions that will make sure that the docs really
are canonical.  (We should provide such functions for all non-canonical
types in the standard library so that, for example, sets are rendered the
same way regardless of representation.)

Cheers,
Mark.

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------