From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: review/merge request: wip-array-refactor Date: Wed, 29 Jul 2009 00:41:28 +0200 Message-ID: References: <874ot48k4h.fsf@arudy.ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1248823660 32194 80.91.229.12 (28 Jul 2009 23:27:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Jul 2009 23:27:40 +0000 (UTC) Cc: guile-devel To: Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jul 29 01:27:34 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MVw4w-0001HJ-R7 for guile-devel@m.gmane.org; Wed, 29 Jul 2009 01:27:31 +0200 Original-Received: from localhost ([127.0.0.1]:47973 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVw4w-00052C-8H for guile-devel@m.gmane.org; Tue, 28 Jul 2009 19:27:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MVvNv-0000Ns-GS for guile-devel@gnu.org; Tue, 28 Jul 2009 18:43:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MVvNq-0000M2-9g for guile-devel@gnu.org; Tue, 28 Jul 2009 18:43:02 -0400 Original-Received: from [199.232.76.173] (port=43029 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVvNq-0000Lz-4k for guile-devel@gnu.org; Tue, 28 Jul 2009 18:42:58 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:10002) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MVvNp-0006LL-I6 for guile-devel@gnu.org; Tue, 28 Jul 2009 18:42:57 -0400 Original-Received: from a-pb-sasl-sd.pobox.com ([64.74.157.62] helo=sasl.smtp.pobox.com) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MVvNo-0007Qz-P6 for guile-devel@gnu.org; Tue, 28 Jul 2009 18:42:56 -0400 Original-Received: from localhost.localdomain (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 3F608143E9; Tue, 28 Jul 2009 18:42:56 -0400 (EDT) Original-Received: from unquote (unknown [83.44.188.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id D189B143E5; Tue, 28 Jul 2009 18:42:53 -0400 (EDT) In-Reply-To: <874ot48k4h.fsf@arudy.ossau.uklinux.net> (Neil Jerram's message of "Wed, 22 Jul 2009 22:48:14 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) X-Pobox-Relay-ID: FE4427D6-7BC7-11DE-9948-AEF1826986A2-02397024!a-pb-sasl-sd.pobox.com X-Detected-Operating-System: by mx20.gnu.org: Solaris 10 (beta) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8981 Archived-At: Hi Neil, Thanks for the review. On Wed 22 Jul 2009 23:48, Neil Jerram writes: > I have two overall questions in mind. > > - What do you have in mind as regards releasing this? Even though it > looks good, I think it would be better to let it mature for a while, > and hence not to put it into 1.9.x/2.0. (And we're not short of new > stuff in 1.9.x/2.0!) Personally I would prefer that it come out in 2.0. I'm fairly (but not entirely) confident of its consistency as it is, and quite confident that it is a more maintainable, and hence fixable, codebase. The reason that I want it in is that bytevectors are a nice api for I/O, but once you have data in memory, often it's best to treat it as a uniform array -- be it of u8 color components, or s32 audio samples. Uniform vectors are almost by nature "in flight" between two places. But it is the bytevector that is most equipped to "fly", via e.g. (rnrs io ports); but bytevectors do not provide an ideal API for manipulation. s32vector-ref is a better API than bytevector-s32-native-ref, if only that the offset of the former is in native units (s32 elements), and of the second in bytes. I guess what I wanted to do was break uniform vectors out of their type ghettoes. Like Perlis said, "Pascal is for building pyramids -- imposing, breathtaking, static structures built by armies pushing heavy blocks into place. Lisp is for building organisms -- imposing, breathtaking, dynamic structures built by squads fitting fluctuating myriads of simpler organisms into place." I should be able to put a 64-bit float into two 32-bit words, when I'm writing an instruction sequence for a 32-bit machine, without having to change my data type -- they are just bytes anyway. > - What about the header file incompatibilities? I.e. the problem that > if there are applications out that that #include , > or another of the renamed ones, they will stop working. Do you > think we are OK just to document this well, or should we do more > than that? I thought that our only support API was that provided by #include . We can add back compatibility header files if necessary. Do you think it is necessary? >> The only bits I could anticipate being controversial would be the last >> two or three patches, in which bytevectors are given an "element type" >> field. This is so that I can make the srfi-4 uniform vector code use >> bytevectors as their representation -- it's one less orthogonal type >> that the VM would have to deal with. >> >> Those patches also allow uniform vectors of one type to be accessed >> using accessors for other types: >> > What is the detailed rationale for [the following examples]? >> (u8vector-ref #u32(#xffffffff) 0) => 255 I ought to be able to get at the bits of a packed (uniform) vector. The whole point of being a uniform vector is to specify a certain bit layout of your data. >> (u8vector? #u32(#xffffffff)) => #f However, we need to preserve type dispatch: (cond ((u8vector? x) ...) ((s8vector? x) ...) ...) >> (bytevector? #u32(#xffffffff)) => #t This to me is like allowing (integer? 1) and (integer? 1.0); in /essence/ a #u32 is an array of bytes, interpreted in a certain way. In practice, one might use real? / complex? / integer? / etc to distinguish elements of the numeric tower; in this case we have a short tower: uniform vectors are bytevectors. >> commit 86d88a223c64276e7cd9b4503e7e2ecca5aae320 >> Author: Andy Wingo >> Date: Thu Jul 16 21:51:47 2009 +0200 >> >> remove deprecated functions from unif.c >> >> * libguile/unif.h: >> * libguile/unif.c: Remove deprecated functions. >> >> * module/ice-9/deprecated.scm: Remove array-related deprecated >> functions. >> >> * NEWS: Update. > > I can understand why a lot of the NEWS deltas evaporate when they are > logically merged into the 1.8-2.0 section, but I'm not sure about > > - the entry for Brainfuck > > - the entry on scm_set_port_seek and scm_set_port_truncate > > Aren't these entries still of interest? > > The rest of this commit looks fine. Yes they are. Good catch. I'll finish this response, and the response to Ludovic, later -- but I wanted to get out the rationale now. Thanks again for the review! Andy -- http://wingolog.org/