From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id 070193858D20 for ; Mon, 9 Jan 2023 09:42:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 070193858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pg1-x534.google.com with SMTP id 7so5479085pga.1 for ; Mon, 09 Jan 2023 01:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=r4vDmQ6u1tgqH178wHSoWbYsRZLC1Bh0gClf9vZIey0=; b=Kb1Qxq6Te6GiyyV9l2FCEniTF0EsSTulUrxVKX3VomEKTb0sPa1EOOsG5t1WQq2vKc CAAxoPgHXfd+GFwzpqbjGhVlLnsP/zirs7EvpTjWIxFjIbmXWy0JkHpjfce1tOMuItn9 xprJ2qL1tDv33XDyDnHdsmLYtl0TDYjuq9ndQsFAkAPuA2jtv3fgrXbdM70wBj4RWBzu EOtYIMqlw+cnOhCRMFBzgs7S+hHATAueHNnSd/p6L7ucee3Vw+dn+T4p78fm/Tl/UMYN dKIpbg47EZyFnQnGgnE2niy5cld8Pqn5ulG2Ny5Jk4CfPpIDefmU4PQ25toNZ1yUYjRD SVyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=r4vDmQ6u1tgqH178wHSoWbYsRZLC1Bh0gClf9vZIey0=; b=SujND8tk+mcgLdTPMe+sUCLPFCSGTWktl9moiQiqnbTPDn/jSXllrDelOHXOQoyU4G sNbBeK4xWwftR/SDj6dcFIvb25tf9tEGQJ1Izw7TOWSNp/fn1QYA6X6DUgjyw30s6BtL xTz6EcumH6QXCr6B0BAgCGmWn0v/IKYwwEOzaRL3xu1J2BU2Wvo3DEPoMyk390/3+M7v Q8Ot3QiqdO9JweYyXcoxQMXDj0id/vHVYBqWZJJtzLcXSl+UUxrC0PxjgYaQmmzelnJR bjzgAhEHD2mn+HFB5XWaNJD2VDQ6I7Ps0AKdCG5bsBEZv+kq4PyND/CLUsWopjmrh60i Tz5Q== X-Gm-Message-State: AFqh2kqzoZTE0nKXl7GPNdiYnE1D9qQAy5MckB0zV423AgxMfWI+xzf/ WAmvsqpbSapyvJiLXo2W8fR88zBxOFpUoe8Ttd+wkdyoOJY= X-Google-Smtp-Source: AMrXdXtUKApSVlsojl8k9J+ZEQOKM/Z8EsLFJT4cAMipIIissos3LZkqe7ab7KXfipts0iOBDaVEUYaYiuINsFyoYBY= X-Received: by 2002:a63:18f:0:b0:478:b2d5:d843 with SMTP id 137-20020a63018f000000b00478b2d5d843mr3113782pgb.415.1673257342019; Mon, 09 Jan 2023 01:42:22 -0800 (PST) MIME-Version: 1.0 References: <0aee6f41-9f36-e9ef-6761-e8d81a3b5f5f@bothner.com> In-Reply-To: From: Arvydas Silanskas Date: Mon, 9 Jan 2023 11:42:10 +0200 Message-ID: Subject: Re: Time for a new release? 3.1.2? To: Lassi Kortela Cc: Sascha Ziemann , kawa mailing list Content-Type: multipart/alternative; boundary="0000000000007d2c9005f1d1958e" X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000007d2c9005f1d1958e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The way I understand the r7rs-large process, is that it tries to split out low floor difficulty / portable concerns (eg., streams) from high floor difficulty / not-portable concerns (syntax-case, etc), so that implementations could choose to implement some but not all of it, to extent that is feasible (I wasn't there when it happened, but my understanding of r6rs controversies was mostly to do with implementers getting handed uncompromising burden of implementation requirements). In that view, it seems sensible to me to have both specific procedures now and plausibly generic procedures later. Also, specific procedures enable more deterministic optimization opportunities. Number system is generic in the standard, but we also have eg. srfi 143 providing non-generic procedures with "allow more efficient implementations" stated as the core reasoning. 2023-01-09, pr, 11:03 Lassi Kortela ra=C5=A1=C4=97: > >> Scheme needs some way to define "interfaces"/"traits" that multiple > data-types > >> can implement. Many Scheme implementations (including Kawa) have that, > but a > >> general portable solution is highly desired. Without that, there is no > point > >> in piling on more and more libraries for more and more data types. > > > This requires generics and this requires method dispatching. > > > > Many Schemers like to pay the price for dynamic types, but are scared by > the > > price for dynamic dispatching. I am still astonished why this is the > case. > > The efficiency debate can only be settled by profiling and benchmarking. > > > Any ideas? > > IMHO the right solution is: > > - Specify generic collection procedures in RnRS. > > - Those procedures MUST handle all the collection types in RnRS. > > - The procedures SHOULD also handle extra collection types provided by > the Scheme implementation (from SRFIs, etc.) > > - The implementation MAY support user-defined generic procedures. When > it does, the standard collection procedures SHOULD be defined using this > framework so that users can extend them. > > The RnRS number procedures are already generic, and work according to > these principles (e.g. Kawa extends them to support quaternions). This > approach is simple, flexible, and has stood the test of time. > --0000000000007d2c9005f1d1958e--