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

Ralph Becket rafe at csse.unimelb.edu.au
Tue Aug 15 11:27:32 AEST 2006


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.

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



More information about the reviews mailing list