Re: coerce a number to a short

> On Dec 13, 2019, at 20:14, somewhat-functional-programmer <[email protected]> wrote:
> 
> I've looked into this issue at length now and I think I have something worth
> discussing and potentially trying[0] . The root issue here lies in how ABCL
> converts its CL representation of integers to Java, as well as its conversion
> of Java primitives to other Java primitives.

[…]

> What are your thoughts? I dislike backwards incompatible changes like this, but
> I think the impact is probably low due to the fact that method resolution used
> rules to only find widening conversions, and the fact that short and byte are
> not as commonly used in method calls.

After much study, reflection and experimentation, I have decided that
I didn't like the incompatible change introduced by this patch in
requiring Lisp code to explictly JCOERCE arguments to find Java call
sites.

Instead, I [managed to solve the original poster's problems of not being able
to call Java methods whose parameters where short or byte][1] by modifying the
Java.findMethod() machinery to use the actual arguments that will be used in
the call for a decision whether to narrow types for calling a given function
makes sense for short or int types.  I was unable to find other problems with
converting primitive types.

[With a little additional elbow grease][2] , I was able to also code a
[fix for finding call-sites][3] that take a varargs parameter such as

    java.util.Arrays.asList(T... arg)

[1]: <https://github.com/armedbear/abcl/pull/144/commits/bfa6e9e44f854ca0c175e73e358d307a7507eeda>
[2]: <https://github.com/armedbear/abcl/pull/144/commits/9fb39d2c0e445bf45739a4f7bb25938ea23f8b5a>
[3]: <https://abcl.org/trac/ticket/259>

Given the major holes pointed out by the
someone-functional-programmers examination of of the
narrowing/widening convention, I am surprised that there are not more
Java calls that can't be made with our current FFI machinery, but
after scouring our bug reports and trying various methods I can't find
any examples.  If anyone knows of a case of the Java FFI not finding
call sites with these patches, please pipe up.

--

While reviewing this patch, I noticed that since one can't use
CL:COERCE to perform a conversion that loses information, as

    (coerce 256 '(unsigned-byte 8))

signals some sort of error for all existing Lisp implementations
(SBCL, CCL, ECL, CLISP, Allegro, LispWorks), therefore I would argue
that something like
   
    (jcoerce 256 "byte")

should also signal an error.  Therefore, JCOERCE should be reworked to
signal some sort of error if the conversion would lose information.  I
continue to work through what we would be needed to both incoporate
somewhat-functional-programmer's patch, which allows things like 

    (jcoerce 2.4 "float")

to work, but that would signal TYPE-ERROR conditions when JCOERCE
call that lose information are attempted.   

My current inclination would be to release the current state as
abcl-1.6.1 without incorporating this patch, as I think the need to
[patch ABCL-ASDF's inablity to download Maven artifacts][4] is much
more pressing than untangling the incomplete inconsistencies in
JCOERCE.

[4]: https://mailman.common-lisp.net/pipermail/armedbear-devel/2020-February/004035.html

-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."