Re: Scheme vector to Java byte[]?

["Hoehle, Joerg-Cyril" <Joerg-Cyril dot Hoehle at t-systems dot com>]

Hi,

Per wrote:

>I wrote up something for the manual.  See below.
I like what you write, esp. document the pointer sharing, the Common-Lisp fill-pointer possibility etc. BTW, double for f*64*vector.

>That might below in a FAQ or Wiki, but I'm not sure it belongs
>in a reference manual.  It it does, where would you put it, and
>what would you write?

The section I have in mind is "Low-level functions", because it's subtitled "The Scheme-Java interface". That's exactly the topic now.

I would not put it into the "Uniform Vectors" section. That section is IMHO about pure Scheme (well, SRFI-4), not Java. People interested in Scheme/SRFI programming should not be bothered by the Kawa stuff. At most I'd put a link there to the low-level section.

BTW, I was ready to suggest having a list of implemented SRFI be added to the document. The "Features" section is not the place where I was looking for them, and the index doesn't mention SRFI.
1. Please add SRFI to the concept index (which overall-index claims to contain) with a link to the features page.
2. Add a subtitle to the features link on the main page
   Features:: Kawa unique selling points, differences from Scheme and SRFI
   Features:: what Kawa supports (OO and types, SRFI, XML, ...)


Returning to u8vector->byte[]
>> 3. I believe there should be an easy way to get the bytes[] out of
>Perhaps, but should it copy or not?  What if the u8vector's length
>is different from the underlying array's length?

At first, it should not copy. Since you documented the sharing for byte->u8vector, it would be logical to share the other way round too.
Furthermore, if the goal is to work with Scheme as long as possible (i.e. use u8vector and lists and Scheme procedures) and only talk to Java where needed, copying would induce a penalty against Java-only programmers.

I'm unsure what you mean by "is different from the underlying array's length". I suppose it's the fill-pointer feature. I'd keep things simple and remember that this documentation is part of the "low-level: Scheme to Java interface" section. Thus I'd document that the whole array is seen by Java, not the one limited by the Lisp-level fill-pointer.
Similarly, Common Lisp has functions which disregard the fill-pointer (see the concepts of "active", "valid array index" and "dimension" in the CLHS glossary).
http://www.lisp.org/HyperSpec/FrontMatter/Starting-Points.html

Common Lisp AREF and SVREF disregard a possible fill-pointer.

It looks like all of this boils down to making 'getBytes public instead of protected.

Regards,
	Jorg Hohle