guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SRFI-151 (Bitwise Operations) Implementation


From: Linus Björnstam
Subject: Re: SRFI-151 (Bitwise Operations) Implementation
Date: Thu, 09 Jan 2020 08:15:18 +0100
User-agent: Cyrus-JMAP/3.1.7-740-g7d9d84e-fmstable-20200109v1

I have a port of the SRFI code as well, using renaming of guile and srfi-60 
procedures as necessary. It has the make-bitwise-generator from srfi-151.

https://bitbucket.org/bjoli/guile-srfi-151/

I will move all that code to sourcehut whenever I have the time since bitbucket 
is shutting down HG support.

It passes all of John's tests.

-- 
  Linus Björnstam

On Thu, 9 Jan 2020, at 05:28, Frank Terbeck wrote:
> Hey Guilers!
> 
> Since I got  a project that uses (potentially large)  integers to encode
> bits in registers,  I was looking at  SRFIs that deal with  that type of
> domain. The most recent entry is SRFI-151, which is in final status.
> 
> Since Guile currently doesn't have an implementation of this SRFI, I fi-
> gured I might as well add one.
> 
> I tried to reuse as many facilities  that are already in Guile to get to
> a complete implementation. So it reuses  stuff from the R6RS bitwise li-
> brary, as well as SRFI-60 (which is titled “Integers as Bits”) and other
> functions from Guile's core.
> 
> SRFI-151 has one  API that returns a SRFI-121 generator¹  to traverse an
> integer. Since Guile currently  doesn't have a SRFI-121 implementation²,
> this function³ is missing from this implementation.
> 
> The implementation can be found here:     https://gitlab.com/ft/srfi-151
> 
> The test-suite  reproduces the examples  from the specification,  plus a
> couple of additional ones.  Maybe this is useful for someone.
> 
> 
> Regards, Frank
> 
> ¹ http://srfi.schemers.org/srfi-121/srfi-121.html
> ² https://www.mail-archive.com/address@hidden/msg14950.html
> ³ make-bitwise-generator
> 
> -- 
> In protocol design, perfection has been reached not when there is
> nothing left to add, but when there is nothing left to take away.
>                                                   -- RFC 1925
> 
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]