Re: expose XHASH [patch]

[Paul Pogonyshev <pogonyshev@gmail.com>]

Ping about the patch. I have no write access to the repository, so I
cannot install it myself.

Also, would be nice if someone installed maphash documentation patch.

Paul

On 2 April 2016 at 13:52, Paul Pogonyshev <pogonyshev@gmail.com> wrote:
> Second patch iteration, taking into account all comments by Paul Eggert.
>
> Paul
>
>
>
>
> * src/fns.c (Fsxhash_eq, Fsxhash_eql): New functions.
>
> * doc/lispref/hash.texi (Defining Hash): Document 'sxhash-eq' and 'sxhash-eql'.
>
> * etc/NEWS: Mention 'sxhash-eq' and 'sxhash-eql'.
>
> On 1 April 2016 at 11:44, Paul Pogonyshev <pogonyshev@gmail.com> wrote:
>> Paul Eggert wrote:
>>> The documentation for the new function should be next to the documentation for sxhash.
>>
>> I just skipped all the examples related to 'sxhash'. But I don't mind.
>>
>>> Shouldn't we expose hashfn_eq, not XHASH? After all, (make-hash-table :test 'eq ...) uses hashfn_eq, not XHASH.
>>
>> Probably you are right. I don't know the internal details well enough
>> to comment on this.
>>
>>> Should we also expose hashfn_eql, which is what make-hash-table uses by default? Or is that a waste of time since hashfn_eql is the default?
>>
>> I'd say expose it too, at least for the cases of composite hashing as
>> in my example.
>>
>>> Not sure I like the name xhash. Maybe sxhash-eq instead? That would let us use the name sxhash-eql for hashfn_eql.
>>
>> I tried to keep familiar names (at least for those who work on C
>> code), but if we change that to 'hashfn_eq' and additionally expose
>> something for 'eql', I guess your idea is better.
>>
>> I'll wait if more comments on these points appear before creating next
>> patch iteration.
>>
>> Paul