Summary

srfi-69 egg hash-table-delete!/-merge!/remove! return type doesn't match SRFI-69

Metadata

Attachments

Description

all 3 have non-void return values & -delete! has wrong return type

(per SRFI): Procedure: hash-table-delete! hash-table key → undefined (per .types): ... srfi-69#hash-table-delete! ((struct hash-table) *) boolean))

& the associated tests use the return value

Changes and comments

[2020-08-26 18:48:16 UTC] kon attached srfi-69.diff (description=SVN diff of suggested changes)

[2021-04-13 08:31:47 UTC] sjamaan wrote:

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?

[2021-04-13 16:23:25 UTC] kon wrote:

it was intentional. this report filed in a fit of standarditis. agree, document what is.

[2021-04-15 08:23:03 UTC] sjamaan changed status from new to closed

[2021-04-15 08:23:03 UTC] sjamaan set resolution to fixed

[2021-04-15 08:23:03 UTC] sjamaan wrote:

Fixed the inconsistent type declaration for `hash-table-merge!` with r40008; as Kon agrees, we should just keep the behaviour so I'm closing the ticket.