From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <glsk-kawa@m.gmane-mx.org>
Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214])
 by sourceware.org (Postfix) with ESMTPS id 479D23857C5E
 for <kawa@sourceware.org>; Sat,  6 Feb 2021 10:22:52 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 479D23857C5E
Received: from list by ciao.gmane.io with local (Exim 4.92)
 (envelope-from <glsk-kawa@m.gmane-mx.org>) id 1l8Kjq-0006hR-3d
 for kawa@sourceware.org; Sat, 06 Feb 2021 11:22:50 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: kawa@sourceware.org
From: Helmut Eller <eller.helmut@gmail.com>
Subject: Re: SRFI inclusion
Date: Sat, 06 Feb 2021 11:22:40 +0100
Message-ID: <m2o8gxxzpr.fsf@gmail.com>
References: <CAPh7weAnDJTJhayk757v+1qvMyVT1PxSs=D_9=X6FxQBCOCAXA@mail.gmail.com>
 <97fcf177-4168-b564-9ce3-32396986d5a1@bothner.com>
Mime-Version: 1.0
Content-Type: text/plain
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
Cancel-Lock: sha1:eLoYDqBHwfOZu/fISNmSQywPHB8=
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,
 FORGED_GMAIL_RCVD, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,
 HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NML_ADSP_CUSTOM_MED,
 SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: kawa@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Kawa mailing list <kawa.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/kawa>,
 <mailto:kawa-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/kawa/>
List-Post: <mailto:kawa@sourceware.org>
List-Help: <mailto:kawa-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/kawa>,
 <mailto:kawa-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Feb 2021 10:22:53 -0000

On Fri, Feb 05 2021, Per Bothner wrote:

> At least there are some semi-standard naming conventions, but I think
> this approach of defining dozens of distinctly-named functions for
> each datatype is a dead end.)

I don't think that this is a problem, because the module system keeps
those functions in their own namespace and shouldn't bother people who
don't use them.

A common interface would be nice, but designing good interfaces is not
easy.  If somebody comes up with a good interface later, maybe it can be
added post-hoc; not ideal, but should be doable with a layer of
indirection.

What bothers me more, is that maintaining those libraries separately for
each Scheme system doesn't scale.  It would probably be better to do it
like they do it for the BOOST libraries.  Have one common code base that
can be compiled with different compilers; possibly with implementation
specific versions but maintained as part of the common code base by the
people who use and care about the libraries.

Helmut