public inbox for kawa@sourceware.org
 help / color / mirror / Atom feed
From: Arvydas Silanskas <nma.arvydas.silanskas@gmail.com>
To: Lassi Kortela <lassi@lassi.io>
Cc: Sascha Ziemann <ceving@gmail.com>,
	kawa mailing list <kawa@sourceware.org>
Subject: Re: Time for a new release? 3.1.2?
Date: Mon, 9 Jan 2023 11:42:10 +0200	[thread overview]
Message-ID: <CAPh7weAPj-zfSRgYLf4dcMAAGekpu8kUoBqbZATpuhXF+cz9VA@mail.gmail.com> (raw)
In-Reply-To: <a55ab139-ce90-6e00-627f-96393ff02d12@lassi.io>

[-- Attachment #1: Type: text/plain, Size: 2311 bytes --]

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 <lassi@lassi.io> rašė:

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

  reply	other threads:[~2023-01-09  9:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-28 17:53 Duncan Mak
2022-09-29  4:38 ` Per Bothner
2022-09-29 15:18   ` Arvydas Silanskas
2022-10-03 11:36     ` Arvydas Silanskas
2022-10-21  9:01       ` Arvydas Silanskas
2022-10-27  4:50         ` Shawn Wagner
2022-12-06  9:07           ` Arvydas Silanskas
2023-01-05 21:34             ` Per Bothner
2023-01-05 22:02               ` Damien Mattei
2023-01-06 12:16               ` Lassi Kortela
2023-01-08 18:11               ` Sascha Ziemann
2023-01-09  9:03                 ` Lassi Kortela
2023-01-09  9:42                   ` Arvydas Silanskas [this message]
2023-01-09 10:51                     ` 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=CAPh7weAPj-zfSRgYLf4dcMAAGekpu8kUoBqbZATpuhXF+cz9VA@mail.gmail.com \
    --to=nma.arvydas.silanskas@gmail.com \
    --cc=ceving@gmail.com \
    --cc=kawa@sourceware.org \
    --cc=lassi@lassi.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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