Re: SRFI inclusion

[Per Bothner <per@bothner.com>]

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
per@bothner.com   http://per.bothner.com/