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: propose deprecation of generalized-vector-* Date: Tue, 22 Jan 2013 19:31:29 +0100 Message-ID: References: <0F432FA1-CFF8-4A22-A477-5291A1B9925D@bluewin.ch> <87ip9mgzp4.fsf@gnu.org> <878v7m5xdh.fsf@pobox.com> <2E5FFE0D-9001-409C-BCD4-9EE3BF9883F0@bluewin.ch> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1358879503 19693 80.91.229.3 (22 Jan 2013 18:31:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Jan 2013 18:31:43 +0000 (UTC) Cc: ludo@gnu.org, guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jan 22 19:32:01 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 1Txidb-0000SG-Dx for guile-devel@m.gmane.org; Tue, 22 Jan 2013 19:31:59 +0100 Original-Received: from localhost ([::1]:57538 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TxidK-0008B0-84 for guile-devel@m.gmane.org; Tue, 22 Jan 2013 13:31:42 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:39474) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TxidF-0008Ai-Pu for guile-devel@gnu.org; Tue, 22 Jan 2013 13:31:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TxidE-0006B7-5z for guile-devel@gnu.org; Tue, 22 Jan 2013 13:31:37 -0500 Original-Received: from zhbdzmsp-smta17.bluewin.ch ([195.186.99.133]:48279) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TxidD-0006AD-Vq; Tue, 22 Jan 2013 13:31:36 -0500 Original-Received: from [195.186.227.131] ([195.186.227.131:60365] helo=zhhdzmsp-smta14.bluewin.ch) by zhbdzmsp-smta17.bluewin.ch (envelope-from ) (ecelerity 2.2.3.47 r(39824M)) with ESMTP id 0E/E6-25886-30BDEF05; Tue, 22 Jan 2013 18:31:32 +0000 Original-Received: from [10.23.3.35] (128.179.67.121) by zhhdzmsp-smta14.bluewin.ch (8.5.142) (authenticated as dll@bluewin.ch) id 50A621990653DA2B; Tue, 22 Jan 2013 18:31:31 +0000 In-Reply-To: <2E5FFE0D-9001-409C-BCD4-9EE3BF9883F0@bluewin.ch> 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.133 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:15549 Archived-At: On Jan 22, 2013, at 15:31, Daniel Llorens wrote: > On Jan 21, 2013, at 17:11, Andy Wingo wrote: >> I always wondered why vector-ref and vector-set! didn't do what >> generalized-vector-ref and generalized-vector-set! did. I mean, they >> are primitive generics. Might it make sense to allow vector-ref to >> operate as generalized-vector-ref did? I really don't know, = myself... >=20 > I think this is fair for type polymorphism. It makes sense to let = vector- work on uniform vectors because the implementation should be = identical. >=20 > It's different for arrays because even for the 1D case you need a = stride and an indirection (and in the current Guile, also bounds). >=20 > That is, I think that the main distinction is not between rank=3D1 and = rank!=3D1 objects, but between =91container=92 and =91views=92 (if this = makes sense). This is why generalized-vector- was bad. It was an if x, = do X, if y, do Y kind of abstraction. To be a bit less vague=85 The current implementation of scm_c_vector_ref() results in behavior = such as scheme@(guile-user)> (define (array-col A j) (make-shared-array A = (lambda (i) (list i j)) (car (array-dimensions A)))) scheme@(guile-user)> (define A #2((1 2) (3 4))) scheme@(guile-user)> (vector? (array-row A 0)) $1 =3D #f scheme@(guile-user)> (vector-ref (array-col A 0) 0) $2 =3D 1 I think vector-ref should probably fail in this case, i.e. the second = branch of scm_c_vector_ref() should be gone. On the other hand scm_c_uniform_vector_ref() goes through = scm_c_generalized_vector_ref() which does handling of = offset/stride/bounds. Instead, uniform vectors should be forced to have = contiguous storage (no offset/stride/bounds) so that scm_c_vector_ref() = is able to handle them and scheme@(guile-user) [1]> (vector-ref #f64(1 2 3) 0) :32:0: In procedure #:32:0 ()>: :32:0: Wrong type argument in position 2: 0 works. This should be all right, because the only way to get = non-contiguous arrays from Scheme (iiuc) is through make-shared-array = =97it's natural that the result should be handled with the array- = functions. The idea is to merge the implementations of SCM vectors and uniform = vectors in the same way that scheme@(guile-user)> (make-array 0 2 2) $3 =3D #2((0 0) (0 0)) is equivalent to scheme@(guile-user)> (make-typed-array #t 0 2 2) $4 =3D #2((0 0) (0 0)) I'm not very conversant with the macrology in vectors.h or the exact way = uniform vectors are implemented, but it seems that this should be = possible. Thoughts? - Daniel