From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Greg Hill Newsgroups: gmane.emacs.devel Subject: Re: maphash Date: Thu, 24 Apr 2003 14:58:18 -0700 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87sms88hie.fsf@tleepslib.sk.tsukuba.ac.jp> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Trace: main.gmane.org 1051221554 17937 80.91.224.249 (24 Apr 2003 21:59:14 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 24 Apr 2003 21:59:14 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Apr 24 23:59:10 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 198ok4-0004dH-00 for ; Thu, 24 Apr 2003 23:58:56 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 198oqT-0001FR-00 for ; Fri, 25 Apr 2003 00:05:33 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 198ojy-00043Z-05 for emacs-devel@quimby.gnus.org; Thu, 24 Apr 2003 17:58:50 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 198ojg-000428-00 for emacs-devel@gnu.org; Thu, 24 Apr 2003 17:58:32 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 198ojf-0003zO-00 for emacs-devel@gnu.org; Thu, 24 Apr 2003 17:58:31 -0400 Original-Received: from renfield.synergymicro.com ([153.105.4.30] helo=synergymicro.com) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 198ojd-0003y0-00; Thu, 24 Apr 2003 17:58:30 -0400 Original-Received: from synergy.synergy.encinitas.ca.us ([153.105.4.29]) by synergymicro.com (8.9.3/8.9.3) with ESMTP id OAA12101; Thu, 24 Apr 2003 14:59:52 -0700 Original-Received: from [198.17.100.22] (G_Hill_Mac [198.17.100.22]) h3OM5koJ009626; Thu, 24 Apr 2003 15:05:47 -0700 In-Reply-To: <87sms88hie.fsf@tleepslib.sk.tsukuba.ac.jp> Original-To: "Stephen J. Turnbull" , rms@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:13436 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13436 At 4:46 PM +0900 4/24/03, Stephen J. Turnbull wrote: > >>>>> "rms" == Richard Stallman writes: > > I have discovered by experimentation that maphash actually does what > I hoped it would, which is to pass key/value pairs to the mapping > function in the same order in which they were added to the table. > > rms> An small anount of experimentation doesn't show you it will > rms> always to do that. It would be necessary to study the code > rms> and construct a proof, before we could promise this to the > rms> users. > >If I understand the OP's description correctly, I can already promise >you that code depending on such a feature won't be portable to XEmacs: > >(let ((my-hash (make-hash-table)) > result) > (puthash "key1" "val1" my-hash) > (puthash "key2" "val2" my-hash) > (puthash "key3" "val3" my-hash) > (maphash (lambda (k v) (setq result (cons k result))) my-hash) > (reverse result)) > >=> ("key2" "key3" "key1") Fortunately for me, in GNU Emacs Stephen's example--and several variations thereof--do work the way I described, and not the way they work in XEmacs. Also, fortunately for me, my code does not have to be portable. At 9:51 PM -0400 4/23/03, Richard Stallman wrote: >Do you want to study the code? After taking a quick look at the C source code, the simple answer to Richard's question is "No, thank you." I do write code in C, when I absolutely have to, but I don't really care for the language. And in general, I don't enjoy the challenge of figuring out how OP's code works, especially when it is written in C _and_ chock full of MACROs. So, I'll just say: That's ok, I understand that you cannot, in good faith, make any promises either that this "feature" works relieably now, or even that if it happens to now, it always will. It _is_ working for me reliably now, and I'll keep using it as long as it does; and I promise I won't complain if my decision to do so comes back to haunt me later on. --Greg