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: Thu, 13 Aug 2009 00:03:27 +0200 Message-ID: References: <874ot48k4h.fsf@arudy.ossau.uklinux.net> <87k51pyj0c.fsf@arudy.ossau.uklinux.net> <87bpmpvt14.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1250117292 9619 80.91.229.12 (12 Aug 2009 22:48:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Aug 2009 22:48:12 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Aug 13 00:48:06 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 1MbMc2-0000Bg-5N for guile-devel@m.gmane.org; Thu, 13 Aug 2009 00:48:06 +0200 Original-Received: from localhost ([127.0.0.1]:42897 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbMbz-0006sw-Md for guile-devel@m.gmane.org; Wed, 12 Aug 2009 18:48:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MbMRT-000285-Nb for guile-devel@gnu.org; Wed, 12 Aug 2009 18:37:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MbMRP-00025n-6s for guile-devel@gnu.org; Wed, 12 Aug 2009 18:37:11 -0400 Original-Received: from [199.232.76.173] (port=41274 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbMRO-00025M-D6 for guile-devel@gnu.org; Wed, 12 Aug 2009 18:37:06 -0400 Original-Received: from a-pb-sasl-sd.pobox.com ([64.74.157.62]:53380 helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MbMRF-0005rI-Lg; Wed, 12 Aug 2009 18:36:58 -0400 Original-Received: from localhost.localdomain (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id A8E312781A; Wed, 12 Aug 2009 18:36:56 -0400 (EDT) Original-Received: from unquote (unknown [79.156.145.67]) (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 B0BED27818; Wed, 12 Aug 2009 18:36:54 -0400 (EDT) In-Reply-To: <87bpmpvt14.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Sun, 09 Aug 2009 18:41:43 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) X-Pobox-Relay-ID: A424AE90-8790-11DE-B6F3-AEF1826986A2-02397024!a-pb-sasl-sd.pobox.com X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) 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:9094 Archived-At: Hello Ludovic :) On Sun 09 Aug 2009 18:41, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Andy Wingo writes: > >> The second model is when you already have a wide deployed base. You can >> make additions to your API and ABI, and deprecated old API or ABI, but >> you can't remove old API or change the ABI. Incompatible breaks are >> painful, and the switching-over time is somewhere between a year and >> three years. The right length of a stable series seems to be about 4 or >> 5 years. > > I'm in favor of sticking to this model, i.e., paying attention to both > source and binary compatibility. That sounds important to me as Guile > is an old piece of software for which users may expect a relative > stability and clear upgrade path when that is needed. I agree. >> I've written lots of code that deals with srfi-4 vectors. I have three >> kinds of use cases. First is data being shoved around in a >> dynamically-typed system: dbus messages, gconf values, a system we=20 >> at work, etc. Second, but related, is dealing with chunks of data that >> come from elsewhere, like GDK pixbufs, or GStreamer buffers. Third is >> hacking compilers, as in Guile itself, or emitting machine code for >> other machines. > > My feeling is that the 1st and 3rd use cases are what bytevectors were > written for in the first place. Agreed. > SRFI-4 is a good fit for the 2nd use case as you're dealing with > fixed-width native-endianness numbers coming from C code. Agreed, modulo the possibility for this data to be embedded within some other stream. > But in this case, I don't think bytevectors are needed at all. I think they are needed whenever you want to *do* something with this data -- i/o for example. >> In summary... I don't mean to be a bore, but I really don't like the >> existing unif.c and srfi-4.c. They are painful to understand and to hack >> on. I think those bits should be merged. > > Agreed. OK, I'll see about merging up until the polymorphic change after the release. >> I also think that srfi-4 vectors should be implemented in terms of >> bytevectors, for the reasons above. > > I'm not convinced, but OTOH, I don't think it hurts. > > Like Neil, the one thing that I'm not fond of is the switch from > disjoint SRFI-4 types to polymorphic types, because programming errors > that currently yield a `wrong-type-arg' error will be silently ignored. > The SRFI text allows it, but the rationale says that "the use of > homogeneous vectors allows certain errors to be caught earlier." OK. Hopefully when I do my merge, the advantages/disadvantages of the various approaches will be more clear to all of us (including myself). Cheers, Andy --=20 http://wingolog.org/