From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Llorens Newsgroups: gmane.lisp.guile.devel Subject: Re: vectors are something else Date: Fri, 12 Apr 2013 09:23:09 +0200 Message-ID: References: <26E44D8E-2A75-466E-BFAE-07E15F60A981@bluewin.ch> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1365752214 2106 80.91.229.3 (12 Apr 2013 07:36:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Apr 2013 07:36:54 +0000 (UTC) Cc: guile-devel To: Daniel Hartwig Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Apr 12 09:36:58 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UQYXZ-0004Rp-KB for guile-devel@m.gmane.org; Fri, 12 Apr 2013 09:36:57 +0200 Original-Received: from localhost ([::1]:38963 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQYXZ-00081P-35 for guile-devel@m.gmane.org; Fri, 12 Apr 2013 03:36:57 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45516) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQYXV-000808-0Z for guile-devel@gnu.org; Fri, 12 Apr 2013 03:36:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQYXT-00089u-Ex for guile-devel@gnu.org; Fri, 12 Apr 2013 03:36:52 -0400 Original-Received: from zhbdzmsp-smta15.bluewin.ch ([195.186.99.132]:61723) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQYKI-0003c7-0z for guile-devel@gnu.org; Fri, 12 Apr 2013 03:23:14 -0400 Original-Received: from [195.186.227.130] ([195.186.227.130:52265] helo=zhhdzmsp-smta12.bluewin.ch) by zhbdzmsp-smta15.bluewin.ch (envelope-from ) (ecelerity 2.2.3.47 r(39824M)) with ESMTP id 00/3E-14388-E56B7615; Fri, 12 Apr 2013 07:23:10 +0000 Original-Received: from [10.0.1.10] (62.203.189.176) by zhhdzmsp-smta12.bluewin.ch (8.5.142) (authenticated as dll@bluewin.ch) id 510085B006CB0EB0; Fri, 12 Apr 2013 07:23:10 +0000 In-Reply-To: X-Mailer: Apple Mail (2.1085) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 195.186.99.132 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16223 Archived-At: On Apr 12, 2013, at 01:53, Daniel Hartwig wrote: > On 11 April 2013 07:07, Daniel Llorens = wrote: >>=20 >> After the array-map patches, I've gone through the vector/array = implementation and there's some stuff I'd like to fix. In stable-2.0 = today: >>=20 >> (define a (make-typed-array ''f64 0 '(1 2)) >> a >> =3D> #1f64@1(0.0 0.0) >>=20 >> so far so good. >>=20 >> (uniform-vector? a) >> =3D> #t >>=20 >> (f64vector-ref? a) >> =3D> #t >>=20 >> so far so good. >>=20 >> (uniform-vector-ref a 0) >> =3D> 0.0 >>=20 >> This is a bug, since the valid indices are 1 and 2. This bug is in = scm_c_generalized_vector_ref (and elsewhere): >=20 > For a vector, the valid indices are as specified by r5rs: >=20 > The _valid indexes_ of a vector are the exact non-negative > integers less than the length of the vector. The first element in a > vector is indexed by zero, and the last element is indexed by one less > than the length of the vector. >=20 > which applies even when accessing arrays as vectors. Offset indexing > is a feature of the array interface only. Right. I want [0] (vector-ref #@1(1 2 3 4) 1) =3D> 2 to fail with a type error, which is consistent with r5rs. However my proposal is also to produce the same type error when the = argument is a rank-1 array with base!=3D0 or inc!=3D1. These may be = indexed from 0, but can only be produced by using the array interface, = and use the array implementation internally. E.g. now you can do [1] (vector-ref (make-shared-array #(1 2 3 4) (lambda (i) (list (* 2 i))) 2) = 0) =3D> 1=20 which is 'correct' (and that object cannot be told apart from a plain = vector using r5rs functions) even though [2] (vector? (make-shared-array #(1 2 3 4) (lambda (i) (list (* 2 i))) 2)) = =3D> #f Forbidding [1] will break some programs. Yesterday it broke a program of = mine where I was using vector-ref on an array which was a row in a rank = 2 array. I think we have license to do this anyway because of [2] and = because that's how the typed vectors work too (bitvector-, bytevector-). The other option is to make [1] #t. But then, vector- is just an alias = of array-. Might as well have (vector-ref #@1(1 2 3 4) 1) work properly. This discussion came up months ago when the generalized-vector interface = was deprecated. At that time, Andy Wingo wanted to keep [1] working or = at least I that's what I understood. My motivation try this again now is = to simplify the implementation of arrays. Currently there is a chain of 4 function calls for a single use of = array-ref (and I may have missed some). This is unacceptable. Also the = vector and uniform-vector functions are all branched on whether the = argument is internally a 'vector' or 'srfi4-vector' or not, which is the = source of the inconsistencies I reported in the previous post.=20 I'll send a patchset later today with at least the interface changes. Regards, Daniel