[armedbear-devel] Longs, Bytes, or casting in general

[Mark Evenson]

On Jul 20, 2012, at 09:03 , Theam Yong Chew wrote:

> On 7/17/12, Theam Yong Chew <senatorzergling at gmail.com> wrote:
>> On 7/17/12, Mark Evenson <evenson at panix.com> wrote:
>>> 
>>> On Jul 17, 2012, at 04:19 , Theam Yong Chew wrote:
>>> 
>>>> Hi folks,
>>>> 
>>>> I was wondering how we can conveniently pass longs, bytes into normal
>>>> Java functions/constructors, for example,
>>>> 
>>>> (jnew "java.lang.Byte" 23)
>>>> ==>
>>>> Java exception 'java.lang.NoSuchMethodException:
>>>> Byte(java.lang.Integer)'.
>>>>  [Condition of type JAVA-EXCEPTION]
>>>> 
>>>> Here only constructor available is for "byte" inputs. It's a pain to
>>>> have to use this every time we use a byte, long, or similar:
>>>> 
>>>> (jnew (jconstructor "java.lang.Byte" "byte") 23)
>>>> #<java.lang.Byte 23 {3A9300BF}>
>>> 
>>> Unfortunately, I can't think of a way around this off the top of
>>> my head, although I may be missing something.  I suppose what we
>>> would want would be some sort of algorithm that would keep trying
>>> constructors by casting the types of parameters up/down their
>>> inheritance trees until it found a match.  Although it would be
>>> rather unsafe (from thinking about it briefly about casting things
>>> between signed/unsigned representation), it might be useful enough
>>> to construct something for experimentation.
>>> 
>>>> Relatedly/alternatively, is there a way convenient to coerce values to
>>>> a certain type, forcing 23 above (default int/Integer) to be a byte or
>>>> long?
>>> 
>>> JCOERCE does this:
>>> 
>>>   CL-USER> (jcoerce 23 "byte")
>>>   #<java.lang.Byte 23 {3A5F299D}>
>>> 
>>> although it always wraps primitive types in the associated numeric tower
>>> class.
>>> 
>> 
>> Thanks Mark & Rudi, good thoughts. I have used my own specific
>> wrappers in the class, but am looking for something lazier this
>> time. jcoerce could be what I need for that, while writing a specific
>> wrapper (as Rudi suggested) could be used in more "formal" settings.
>> 
>> Cheers & happy consing,
>> 
>> Yong
> 
> Oops, are these expected?
> 
> (jcoerce 23 "byte")
> ==> #<java.lang.Byte 23 {7EA742A1}>
> 
> (jcoerce 23 "int")
> ==> #<java.lang.Integer 23 {6E7C6928}>
> 
> All seems good, but this seems exceptional,
> 
> (jcoerce 23 "long")
> ; Evaluation aborted on #<TYPE-ERROR {4AAA045F}>.
> 
> (jcoerce (expt 2 128) "long")
> ==> ; Evaluation aborted on #<TYPE-ERROR {BCAB4A5}>.
> 
> Additionally, what about these?
> 
> (jcoerce 23 "float")
> ==> ; Evaluation aborted on #<TYPE-ERROR {3E478AD6}>.
> 
> (jcoerce 23 "double")
> ==> ; Evaluation aborted on #<TYPE-ERROR {4AC5AF5C}>.
> 
> It seems we have to use a closer matching type:
> 
> (jcoerce 23.0 "float")
> ==> #<java.lang.Float 23.0 {5DC7C133}>
> 
> (jcoerce 23d0 "double")
> ==> #<java.lang.Double 23.0 {11E63F4A}>
> 
> 
> 
> Is long missing support, and should float/doubles be automatically
> handled too? I suspect your previous comment means yes?

Looks like our implementation is buggy.  Need to collect all the info, and file an issue.