public inbox for kawa@sourceware.org
 help / color / mirror / Atom feed
* SRFI inclusion
@ 2021-02-05 16:22 Arvydas Silanskas
  2021-02-05 22:03 ` Per Bothner
  0 siblings, 1 reply; 4+ messages in thread
From: Arvydas Silanskas @ 2021-02-05 16:22 UTC (permalink / raw)
  To: kawa mailing list

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)?

Best regards
Arvydas

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: SRFI inclusion
  2021-02-05 16:22 SRFI inclusion Arvydas Silanskas
@ 2021-02-05 22:03 ` Per Bothner
  2021-02-06 10:22   ` Helmut Eller
  0 siblings, 1 reply; 4+ messages in thread
From: Per Bothner @ 2021-02-05 22:03 UTC (permalink / raw)
  To: kawa

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/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: SRFI inclusion
  2021-02-05 22:03 ` Per Bothner
@ 2021-02-06 10:22   ` Helmut Eller
  2021-02-06 12:48     ` Lassi Kortela
  0 siblings, 1 reply; 4+ messages in thread
From: Helmut Eller @ 2021-02-06 10:22 UTC (permalink / raw)
  To: kawa

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: SRFI inclusion
  2021-02-06 10:22   ` Helmut Eller
@ 2021-02-06 12:48     ` Lassi Kortela
  0 siblings, 0 replies; 4+ messages in thread
From: Lassi Kortela @ 2021-02-06 12:48 UTC (permalink / raw)
  To: Helmut Eller, kawa

> 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.

I agree that the maintenance burden for practical Scheme libraries is 
growing too great for any one person or implementation. We've just been 
having discussions in this general direction on the #scheme IRC channel. 
Several people would like something like the SRFI process, but allowing 
for API evolution, with less stringent requirements to get the API 
design right all at once.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-02-06 12:48 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-05 16:22 SRFI inclusion Arvydas Silanskas
2021-02-05 22:03 ` Per Bothner
2021-02-06 10:22   ` Helmut Eller
2021-02-06 12:48     ` Lassi Kortela

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).