This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
> From: Marcin 'Qrczak' Kowalczyk <qrczak@xxxxxxxxxx> >> Paul Schlie <schlie@xxxxxxxxxxx> writes: >> - Personally, it seems reasonable to require that a base implementation >> support only finite modular integers with a precision sufficient to >> represent the larger of: >> >> (integer-range) => <max-positive-representable-integer> or >> >> (length <list-of-all-allocatable-elements-for-a-given-implementation>) > > My toy Scheme interpreter is hosted by a language with native bignums, > and no distinction between fixnums and bignums in the public API. > A requirement to support modular arithmetic would be inconvenient here. - then (integer-range) for your implementation would be fairly large, and no ambiguity exists unless the maximum bignum value is overflowed. > (Actually the hosting language does have some unsafe fixnum-only > operations, but I'm not sure whether to treat them as public.) - unless I misunderstand, unless a bignum implementation supports unbounded indefinitely large values (which basically means that an arithmetic computation may crash a program if requiring more memory than available be allocated to return an arbitrarily large value), then it seems reasonable that even bignum implementations should support some bound; and the question then becomes, what are the semantics of an operation which arithmetically overflow's the result's bound or insufficient memory exists to safely allocate to that result (i.e. modulo, +/- Inf, or NaN return value)? [throwing an exception is most likely less desirable than simply knowing that a well defined overflow behavior will result if a value exceeds some maxium range, even (or especially) for bignums, as there's no magic in the world, they simply can't be indefinitely large]