unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* expose XHASH [patch]
@ 2016-03-31 19:29 Paul Pogonyshev
  2016-03-31 21:52 ` Stefan Monnier
  2016-03-31 22:43 ` Paul Eggert
  0 siblings, 2 replies; 12+ messages in thread
From: Paul Pogonyshev @ 2016-03-31 19:29 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

Suppose you need a hash table with the following Lisp structures
as keys:

    (NAME . [VECTOR-OF-ATTRIBUTES])

where NAME is a string.  The structures are supposed to be
compared in a "mixed" way: NAME with 'equal' (or 'string='), but
VECTOR-OF-ATTRIBUTES should be compared with 'eq', i.e. by
identity.

Now, while defining test function for 'define-hash-table-test' is
not a problem, hash is problematic.  While 'sxhash' _will_ work,
it is wasteful, since it computes needless information about
vector contents.  Excluding vector from the hash completely is
also legal, but might considerably worsen hash table performance.

Attached trivial patch just exposes internally used XHASH(),
which fully suits this usecase.  E.g. with it you could

    (defun my-funny-hash (structure)
      (+ (sxhash (car structure)) (* 13 (xhash (cdr structure)))))

Please don't write that the example is stupid, it is just an
example after all.

Paul



* src/fns.c (Fxhash): New function.

* doc/lispref/hash.texi (Defining Hash): Document 'xhash'.

* etc/NEWS: Mention 'xhash'.

[-- Attachment #2: xhash.diff --]
[-- Type: text/plain, Size: 2153 bytes --]

diff --git a/doc/lispref/hash.texi b/doc/lispref/hash.texi
index 8389c21..6ee18d6 100644
--- a/doc/lispref/hash.texi
+++ b/doc/lispref/hash.texi
@@ -307,6 +307,16 @@ and equal-looking objects are considered the same key.
 (make-hash-table :test 'contents-hash)
 @end example
 
+@defun xhash obj
+This function returns a hash code for Lisp object @var{obj}.  Its
+result reflects identity of @var{obj}, but not its contents.
+
+If two objects @var{obj1} and @var{obj2} are @var{eq}, then
+@code{(xhash @var{obj1})} and @code{(xhash @var{obj2})} are the same
+integer.
+@end defun
+
+
 @node Other Hash
 @section Other Hash Table Functions
 
diff --git a/etc/NEWS b/etc/NEWS
index 66777e9..146c756 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -208,6 +208,12 @@ permanent and documented, and may be used by Lisp programs.  Its value
 is a list of currently open parenthesis positions, starting with the
 outermost parenthesis.
 
++++
+** New function 'xhash' returns identity hash code of a Lisp object.
+If two objects are 'eq', then the result of 'xhash' on them will be
+the same.  In other words, this function to 'eq' is the same as
+'sxhash' is to 'equal'.
+
 \f
 * Changes in Emacs 25.2 on Non-Free Operating Systems
 
diff --git a/src/fns.c b/src/fns.c
index 114a556..a1cf2b1 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -4449,6 +4449,16 @@ sxhash (Lisp_Object obj, int depth)
  ***********************************************************************/
 
 
+DEFUN ("xhash", Fxhash, Sxhash, 1, 1, 0,
+       doc: /* Compute identity hash code for OBJ and return it as integer.
+In other words, hash codes of two non-`eq' lists will be (most likely)
+different, even if the lists contain the same elements. */)
+  (Lisp_Object obj)
+{
+  return make_number (XHASH (obj));
+}
+
+
 DEFUN ("sxhash", Fsxhash, Ssxhash, 1, 1, 0,
        doc: /* Compute a hash code for OBJ and return it as integer.  */)
   (Lisp_Object obj)
@@ -5067,6 +5077,7 @@ syms_of_fns (void)
   DEFSYM (Qkey_or_value, "key-or-value");
   DEFSYM (Qkey_and_value, "key-and-value");
 
+  defsubr (&Sxhash);
   defsubr (&Ssxhash);
   defsubr (&Smake_hash_table);
   defsubr (&Scopy_hash_table);

^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: expose XHASH [patch]
  2016-03-31 19:29 expose XHASH [patch] Paul Pogonyshev
@ 2016-03-31 21:52 ` Stefan Monnier
  2016-03-31 22:43 ` Paul Eggert
  1 sibling, 0 replies; 12+ messages in thread
From: Stefan Monnier @ 2016-03-31 21:52 UTC (permalink / raw)
  To: emacs-devel

> Please don't write that the example is stupid, it is just an
> example after all.

FWIW, I have bumped into various cases where I also needed to define
a hash for an equality function that's defined for example as (and (eq
(car x) (car y)) (eq (cdr x) (cdr y))).  Worse yet: you say that "sxhash
_will_ work" but in reality it won't if the objects are later modified
by side-effects.

See for example:

           (cl--generic-with-memoization
               ;; FIXME: Since the fields of `generic' are modified, this
               ;; hash-table won't work right, because the hashes will change!
               ;; It's not terribly serious, but reduces the effectiveness of
               ;; the table.
               (gethash (cons generic methods)
                        cl--generic-combined-method-memoization)

from cl-generic.el.  I wrote "It's not terribly serious", but IIRC there
can be cases where it causes real problems.

So a big "yes please" from me.


        Stefan




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: expose XHASH [patch]
  2016-03-31 19:29 expose XHASH [patch] Paul Pogonyshev
  2016-03-31 21:52 ` Stefan Monnier
@ 2016-03-31 22:43 ` Paul Eggert
  2016-04-01  9:44   ` Paul Pogonyshev
  1 sibling, 1 reply; 12+ messages in thread
From: Paul Eggert @ 2016-03-31 22:43 UTC (permalink / raw)
  To: Paul Pogonyshev, emacs-devel

On 03/31/2016 12:29 PM, Paul Pogonyshev wrote:
> Attached trivial patch just exposes internally used XHASH(),
> which fully suits this usecase.

Thanks, I like the overall idea but have some quibbles about the details.

The documentation for the new function should be next to the 
documentation for sxhash.

Shouldn't we expose hashfn_eq, not XHASH? After all, (make-hash-table 
:test 'eq ...) uses hashfn_eq, not XHASH.

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?

Not sure I like the name xhash. Maybe sxhash-eq instead? That would let 
us use the name sxhash-eql for hashfn_eql.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: expose XHASH [patch]
  2016-03-31 22:43 ` Paul Eggert
@ 2016-04-01  9:44   ` Paul Pogonyshev
  2016-04-02 11:52     ` Paul Pogonyshev
  0 siblings, 1 reply; 12+ messages in thread
From: Paul Pogonyshev @ 2016-04-01  9:44 UTC (permalink / raw)
  To: Paul Eggert; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: expose XHASH [patch]
  2016-04-01  9:44   ` Paul Pogonyshev
@ 2016-04-02 11:52     ` Paul Pogonyshev
  2016-04-08 16:08       ` Paul Pogonyshev
  0 siblings, 1 reply; 12+ messages in thread
From: Paul Pogonyshev @ 2016-04-02 11:52 UTC (permalink / raw)
  To: Paul Eggert; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]

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

[-- Attachment #2: sxhash-eq[l].diff --]
[-- Type: text/plain, Size: 3827 bytes --]

diff --git a/doc/lispref/hash.texi b/doc/lispref/hash.texi
index 8389c21..a197399 100644
--- a/doc/lispref/hash.texi
+++ b/doc/lispref/hash.texi
@@ -273,13 +273,34 @@ This function returns a hash code for Lisp object @var{obj}.
 This is an integer which reflects the contents of @var{obj}
 and the other Lisp objects it points to.
 
-If two objects @var{obj1} and @var{obj2} are equal, then @code{(sxhash
-@var{obj1})} and @code{(sxhash @var{obj2})} are the same integer.
+If two objects @var{obj1} and @var{obj2} are @code{equal}, then
+@code{(sxhash @var{obj1})} and @code{(sxhash @var{obj2})} are the same
+integer.
+
+If the two objects are not @code{equal}, the values returned by
+@code{sxhash} are usually different, but not always; once in a rare
+while, by luck, you will encounter two distinct-looking objects that
+give the same result from @code{sxhash}.
+@end defun
+
+@defun sxhash-eq obj
+This function returns a hash code for Lisp object @var{obj}.  Its
+result reflects identity of @var{obj}, but not its contents.
+
+If two objects @var{obj1} and @var{obj2} are @code{eq}, then
+@code{(xhash @var{obj1})} and @code{(xhash @var{obj2})} are the same
+integer.
+@end defun
+
+@defun sxhash-eql obj
+This function returns a hash code for Lisp object @var{obj} suitable
+for @code{eql} comparison.  I.e. it reflects identity of @var{obj}
+except for the case where the object is a float number, in which case
+hash code is generated for the value.
 
-If the two objects are not equal, the values returned by @code{sxhash}
-are usually different, but not always; once in a rare while, by luck,
-you will encounter two distinct-looking objects that give the same
-result from @code{sxhash}.
+If two objects @var{obj1} and @var{obj2} are @code{eql}, then
+@code{(xhash @var{obj1})} and @code{(xhash @var{obj2})} are the same
+integer.
 @end defun
 
   This example creates a hash table whose keys are strings that are
diff --git a/etc/NEWS b/etc/NEWS
index 726b4b9..2d91166 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -208,6 +208,12 @@ permanent and documented, and may be used by Lisp programs.  Its value
 is a list of currently open parenthesis positions, starting with the
 outermost parenthesis.
 
++++
+** New functions 'sxhash-eq' and 'sxhash-eql' return hash codes of a
+Lisp object suitable for use with 'eq' and 'eql' correspondingly.  If
+two objects are 'eq' ('eql'), then the result of 'sxhash-eq'
+('sxhash-eql') on them will be the same.
+
 \f
 * Changes in Emacs 25.2 on Non-Free Operating Systems
 
diff --git a/src/fns.c b/src/fns.c
index 114a556..825e443 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -4457,6 +4457,25 @@ DEFUN ("sxhash", Fsxhash, Ssxhash, 1, 1, 0,
   return make_number (hash);
 }
 
+DEFUN ("sxhash-eq", Fsxhash_eq, Ssxhash_eq, 1, 1, 0,
+       doc: /* Compute identity hash code for OBJ and return it as integer.
+In other words, hash codes of two non-`eq' lists will be (most likely)
+different, even if the lists contain the same elements. */)
+  (Lisp_Object obj)
+{
+  return make_number (hashfn_eq (NULL, obj));
+}
+
+DEFUN ("sxhash-eql", Fsxhash_eql, Ssxhash_eql, 1, 1, 0,
+       doc: /* Compute identity hash code for OBJ and return it as integer.
+In comparison to `sxhash-eq', it is also guaranteed that hash codes
+of equal float numbers will be the same, even if the numbers are not
+the same Lisp object. */)
+  (Lisp_Object obj)
+{
+  return make_number (hashfn_eql (NULL, obj));
+}
+
 
 DEFUN ("make-hash-table", Fmake_hash_table, Smake_hash_table, 0, MANY, 0,
        doc: /* Create and return a new hash table.
@@ -5068,6 +5087,8 @@ syms_of_fns (void)
   DEFSYM (Qkey_and_value, "key-and-value");
 
   defsubr (&Ssxhash);
+  defsubr (&Ssxhash_eq);
+  defsubr (&Ssxhash_eql);
   defsubr (&Smake_hash_table);
   defsubr (&Scopy_hash_table);
   defsubr (&Shash_table_count);

^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: expose XHASH [patch]
  2016-04-02 11:52     ` Paul Pogonyshev
@ 2016-04-08 16:08       ` Paul Pogonyshev
  2016-04-08 18:10         ` Stefan Monnier
  0 siblings, 1 reply; 12+ messages in thread
From: Paul Pogonyshev @ 2016-04-08 16:08 UTC (permalink / raw)
  To: Paul Eggert; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: expose XHASH [patch]
  2016-04-08 16:08       ` Paul Pogonyshev
@ 2016-04-08 18:10         ` Stefan Monnier
  2016-04-08 18:37           ` Paul Pogonyshev
  0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2016-04-08 18:10 UTC (permalink / raw)
  To: emacs-devel

>> * src/fns.c (Fsxhash_eq, Fsxhash_eql): New functions.

It might make sense to rename sxhash to sxhash-equal for consistency.


        Stefan




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: expose XHASH [patch]
  2016-04-08 18:10         ` Stefan Monnier
@ 2016-04-08 18:37           ` Paul Pogonyshev
  2016-04-08 18:44             ` Stefan Monnier
  0 siblings, 1 reply; 12+ messages in thread
From: Paul Pogonyshev @ 2016-04-08 18:37 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

On 8 April 2016 at 20:10, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> * src/fns.c (Fsxhash_eq, Fsxhash_eql): New functions.
>
> It might make sense to rename sxhash to sxhash-equal for consistency.

Well, I don't know, it's a functions that have existed for a good
amount of time already. And also having some parallel in common lisp,
for example. Or do you mean like renaming, but making `sxhash' an
alias for `sxhash-equal'?

Paul



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: expose XHASH [patch]
  2016-04-08 18:37           ` Paul Pogonyshev
@ 2016-04-08 18:44             ` Stefan Monnier
  2016-04-08 19:24               ` Paul Pogonyshev
  0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2016-04-08 18:44 UTC (permalink / raw)
  To: Paul Pogonyshev; +Cc: emacs-devel

> Well, I don't know, it's a functions that have existed for a good
> amount of time already. And also having some parallel in common lisp,
> for example. Or do you mean like renaming, but making `sxhash' an
> alias for `sxhash-equal'?

Something like that, yes.


        Stefan



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: expose XHASH [patch]
  2016-04-08 18:44             ` Stefan Monnier
@ 2016-04-08 19:24               ` Paul Pogonyshev
  2016-04-08 20:51                 ` Stefan Monnier
  2016-04-08 22:37                 ` Paul Eggert
  0 siblings, 2 replies; 12+ messages in thread
From: Paul Pogonyshev @ 2016-04-08 19:24 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

Here is the next patch iteration. I didn't rename C level function and
also didn't touch *.el files that already use `sxhash'.

Paul


* src/fns.c (Fsxhash_eq, Fsxhash_eql): New functions.
(Fsxhash_equal): Rename from 'Fsxhash'.

* lisp/subr.el (sxhash): New alias for 'sxhash-equal'.

* lisp/byte-opt.el: List 'sxhash-eq' and 'sxhash-eql' as
side-effect free functions.

* doc/lispref/hash.texi (Defining Hash): Document 'sxhash-eq' and
'sxhash-eql'.  Change 'sxhash' to 'sxhash-equal', but mention
that the former is an alias for the latter.

* etc/NEWS: Mention 'sxhash-eq' and 'sxhash-eql'.  Mention that
'sxhash' is now an alias for 'sxhash-equal'.

On 8 April 2016 at 20:44, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Well, I don't know, it's a functions that have existed for a good
>> amount of time already. And also having some parallel in common lisp,
>> for example. Or do you mean like renaming, but making `sxhash' an
>> alias for `sxhash-equal'?
>
> Something like that, yes.
>
>
>         Stefan

[-- Attachment #2: sxhash.diff --]
[-- Type: text/plain, Size: 6275 bytes --]

diff --git a/doc/lispref/hash.texi b/doc/lispref/hash.texi
index 8389c21..4607bb0 100644
--- a/doc/lispref/hash.texi
+++ b/doc/lispref/hash.texi
@@ -268,18 +268,43 @@ under the property @code{hash-table-test}; the property value's form is
 @code{(@var{test-fn} @var{hash-fn})}.
 @end defun
 
-@defun sxhash obj
+@defun sxhash-equal obj
 This function returns a hash code for Lisp object @var{obj}.
 This is an integer which reflects the contents of @var{obj}
 and the other Lisp objects it points to.
 
-If two objects @var{obj1} and @var{obj2} are equal, then @code{(sxhash
-@var{obj1})} and @code{(sxhash @var{obj2})} are the same integer.
+If two objects @var{obj1} and @var{obj2} are @code{equal}, then
+@code{(sxhash-equal @var{obj1})} and @code{(sxhash-equal @var{obj2})}
+are the same integer.
 
-If the two objects are not equal, the values returned by @code{sxhash}
-are usually different, but not always; once in a rare while, by luck,
-you will encounter two distinct-looking objects that give the same
-result from @code{sxhash}.
+If the two objects are not @code{equal}, the values returned by
+@code{sxhash-equal} are usually different, but not always; once in a
+rare while, by luck, you will encounter two distinct-looking objects
+that give the same result from @code{sxhash-equal}.
+
+@b{Common Lisp note:} In Common Lisp a similar function is called
+@code{sxhash}.  Emacs provides this name as a compatibility alias for
+@code{sxhash-equal}.
+@end defun
+
+@defun sxhash-eq obj
+This function returns a hash code for Lisp object @var{obj}.  Its
+result reflects identity of @var{obj}, but not its contents.
+
+If two objects @var{obj1} and @var{obj2} are @code{eq}, then
+@code{(xhash @var{obj1})} and @code{(xhash @var{obj2})} are the same
+integer.
+@end defun
+
+@defun sxhash-eql obj
+This function returns a hash code for Lisp object @var{obj} suitable
+for @code{eql} comparison.  I.e. it reflects identity of @var{obj}
+except for the case where the object is a float number, in which case
+hash code is generated for the value.
+
+If two objects @var{obj1} and @var{obj2} are @code{eql}, then
+@code{(xhash @var{obj1})} and @code{(xhash @var{obj2})} are the same
+integer.
 @end defun
 
   This example creates a hash table whose keys are strings that are
@@ -289,7 +314,7 @@ compared case-insensitively.
 (defun case-fold-string= (a b)
   (eq t (compare-strings a nil nil b nil nil t)))
 (defun case-fold-string-hash (a)
-  (sxhash (upcase a)))
+  (sxhash-equal (upcase a)))
 
 (define-hash-table-test 'case-fold
   'case-fold-string= 'case-fold-string-hash)
@@ -302,7 +327,7 @@ predefined test value @code{equal}.  The keys can be any Lisp object,
 and equal-looking objects are considered the same key.
 
 @example
-(define-hash-table-test 'contents-hash 'equal 'sxhash)
+(define-hash-table-test 'contents-hash 'equal 'sxhash-equal)
 
 (make-hash-table :test 'contents-hash)
 @end example
diff --git a/etc/NEWS b/etc/NEWS
index d38bc3d..6ec82f8 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -217,6 +217,17 @@ outermost parenthesis.
 ** The function 'redirect-debugging-output' now works on platforms
 other than GNU/Linux.
 
++++
+** New functions 'sxhash-eq' and 'sxhash-eql' return hash codes of a
+Lisp object suitable for use with 'eq' and 'eql' correspondingly.  If
+two objects are 'eq' ('eql'), then the result of 'sxhash-eq'
+('sxhash-eql') on them will be the same.
+
++++
+** Function 'sxhash' has been renamed to 'sxhash-equal' for
+consistency with the new functions.  For compatibility, 'sxhash'
+remains as an alias to 'sxhash-equal'.
+
 \f
 * Changes in Emacs 25.2 on Non-Free Operating Systems
 
diff --git a/lisp/emacs-lisp/byte-opt.el b/lisp/emacs-lisp/byte-opt.el
index b3bf4a5..dbaf2bc 100644
--- a/lisp/emacs-lisp/byte-opt.el
+++ b/lisp/emacs-lisp/byte-opt.el
@@ -1209,8 +1209,9 @@
 	 radians-to-degrees rassq rassoc read-from-string regexp-quote
 	 region-beginning region-end reverse round
 	 sin sqrt string string< string= string-equal string-lessp string-to-char
-	 string-to-int string-to-number substring sxhash symbol-function
-	 symbol-name symbol-plist symbol-value string-make-unibyte
+	 string-to-int string-to-number substring
+	 sxhash sxhash-equal sxhash-eq sxhash-eql
+	 symbol-function symbol-name symbol-plist symbol-value string-make-unibyte
 	 string-make-multibyte string-as-multibyte string-as-unibyte
 	 string-to-multibyte
 	 tan truncate
diff --git a/lisp/subr.el b/lisp/subr.el
index cad6319..a6d6fa4 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -66,6 +66,7 @@ For more information, see Info node `(elisp)Declaring Functions'."
 ;;;; Basic Lisp macros.
 
 (defalias 'not 'null)
+(defalias 'sxhash 'sxhash-equal)
 
 (defmacro noreturn (form)
   "Evaluate FORM, expecting it not to return.
diff --git a/src/fns.c b/src/fns.c
index 1ace3bb..da74b9c 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -4447,8 +4447,26 @@ sxhash (Lisp_Object obj, int depth)
 			    Lisp Interface
  ***********************************************************************/
 
+DEFUN ("sxhash-eq", Fsxhash_eq, Ssxhash_eq, 1, 1, 0,
+       doc: /* Compute identity hash code for OBJ and return it as integer.
+In other words, hash codes of two non-`eq' lists will be (most likely)
+different, even if the lists contain the same elements. */)
+  (Lisp_Object obj)
+{
+  return make_number (hashfn_eq (NULL, obj));
+}
+
+DEFUN ("sxhash-eql", Fsxhash_eql, Ssxhash_eql, 1, 1, 0,
+       doc: /* Compute identity hash code for OBJ and return it as integer.
+In comparison to `sxhash-eq', it is also guaranteed that hash codes
+of equal float numbers will be the same, even if the numbers are not
+the same Lisp object. */)
+  (Lisp_Object obj)
+{
+  return make_number (hashfn_eql (NULL, obj));
+}
 
-DEFUN ("sxhash", Fsxhash, Ssxhash, 1, 1, 0,
+DEFUN ("sxhash-equal", Fsxhash_equal, Ssxhash_equal, 1, 1, 0,
        doc: /* Compute a hash code for OBJ and return it as integer.  */)
   (Lisp_Object obj)
 {
@@ -5066,7 +5084,9 @@ syms_of_fns (void)
   DEFSYM (Qkey_or_value, "key-or-value");
   DEFSYM (Qkey_and_value, "key-and-value");
 
-  defsubr (&Ssxhash);
+  defsubr (&Ssxhash_eq);
+  defsubr (&Ssxhash_eql);
+  defsubr (&Ssxhash_equal);
   defsubr (&Smake_hash_table);
   defsubr (&Scopy_hash_table);
   defsubr (&Shash_table_count);

^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: expose XHASH [patch]
  2016-04-08 19:24               ` Paul Pogonyshev
@ 2016-04-08 20:51                 ` Stefan Monnier
  2016-04-08 22:37                 ` Paul Eggert
  1 sibling, 0 replies; 12+ messages in thread
From: Stefan Monnier @ 2016-04-08 20:51 UTC (permalink / raw)
  To: Paul Pogonyshev; +Cc: emacs-devel

> Here is the next patch iteration. I didn't rename C level function and
> also didn't touch *.el files that already use `sxhash'.

LGTM,


        Stefan



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: expose XHASH [patch]
  2016-04-08 19:24               ` Paul Pogonyshev
  2016-04-08 20:51                 ` Stefan Monnier
@ 2016-04-08 22:37                 ` Paul Eggert
  1 sibling, 0 replies; 12+ messages in thread
From: Paul Eggert @ 2016-04-08 22:37 UTC (permalink / raw)
  To: Paul Pogonyshev; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

Thanks. I installed that into the master branch, with the attached 
further minor cleanups for the hash function code. I wrote a new 
ChangeLog entry for it because I didn't notice the free text in your 
email until just now. Perhaps next time you can send the output of 'git 
send-email'? That's what I did to generate this attachment anyway.

[-- Attachment #2: 0002-Minor-improvements-for-hash-function-primitives.patch --]
[-- Type: application/x-patch, Size: 7568 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2016-04-08 22:37 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-31 19:29 expose XHASH [patch] Paul Pogonyshev
2016-03-31 21:52 ` Stefan Monnier
2016-03-31 22:43 ` Paul Eggert
2016-04-01  9:44   ` Paul Pogonyshev
2016-04-02 11:52     ` Paul Pogonyshev
2016-04-08 16:08       ` Paul Pogonyshev
2016-04-08 18:10         ` Stefan Monnier
2016-04-08 18:37           ` Paul Pogonyshev
2016-04-08 18:44             ` Stefan Monnier
2016-04-08 19:24               ` Paul Pogonyshev
2016-04-08 20:51                 ` Stefan Monnier
2016-04-08 22:37                 ` Paul Eggert

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).