From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] add SRFI: srfi-121; generators Date: Mon, 3 Aug 2020 21:41:15 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16476"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Mark H Weaver , John Cowan To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Mon Aug 03 21:43:48 2020 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k2gN9-0004DO-PB for guile-devel@m.gmane-mx.org; Mon, 03 Aug 2020 21:43:47 +0200 Original-Received: from localhost ([::1]:36996 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k2gN8-0003hJ-Or for guile-devel@m.gmane-mx.org; Mon, 03 Aug 2020 15:43:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41784) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k2gKy-0001oy-3N for guile-devel@gnu.org; Mon, 03 Aug 2020 15:41:32 -0400 Original-Received: from mail-pl1-x642.google.com ([2607:f8b0:4864:20::642]:38228) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k2gKv-0004jn-I1 for guile-devel@gnu.org; Mon, 03 Aug 2020 15:41:31 -0400 Original-Received: by mail-pl1-x642.google.com with SMTP id t11so1591384plr.5 for ; Mon, 03 Aug 2020 12:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i7rAcvlTyld8AjtyvemSn4CWcsZLa/xuifAQ0VU+FhQ=; b=JDG6cL9qivo4Jzfid0TOhyYbgkKkQfXVzEXWknF/kgt4gitpP0DnL8+GxRV7Gswdwp mumEUHP/VFTksC2k/4Ny2GLgHJf16W8YpLXUZKYwkhmuytIH7+i+/dddxxTYL2ynOLxW 9aXvWh6AZVV7ZpwaGGk4kp2SQmhkfOF6bjUnFoUD+j20GX1aDWsAVvvvWSAggGKusDKG ++Gv6Cgj7jphrt6qtlqibdr8q7PWlzXHNxHK0d77GRxNfzJQwgXk48rRiwqQy5jWRdai O+zsB9IrcvfqwQHTZ4Uxvpny+7lksJL/3ciROaN10Ny3BD9bEoOCbFcWU9heI/pTzD4L ikew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i7rAcvlTyld8AjtyvemSn4CWcsZLa/xuifAQ0VU+FhQ=; b=j8EMYk1uxtysdKJdwZAYOamfYBINzPEQ+4sk6iQOp1zM14Jqj02yTqLYc3nuDlS7Iy HdUdUJq/oS9p6r80AERCyCCHzCEW23JHQFcynSACMh5kpqRHKk7VHKId3vExwkq6C1t8 k8fS6OeY+M0f73aOYFYUKJnE+s6+QvJzGyiTVvLmivRW9pKUsYt1ERebzxSgUx0kieMU 2H+ilkyIWL5VyUm9jdBQtRLsKaEkhGZ3G+PSDyly+6iDodogT6JCddyJksKdUGaBI5kL g2gatJJjswUL7vWEjh2I926ygjmbnSbvL5R1kOLep/VSektRAiNrEjpbZfLC8+oy0XBn aXNg== X-Gm-Message-State: AOAM533MhqsQmMlXerJzUd2/M75ZphpoEhJmwML5fsCklyQwGL3yozWL b8RfbLM7GLnRBjcY7ALDZb4wI68gShcS3ZF+d1LQyD1AX3hzQw== X-Google-Smtp-Source: ABdhPJylUQzKRSqWnjtB360DsxpEK+jvrAp/lcEMSmFRpLyxjGr7/k3wfO0bID98YDptpmOSSOK1reUda+EMNv66Wig= X-Received: by 2002:a17:90a:d583:: with SMTP id v3mr831025pju.33.1596483686364; Mon, 03 Aug 2020 12:41:26 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::642; envelope-from=marc.nieper@gmail.com; helo=mail-pl1-x642.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.io gmane.lisp.guile.devel:20568 Archived-At: Am Mo., 3. Aug. 2020 um 18:00 Uhr schrieb : > Message: 1 > Date: Sun, 02 Aug 2020 18:39:32 -0400 > From: Mark H Weaver > To: John Cowan > Cc: guile-devel@gnu.org > Subject: Re: [PATCH] add SRFI: srfi-121; generators > Message-ID: <87v9i0zn7k.fsf@netris.org> > Content-Type: text/plain > It didn't occur to me that the reference implementation of a finalized > SRFI would include comments like "the spec would have me return #f, but > I think it must simply be wrong". However, I see now that I was > mistaken. Indeed, those buggy implementations and confused comments are > in both the SRFI-121 and SRFI-158 reference implementations. To be fair, one should remark that the reference (or, rather, sample) implementations do not belong to the SRFIs proper. That said, it is surprising why the questions raised in the sample implementation haven't been resolved during the draft period of the SRFI. > I'm sorry to say it, but in my opinion SRFI-121 and SRFI-158 should be > deprecated and avoided. The reference implementations do not match the > specifications, and the specifications themselves are self-contradictory > (see above). Therefore, it's entirely possible that users of these > SRFIs may have contradictory expectations about how these procedures > behave. Some may have read the spec one way, some may have read the > spec in a contradictory way, some may have learned from how the buggy > reference implementation behaves, and others may have learned from the > behavior of a different SRFI-121 implementation that doesn't have those > bugs. At this point, I don't see how the problems can be fixed without > breaking some users' assumptions, and therefore breaking existing code. There are a number of SRFIs with post-finalization notes, most of which alter some behavior of their respective SRFIs. At the moment, there is no general programmatic way to know whether a specific implementation is up-to-date with respect to these post-finalization notes or not. A similar problem occurs with libraries that have already been voted into R7RS-large. In the Red Edition, (scheme generator) stood for the interface of SRFI 121; in the Tangerine Edition, it stands for SRFI 158. Of course, one can circumvent any problems by importing the libraries through their SRFI names and not using the scheme namespace before R7RS-large has been finalized. > I sincerely hope that these two SRFIs are an aberration, and not > representative of the quality of the R7RS-large effort. While I have been contributing to R7RS-large, I have to agree with you to some extent. Most of the SRFIs that have been voted into R7RS-large or are to be submitted for it don't have the quality of the R6RS or R7RS(-small) specifications. This is especially true in the following areas: - Questions of tail context are often ignored. - Higher-order procedures are often silent with respect to call/cc, exceptions or side effects. - Formal syntax is often missing. - Formal semantics are almost always missing. In particular, the ignorance of call/cc in most SRFIs dealing with higher-order procedures make this defining feature of Scheme hard to use in a portable way. SRFI 121/158 is incidentally also an example for this. Take 'gappend' from SRFI 158, for example. It doesn't specify when the various generator arguments are being called. Of course, all this can be fixed, but by the sheer size of R7RS-large, I doubt that it ever will. Marc PS: One of my own issues with SRFI 158 is that accumulators are not that well-designed from a logical point of view. I summarized it here: https://srfi-email.schemers.org/srfi-158/msg/6219505/. A follow-up thread begins here: https://srfi-email.schemers.org/srfi-158/msg/6557831/.