chicken-janitors
[Top][All Lists]
Advanced

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

Re: #1718: srfi-69 egg hash-table-delete!/-merge!/remove! return type do


From: Chicken Trac
Subject: Re: #1718: srfi-69 egg hash-table-delete!/-merge!/remove! return type doesn't match SRFI-69
Date: Tue, 13 Apr 2021 06:31:47 -0000

#1718: srfi-69 egg hash-table-delete!/-merge!/remove! return type doesn't match
SRFI-69
------------------------------------------+---------------------
            Reporter:  Kon Lovett         |      Owner:  (none)
                Type:  defect             |     Status:  new
            Priority:  not urgent at all  |  Milestone:  someday
           Component:  extensions         |    Version:  5.2.0
          Resolution:                     |   Keywords:  srfi-69
Estimated difficulty:  trivial            |
------------------------------------------+---------------------

Comment (by sjamaan):

 hmm, I think this change is intentional, and should be allowed even if
 undefined in the SRFI. To me it seems like a nice extension to have hash-
 table-merge! return the hash table into which was merged, analogously to
 hash-table-merge without the bang. However, if we decide to keep this we
 should fix the types entry because right now it's specified as returning
 undefined, which is inconsistent with the procedure's actual behaviour.

 Delete returning whether something was deleted also seems to be
 intentional and a nice behaviour.

 It looks like hash-table-remove! actually returns `void` already. At least
 I was unable to get it to return anything else.  In the body the final
 form is `#t`, but note that that is inside a `do` loop which has a
 `##sys#setislot` as its final action *which returns void) when the stop
 condition test returns true.

 Finally, changing the behaviour (especially of `hash-table-merge!`) will
 probably break user code, so I'm not sure that's a great idea. Portable
 code should not be using the return value anyway (as it's undefined), so
 should not be affected, but CHICKEN-specific code that uses the actual
 behaviour rather than the documented behaviour will break. Note that
 `hash-table-merge!` in the CHICKEN documentation is explicitly
 [[http://wiki.call-cc.org/eggref/5/srfi-69#hash-table-merge|documented]]
 to return its first argument:

 > hash-table-merge!
 > `[procedure] (hash-table-merge! HASH-TABLE-1 HASH-TABLE-2)`
 >
 > Returns `HASH-TABLE-1` as the union of `HASH-TABLE-1` and `HASH-
 TABLE-2`. Keys that exist in both tables will be taken from `HASH-
 TABLE-1`.

 What do the other core devs think?

-- 
Ticket URL: <https://bugs.call-cc.org/ticket/1718#comment:1>
CHICKEN Scheme <https://www.call-cc.org/>
CHICKEN Scheme is a compiler for the Scheme programming language.

reply via email to

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