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 Vasilij Schneidermann 20 Nov 2020 16:42 UTC
> The last option is the one that is the best. It mirrors the behavior
> in other programming languages.

Alright, so the signatures would change to (engine-pack engine key) and
(engine-unpack engine bytevector) would stay unchanged.

> I was thinking about replacing the list with a vector. What do you
> think about it?

You mean for the nested code? Not sure about that and considering lists
are so much more prevalent in Scheme code, I'd go for that as
representation. Another point in favor is the Java binding for
FoundationDB using the list interface instead of arrays.

> I am not sure about pluralizing the argument KEY if KEY can be a list,
> vector or a single bytevector.

With the above change it's no longer necessary.

Vasilij