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