Re: Use core or SRFIs?

[John Cowan]

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> 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> 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>
>> 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> 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
>>> >
>>> >
>>> >
>>>
>>