From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Zelphir Kaltstahl Newsgroups: gmane.lisp.guile.user Subject: Re: Use core or SRFIs? Date: Thu, 24 Oct 2019 22:18:39 +0200 Message-ID: References: <9ef7ae59-a2b8-ea06-131c-569512409047@posteo.de> <65d13994-0020-37bd-80ec-edf89e4e1e03@posteo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="113170"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: Guile User To: John Cowan Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Oct 24 22:19:34 2019 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iNjZz-000TCq-RC for guile-user@m.gmane.org; Thu, 24 Oct 2019 22:19:32 +0200 Original-Received: from localhost ([::1]:51698 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iNjZy-0000Eu-9E for guile-user@m.gmane.org; Thu, 24 Oct 2019 16:19:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35878) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iNjZG-000062-AW for guile-user@gnu.org; Thu, 24 Oct 2019 16:18:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iNjZD-0001ol-HR for guile-user@gnu.org; Thu, 24 Oct 2019 16:18:46 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:54023) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iNjZC-0001oE-U0 for guile-user@gnu.org; Thu, 24 Oct 2019 16:18:43 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 05FE52400E5 for ; Thu, 24 Oct 2019 22:18:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1571948321; bh=3XC+Eo+1Atu4HSVXex6HQb5rGuI1gRK85CtONRyT0TE=; h=Subject:To:Cc:From:Date:From; b=kvB5coZUrEQUa/u4SGW9WKQkO2DpiOp9xFRn4eKKzvyFmjfi/mcBpjovllTQT/OYg oq8oM5+8AkZWbESd7wRT/pHnqcBVxtduz4V2sbRq9XFSWw+azLKwIslFtjhLWcc6H1 q4TDt83Vgjm0vVMIPMBhm96nCrhqGFoH3OVMl+TLVmN0i7PvTHzqosIRE88GnLalRh i6VukuCVzvZrLUsB4qMrJANMpH19uq1Jl+rLqQzwnnSD10A8Qo2kLA5CSGnYgDV27s Md0IYNla7s0BS6c2jN2Ozt66IMcemJ1b0vHI9LZYDDVHPtrvDOIjj14B2KRT/Kt5zk sEl50fsEjmn+g== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 46zdqN15C9z9rxM; Thu, 24 Oct 2019 22:18:39 +0200 (CEST) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 185.67.36.66 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:15834 Archived-At: 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 .=C2= =A0 > Clone it and do a little adapting.=C2=A0 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 > > wrote: > > Sorry, I am a bit clueless right now. I have the following question= s: > > 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 > =C2=A0 (syntax-rules () > =C2=A0=C2=A0=C2=A0 [(time expr expr* ...) > =C2=A0=C2=A0=C2=A0=C2=A0 (begin > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (define start-time (current-ti= me time-monotonic)) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 expr > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 expr* ... > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (define end-time (current-time= time-monotonic)) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (let* ([diff (time-difference = end-time start-time)] > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 [elapsed-ns (+ (/ (time-nanosecond diff) 1e9) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 (time-second diff))]) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (display (format #= t "~fs~%" elapsed-ns))))])) > > > (time > =C2=A0(let ([int1 #b10101010] > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [int2 #b01010101]) > =C2=A0=C2=A0 (do ([i 1 (+ i 1)]) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ([> i 1000000]) > =C2=A0=C2=A0=C2=A0=C2=A0 (logand int1 int2)))) > ~~~~~ > > And here is the one for my old / current code: > > ~~~~~ > (use-modules (srfi srfi-19)) > > (define-syntax time > =C2=A0 (syntax-rules () > =C2=A0=C2=A0=C2=A0 [(time expr expr* ...) > =C2=A0=C2=A0=C2=A0=C2=A0 (begin > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (define start-time (current-ti= me time-monotonic)) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 expr > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 expr* ... > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (define end-time (current-time= time-monotonic)) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (let* ([diff (time-difference = end-time start-time)] > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 [elapsed-ns (+ (/ (time-nanosecond diff) 1e9) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 (time-second diff))]) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (display (format #= t "~fs~%" elapsed-ns))))])) > > > (define (binary-bit-vector-operation bv1 bv2 proc) > =C2=A0 (define (iter bit-list1 bit-list2) > =C2=A0=C2=A0=C2=A0 (cond [(or (null? bit-list1) (null? bit-list2)) = '()] > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [else (cons = (proc (car bit-list1) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 (car bit-list2)) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (iter (cdr bit-= list1) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 (cdr bit-list2)))])) > =C2=A0 (list->bitvector > =C2=A0=C2=A0 (iter (bitvector->list bv1) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (bitvector->list b= v2)))) > > > (time > =C2=A0(let ([bv1 #*10101010] > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [bv2 #*01010101]) > =C2=A0=C2=A0 (do ([i 1 (+ i 1)]) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ([> i 1000000]) > =C2=A0=C2=A0=C2=A0=C2=A0 (binary-bit-vector-operation > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bv1 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bv2 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (lambda (b1 b2) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (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!=C2=A0 Just look at the logic in srfi-151.sld = and >> see how it needs to be modified for Guile.=C2=A0 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 >> > >> 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 >> >> . >> 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.=C2=A0 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.=C2= =A0 >>> It is part of the Tangerine Edition of R7RS-large. >>> >>> On Thu, Oct 24, 2019 at 12:43 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 >>> > wrote: >>> >>> > Hello Guile Users! >>> > >>> > I have a question regarding usage of SRFIs in Guile cod= e. >>> > >>> > 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 >>> > >>> > >>> > >>>