From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Julian Graham" Newsgroups: gmane.lisp.guile.devel Subject: Re: pass at srfi-89 implementation Date: Mon, 19 May 2008 16:28:28 -0400 Message-ID: <2bc5f8210805191328o33656ab2ue07daf5f372c6610@mail.gmail.com> References: <2bc5f8210805022037t73e3e30ay835ad4814e308397@mail.gmail.com> <87od72gidl.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1211228983 1790 80.91.229.12 (19 May 2008 20:29:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 May 2008 20:29:43 +0000 (UTC) Cc: guile-devel@gnu.org To: "=?ISO-8859-1?Q?Ludovic_Court=E8s?=" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon May 19 22:30:21 2008 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 1JyBza-0002sO-PO for guile-devel@m.gmane.org; Mon, 19 May 2008 22:29:59 +0200 Original-Received: from localhost ([127.0.0.1]:57975 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JyByq-0008OV-OU for guile-devel@m.gmane.org; Mon, 19 May 2008 16:29:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JyByG-0008AK-4c for guile-devel@gnu.org; Mon, 19 May 2008 16:28:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JyByF-00089y-JS for guile-devel@gnu.org; Mon, 19 May 2008 16:28:35 -0400 Original-Received: from [199.232.76.173] (port=47432 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JyByF-00089t-96 for guile-devel@gnu.org; Mon, 19 May 2008 16:28:35 -0400 Original-Received: from fg-out-1718.google.com ([72.14.220.155]:44045) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JyByE-0005yw-RU for guile-devel@gnu.org; Mon, 19 May 2008 16:28:35 -0400 Original-Received: by fg-out-1718.google.com with SMTP id l26so2628855fgb.30 for ; Mon, 19 May 2008 13:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=xpIQK9mmenNsUvWoNglqsl/QBoq0hXKQbtlLvQV9rCU=; b=W/kEjOocRHy//n7/q7YCSrUbYlX2GXFFDcyxhHQNdE/x4AiYAq7TqFR0zuCbM40OUNm9f5XekCLX0xQuvcJeaNDfiDZSx4wFqWbFN6BH4bJ2yErWs4+1RRyTRFqKMOJVCOF1tXg+DkZBBbxOXruU7tviTrZvpzGmVgNtV1HkBX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GGQtykEYek7Du52t9lxl1g+u/JHwMxaRZafVrwvRK2bulAODk1EajBBUEba9z6f5H+Bapfbf5KEI7AZT1tFYCIDlK1paF7QasGpdifhXvrFwLR+n9qiGycmAOOH3S4bCAwxq/PoktpPTbpcbrVYCA/DeRaHwGT6YFIu8kcePo2Y= Original-Received: by 10.82.188.14 with SMTP id l14mr1053527buf.85.1211228908028; Mon, 19 May 2008 13:28:28 -0700 (PDT) Original-Received: by 10.82.100.3 with HTTP; Mon, 19 May 2008 13:28:28 -0700 (PDT) In-Reply-To: <87od72gidl.fsf@gnu.org> Content-Disposition: inline X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) 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:7256 Archived-At: Well, there's a reference implementation of SRFI-89 that (I think) could just be dropped in and used, now that we have SRFI-88-style keywords. I was just hoping that the existence of `(ice-9 optargs)' would make possible a more compact / potentially more efficient implementation. > Would it be a lot more time to make SRFI-89 independent of `(ice-9 > optargs)' given the differences you describe? > > IMO it would look cleaner and be more robust in the face of changes in > `(ice-9 optargs)'. It would also make sure the SRFI-89 implementation > is not subtly biased towards what's in `(ice-9 optargs)'. > > What do you think?