From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Hartwig Newsgroups: gmane.lisp.guile.devel Subject: Re: vectors are something else Date: Fri, 12 Apr 2013 18:15:05 +0800 Message-ID: References: <26E44D8E-2A75-466E-BFAE-07E15F60A981@bluewin.ch> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1365761712 2990 80.91.229.3 (12 Apr 2013 10:15:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Apr 2013 10:15:12 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Apr 12 12:15:16 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 1UQb0l-0007Ps-CV for guile-devel@m.gmane.org; Fri, 12 Apr 2013 12:15:15 +0200 Original-Received: from localhost ([::1]:42588 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQb0k-0002B8-U9 for guile-devel@m.gmane.org; Fri, 12 Apr 2013 06:15:14 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54659) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQb0e-00025P-6G for guile-devel@gnu.org; Fri, 12 Apr 2013 06:15:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQb0c-0005JZ-IS for guile-devel@gnu.org; Fri, 12 Apr 2013 06:15:08 -0400 Original-Received: from mail-ie0-x22d.google.com ([2607:f8b0:4001:c03::22d]:46987) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQb0c-0005I5-6W for guile-devel@gnu.org; Fri, 12 Apr 2013 06:15:06 -0400 Original-Received: by mail-ie0-f173.google.com with SMTP id k13so120008iea.4 for ; Fri, 12 Apr 2013 03:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=3iYWZ7CeEZBZdW5V5vQwe78yG0nZZgNKCVqIpPXgSNw=; b=c13dO5k9Z2YPNay6QZQ4z7wS1uAi0DHpOr2Ovwe/2qpdn8gEtrvv072Ui+COwR/NQf gmAucDEWRvxK94sW+jpBITM5q7dqhnNIpsZXWiVXc4jhhWKDGM4kBxGa1xE+UerOE77V KAV6abBBjWL/tMq/xU/tXn8Ara+nS5Q5KhkuIE8lXOntW2UGHFacJ49WKEmobYgTjcNi DfPndAQoXHr0Waud//NUblYPVgzQ9h/JdDmTfwB82c2PcDr/nil789zrLYxXMJlhh2xq dvk6JOtVoUux7cwj86WrfzhBgXfHiq5ez25uKjhbh9XjDPhS4LDEsEWjNwbtkKkV8dqU oVVw== X-Received: by 10.50.135.105 with SMTP id pr9mr1292942igb.6.1365761705669; Fri, 12 Apr 2013 03:15:05 -0700 (PDT) Original-Received: by 10.64.26.168 with HTTP; Fri, 12 Apr 2013 03:15:05 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::22d 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:16227 Archived-At: On 12 April 2013 15:23, Daniel Llorens wrote: > > 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. > Ah. I should have read more the later part of your mail. > 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. I don't think this particular test is that useful, as it is too concerned with the details of how the array indices map to the underlying vector, rather than whether the array indices themselves are compatible with the vector indexing semantics. Too restrictive IMO, you may as well just not permit any array passed to vector interfaces. [Besides, you can already get at the underlying vector using =E2=80=98shared-array-root=E2=80=99.] > 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 > > 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 [2] #t. But then, vector- is just > an alias of array-. Sure, [1] and [2] should probably be consistent. This does not make =E2=80=98vector-=E2=80=99 an alias however, as the seman= tics of vector indexing must still be respected. There are two layers of indexing, vector (simple) and array (fancy). For some objects the two are compatible, like in [1]. For others like =E2=80=98#1@1(1 2)=E2= =80=99 they are incompatible. This compatibility is based on the indices themselves, not how they are calculated (e.g =E2=80=98inc!=3D1=E2= =80=99 is not relevent for compatibility). #1@1(a b c d) is: Element a b c d Array index 1 2 3 4 Vector index 0 1 2 3 There is some utility in permitting [1] where an arrays indices are vector-compatible: array data (or a subset) can be passed to a procedure expecting a vector without copying. Is it worth the overhead to support this in the vector code? I think so, but then, haven't looked at the code :-) Where an arrays indices are vector-incompatible, you can still permit vector indexing of the elements by ignoring the array indices (i.e. current =E2=80=98vector-ref=E2=80=99), or you can fail. Fail= ing will result in less surprises. This suggestion: > Might as well have (vector-ref #@1(1 2 3 4) 1) work properly > [by returning =E2=80=981=E2=80=99 instead of =E2=80=982=E2=80=99]. is not possible: the vector interface must use vector indexing which means the first element of any object has index =E2=80=980=E2=80=99. It seems you prefer failing in the incompatible case, though I have no strong preference either way. For non-rank-1 arrays, the indices are clearly incompatible though =E2=80=98array-contents=E2=80=99 already establishes a precedent for the rank-1 ordering of the elements, and supporting that case could be possible as well. > > 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. Perhaps. I assume that =E2=80=98array-map!=E2=80=99 etc. are more efficien= t for accessing multiple elements with the startup overhead is amortized over all the elements. > 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. Are those results from stable-2.0? I do not reproduce some of the type errors on my system, e.g.: (bitvector-ref (make-typed-array 'b #t '(1 2)) 0) =3D> #t >From your original mail: > a. the array implementation can rely on all [vector] types > having known base=3D0 and inc=3D1. Is that not already the case? Regards