Re: Use core or SRFIs?

[Zelphir Kaltstahl]

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
> <address@hidden <mailto:address@hidden>> 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
>>     <address@hidden <mailto:address@hidden>>
>>     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
>>>         <address@hidden <mailto:address@hidden>> 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 <
>>>             address@hidden
>>>             <mailto:address@hidden>> 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
>>>             >
>>>             >
>>>             >
>>>