all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Philipp Stephani <p.stephani2@gmail.com>
Cc: 28753@debbugs.gnu.org
Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa
Date: Sun, 4 Mar 2018 16:01:53 -0800 (PST)	[thread overview]
Message-ID: <96840423-b3ba-4c4b-96d5-59a26d3e2455@default> (raw)
In-Reply-To: <CAArVCkTne4BWFdOThFUbu7BVtzjAq3m4VRbzN6ozY=99Dk24Rg@mail.gmail.com>

>> Order is quite important for alists, generally.
>> Is there some reason we should not be able to count on
>> this `maphash' behavior?
>
> Order in hashtables is not guaranteed. If anything relies
> on the order, it's buggy.
 
Emacs hash tables don't fall from the sky.  They are not
shadows of some Platonic ideal.  This is a design choice.
Emacs Lisp can implement hash tables any way it wants.

>> I don't know whether it is guaranteed, but this use case
>> involving conversion to alist looks like a good argument
>> for some guarantee wrt order.
>
> No. Ordering guarantees require additional complexity and
> overhead, and are almost never needed.

Neither of those assertions has been demonstrated.  Feel
free to do so (how much overhead, how infrequent).

And infrequency of use is not, alone, a good reason not
to support something.  Infrequent does not mean unimportant.

>> Another possibility (?): Allow _optional_ creation of
>> a hash table that does preserve such ordering (even if
>> just by recording order of entry and making that
>> available to `maphash').  E.g., add a keyword arg for
>> `make-hash-table' that does just that.
>>
>> Even if it turned out that this consistently or occasionally
>> detracted from performance, it could be a useful option.
>> Conversion to an alist would be a case in point.
>
> I don't think it would be worth the additional complexity.

Why?  How much additional complexity?

> Hash tables have been available for ages in most programming
> languages, and almost never does anybody ask for ordering
> guarantees. (For example, I have never seen somebody using
> LinkedHashMap in Java.)

Emacs Lisp has lots of features that are not in "most
programming languages".  Propertized strings, for one
trivial example.

> Even for alists, most of the time maintaining insertion
> order is an irrelevant detail,

What time maintaining insertion order?  I can't imagine
what you mean by that.

> most users care only about get/put/remove.

Not demonstrated.  But even if it were true, it wouldn't
follow that Lisp alist order is unimportant.

Next you'll be suggesting that because lists are mutated
relatively infrequently it is unimportant to be able to
modify list structure or test cons equality with `eq'.
Or that because true lists are used most of the time we
might as well drop support of dotted lists.

----

Naive google search -

https://www.javaspecialists.eu/archive/Issue073.html

https://stackoverflow.com/questions/12998568/hashmap-vs-linkedhashmap-performance-in-iteration-over-values/12998878

https://stackoverflow.com/questions/26623129/when-to-use-linkedhashmap-over-hashmap-in-java





      reply	other threads:[~2018-03-05  0:01 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-09  0:25 bug#28753: 25.3; Functions to get alist from hash table and vice versa Drew Adams
2017-10-09 13:20 ` Michael Heerdegen
2017-10-09 14:11   ` Drew Adams
2017-10-11 16:42     ` Drew Adams
     [not found]       ` <87wp4038m0.fsf@web.de>
2017-10-12 13:27         ` Nicolas Petton
2017-10-12 13:46           ` Michael Heerdegen
2017-10-12 14:36           ` Drew Adams
2017-11-06 16:19             ` Drew Adams
2017-11-07  0:46               ` Noam Postavsky
2017-11-07  2:24                 ` Drew Adams
2017-11-07  2:51                   ` Noam Postavsky
2017-11-07 13:28                 ` Michael Heerdegen
2017-12-30 20:40                   ` Philipp Stephani
2017-12-30 21:08                     ` Drew Adams
2017-12-30 21:15                       ` Philipp Stephani
2017-10-12 15:56           ` Noam Postavsky
2017-10-12 13:30       ` Nicolas Petton
2022-04-22 13:18   ` Lars Ingebrigtsen
2022-04-22 15:21     ` Drew Adams
2017-12-30 21:26 ` Philipp Stephani
2017-12-31  0:01   ` Drew Adams
2018-03-04 19:17     ` Philipp Stephani
2018-03-05  0:01       ` Drew Adams [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=96840423-b3ba-4c4b-96d5-59a26d3e2455@default \
    --to=drew.adams@oracle.com \
    --cc=28753@debbugs.gnu.org \
    --cc=p.stephani2@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.