From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sunjoong Lee Newsgroups: gmane.lisp.guile.devel Subject: Re: SRFI-64 module and SRFI-78 module -- archive file attached Date: Mon, 14 May 2012 06:22:09 +0900 Message-ID: <87pqa7n5dq.fsf@gmail.com> References: <87bolwmkmg.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1336944354 13693 80.91.229.3 (13 May 2012 21:25:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 13 May 2012 21:25:54 +0000 (UTC) Cc: guile-devel@gnu.org To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun May 13 23:25:54 2012 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 1STgIa-0001GJ-MI for guile-devel@m.gmane.org; Sun, 13 May 2012 23:25:52 +0200 Original-Received: from localhost ([::1]:47140 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1STgIa-00060J-1J for guile-devel@m.gmane.org; Sun, 13 May 2012 17:25:52 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1STgIS-000600-Hn for guile-devel@gnu.org; Sun, 13 May 2012 17:25:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1STgFI-0005pz-4g for guile-devel@gnu.org; Sun, 13 May 2012 17:22:39 -0400 Original-Received: from mail-pz0-f41.google.com ([209.85.210.41]:62158) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1STgFH-0005pj-Nd for guile-devel@gnu.org; Sun, 13 May 2012 17:22:28 -0400 Original-Received: by dakp5 with SMTP id p5so5575606dak.0 for ; Sun, 13 May 2012 14:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=KkEcMt7qNpsa9wsR70f/iVi77VuAu4e73USpHcQc1gw=; b=GpMpBT2Xsv8+WbCX9g155VKpOpZR9LZszr44Ho8pHYCnVz5NYDF0YQ9b7dXUhopxgw hWDydMyl4TUcpFFdPFl7rQT9kQWYwvbbpicRsv5mXDzvAY9OOXVHNCPC0HnqYuiODgRL G3UVQ0HmmVkt4PW/WGd5zS1XfmO5FRRxDmzi9rG6XZBCxLi53oNNtdEOULWQhlR8MnTI J11DPQjpKFUAAoOuT90qmESdKagkbEbl9YcdLcOv3NwMMsMYOMZHtN+eBdNQTDVnqvfH 3eq8gueMjJMveKf5sVn2YKSvxNJUbsjlKkAta9OHcU4Ie9+E6VkKR4oPYIpmqsxFiT7d nTeg== Original-Received: by 10.68.191.201 with SMTP id ha9mr16512739pbc.75.1336944143405; Sun, 13 May 2012 14:22:23 -0700 (PDT) Original-Received: from localhost ([61.81.58.28]) by mx.google.com with ESMTPS id rv5sm5378434pbc.56.2012.05.13.14.22.20 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 May 2012 14:22:22 -0700 (PDT) In-Reply-To: (Noah Lavine's message of "Sat, 12 May 2012 13:30:49 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.210.41 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:14407 Archived-At: Hi, Noah; Thanks for comments. On 05/13/2012 Noah Lavine writes: > Second, since your changes add compatibility for several Scheme > implementations, have you thought about trying to make them part of > the reference implementation? You would probably have to email Per > Bothner to ask him, but that might be the best way to make your > changes available to all of the implementations you are making it for. > If not, I hope Guile would like to have it, but I think you are > targeting more than just Guile. When I'd made my srfi-64.scm to pass srfi-64-test.scm, a test suite for the SRFI 64 itself, on Guile 2.0.0, I felt happy and remembered my googling to search a SRFI 64 implementation working on Guile. Now, the filename of srfi-64.scm is srfi-64-port.scm and the new srfi-64.scm file uses it with include-from-path. Hum... I use Guile 2.0.5 now. Anyway, I'd sent a email to Per Bothner and he had commented on it. On 04/13/2012 Per Bothner writes: > This is nice. It would be great if the Guile port would be merged > into the reference implementation, presumably using cond-expand. > That way bug-fixes or changes in one could be more easily be > merged into the other. I'd misunderstood his words then. In the reply for you, Per wrote: On 04/20/2012 Per Bothner writes: > My suggestion was that it would be nice (but not essential) > if the Guile implementation could be based on and merged back into > the reference implementation, perhaps using cond-expand to > encapsulate the Guile-specific changes. > > Unfortunately, this Guile port seems like a complete rewrite: > The diff (relative to the reference implementation) is over twice as big > as than the original reference implementation! This makes it difficult > to evaluate the changes, which makes it difficult to accept it as an > update to the reference implementation. I was hoping the Guile port would > be a modest set of changes to the reference implementation; this is > not. After his first comments, I'd misunderstood it of course, I found the reference implementation does not pass srfi-64-test.scm on Chicken and Gambit either. I fixed it with my srfi-64.scm. After his second comments, a reply for you of course, I understood his first comments and made a patch file for the reference implementation. That patch was just for Guile and not included fix for Chicken and Gambit. On 04/21/2012 Per Bothner writes: > Much better. I applied your patch to the reference implementation, > and that seems to work. I source file name and line numbers, which > makes things much more pleasant. I'm waiting Per publish a new version of the reference implementation. In the mean while, I had realized my srfi-64.scm had a bug; I'd used cond-expand-provide within cond-expand and that made a problem. So, I renamed srfi-64.scm to srfi-64-port.scm and wrote a new srfi-64.scm using it with include-from-path. Talking about Gambit, there are a Black Hole, a moudle system for Gambit, module called srfi; srfi moudle has test.scm and it's a almost testing.scm, a Per's reference implementation. So, it would fail to srfi-64-test.scm, I think. Talking about Chicken, there a egg, a module system for Chicken, moudle called test; test moudle is very similar to SRFI 64 but not is. I'd failed to compile the reference implementation on Chicken. Of course, srfi-64-port.scm can be compiled. On Kawa and Rocket, the reference implementation would work well. My point is SRFI 64 support on Guile would be helpful to people want to write a portable test code. For me, I'm contented with Guile 2.0 now but might want to write a Gambit or Chicken code someday and want not to study syntax for writing a test code itself again. Is SRFI 64 perfect? Of course not, but I would re-use my own test codes if it's based on SRFI 64, I think. So, I'd avoid making srfi-64-port.scm go from SRFI 64 specification. SRFI 78 module is a bonus; I'm not sure that be a right expression, a bonus. SRFI 78 is a very simple application of SRFI 42 and Guile supports SRFI 42 already. Thanks.