Email list hosting service & mailing list manager

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)

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