(Previous discussion continued)
|
||
Fwd: Re: Numerical limits (fixnum vs bignum) Lassi Kortela (20 Sep 2019 22:41 UTC)
|
||
Re: Numerical limits (fixnum vs bignum)
Lassi Kortela
(20 Sep 2019 22:51 UTC)
|
||
(missing)
|
||
Re: Numerical limits (fixnum vs bignum)
Lassi Kortela
(21 Sep 2019 07:57 UTC)
|
||
Re: Numerical limits (fixnum vs bignum)
John Cowan
(21 Sep 2019 15:21 UTC)
|
Fwd: Re: Numerical limits (fixnum vs bignum) Lassi Kortela 20 Sep 2019 22:41 UTC
On Fri, Sep 20, 2019 at 6:23 PM Lassi Kortela <xxxxxx@lassi.io> wrote: Agreed. The fx procedures raise an exception, which I think is good enough > In R7RS it's an error (Chicken just assumes that what you pass in is a fixnum, even if it's a pointer). > But we have to guarantee that users can pass any Unicode codepoint into > any of the procedures, and they can handle it without raising an > exception. It's not nice if for example `ascii-string?` blows up > mysteriously when given some string with huge Unicode values. > No, ascii-string clearly has to accept any string at all, but I think that's a special case. The other procedures should I think accept any character or any exact integer 0-127. Is it guaranteed in all of R6RS, R7RS-small and R7RS-large that > char->integer always returns a fixnum? > R7RS-small theoretically allows non-Unicode characters to exist, with codepoints from #x11FFFF onwards, and the largest fixnum that's actually required to exist is #x7FFFFF (though few if any Schemes limit fixnums that severely). In practice nobody implements or uses such characters. -- John Cowan http://vrici.lojban.org/~cowan xxxxxx@ccil.org Overhead, without any fuss, the stars were going out. --Arthur C. Clarke, "The Nine Billion Names of God"