Rethinking sample unpack behavior
Vasilij Schneidermann
(20 Nov 2020 12:11 UTC)
|
Re: Rethinking sample unpack behavior
Amirouche Boubekki
(20 Nov 2020 16:18 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:43 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