Compile it yourself! Just look at the logic in srfi-151.sld and see how it needs to be modified for Guile. Easy-peasy.
It's a lot less work to port a SRFI implementation than to do things from scratch. On Thu, Oct 24, 2019 at 2:26 PM Zelphir Kaltstahl < [email protected]> wrote: > Ah, but SRFI 151 is not implemented in my version of Guile: > > ~~~~~ > scheme@(guile-user)> (use-modules (srfi srfi-151)) > While compiling expression: > no code for module (srfi srfi-151) > scheme@(guile-user)> > ~~~~~ > > Guile version: 2.2.6 from Guix: > > ~~~~~ > guile (GNU Guile) 2.2.6 > Copyright (C) 2019 Free Software Foundation, Inc. > > License LGPLv3+: GNU LGPL 3 or later <http://gnu.org/licenses/lgpl.html> > <http://gnu.org/licenses/lgpl.html>. > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > ~~~~~ > > Are you suggesting, that I copy the code for SRFI 151 from somewhere and > put it into my project? > > Regards, > > Zelphir > On 10/24/19 7:02 PM, John Cowan wrote: > > For bitwise integers, I recommend SRFI 151. If you use your > implementation to provide the seven core functions bitwise-not, > bitwise-and, bitwise-ior, bitwise-xor, arithmetic-shift, integer-length, > and bit-count, all of which have definitions in bitwise-core.scm that are > very slow, then you'll have a package that can do pretty much what all the > bitwise SRFIs provide and more with acceptable performance. > > There is a conversion table at the end of the SRFI between the names used > by other SRFIs and the names used by SRFI 151; they are as close to SRFI 33 > and SRFI 60 as practical. It is part of the Tangerine Edition of > R7RS-large. > > On Thu, Oct 24, 2019 at 12:43 PM Nala Ginrut <[email protected]> wrote: > >> Personally, I prefer srfi. But sometimes I mix with RnRS. >> I think it's better to avoid Guile specific things, however, Guile >> provides >> many good things that the standard doesn't have. >> >> On Thu, Oct 24, 2019 at 11:56 PM Zelphir Kaltstahl < >> [email protected]> wrote: >> >> > Hello Guile Users! >> > >> > I have a question regarding usage of SRFIs in Guile code. >> > >> > Sometimes there are core functions, which are also available from an >> > SRFI implementation. One example I am currently dealing with are bitwise >> > operations for integer numbers. There is SRFI 60 and there are the core >> > functions like logand, logior and so on. >> > >> > Usually I tend to think, that using the SRFI implementation in such >> > situation is better, as it is an implementation of a common interface, >> > which other Schemes might also have implemented. Using that makes code >> > more portable to other Schemes. However, I want to be sure, that this is >> > a good way of thinking about it. Are there ever arguments against using >> > an SRFI implementation, when an SRFI implementation provides what I >> need? >> > >> > Another example are structs. I usually use SRFI 9 to make some structs, >> > instead of the core record or struct type. >> > >> > What do you think? >> > >> > Best regards, >> > >> > Zelphir >> > >> > >> > >> >
