alessiostalla at gmail.com
Tue Mar 16 15:57:52 UTC 2010
On Tue, Mar 16, 2010 at 4:41 PM, Alan Ruttenberg
<alanruttenberg at gmail.com> wrote:
> On Mar 16, 2010, at 8:47 AM, dmiles at users.sourceforge.net wrote:
>> This is because ABCL:
>> Fixnum => int
>> Bignum => BigInteger
>> ABCL does not have a 'long' type so it is normal workaround to produce
>> a new 'long in your case.
>> So depends who is desiring: There is no real spec other than Allegro
>> But Allegro spec here is lossy..
>> (meaning if you went from a Lisp Bignum->Java->Lisp.. the number would
>> scaled back to Long.MAX_VALUE) So their spec is even more
>> It would be possible that when the Bignum is within normal java long
>> range the javaInstance() could return a java.lang.Long instead.
>> Does everyone think this would be better behavior than current ABCL and Allegro?
> I'm thinking it would be. However, given that there is a workaround I wouldn't put it as high priority - more as a cleanup.
I think it would be, too. It's also arguably more efficient to
manipulate Longs than BigIntegers. However, doing so requires that we
also implement promotion, I mean, if a calculation result overflows
longs it should be automatically upgraded to big integer. Java does
not do anything like that, so I believe we must do it ourselves.
>> On Mon, Mar 15, 2010 at 11:47 PM, Alan Ruttenberg
>> <alanruttenberg at gmail.com> wrote:
>>> Am I right to observe that abcl coerces any number > fixnum size to bigint?
>>> I'm having trouble calling a java method that takes a long. I seem to
>>> have worked around it calling the method with (new 'long
>>> "9223372036854775807") rather than 9223372036854775807 .
>>> Is this the desired behavior?
>>> armedbear-devel mailing list
>>> armedbear-devel at common-lisp.net
> armedbear-devel mailing list
> armedbear-devel at common-lisp.net
More information about the armedbear-devel