Rethinking sample unpack behavior
Vasilij Schneidermann
(20 Nov 2020 12:11 UTC)
|
Re: Rethinking sample unpack behavior Amirouche Boubekki (20 Nov 2020 16:18 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:43 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)
|
Re: Rethinking sample unpack behavior Amirouche Boubekki 20 Nov 2020 16:18 UTC
First thanks again for looking into this. Le ven. 20 nov. 2020 à 13:12, Vasilij Schneidermann <xxxxxx@vasilij.de> a écrit : > > 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. The last option is the one that is the best. It mirrors the behavior in other programming languages. I was thinking about replacing the list with a vector. What do you think about it? > > 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). I am not sure about pluralizing the argument KEY if KEY can be a list, vector or a single bytevector. -- Amirouche ~ https://hyper.dev