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: Tue, 4 Aug 2020 17:58:07 +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="22725"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Mark H Weaver , guile-devel@gnu.org To: John Cowan Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Aug 04 17:58:41 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 1k2zKr-0005nA-Fw for guile-devel@m.gmane-mx.org; Tue, 04 Aug 2020 17:58:41 +0200 Original-Received: from localhost ([::1]:45934 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k2zKq-0004L0-DG for guile-devel@m.gmane-mx.org; Tue, 04 Aug 2020 11:58:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41822) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k2zKa-0004I9-Pg for guile-devel@gnu.org; Tue, 04 Aug 2020 11:58:25 -0400 Original-Received: from mail-pg1-x544.google.com ([2607:f8b0:4864:20::544]:39457) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k2zKY-0003fI-Ne for guile-devel@gnu.org; Tue, 04 Aug 2020 11:58:24 -0400 Original-Received: by mail-pg1-x544.google.com with SMTP id z5so22447443pgb.6 for ; Tue, 04 Aug 2020 08:58:20 -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=nycxXTywNpiKv7cZYGHoNCsb4Jr1DCLs37roR9YLp6I=; b=Fual4L+Zi93j6LsmaTsi1gyPhEamLz6mlgCvNcxaKwSySzXwoFrckeMDfriMZ61teS +6uct3ZTNHhl3S4qc2gqHkX5SeRDgvwCI4+dKDppkpFlZqbsq4oUq4inzaIrnbcRUy/9 6BteH4XP6Zb+zY9PXaoAjyA62emJGe4ZmuYe+yLrrzT8VA5VbJmyaPvsEGCSDGnt7/aR joPdj3jWbg483lt2REchXVxOZyvS0QGabpDzGaoi0PNIBKvahl0zrYLfWx7TKfRUhaPm x18uQSbRSepiyh5A4vDrF0giHB6DBl3yaoriKcPo2+uKyE4zbIyIKMx0Kghc6vtoSqBp OTsQ== 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=nycxXTywNpiKv7cZYGHoNCsb4Jr1DCLs37roR9YLp6I=; b=ecpaitzTFFz/Tq+lw3dLz15vOM+f8BtQqvXIAyLW/lY6hls0wtaHW/GpZnO0+IHQN4 w8LyicTM4HlVzlIvLyz4yMSzhTAyMKb8f84lM+e4/AnEYWbbH1T4xhRBScyGskwH8M/w C0DIlGbhelXGD2Z0M85VK64f7EqKgo5Fy/Pv1Ej1CwSVanL1BVpcs++8d0oVRzoj9iQF RYC9toyoiRPJoa74RMLmKAM4+esWuIe+2TyMK3NpxCjIxIJM+YSYrJsL/h/Cu0e5pRgW xBtuWGtS5XYJ0JMn4MnD8jR/KZ/I66XvT7Xzja5ojY0yL0KVCIWFjzUEZJScCB0LfT6Q WW4Q== X-Gm-Message-State: AOAM530BRagGjrf4xRFy7t3utHuRe8GyOTylZVkCIE66ns6yvY8QVUOI nxtPfqKqz6GWNfubtGwtaIc0rCSUfd/iF9tzi24= X-Google-Smtp-Source: ABdhPJyfPzx8tL44eJzaWfUvJczDNuMDjVv7CpUpCDOndFmy7809+tU26a2f1z/nS+AViAuFybnHCYCmwe5kB3i4H/M= X-Received: by 2002:a63:5b55:: with SMTP id l21mr20494544pgm.348.1596556699294; Tue, 04 Aug 2020 08:58:19 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::544; envelope-from=marc.nieper@gmail.com; helo=mail-pg1-x544.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 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:20571 Archived-At: Am Di., 4. Aug. 2020 um 17:24 Uhr schrieb John Cowan : >> 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. > > > How could there be? The implementations are written in a Turing-complete language. If we had R6RS's library versions, we could just bump the version number each time the API is changed due to a PFN. (Note that I am not saying that R6RS's version numbers are the best tool; my point is more that there are tools.) >> 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. > > > I only did that because 158 is upward compatible with 121; indeed, bug-for-bug compatible, as it turned out. SRFI 158 is not upward compatible in the full sense with SRFI 121 because it exports more identifiers. Of course, chances that some code will break are low. Likewise, SRFI 166, which will most likely replace SRFI 159, is not fully upward compatible. That said, these incompatible changes during the draft period of R7RS-large are the lesser of two evils. As I said, if one needs a more stable interface, just import (srfi 121) or (srfi 159) instead of (scheme generator) or (scheme show). >> 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 > Inevitably so. A large granite boulder cannot be cut like a diamond, but it has uses that a diamond does not (and vice versa, of course). There's already a large granite boulder called Python. When we want to advertise R7RS-large, which differences shall we point out (apart from the Lisp syntax)? >> - Questions of tail context are often ignored. >> - Higher-order procedures are often silent with respect to call/cc, >> exceptions or side effects. > > > Regrettably both true. Scheme is so often used without effects that it's easy to forget they exist. >> - Formal syntax is often missing. > What further syntax do you want? Procedures have only a single syntax, so all we need to know is what arguments exist and in what order. Macros are few, but informal explanations (as in R[57]RS) seem sufficient to me. For procedures, we don't need any formal syntax, of course. If it's needed, it is for macros. If you take a look at many earlier SRFIs, grammar production rules extending those of R5RS are given, which help to understand the syntax. On the other hand if you take a look at many other SRFIs, let's take SRFI 204 for example, it's hard to know how to implement them just from reading the spec and not the implementation. >> - Formal semantics are almost always missing. > That requires someone who can write their own Greek, which would not be me. You don't need to write arcane formulas. Take SRFI 2, for example. The semantics are pretty well laid out. >> 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. > I don't follow you. It is quite explicit that each is called until it is exhausted in left to right order. For example, the current spec allows that "gappend" already calls the various generators supplied as arguments (and stores their results) before returning the resulting generator. It is specified, in which order the values are delivered, but it isn't specified when the supplied generators are asked for their values. There may be an obvious order of procedure calls, but it is not in the spec. Thus, if any of the supplied generators has side effects, we will have an implementation-dependent result. Moreover, we don't know what happens when the control flow steps out of or into one of the supplied generator procedures through exceptions or call/cc. "gappend" was just an example, though. There are many other examples in many other SRFIs (my own probably as well) where we are not as precise as R6RS or R7RS. This is somewhat a pity as R7RS-large should be able to cover that part of R6RS that is not covered by R7RS-small due to its, well, small size. So it would be great if the quality of R7RS-large were at least as good as the quality of R6RS.