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

[Mark Brown]

On 15-Aug-2006, Ralph Becket <rafe at csse.unimelb.edu.au> 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've just realised that the argument to this function can be _any_ type,
not just c_pointer.  In that case, yes, this function is impure (and poorly
named, might I add).

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

Whereas lying about its purity is okay?  :-O

In any case, why does deconstruct return "<<c_pointer>>" for c_pointers?
Why not a string representation of the address?

(Also, the behaviour for c_pointers and foreign types should be documented
in the comments above functor/4.)

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