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: Wed, 23 Jan 2013 00:27:57 +0100 Message-ID: <973AF25A-2756-4FCD-9EA5-3E63DAB4E167@bluewin.ch> References: <0F432FA1-CFF8-4A22-A477-5291A1B9925D@bluewin.ch> <87ip9mgzp4.fsf@gnu.org> <878v7m5xdh.fsf@pobox.com> <2E5FFE0D-9001-409C-BCD4-9EE3BF9883F0@bluewin.ch> <87d2wxos8b.fsf@pobox.com> 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 1358897297 26474 80.91.229.3 (22 Jan 2013 23:28:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Jan 2013 23:28:17 +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 Wed Jan 23 00:28:36 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 1TxnGe-0000dr-0E for guile-devel@m.gmane.org; Wed, 23 Jan 2013 00:28:36 +0100 Original-Received: from localhost ([::1]:46148 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TxnGM-0003UZ-MC for guile-devel@m.gmane.org; Tue, 22 Jan 2013 18:28:18 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:42227) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TxnGG-0003Sv-Dz for guile-devel@gnu.org; Tue, 22 Jan 2013 18:28:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TxnGB-00033d-SW for guile-devel@gnu.org; Tue, 22 Jan 2013 18:28:12 -0500 Original-Received: from zhbdzmsp-smta17.bluewin.ch ([195.186.99.133]:50193) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TxnG6-00031r-TT; Tue, 22 Jan 2013 18:28:03 -0500 Original-Received: from [195.186.227.131] ([195.186.227.131:39222] helo=zhhdzmsp-smta14.bluewin.ch) by zhbdzmsp-smta17.bluewin.ch (envelope-from ) (ecelerity 2.2.3.47 r(39824M)) with ESMTP id 32/3C-25886-E702FF05; Tue, 22 Jan 2013 23:27:59 +0000 Original-Received: from [10.0.1.10] (62.203.143.186) by zhhdzmsp-smta14.bluewin.ch (8.5.142) (authenticated as dll@bluewin.ch) id 50A6219906596BC7; Tue, 22 Jan 2013 23:27:58 +0000 In-Reply-To: <87d2wxos8b.fsf@pobox.com> 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:15555 Archived-At: On Jan 22, 2013, at 21:52, Andy Wingo wrote: Hello, > Handling stride and bounds is not a problem. The generic array handle > interface lets us do this in a straightforward way. Certainly, but in this case, a vector is just an array of rank 1. I = guess I don't value that much having a specific interface just for rank = 1 objects. > It was in 1.8. In 2.0 it table-driven and extensible, which isn't a = bad > thing at all IMO. There is still some case jumping in evidence in scm_c_vector_ref() ... I don't think of vectors and bytevectors and uniform vectors as distinct = types. Uniform vectors are an optimization where the objects in the = =91vector=92 share the type tag. That's why for me it makes perfect = sense to have (vector? #u8(1)) -> #t and to allow (vector-ref #u8(1) 0). = And the array/typed-array interface already works like this. > scheme@(guile-user)> (vector? "foo") > $1 =3D #f > scheme@(guile-user)> (generalized-vector? "foo") > $2 =3D #t > scheme@(guile-user)> (vector-ref "foo" 1) > :3:0: Wrong type argument in position 2: 1 > scheme@(guile-user)> (generalized-vector-ref "foo" 1) > $3 =3D #\o >=20 > The error message is incorrect, unfortunately... anyway. I think this > highlights the reason why we can't make vector-ref generic: vector? = and > string? should be disjoint predicates. (Or should they? Scheme has > real problems with polymorphism. I don't know and am interested in > arguments.) I can rationalize this because a string is (in principle) sufficiently = different from a vector, maybe because of Unicode (speaking over my = head here). Not the case for numeric vectors or bytevectors, although = the standards also disagree for the latter.=20 > My instinct would be to redefine vector as an interface of sorts: > vector-indexable. Generic vector. generalized-vector -- oh wait = we're > back to the beginning! If I understand correctly, at this point it's a matter of names =97we = can't use use vector?, vector-ref, etc. for this generic interface = because those names are captured by the standard. > Not sure this is really what should happen. The generalized array > interface from generalized-arrays can deal with this quite well, with = no > need for a restriction. I'm good with vector being shorthand for rank-1 array. Or even shorthand = for type-#t rank-1 array. I was trying to carve an exclusive function = for =91vector=92 that went beyond being shorthand for rank-1 array. It = stands out that vector? is in fact making that distinction (vector? = meaning both SCM elements *and* no stride/bounds). Maybe it shouldn't? > I think the string case is vexing, and we really need to go back to > fundamentals. >=20 > What is a vector? >=20 > Possible answers: >=20 > 1. A vector is something that answers #t to vector?, which contains > some number of storage slots accessible in a mostly-O(1) way, the > number of slots is given by vector-length, and the slots can be > accessed with vector-ref and vector-set!. >=20 > 2. A vector is a specific kind of object, implementing the interface > described above, and disjoint from all other kinds of objects. >=20 > 3. A vector is a specific kind of object, as before, disjoint from = all > other kinds of objects defined in the R5RS. >=20 > 4. A vector is a specific kind of object, as before, disjoint from = all > other kinds of objects defined in the R6RS. >=20 > (1) defines vectors as an interface. >=20 > (2) defines vectors as a specific data structure. >=20 > (3) admits to a number of distinct types that may be vectors, of which > one kind is defined by the R5RS. >=20 > (4) is like (3), but it precludes bytevectors from being vectors. >=20 > What do you think a vector is? :) Something between 1 and 2=85 If vector? has to be disjoint from bytevector?, presumably that's true = also for f64vector?, etc. in which case we should * keep generalized-vector as it is. * restrict vector- to objects that satisfy vector?. vector? allows = stride/bounds but not uniform type. This provides the disjointness. The array interface seems more logical. Everything is array? and then = things are typed-array? of specific types. I see myself not using the = vector interface at all. I don't know. - Daniel