[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: expose XHASH [patch]

From: Paul Pogonyshev
Subject: Re: expose XHASH [patch]
Date: Fri, 8 Apr 2016 18:08:41 +0200

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.


On 2 April 2016 at 13:52, Paul Pogonyshev <address@hidden> 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 <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]