[m-rev.] diff 1/3: Move pointer_equals/2 into the private_builtin module.

Julien Fischer jfischer at opturion.com
Sun Jun 30 17:45:06 AEST 2013


On Sun, 30 Jun 2013, Paul Bone wrote:

> On Sun, Jun 30, 2013 at 04:46:49AM +1000, Julien Fischer wrote:
>> On Fri, 28 Jun 2013, Paul Bone wrote:
>>
>>> My other two patches in this series are still okay, and the second one is
>>> still waiting for review.
>>>
>>> Move pointer_equals/2 into the private_builtin module.
>>>
>>> library/version_hash_table.m:
>>> library/private_builtin.m:
>>>    As above.
>>>
>>> library/private_builtin.m:
>>>    Adjust a comment to say that some predicates are implemented in the
>>>    normal way in this module.
>>> ---
>>> library/private_builtin.m    | 40 ++++++++++++++++++++++++++++++++++++++--
>>> library/version_hash_table.m | 30 +-----------------------------
>>> 2 files changed, 39 insertions(+), 31 deletions(-)
>>>
>>> diff --git a/library/private_builtin.m b/library/private_builtin.m
>>> index 1dd866d..cd3bffc 100644
>>> --- a/library/private_builtin.m
>>> +++ b/library/private_builtin.m
>>> @@ -23,8 +23,9 @@
>>> % does not get included in the Mercury library reference manual.
>>> %
>>> % Many of the predicates defined in this module are builtin - they do not have
>>> -% definitions because the compiler generates code for them inline. Some others
>>> -% are implemented in the runtime.
>>> +% definitions because the compiler generates code for them inline. A second
>>> +% group are implemented in the runtime.  Whilst a third group are
>>> +% implemented normally in this module.
>>> %
>>> %-----------------------------------------------------------------------------%
>>> %-----------------------------------------------------------------------------%
>>> @@ -118,6 +119,11 @@
>>>     %
>>> :- pred typed_compare(comparison_result::uo, T1::in, T2::in) is det.
>>>
>>> +    % True if the two objects have the same pointer value in the underlying
>>> +    % implementation.
>>> +    %
>>
>> I suggest something along the lines of:
>>
>>      True iff the the two terms occupy the same address in memory.
>>      This is useful as a cheap test of equality when implmenting
>>      user-defined equality.
>
> Okay.
>
>> (Can I object to the name pointer_equals on the grounds that only a
>> minority of our current target languages actually have a notion of
>> pointers?  ;-) )
>
> It this a joke based on my clauses/alternatives bug?

No, it's a way of wondering whether there is a more target language
agnostic name for this.

> Note that even in Java the concept of 'pointer equality' is still present
> even though they don't have pointers.  In a language with mutable data this
> abstraction will always leak.
>
>>> +:- pred pointer_equals(T::in, T::in) is semidet.
>>> +
>>
>> I suggest s/pointer_equals/pointer_equal/
>>
>
> Okay.
>
>> (Likewise, version_hash_table.equals/2 should really have been called
>> version_hash_table.equal/2 for the purposes of consistency with the
>> rest of the stdlib.)
>
> It's probably not too late to rename those without breaking much code and
> using the usual method of deprecating the old names.

Renaming them now is fine I think.

Cheers,
Julien.





More information about the reviews mailing list