Use core or SRFIs?

Use core or SRFIs?

[Zelphir Kaltstahl]

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

Re: Use core or SRFIs?

[Nala Ginrut]

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

Re: Use core or SRFIs?

[Zelphir Kaltstahl]

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

Re: Use core or SRFIs?

[Taylan Kammer]

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/

Re: Use core or SRFIs?

[John Cowan]

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

Re: Use core or SRFIs?

[Zelphir Kaltstahl]

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

Re: Use core or SRFIs?

[John Cowan]

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

Re: Use core or SRFIs?

[Zelphir Kaltstahl]

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

Re: Use core or SRFIs?

[Zelphir Kaltstahl]

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

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

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