public inbox for
 help / color / mirror / Atom feed
From: Per Bothner <>
Subject: Re: SRFI inclusion
Date: Fri, 5 Feb 2021 14:03:14 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2/5/21 8:22 AM, Arvydas Silanskas via Kawa wrote:
> Good evening,
> What is the process of deciding upon & including SRFIs in kawa? May I have
> a go at implementing library-like SRFIs 27, 145, 158, 180, 189 and making
> merge requests without a fear of objections about the choice of SRFI itself
> (naturally objections over quality of implementation itself is another
> deal)?

My opinion - others are welcome to chime in:

There are many SRFIs I think may be ill-considered: Primarily the shear number
of them makes it impossible for anyone to grasp them all, or create a coherent
vision of them.  (To be fair even C++ and Java suffer from useful classes being designed
in isolation from each other.)  Secondarily, the number of container classes without any
kind of inheritance or overloading.  (For example draft SRFI 215 flexvector defines
a useful data type and a useful set of functions for working with them. However, it's a
new large set of functions, with no overlap with functions for working with plain vectors.
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.)

That said, the ones you mention seem (at a quick glance) small and standalone,
and I don't see any problem including them as libraries.  Including new names
in the (kawa base) package is a much higher hurdle, of course.

In terms of implementation, when a SRFI duplicates existing Kawa functionality
(in terms of basic functionality, not necessarily every detail) I strongly prefer
that it be implemented on top of Kawa functionality, especially any types that
are introduced.  For example new container types should if possible use an
existing Kawa class, or should inherit from the appropriate existing classes/interfaces.
	--Per Bothner

  reply	other threads:[~2021-02-05 22:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-05 16:22 Arvydas Silanskas
2021-02-05 22:03 ` Per Bothner [this message]
2021-02-06 10:22   ` Helmut Eller
2021-02-06 12:48     ` Lassi Kortela

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).