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 17:43 UTC

Le ven. 20 nov. 2020 à 17:42, Vasilij Schneidermann <xxxxxx@vasilij.de> a écrit :
>
> > 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.

Agreed.

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

Yes it is a discussion about code using engine-pack. Not strictly
related to SRFI-167.

Yes lists are more prevalent in Scheme code. But vectors allow us to
reference an item that is beyond car and cadr. Also, how would you
represent vectors and pairs?

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

Ok!

--
Amirouche ~ https://hyper.dev