[m-rev.] For review: deconstruct non-canonical terms in pretty_printer.m

[Mark Brown]

On 08-Oct-2007, Ian MacLarty <maclarty at csse.unimelb.edu.au> wrote:
> On Mon, Oct 08, 2007 at 03:54:21PM +1000, Mark Brown wrote:
> > On 08-Oct-2007, Ralph Becket <rafe at csse.unimelb.edu.au> wrote:
> > > Index: library/pretty_printer.m
> > > ===================================================================
> > > RCS file: /home/mercury1/repository/mercury/library/pretty_printer.m,v
> > > retrieving revision 1.6
> > > diff -u -r1.6 pretty_printer.m
> > > --- library/pretty_printer.m	3 Sep 2007 16:41:41 -0000	1.6
> > > +++ library/pretty_printer.m	8 Oct 2007 04:05:09 -0000
> > > @@ -645,7 +645,18 @@
> > >          Doc = set_formatting_limit_correctly(!.Limit,
> > >              Formatter(Univ, ArgTypeDescs))
> > >        else
> > > -        deconstruct(univ_value(Univ), canonicalize, Name, _Arity, Args),
> > > +        % We justify this promise on the grounds that
> > > +        % (a) observers of views of non-canonical values should give
> > > +        % them the same denotation,
> > > +        % (b) practically it is far more useful to see the construction
> > > +        % of non-canonical values (e.g., when debugging programs), and
> > > +        % (c) propagating cc_multi all the way up into the interface could
> > > +        % make use of the pretty printer very awkward.
> > > +        %
> > > +        promise_equivalent_solutions [Name, Args] (
> > > +            deconstruct(univ_value(Univ), include_details_cc,
> > > +                Name, _Arity, Args)
> > > +        ),
> > 
> > In view of the followup discussion on the developers list, i think you
> > should:
> > 
> >     - Add the promise here, and add a comment to say that the promise is
> >       valid because of the way that we interpret equality on the doc type.
> > 
> >     - Document in the interface that the intended interpretation of equality
> >       on type doc is that docs are equal if they describe the same logical
> >       document, and in particular that docs created with format/1 are equal
> >       if the terms are equal.
> > 
> >     - Also document that we don't actually implement this version of
> >       equality, and enjoin users to avoid it.  It would help to give the
> >       example of two docs created from equal non-canonical terms being equal
> >       according to the intended interpretation, but failing a test
> >       unification.
> > 
> >     - Make format/8 cc_multi.  Use cc_multi_equal at an appropriate point.
> > 
> >     - I would suggest adding format_io/8, which is specialised to the io
> >       stream, and which is det.  This will need a promise too: document
> >       that this promise is safe because we can never test io streams for
> >       equality.
> > 
> >     - If you actually do need a string stream, we can discuss that next.
> > 
> 
> Isn't the above call to deconstruct inside the implementation of
> format/8?  If so why not just let the cc_multiness propogate up to
> format/8, instead of adding this promise here and then using
> cc_multi_equal in format/8?  From looking at pretty_printer.m it seems
> the only exported predicate that calls deconstruct is format/8, but
> perhaps I'm missing something?

No, you're right.  Now that I look at the implementation of format/1, it
seems that the implementation of equality is in fact correct according to
the above interpretation (or atleast, it is as correct as the implementations
of equality on the polymorphic terms that are passed to format/1 are).

So ignore my above advice.  I now think you should:

	- Change format/8 to format/9, by adding an extra parameter of type
	  noncanon_handling (like term_to_xml.write_xml_element_general),
	  which it passes down to deconstruct/5.  Give it different modes
	  for different values of the parameter.

	- Export format_cc/8 which is cc_multi, and calls format/9 with the
	  parameter include_details_cc.

	- Export format/8 which is det, which only operates on io streams,
	  and which calls format/8 inside promise_equivalent_solutions.

The question remains: did you actually need a det version operating on string
streams?

Cheers,
Mark.

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