[m-rev.] For review: pretty print c_pointers as addresses

[Ian MacLarty]

On Tue, Aug 15, 2006 at 11:27:32AM +1000, Ralph Becket wrote:
> Mark Brown, Monday, 14 August 2006:
> > On 14-Aug-2006, Ralph Becket <rafe at csse.unimelb.edu.au> wrote:
> > > +
> > > +% This really should be impure...
> > > +%
> > > +:- func c_pointer_addr(T) = int.
> > > +
> > > +:- pragma foreign_proc("C",
> > > +    c_pointer_addr(X::in) = (Addr::out),
> > > +    [promise_pure, will_not_call_mercury, will_not_modify_trail],
> > > +"
> > > +    Addr = (MR_Integer) X;
> > > +").
> > 
> > If something really should be impure, then don't promise that it is pure.
> > But why should this function be impure?
> 
> I believe that foreign types also appear as c_pointers in deconstruct.
> If a foreign type has user defined equality then c_pointer_addr provides
> a way of distinguishing between otherwise semantically equal values.
> 
> This is an issue with the pretty printer in general, however: it is not
> aware of user defined equality, but it does expose the representation of
> values.
> 
> Pragmatically speaking, making the pretty printer cc_multi would be very
> awkward for users.
> 

May I suggest the following approach:

1.  Add a new function symbol to the doc type, say 'ADDR' that takes a
    univ argument.

2.  Modify generic_term_to_doc so that it returns this function symbol
    with univ(X) as its argument instead of calling c_pointer_addr/1.
    This means to_doc can be legitamitely det, where with your diff
    it is actually cc_multi.  If you lie and make it det then to_doc(X)
    = to_doc(Y) could fail even though X = Y.

3.  Modify pprint.write to call c_pointer_addr when it encounters an 
    'ADDR' function symbol.  You could even introduce a cc_multi version
    of pprint.write that calls c_pointer_addr and a det version that
    just prints <<c_pointer>> or <<foreign>>.  However I have no
    objections to making the version that calls c_pointer_addr det.
    I have no objections, because it takes the IO state and as I see
    it the IO state contains the heap (and therefore enough information to
    deterministically calculate the representation of the value). 
    Anyway you can never backtrack over calls that take the IO state,
    so whether its cc_multi or det makes no practical difference in this
    case.

Ian.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------