From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: John Cowan Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] add SRFI: srfi-121; generators Date: Tue, 4 Aug 2020 11:24:37 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000001baa6505ac0edb3d" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28988"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Mark H Weaver , guile-devel@gnu.org To: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Aug 04 17:25:05 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 1k2yoL-0007Qo-CL for guile-devel@m.gmane-mx.org; Tue, 04 Aug 2020 17:25:05 +0200 Original-Received: from localhost ([::1]:45806 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k2yoK-0006Xc-EI for guile-devel@m.gmane-mx.org; Tue, 04 Aug 2020 11:25:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33826) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k2yoA-0006XT-J0 for guile-devel@gnu.org; Tue, 04 Aug 2020 11:24:54 -0400 Original-Received: from mail-qk1-x743.google.com ([2607:f8b0:4864:20::743]:33612) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k2yo7-0006Cl-Ha for guile-devel@gnu.org; Tue, 04 Aug 2020 11:24:54 -0400 Original-Received: by mail-qk1-x743.google.com with SMTP id l23so38766532qkk.0 for ; Tue, 04 Aug 2020 08:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oPS8b6dUbmc8IGJZKv3SMtjfZD7ZwyQe9pZ7HWbMboA=; b=ncME7irGO7VsTpaQrClauQcpLBD1pwB345GVdTFM+j+I5/tGMn/vdKOmiRpYQzzi8n q5D4I5j2wN7lIyaiaZ4ItqBOkO21/uhNNgh6STYRwdgs9w5PcFYFwndu2p0Si0NTLPji 6df9LN92Y/5puosvycSHhHKuTnfP7RQjIj/rbPKF6XCyDUJZJ2PLapItLjxIT9ksjaDo 4FCJL6VbyWQojJAwxOqmpqW8gh5uxtGwvQqbBnUAcIXLUBQ/YOV8inpVqZ2kZmVwyW3G tO/uiD+BdZB/a6BFUacaY2D+zhTJZhsVnRVKrdqcG7JBkH71uKN++K3NMpIXhLkHs7pI LEag== 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=oPS8b6dUbmc8IGJZKv3SMtjfZD7ZwyQe9pZ7HWbMboA=; b=pmgKn//sxnhG6/RAGfqw/LS/7hwH7LL+2oOA/v//xMQbYs8vwndb8siWbwdvNzZKVZ a0j7tQ4Tq+KCMa3WVHA6VMMwB1DhYq4rGM9BLlDC5dlMm96QHJ92fNo9+b9c8lZmGWiA z5WBWGVzwN5hpzm7HyQIqoQ92YqGdqTPkfdxJsXH/43CRUwAXEuiwyrfnKlw2iIWyfoQ I5Krn5bsaKpf4D6PrPjCaamRLQ0txsyOJMhjBurq+KsZ8p2unrlte/IwdZUjUi56QJ+i /h1Z5kykwpIqK+VTGR/D5FLsjUDsri/CcK32Xmc6Trw2dHUz3ouVNHsnRkKK/bYb3gbF qpIw== X-Gm-Message-State: AOAM533MyBSvItgBhcxQJ6N5YTgLxGAM3w2sJUOmYjmaA9L6nOOvbQxc tlA4fIF5NsWrpKTX3gSWEd09Bx5PHlTVvkV9k+j1yA== X-Google-Smtp-Source: ABdhPJwB9k1xXXTsnR/qHWZVo9NcFU4Aznk2rvNo4gtdJjzwp0l22KlQZ0rBSidcc+xjYYW3yy3STEyIdicDnQJcN9Y= X-Received: by 2002:a37:9e41:: with SMTP id h62mr20622135qke.426.1596554689089; Tue, 04 Aug 2020 08:24:49 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::743; envelope-from=cowan@ccil.org; helo=mail-qk1-x743.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: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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:20570 Archived-At: --0000000000001baa6505ac0edb3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 3, 2020 at 3:41 PM Marc Nieper-Wi=C3=9Fkirchen wrote: > 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". It certainly should not. But it can happen when one person writes the spec and another the implementation, and communication is less than perfect. Process improvements since then should make this less likely, but arse [sic] longa, vita brevis. > > 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, That can and shall be fixed. The spec is stabilized, short of a post-finalization note (which is never mandatory), but the implementation, like any other program, must be presumed to have bugs, which is why its behavior is *not* part of the spec (and why we don't use the term "reference implementation" any more). > > and the specifications themselves are self-contradictory (see above). I'll look into that further. > > At this point, I don't see how the problems can be fixed without > > breaking some users' assumptions, and therefore breaking existing code. > *All* bug fixes, even those to bring an implementation into compliance with its spec, risk breaking existing code. Some people may have inserted workarounds that are unavoidably not idempotent. My favorite example of this is a stock-ticker service that transmitted incorrect stock prices for stocks with 4-letter ticker symbols like AAPL. The bug was easy to work around, and many people did. When the bug was eventually fixed, many clients were extremely annoyed, and insisted that correct prices only be made available when using a versioning flag. I don't know the final outcome. I hope the people responsible for the server stood their ground. 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. > 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. > 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). > - 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. - Formal semantics are almost always missing. > That requires someone who can write their own Greek, which would not be me. > 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. > 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/. > I stand behind my final reply in that thread as well as Shiro's. John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org A mosquito cried out in his pain, "A chemist has poisoned my brain!" The cause of his sorrow / Was para-dichloro- Diphenyltrichloroethane. (aka DDT) --0000000000001baa6505ac0edb3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 3, 2020 at 3:41 PM Marc N= ieper-Wi=C3=9Fkirchen <marc.nie= per@gmail.com> wrote:

> It didn&#= 39;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".=C2=A0

It certainly should not.=C2=A0 But it can happen when one person wri= tes the spec and another the implementation, and communication is less than= perfect.=C2=A0 Process improvements since then should make this less likel= y, but arse=C2=A0[sic] longa, vita brevis.
=C2=A0
> I'm sorry to say it, but i= n my opinion SRFI-121 and SRFI-158 should be
> deprecated and avoided.=C2=A0 The reference implementations do not mat= ch the
> specifications,

That can and shall be = fixed.=C2=A0 The spec is stabilized, short of a post-finalization note (whi= ch is never mandatory), but the implementation, like any other program, mus= t be presumed to have bugs, which is why its=C2=A0behavior is *not* part of= the spec (and why we don't use the term "reference implementation= " any more).
=C2=A0
> and the specifications themselves are self-contradictor= y=C2=A0(see above).=C2=A0

I'll look in= to that further.
=C2=A0
> At this point, I don't see how the problems can be f= ixed without
> breaking some users' assumptions, and therefore breaking existing = code.

*All* bug fixes, even those to br= ing an implementation into compliance with its spec, risk breaking existing= code.=C2=A0 Some people may have inserted workarounds that are unavoidably= not idempotent.

My favorite example of this is a = stock-ticker service that transmitted incorrect stock prices for stocks wit= h 4-letter ticker symbols like AAPL.=C2=A0 The bug was easy to work around,= and many people did.=C2=A0 When the bug was eventually fixed, many clients= were extremely annoyed, and insisted that correct prices only be made avai= lable when using a versioning flag.=C2=A0 I don't know the final outcom= e.=C2=A0 I hope the people responsible for the server stood their ground.

=C2=A0= 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?=C2=A0= The implementations are written in a Turing-complete language.
= =C2=A0
A similar pro= blem 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.
=C2=A0
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.= =C2=A0 A large granite boulder cannot be cut like a diamond, but it has use= s that a diamond does not (and vice versa, of course).
=C2=A0
- Questions of tail con= text are often ignored.
- Higher-order procedures are often silent with respect to call/cc,
exceptions or side effects.

Regrettably= both true.=C2=A0 Scheme is so often used without effects that it's eas= y to forget they exist.
=C2=A0
- Formal syntax is often missing.

What = further syntax do you want?=C2=A0 Procedures have only a single syntax, so = all we need to know is what arguments exist and in what order.=C2=A0 Macros= are few, but informal explanations (as in R[57]RS) seem sufficient to me.<= /div>

- Formal semantics are almost always missing.

That requires someone who can write their own Greek, which would not= be me.
=C2=A0
SRFI 121/158 is incidentally also an example for this. Take 'gappe= nd'
from SRFI 158, for example. It doesn't specify when the various
generator arguments are being called.

I= don't follow you.=C2=A0 It is quite explicit that each is called until= it is exhausted in left to right order.
=C2=A0
PS: One of my own issues with SRFI 15= 8 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/62= 19505/. A follow-up
thread begins here:
https://srfi-email.schemers.org/srfi-158/msg/65= 57831/.

I stand behind my final rep= ly in that thread as well as Shiro's.



John Cowan =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://vrici.lojban.org/~cowan =C2=A0 =C2= =A0 =C2=A0 =C2=A0cowan@ccil.org
A = mosquito cried out in his pain,
"A chemist has poisoned my brain!&q= uot;
The cause of his sorrow / Was para-dichloro-
Diphenyltrichl= oroethane. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(aka DDT)
=C2=A0<= /div>
--0000000000001baa6505ac0edb3d--