bugKawa - Bugs: bug #49537, 'format' on String[] (supported?)...

 
 

bug #49537: 'format' on String[] (supported?) prints only first

Submitter:  Sudarshan S Chawathe <chaw>
Submitted:  Sat 05 Nov 2016 01:10:52 AM UTC
   
 
Category:  Scheme language Severity:  3 - Normal
Item Group:  Unexpected result Status:  Postponed
Privacy:  Public Assigned to:  bothner
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 19 Dec 2016 09:42:52 AM UTC, comment #4: 

This has been changed/fixed in the "invoke" branch.

Per Bothner <bothner>
Group administrator
Sun 06 Nov 2016 04:25:51 PM UTC, comment #3: 

A Java varargs methods that takes (S s, T... ts) is compiled to (S s, T[] ts).  For compatibility reasons, Java allows such a method to be called either with an array or flattened: (s, ts) or (s, t1, t2, t2), where ts == {t1, t2, t3}.  The latter is basically compiled into the former.

For compatibility (again), Kawa allows either when calling a varargs method.  A varargs method is either one written as such in Java, or a Kawa method with a #!rest parameter whose type is specified to be an array (rather than a list).

There is obviously an ambiguity when T==Object and the number of varargs arguments is 1.

See the explicitArrayAsVarArgsAllowed fied in PrimProcedure.java. I think you'll find if you change that to false, the weird behavior goes away. I'll probably change it to false for Kawa 3.0 (based on the invoke branch).

Per Bothner <bothner>
Group administrator
Sat 05 Nov 2016 01:31:39 PM UTC, comment #2: 

A quick additional observation which may be relevant:  If the first argument to format is changed from #t to #f, the result changes to the expected:

#|kawa:1|# (format #f "~s~%" (String[] "s2" "s3" "s5"))
["s2" "s3" "s5"]
#|kawa:2|# (format #t "~s~%" (String[] "s2" "s3" "s5"))
"s2"
#|kawa:3|#


Separately from the above, a question (out of curiosity) regarding the splicing aspect you noted earlier: Is it true that the behavior is caused by the array getting spliced in (to maintain the deprecated usage) when it shouldn't be (based on viewing it as a single Scheme object)? 

I ask because the above (and my earlier) examples are different from the ones in the docs in that they assume that the array will not be spliced.  Which then makes me wonder how the example with the int[] works at all.  (I peeped into the gnu/kawa/format/* code quickly but didn't look very carefully.)

Sorry for the rambling.  My main purpose is to include the earlier data point on #t v. #f in format.



Sudarshan S Chawathe <chaw>
Sat 05 Nov 2016 04:48:33 AM UTC, comment #1: 

I believe you've hit this issue, mentioned in the "Recent News" section of the manual:

  Kawa traditionally followed Java in allowing you to pass an array with the "rest" arguments to a varargs method. (A "varargs" method includes Java varargs methods, as well as Kawa methods with a #!rest parameter that is explicitly typed to be an array type.) For example, you could write:

  (define args (Object[] 3 "cm"))
  (java.lang.String:format "length:%s%s" args)

  This is deprecated, and may stop working in a future release.
  Instead, use the splice operator:

  (java.lang.String:format "length:%s%s" @args)


Per Bothner <bothner>
Group administrator
Sat 05 Nov 2016 01:10:52 AM UTC, original submission:  

I am not sure if 'format' is meant to support Java arrays and so am not sure if this is a bug.  Nevertheless, following is the behavior that seems odd to me:

chaw@vereq:~$ kawa
#|kawa:1|# (format #t "~s~%" (int[] 2 3 5))
[2 3 5]
#|kawa:2|# (format #t "~s~%" (String[] "s2" "s3" "s5"))
"s2"
#|kawa:3|#


chaw@vereq:~$ kawa --version
Kawa 2.1.91 (revision 9020M)
Copyright (C) 2016 Per Bothner
chaw@vereq:~$ uname -a
Linux vereq.eip10.org 3.16.0-4-686-pae #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) i686 GNU/Linux
chaw@vereq:~$
java -version
openjdk version "1.8.0_102"
OpenJDK Runtime Environment (build 1.8.0_102-8u102-b14.1-1~bpo8+1-b14)
OpenJDK Server VM (build 25.102-b14, mixed mode)


Sudarshan S Chawathe <chaw>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bothner (Posted a comment)
  • -email is unavailable- added by chaw (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-11-05 bothner StatusNone Postponed
        Assigned toNone bothner

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code