Rethinking sample unpack behavior Vasilij Schneidermann (20 Nov 2020 12:11 UTC)
|
Re: Rethinking sample unpack behavior
Amirouche Boubekki
(20 Nov 2020 16:19 UTC)
|
Re: Rethinking sample unpack behavior
Vasilij Schneidermann
(20 Nov 2020 16:42 UTC)
|
Re: Rethinking sample unpack behavior
Amirouche Boubekki
(20 Nov 2020 17:44 UTC)
|
Re: Rethinking sample unpack behavior
Vasilij Schneidermann
(21 Nov 2020 12:51 UTC)
|
Re: Rethinking sample unpack behavior
Amirouche Boubekki
(21 Nov 2020 13:07 UTC)
|
Rethinking sample unpack behavior Vasilij Schneidermann 20 Nov 2020 12:11 UTC
Hello again, The sample implementation of pack accepts a variable amount of arguments, but unpack returns a list instead of multiple values. This makes it inconvenient to use them as inverse of each other and I suspect this hasn't been caught as all tests operate on bytevectors instead of in terms of pack/unpack results. I've looked at their documentation and found it remarkably unclear ("a packing procedure that allows to encode some scheme types into bytevectors" sounds like it speaks of the accepted types and what they map to, not like it supporting encoding several values in one function call, likewise "decode a bytevector encoded with the above pack procedure into a Scheme object." doesn't suggest the Scheme object is going to be a list of every result). I see two options here: - Clear up the documentation for unpack and make it always return multiple values. - Clear up the documentation and function signatures so that you always encode a single value and decode into a single value. Vasilij PS: One minor quibble about pack: Its function signature is (engine-pack engine . key), but I believe pluralizing the rest argument to keys would make it clear that more than one key can be passed (as opposed to key being an optional argument).