Some comments relating to ICFP contest Andre van Tonder (25 Jul 2006 20:25 UTC)
Re: Some comments relating to ICFP contest Alex Shinn (26 Jul 2006 02:04 UTC)
Re: Some comments relating to ICFP contest Michael Sperber (26 Jul 2006 05:03 UTC)
Re: Some comments relating to ICFP contest Alan Watson (26 Jul 2006 08:40 UTC)
Re: Some comments relating to ICFP contest Michael Sperber (26 Jul 2006 09:02 UTC)
Re: Some comments relating to ICFP contest bear (04 Sep 2006 17:31 UTC)
Re: Some comments relating to ICFP contest Andre van Tonder (26 Jul 2006 15:12 UTC)
Re: Some comments relating to ICFP contest Michael Sperber (26 Jul 2006 15:35 UTC)
Re: Some comments relating to ICFP contest Andre van Tonder (26 Jul 2006 16:23 UTC)
Re: Some comments relating to ICFP contest Michael Sperber (27 Jul 2006 15:51 UTC)

Re: Some comments relating to ICFP contest Andre van Tonder 26 Jul 2006 15:12 UTC

On Wed, 26 Jul 2006, Michael Sperber wrote:

> For sure, SRFI 77 doesn't have 32-bit or 64-bit integers *as types*.
> (And that would cause major pain with the way Scheme's arithmetic is
> generally set up.)

> However, it does have the necessary operations to
> easily implement 32-bit or 64-bit unsigned or two's complement
> arithmetic in the form of `div+mod' and `div0+mod0' operations.  As
> such, it also has bit operations on them.

Conceded.  But the context of my comment was efficiency.  How likely is it that
implementations will compile the expression (exact-and (* x y) #xFFFFFFFF) to
the single machine instruction available on many architectures?

Given that SRFI-74 already mentions ranges u32, s32, ..., operations such as
exact-u32*, exact-s32-div, ..., would seem natural and could address the
efficiency concern.

> SRFI 77 doesn't have, but R6RS will have, support for "unboxed arrays"
> of numbers in the form of a variation on SRFI 74.  I'm not sure they
> qualify as "uniform," but is the uniformity crucial to your
> application?

Oh, they would probably do the job.

Andre