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 > <zelphirkaltst...@posteo.de <mailto:zelphirkaltst...@posteo.de>> 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 >> <nalagin...@gmail.com <mailto:nalagin...@gmail.com>> 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 < >> zelphirkaltst...@posteo.de >> <mailto:zelphirkaltst...@posteo.de>> 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 >> > >> > >> > >>
