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)

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).