* Use core or SRFIs? @ 2019-10-24 15:55 Zelphir Kaltstahl 2019-10-24 16:01 ` Nala Ginrut 2019-10-24 17:01 ` Taylan Kammer 0 siblings, 2 replies; 11+ messages in thread From: Zelphir Kaltstahl @ 2019-10-24 15:55 UTC (permalink / raw) To: guile-user 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Use core or SRFIs? 2019-10-24 15:55 Use core or SRFIs? Zelphir Kaltstahl @ 2019-10-24 16:01 ` Nala Ginrut 2019-10-24 16:41 ` Zelphir Kaltstahl 2019-10-24 17:02 ` John Cowan 2019-10-24 17:01 ` Taylan Kammer 1 sibling, 2 replies; 11+ messages in thread From: Nala Ginrut @ 2019-10-24 16:01 UTC (permalink / raw) To: Zelphir Kaltstahl; +Cc: Guile User 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 < zelphirkaltstahl@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 > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Use core or SRFIs? 2019-10-24 16:01 ` Nala Ginrut @ 2019-10-24 16:41 ` Zelphir Kaltstahl 2019-10-24 17:02 ` John Cowan 1 sibling, 0 replies; 11+ messages in thread From: Zelphir Kaltstahl @ 2019-10-24 16:41 UTC (permalink / raw) To: Nala Ginrut; +Cc: Guile User Hi! I see. Thanks, that is what I did so far as well : ) Best regards, Zelphir On 10/24/19 6:01 PM, Nala Ginrut 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 > <zelphirkaltstahl@posteo.de <mailto:zelphirkaltstahl@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 > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Use core or SRFIs? 2019-10-24 16:01 ` Nala Ginrut 2019-10-24 16:41 ` Zelphir Kaltstahl @ 2019-10-24 17:02 ` John Cowan 2019-10-24 18:26 ` Zelphir Kaltstahl 1 sibling, 1 reply; 11+ messages in thread From: John Cowan @ 2019-10-24 17:02 UTC (permalink / raw) To: Nala Ginrut; +Cc: Guile User 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 <nalaginrut@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 < > zelphirkaltstahl@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 > > > > > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Use core or SRFIs? 2019-10-24 17:02 ` John Cowan @ 2019-10-24 18:26 ` Zelphir Kaltstahl 2019-10-24 18:50 ` John Cowan 0 siblings, 1 reply; 11+ messages in thread From: Zelphir Kaltstahl @ 2019-10-24 18:26 UTC (permalink / raw) To: John Cowan, Nala Ginrut; +Cc: Guile User 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>. 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 <nalaginrut@gmail.com > <mailto:nalaginrut@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 < > zelphirkaltstahl@posteo.de <mailto:zelphirkaltstahl@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 > > > > > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Use core or SRFIs? 2019-10-24 18:26 ` Zelphir Kaltstahl @ 2019-10-24 18:50 ` John Cowan 2019-10-24 19:47 ` Zelphir Kaltstahl 0 siblings, 1 reply; 11+ messages in thread From: John Cowan @ 2019-10-24 18:50 UTC (permalink / raw) To: Zelphir Kaltstahl; +Cc: Guile User 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 < zelphirkaltstahl@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 <nalaginrut@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 < >> zelphirkaltstahl@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 >> > >> > >> > >> > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Use core or SRFIs? 2019-10-24 18:50 ` John Cowan @ 2019-10-24 19:47 ` Zelphir Kaltstahl 2019-10-24 19:56 ` John Cowan 0 siblings, 1 reply; 11+ messages in thread From: Zelphir Kaltstahl @ 2019-10-24 19:47 UTC (permalink / raw) To: John Cowan; +Cc: Guile User 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 > <zelphirkaltstahl@posteo.de <mailto:zelphirkaltstahl@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 >> <nalaginrut@gmail.com <mailto:nalaginrut@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 < >> zelphirkaltstahl@posteo.de >> <mailto:zelphirkaltstahl@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 >> > >> > >> > >> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Use core or SRFIs? 2019-10-24 19:47 ` Zelphir Kaltstahl @ 2019-10-24 19:56 ` John Cowan 2019-10-24 20:18 ` Zelphir Kaltstahl 0 siblings, 1 reply; 11+ messages in thread From: John Cowan @ 2019-10-24 19:56 UTC (permalink / raw) To: Zelphir Kaltstahl; +Cc: Guile User 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 < zelphirkaltstahl@posteo.de> 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 < > zelphirkaltstahl@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 <nalaginrut@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 < >>> zelphirkaltstahl@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 >>> > >>> > >>> > >>> >> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Use core or SRFIs? 2019-10-24 19:56 ` John Cowan @ 2019-10-24 20:18 ` Zelphir Kaltstahl 0 siblings, 0 replies; 11+ messages in thread From: Zelphir Kaltstahl @ 2019-10-24 20:18 UTC (permalink / raw) To: John Cowan; +Cc: Guile User I see, thank you. I am still not sure using SRFI 151 will have any advantage for my program: - Is there any plan to phase out SRFI 60, so that in the future my code using SRFI 60 would not work any longer? - Is SRFI 60 considered to be slow running code? - Is there something bad about how SRFI 60 is implemented for Guile? - Why would I use SRFI 151 instead of SRFI 60? What is the advantage of that, considering, that it would bring more code into my project, which I would have to manage and even get to run first? So far SRFI 60 has worked in my refactored (from using bit vectors to using integers) procedures. As long as I cannot see an advantage of using SRFI 151, I will probably stick with SRFI 60 usage. I might not have some knowledge context here. Thanks for hinting to SRFI 151 though. I did not know that there were several "treat integers as bits" libraries out there. Regards, Zelphir On 10/24/19 9:56 PM, John Cowan wrote: > 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 > <zelphirkaltstahl@posteo.de <mailto:zelphirkaltstahl@posteo.de>> 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 >> <zelphirkaltstahl@posteo.de <mailto:zelphirkaltstahl@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 >>> <nalaginrut@gmail.com <mailto:nalaginrut@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 < >>> zelphirkaltstahl@posteo.de >>> <mailto:zelphirkaltstahl@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 >>> > >>> > >>> > >>> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Use core or SRFIs? 2019-10-24 15:55 Use core or SRFIs? Zelphir Kaltstahl 2019-10-24 16:01 ` Nala Ginrut @ 2019-10-24 17:01 ` Taylan Kammer 2019-10-24 19:48 ` Zelphir Kaltstahl 1 sibling, 1 reply; 11+ messages in thread From: Taylan Kammer @ 2019-10-24 17:01 UTC (permalink / raw) To: guile-user On 24.10.2019 17:55, Zelphir Kaltstahl 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? My decision-tree on this question would go like this: Do I *really* care about my code being portable? | -> Yes -> Use the SRFI | -> No | Is the Guile API an old and crusty one that may be deprecated? | -> Yes -> Use the SRFI | -> No | Is the Guile API noticeably better than the SRFI? | -> Yes -> Use the Guile API | -> No -> Use the SRFI The criteria for the API/implementation being "better" might include, depending on the situation and your subjective tastes: - simplicity - feature-richness - performance I would default to using the SRFI if the Guile-specific API isn't noticeably better, because maybe one day you or someone else will try to make your code portable. I don't know of an argument for using a Guile-specific API when there's an SRFI that does the same, is as good, and is supported by Guile. > Best regards, > > Zelphir > Kind regards, - Taylan P.S. for SRFI enthusiasts: I've written a ton of them in R7RS Scheme, many of which Guile might support: https://github.com/TaylanUB/scheme-srfis/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Use core or SRFIs? 2019-10-24 17:01 ` Taylan Kammer @ 2019-10-24 19:48 ` Zelphir Kaltstahl 0 siblings, 0 replies; 11+ messages in thread From: Zelphir Kaltstahl @ 2019-10-24 19:48 UTC (permalink / raw) To: guile-user Thanks for your input! This also reads reasonable. On 10/24/19 7:01 PM, Taylan Kammer wrote: > On 24.10.2019 17:55, Zelphir Kaltstahl 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? > My decision-tree on this question would go like this: > > Do I *really* care about my code being portable? > | > -> Yes -> Use the SRFI > | > -> No > | > Is the Guile API an old and crusty one that may be deprecated? > | > -> Yes -> Use the SRFI > | > -> No > | > Is the Guile API noticeably better than the SRFI? > | > -> Yes -> Use the Guile API > | > -> No -> Use the SRFI > > The criteria for the API/implementation being "better" might include, > depending on the situation and your subjective tastes: > > - simplicity > - feature-richness > - performance > > I would default to using the SRFI if the Guile-specific API isn't > noticeably better, because maybe one day you or someone else will try to > make your code portable. I don't know of an argument for using a > Guile-specific API when there's an SRFI that does the same, is as good, > and is supported by Guile. > >> Best regards, >> >> Zelphir >> > Kind regards, > > - Taylan > > > P.S. for SRFI enthusiasts: I've written a ton of them in R7RS Scheme, > many of which Guile might support: > > https://github.com/TaylanUB/scheme-srfis/ > ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-10-24 20:18 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-10-24 15:55 Use core or SRFIs? Zelphir Kaltstahl 2019-10-24 16:01 ` Nala Ginrut 2019-10-24 16:41 ` Zelphir Kaltstahl 2019-10-24 17:02 ` John Cowan 2019-10-24 18:26 ` Zelphir Kaltstahl 2019-10-24 18:50 ` John Cowan 2019-10-24 19:47 ` Zelphir Kaltstahl 2019-10-24 19:56 ` John Cowan 2019-10-24 20:18 ` Zelphir Kaltstahl 2019-10-24 17:01 ` Taylan Kammer 2019-10-24 19:48 ` Zelphir Kaltstahl
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).