See <https://github.com/scheme-requests-for-implementation/srfi-151>. Clone it and do a little adapting. The .sld extension is a common, but not required, convention for R7RS libraries, but the guts of it are in the other files.
On Thu, Oct 24, 2019 at 3:47 PM Zelphir Kaltstahl < [email protected]> wrote: > Sorry, I am a bit clueless right now. I have the following questions: > > Where would I find srfi-151.sld? > > What is a *.sld file? (If I had to come up with a guess: "Scheme language > definition"?) > > If it is already standard Scheme code, why would I need to adapt it for > Guile? Does it need to be modified? > > > I think modifying an external library, which does not exist for Guile yet, > is a bit out of scope for my project. I also found logand, logior and > similar to be super fast. I expect that the SRFI 60 functions are mapped to > the Guile core logand and similar internally. I ran a million times logand > in approximately 1.3 seconds. Is that slow? > > Background: I am working on a bit board implementation and my current > (working) implementation uses bit vectors, because I did initially not get > it, that I could use integers with those bit-wise operations instead of bit > vectors. I had the initial impression, that the code ran fast, but using > logand and logior and similar, I already have an approximate 300x speedup. > Not sure whether that should still be considered slow. Here is some timing > code I used to measure a very simple case: > > ~~~~~ > (use-modules (srfi srfi-19)) > > (define-syntax time > (syntax-rules () > [(time expr expr* ...) > (begin > (define start-time (current-time time-monotonic)) > expr > expr* ... > (define end-time (current-time time-monotonic)) > (let* ([diff (time-difference end-time start-time)] > [elapsed-ns (+ (/ (time-nanosecond diff) 1e9) > (time-second diff))]) > (display (format #t "~fs~%" elapsed-ns))))])) > > > (time > (let ([int1 #b10101010] > [int2 #b01010101]) > (do ([i 1 (+ i 1)]) > ([> i 1000000]) > (logand int1 int2)))) > ~~~~~ > > And here is the one for my old / current code: > > ~~~~~ > (use-modules (srfi srfi-19)) > > (define-syntax time > (syntax-rules () > [(time expr expr* ...) > (begin > (define start-time (current-time time-monotonic)) > expr > expr* ... > (define end-time (current-time time-monotonic)) > (let* ([diff (time-difference end-time start-time)] > [elapsed-ns (+ (/ (time-nanosecond diff) 1e9) > (time-second diff))]) > (display (format #t "~fs~%" elapsed-ns))))])) > > > (define (binary-bit-vector-operation bv1 bv2 proc) > (define (iter bit-list1 bit-list2) > (cond [(or (null? bit-list1) (null? bit-list2)) '()] > [else (cons (proc (car bit-list1) > (car bit-list2)) > (iter (cdr bit-list1) > (cdr bit-list2)))])) > (list->bitvector > (iter (bitvector->list bv1) > (bitvector->list bv2)))) > > > (time > (let ([bv1 #*10101010] > [bv2 #*01010101]) > (do ([i 1 (+ i 1)]) > ([> i 1000000]) > (binary-bit-vector-operation > bv1 > bv2 > (lambda (b1 b2) > (and b1 b2)))))) > ~~~~~ > > It is also in my todo file on: > > https://notabug.org/ZelphirKaltstahl/bitboard/src/dev/todo.org > > (Btw.: I really like that notabug renders Emacs Org-mode files!) > > Regards, > > Zelphir > On 10/24/19 8:50 PM, John Cowan wrote: > > 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 >>> > >>> > >>> > >>> >>
