all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Re: maphash
       [not found] <p04310100bac9ebec6275@[198.17.100.22]>
@ 2003-04-24  1:51 ` Richard Stallman
  2003-04-24  7:46   ` maphash Stephen J. Turnbull
  0 siblings, 1 reply; 15+ messages in thread
From: Richard Stallman @ 2003-04-24  1:51 UTC (permalink / raw)
  Cc: emacs-devel

    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. 

An small anount of experimentation doesn't show you it will always to
do that.  It would be necessary to study the code and construct a
proof, before we could promise this to the users.

Do you want to study the code?

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

* Re: maphash
  2003-04-24  1:51 ` maphash Richard Stallman
@ 2003-04-24  7:46   ` Stephen J. Turnbull
  2003-04-24 21:58     ` maphash Greg Hill
  0 siblings, 1 reply; 15+ messages in thread
From: Stephen J. Turnbull @ 2003-04-24  7:46 UTC (permalink / raw)
  Cc: emacs-devel

>>>>> "rms" == Richard Stallman <rms@gnu.org> 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")


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

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

* Re: maphash
  2003-04-24  7:46   ` maphash Stephen J. Turnbull
@ 2003-04-24 21:58     ` Greg Hill
  2003-04-26  2:32       ` maphash Richard Stallman
  0 siblings, 1 reply; 15+ messages in thread
From: Greg Hill @ 2003-04-24 21:58 UTC (permalink / raw)
  Cc: emacs-devel

At 4:46 PM +0900 4/24/03, Stephen J. Turnbull wrote:
>  >>>>> "rms" == Richard Stallman <rms@gnu.org> 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

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

* Re: maphash
  2003-04-24 21:58     ` maphash Greg Hill
@ 2003-04-26  2:32       ` Richard Stallman
  0 siblings, 0 replies; 15+ messages in thread
From: Richard Stallman @ 2003-04-26  2:32 UTC (permalink / raw)
  Cc: emacs-devel

    Fortunately for me, in GNU Emacs Stephen's example--and several 
    variations thereof--do work the way I described,
    ...

    After taking a quick look at the C source code, the simple answer to 
    Richard's question is "No, thank you."

We can't document this feature unless we know it can be relied on.  I
took a quick look at the code of maphash and it led me to doubt that
this is generally true, but while I have the know-how to study it
carefully, I do not have the time.

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

* maphash
@ 2024-09-10 15:52 Helmut Eller
  2024-09-11 14:23 ` maphash Mattias Engdegård
  0 siblings, 1 reply; 15+ messages in thread
From: Helmut Eller @ 2024-09-10 15:52 UTC (permalink / raw)
  To: emacs-devel

The documentation states that puthash and remhash are only "allowed" to
use the current key while a maphash is in progress.  (Interestingly, it
says nothing about gethash.)

However, the code in comp.el uses puthash with other keys.  E.g
comp--add-cond-cstrs-simple iterates over a hashtable of basic blocks
and while the iteration is in progress, it calls
comp--add-cond-cstrs-target-block which puts new basic blocks into the
hashtable.

(With the current implementation, inserting may rehash the table which
can cause maphash to "skip" some entries or visit some entries twice.)

Should the hashtable implementation detect such situations and perhaps
signal an error or a warning?



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

* Re: maphash
  2024-09-10 15:52 maphash Helmut Eller
@ 2024-09-11 14:23 ` Mattias Engdegård
  2024-09-11 22:45   ` maphash Andrea Corallo
  0 siblings, 1 reply; 15+ messages in thread
From: Mattias Engdegård @ 2024-09-11 14:23 UTC (permalink / raw)
  To: Helmut Eller; +Cc: emacs-devel, Andrea Corallo

10 sep. 2024 kl. 17.52 skrev Helmut Eller <eller.helmut@gmail.com>:

> The documentation states that puthash and remhash are only "allowed" to
> use the current key while a maphash is in progress.  (Interestingly, it
> says nothing about gethash.)

That is correct. The purpose of these rules is to avoid us being shackled to a specific behaviour if a user breaks them; we don't want any more implementation restrictions than necessary.

We still protect Lisp abstractions so the user shouldn't fear segfaults, but there are no promises when it comes to the iteration order, whether iteration will encounter added elements, the same element twice or some none at all, etc.

> However, the code in comp.el uses puthash with other keys.  E.g
> comp--add-cond-cstrs-simple iterates over a hashtable of basic blocks
> and while the iteration is in progress, it calls
> comp--add-cond-cstrs-target-block which puts new basic blocks into the
> hashtable.

This sounds like a bug in nativecomp then, even if it happens not to have any bad consequences right now.

> Should the hashtable implementation detect such situations and perhaps
> signal an error or a warning?

Not unless it can be done at basically no cost. This is not a very common mistake and letting all correct code pay for it wouldn't be a good trade-off.




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

* Re: maphash
  2024-09-11 14:23 ` maphash Mattias Engdegård
@ 2024-09-11 22:45   ` Andrea Corallo
  2024-09-28  8:42     ` maphash Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: Andrea Corallo @ 2024-09-11 22:45 UTC (permalink / raw)
  To: Mattias Engdegård; +Cc: Helmut Eller, emacs-devel

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 10 sep. 2024 kl. 17.52 skrev Helmut Eller <eller.helmut@gmail.com>:
>
>> The documentation states that puthash and remhash are only "allowed" to
>> use the current key while a maphash is in progress.  (Interestingly, it
>> says nothing about gethash.)
>
> That is correct. The purpose of these rules is to avoid us being shackled to a specific behaviour if a user breaks them; we don't want any more implementation restrictions than necessary.
>
> We still protect Lisp abstractions so the user shouldn't fear
> segfaults, but there are no promises when it comes to the iteration
> order, whether iteration will encounter added elements, the same
> element twice or some none at all, etc.
>
>> However, the code in comp.el uses puthash with other keys.  E.g
>> comp--add-cond-cstrs-simple iterates over a hashtable of basic blocks
>> and while the iteration is in progress, it calls
>> comp--add-cond-cstrs-target-block which puts new basic blocks into the
>> hashtable.
>
> This sounds like a bug in nativecomp then, even if it happens not to have any bad consequences right now.

Ops! Will look at thanks

  Andrea



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

* Re: maphash
  2024-09-11 22:45   ` maphash Andrea Corallo
@ 2024-09-28  8:42     ` Eli Zaretskii
  2024-09-30 14:29       ` maphash Andrea Corallo
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2024-09-28  8:42 UTC (permalink / raw)
  To: Andrea Corallo; +Cc: mattias.engdegard, eller.helmut, emacs-devel

Ping!  Andrea, did you have time to look at this?

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: Helmut Eller <eller.helmut@gmail.com>,  emacs-devel@gnu.org
> Date: Wed, 11 Sep 2024 18:45:16 -0400
> 
> Mattias Engdegård <mattias.engdegard@gmail.com> writes:
> 
> > 10 sep. 2024 kl. 17.52 skrev Helmut Eller <eller.helmut@gmail.com>:
> >
> >> The documentation states that puthash and remhash are only "allowed" to
> >> use the current key while a maphash is in progress.  (Interestingly, it
> >> says nothing about gethash.)
> >
> > That is correct. The purpose of these rules is to avoid us being shackled to a specific behaviour if a user breaks them; we don't want any more implementation restrictions than necessary.
> >
> > We still protect Lisp abstractions so the user shouldn't fear
> > segfaults, but there are no promises when it comes to the iteration
> > order, whether iteration will encounter added elements, the same
> > element twice or some none at all, etc.
> >
> >> However, the code in comp.el uses puthash with other keys.  E.g
> >> comp--add-cond-cstrs-simple iterates over a hashtable of basic blocks
> >> and while the iteration is in progress, it calls
> >> comp--add-cond-cstrs-target-block which puts new basic blocks into the
> >> hashtable.
> >
> > This sounds like a bug in nativecomp then, even if it happens not to have any bad consequences right now.
> 
> Ops! Will look at thanks
> 
>   Andrea
> 
> 



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

* Re: maphash
  2024-09-28  8:42     ` maphash Eli Zaretskii
@ 2024-09-30 14:29       ` Andrea Corallo
  2024-10-01 16:31         ` maphash Andrea Corallo
  0 siblings, 1 reply; 15+ messages in thread
From: Andrea Corallo @ 2024-09-30 14:29 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: mattias.engdegard, eller.helmut, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

> Ping!  Andrea, did you have time to look at this?

No sorry, hope this week to have time to tackle my todolist.

  Andrea



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

* Re: maphash
  2024-09-30 14:29       ` maphash Andrea Corallo
@ 2024-10-01 16:31         ` Andrea Corallo
  2024-10-01 16:59           ` maphash Mattias Engdegård
  0 siblings, 1 reply; 15+ messages in thread
From: Andrea Corallo @ 2024-10-01 16:31 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: mattias.engdegard, eller.helmut, emacs-devel

Andrea Corallo <acorallo@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Ping!  Andrea, did you have time to look at this?
>
> No sorry, hope this week to have time to tackle my todolist.

Okay should be fixed with 372ce6adbf3 in master.

Thanks

  Andrea



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

* Re: maphash
  2024-10-01 16:31         ` maphash Andrea Corallo
@ 2024-10-01 16:59           ` Mattias Engdegård
  2024-10-01 18:36             ` maphash Andrea Corallo
  0 siblings, 1 reply; 15+ messages in thread
From: Mattias Engdegård @ 2024-10-01 16:59 UTC (permalink / raw)
  To: Andrea Corallo; +Cc: Eli Zaretskii, Helmut Eller, emacs-devel

1 okt. 2024 kl. 18.31 skrev Andrea Corallo <acorallo@gnu.org>:

> Okay should be fixed with 372ce6adbf3 in master.

Thank you! Would you also take a look at the four DOHASH_SAFE uses in comp.c, and see if there is any possibility of mutation of the tables iterated over? Then they could be changed to DOHASH.




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

* Re: maphash
  2024-10-01 16:59           ` maphash Mattias Engdegård
@ 2024-10-01 18:36             ` Andrea Corallo
  2024-10-02  8:43               ` maphash Mattias Engdegård
  0 siblings, 1 reply; 15+ messages in thread
From: Andrea Corallo @ 2024-10-01 18:36 UTC (permalink / raw)
  To: Mattias Engdegård; +Cc: Eli Zaretskii, Helmut Eller, emacs-devel

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 1 okt. 2024 kl. 18.31 skrev Andrea Corallo <acorallo@gnu.org>:
>
>> Okay should be fixed with 372ce6adbf3 in master.
>
> Thank you! Would you also take a look at the four DOHASH_SAFE uses in
> comp.c, and see if there is any possibility of mutation of the tables
> iterated over? Then they could be changed to DOHASH.

Thanks I think the use of DOHASH_SAFE is correct there.

  Andrea



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

* Re: maphash
  2024-10-01 18:36             ` maphash Andrea Corallo
@ 2024-10-02  8:43               ` Mattias Engdegård
  2024-10-03 11:18                 ` maphash Andrea Corallo
  0 siblings, 1 reply; 15+ messages in thread
From: Mattias Engdegård @ 2024-10-02  8:43 UTC (permalink / raw)
  To: Andrea Corallo; +Cc: Eli Zaretskii, Helmut Eller, emacs-devel

1 okt. 2024 kl. 20.36 skrev Andrea Corallo <acorallo@gnu.org>:

>> Would you also take a look at the four DOHASH_SAFE uses in
>> comp.c, and see if there is any possibility of mutation of the tables
>> iterated over? Then they could be changed to DOHASH.
> 
> Thanks I think the use of DOHASH_SAFE is correct there.

Mind explaining why? Note that DOHASH does attempt to catch some table mutations when checking is enabled.

DOHASH_SAFE is intended for Fmapcar, where there may be mutations and we mustn't crash because of them but we don't care about semantics in that case.




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

* Re: maphash
  2024-10-02  8:43               ` maphash Mattias Engdegård
@ 2024-10-03 11:18                 ` Andrea Corallo
  2024-10-04  8:30                   ` maphash Mattias Engdegård
  0 siblings, 1 reply; 15+ messages in thread
From: Andrea Corallo @ 2024-10-03 11:18 UTC (permalink / raw)
  To: Mattias Engdegård; +Cc: Eli Zaretskii, Helmut Eller, emacs-devel

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 1 okt. 2024 kl. 20.36 skrev Andrea Corallo <acorallo@gnu.org>:
>
>>> Would you also take a look at the four DOHASH_SAFE uses in
>>> comp.c, and see if there is any possibility of mutation of the tables
>>> iterated over? Then they could be changed to DOHASH.
>> 
>> Thanks I think the use of DOHASH_SAFE is correct there.
>
> Mind explaining why? Note that DOHASH does attempt to catch some table mutations when checking is enabled.
>
> DOHASH_SAFE is intended for Fmapcar, where there may be mutations and we mustn't crash because of them but we don't care about semantics in that case.

Sorry from your prev message I understood the opposit.  With abb932290df
we now use DOHASH (not that I expect any measurable perf impact).

Thanks

  Andrea



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

* Re: maphash
  2024-10-03 11:18                 ` maphash Andrea Corallo
@ 2024-10-04  8:30                   ` Mattias Engdegård
  0 siblings, 0 replies; 15+ messages in thread
From: Mattias Engdegård @ 2024-10-04  8:30 UTC (permalink / raw)
  To: Andrea Corallo; +Cc: Eli Zaretskii, Helmut Eller, emacs-devel

3 okt. 2024 kl. 13.18 skrev Andrea Corallo <acorallo@gnu.org>:

> Sorry from your prev message I understood the opposit.  With abb932290df
> we now use DOHASH (not that I expect any measurable perf impact).

Excellent, thank you. It's mostly about showing clearly that we don't expect anything silly going on in those loops (and getting some extra checking when enabled).




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

end of thread, other threads:[~2024-10-04  8:30 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-09-10 15:52 maphash Helmut Eller
2024-09-11 14:23 ` maphash Mattias Engdegård
2024-09-11 22:45   ` maphash Andrea Corallo
2024-09-28  8:42     ` maphash Eli Zaretskii
2024-09-30 14:29       ` maphash Andrea Corallo
2024-10-01 16:31         ` maphash Andrea Corallo
2024-10-01 16:59           ` maphash Mattias Engdegård
2024-10-01 18:36             ` maphash Andrea Corallo
2024-10-02  8:43               ` maphash Mattias Engdegård
2024-10-03 11:18                 ` maphash Andrea Corallo
2024-10-04  8:30                   ` maphash Mattias Engdegård
     [not found] <p04310100bac9ebec6275@[198.17.100.22]>
2003-04-24  1:51 ` maphash Richard Stallman
2003-04-24  7:46   ` maphash Stephen J. Turnbull
2003-04-24 21:58     ` maphash Greg Hill
2003-04-26  2:32       ` maphash Richard Stallman

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.