Re: [PATCHv3] Extensions for SRFI-171 (Transducers)

[Ludovic Courtès]

Hello,

Colin Woodbury  skribis:

> In that case, please hold on the patch. I am currently "rounding out"
> the "one true Transducer API" in several other Lisps, and am close to
> what I consider a representative set of the desirable primitives a
> developer would want out-of-the-box. One I'm done there, I will return
> to this and a few things that are currently missing.
>
> The other Lisps have also achieved a zip-like pattern (i.e. passing
> multiple collections to `transduce` at the same time, thus allowing
> functions like `map` to operate on multiple inputs).
>
> There is also the issue of SRFI-171's disambiguated `transduce-list`,
> `transduce-vector`, etc., since Scheme has no `defgeneric` by
> default. Guile _does_ however, so we could write a generic `transduce`
> in Guile's own extensions. In general though it would be nice if
> SRFI-XYZ "Transducers Redux" could depend on a standardized generics
> system, but alas.
>
> Anyway, thanks for getting back to me. I'll return to this effort in
> due time.

Alright, ping me when you feel ready!

Thanks,
Ludo’.

Re: [PATCHv3] Extensions for SRFI-171 (Transducers)

[Colin Woodbury]

On 8/18/23 19:03, Ludovic Courtès wrote:

Apologies for the delays, we’re pioneering “slow dev” I guess.  :-)


Haha no issue at all!

> Could you take a look?

In that case, please hold on the patch. I am currently "rounding out" 
the "one true Transducer API" in several other Lisps, and am close to 
what I consider a representative set of the desirable primitives a 
developer would want out-of-the-box. One I'm done there, I will return 
to this and a few things that are currently missing.


The other Lisps have also achieved a zip-like pattern (i.e. passing 
multiple collections to `transduce` at the same time, thus allowing 
functions like `map` to operate on multiple inputs).


There is also the issue of SRFI-171's disambiguated `transduce-list`, 
`transduce-vector`, etc., since Scheme has no `defgeneric` by default. 
Guile _does_ however, so we could write a generic `transduce` in Guile's 
own extensions. In general though it would be nice if SRFI-XYZ 
"Transducers Redux" could depend on a standardized generics system, but 
alas.


Anyway, thanks for getting back to me. I'll return to this effort in due 
time.


Cheers,

Colin

Re: [PATCHv3] Extensions for SRFI-171 (Transducers)

[Ludovic Courtès]

Hi Colin,

Colin Woodbury  skribis:

> Hi again, any thoughts on these SRFI-171 extensions?

Looong ago, before we waited for copyright assignment to be on file, I
made minor suggestions on the patch, which I think you haven’t responded
to:

  https://lists.gnu.org/archive/html/guile-devel/2023-01/msg00044.html

Could you take a look?

Apologies for the delays, we’re pioneering “slow dev” I guess.  :-)

Thanks,
Ludo’.

Re: [PATCHv3] Extensions for SRFI-171 (Transducers)

[Colin Woodbury]

On 8/13/23 04:37, Linus Björnstam wrote:

Hi!

I have finally started getting some computer time again, and I will make sure 
to get this into some kind of extra library in the official SRFI repo.

It will not be official, but maybe for a future SRFI based on SRFI 171.
  



Hi Linus, good to hear from you. See also my recent work on Transducers 
in general here:


https://sr.ht/~fosskers/transducers/sources

My goal is to unify the Transducers interface across as many Lisps as 
possible. Note that I've added more primitives there than what I 
proposed to add to Guile with these patches. Eventually my hope is that 
my unification work can identify all the main primitives and expected 
behaviour of Transducers, and thus become the basis for a successor to 
SFRI-171 for Scheme.


Cheers!

Re: [PATCHv3] Extensions for SRFI-171 (Transducers)

[Linus Björnstam]

Hi!

I have finally started getting some computer time again, and I will make sure 
to get this into some kind of extra library in the official SRFI repo. 

It will not be official, but maybe for a future SRFI based on SRFI 171.
 

-- 
  Linus Björnstam

On Wed, 28 Jun 2023, at 14:27, Colin Woodbury wrote:
> Hi again, any thoughts on these SRFI-171 extensions?
>
> On 5/18/23 09:36, Colin Woodbury wrote:
>> Hi! Forgive the delay; my copyright assignment for Guile has finally 
>> gone through. Please let me know if the patches are still good!
>>
>> Colin
>>
>> On 1/24/23 18:07, Ludovic Courtès wrote:
>>> Hi Colin,
>>>
>>> Colin Woodbury  skribis:
>>>
 Sorry if I wasn't clear - I have alright assigned copyright to the FSF
 (about 1.5 years ago). Things should be good to go, unless I've
 misunderstood.
>>> I checked the records on fencepost.gnu.org and AFAICS, you assigned
>>> copyright for Emacs only (copyright assignments are for a single GNU
>>> package), so you will need to do the paperwork for Guile this time.
>>>
>>> Thanks in advance.  :-)
>>>
>>> Ludo’.

Re: [PATCHv3] Extensions for SRFI-171 (Transducers)

[Colin Woodbury]

Hi again, any thoughts on these SRFI-171 extensions?

On 5/18/23 09:36, Colin Woodbury wrote:
Hi! Forgive the delay; my copyright assignment for Guile has finally 
gone through. Please let me know if the patches are still good!


Colin

On 1/24/23 18:07, Ludovic Courtès wrote:

Hi Colin,

Colin Woodbury  skribis:


Sorry if I wasn't clear - I have alright assigned copyright to the FSF
(about 1.5 years ago). Things should be good to go, unless I've
misunderstood.

I checked the records on fencepost.gnu.org and AFAICS, you assigned
copyright for Emacs only (copyright assignments are for a single GNU
package), so you will need to do the paperwork for Guile this time.

Thanks in advance.  :-)

Ludo’.

Re: [PATCHv3] Extensions for SRFI-171 (Transducers)

[Colin Woodbury]

Hi! Forgive the delay; my copyright assignment for Guile has finally 
gone through. Please let me know if the patches are still good!


Colin

On 1/24/23 18:07, Ludovic Courtès wrote:

Hi Colin,

Colin Woodbury  skribis:


Sorry if I wasn't clear - I have alright assigned copyright to the FSF
(about 1.5 years ago). Things should be good to go, unless I've
misunderstood.

I checked the records on fencepost.gnu.org and AFAICS, you assigned
copyright for Emacs only (copyright assignments are for a single GNU
package), so you will need to do the paperwork for Guile this time.

Thanks in advance.  :-)

Ludo’.

Re: [PATCHv3] Extensions for SRFI-171 (Transducers)

[Ludovic Courtès]

Hi Colin,

Colin Woodbury  skribis:

> Sorry if I wasn't clear - I have alright assigned copyright to the FSF
> (about 1.5 years ago). Things should be good to go, unless I've
> misunderstood.

I checked the records on fencepost.gnu.org and AFAICS, you assigned
copyright for Emacs only (copyright assignments are for a single GNU
package), so you will need to do the paperwork for Guile this time.

Thanks in advance.  :-)

Ludo’.

Re: [PATCHv3] Extensions for SRFI-171 (Transducers)

[Colin Woodbury]

Hi Ludovic,

Sorry if I wasn't clear - I have alright assigned copyright to the FSF 
(about 1.5 years ago). Things should be good to go, unless I've 
misunderstood.


Cheers,

Colin

On 1/24/23 07:17, Ludovic Courtès wrote:

Hi Colin,

Colin Woodbury  skribis:


Hi Ludovic, thanks for getting back to me! I've updated the patches as
you've suggested. I think I've gotten the commit format correct this
time.

Yup, it’s looks perfect!


Also, I'll opt to assign copyright to the FSF, as I've already done so
for Emacs (and signed the papers, etc.).

Alright.  In that case, could you send the form at

to ass...@gnu.org (as noted at the top).  If you don’t get a reply
within two weeks, please let Andy and/or myself know and we’ll ping
them.

I know this is frustrating but I’ll wait for their notification to push
the changes (on the bright side, it’s a one-time delay).


Let there be transduction! Cheers,

Definitely.  :-)

Thanks!

Ludo’.

Re: [PATCHv3] Extensions for SRFI-171 (Transducers)

[Ludovic Courtès]

Hi Colin,

Colin Woodbury  skribis:

> Hi Ludovic, thanks for getting back to me! I've updated the patches as
> you've suggested. I think I've gotten the commit format correct this
> time.

Yup, it’s looks perfect!

> Also, I'll opt to assign copyright to the FSF, as I've already done so
> for Emacs (and signed the papers, etc.).

Alright.  In that case, could you send the form at

to ass...@gnu.org (as noted at the top).  If you don’t get a reply
within two weeks, please let Andy and/or myself know and we’ll ping
them.

I know this is frustrating but I’ll wait for their notification to push
the changes (on the bright side, it’s a one-time delay).

> Let there be transduction! Cheers,

Definitely.  :-)

Thanks!

Ludo’.

Re: [PATCHv3] Extensions for SRFI-171 (Transducers)

[Colin Woodbury]

Hi Ludovic, thanks for getting back to me! I've updated the patches as 
you've suggested. I think I've gotten the commit format correct this time.


Also, I'll opt to assign copyright to the FSF, as I've already done so 
for Emacs (and signed the papers, etc.).


Let there be transduction! Cheers,

Colin

On 1/15/23 00:09, Ludovic Courtès wrote:

Hi Colin and all!

These patches look like a nice addition.

First, you have the option of assigning your copyright for this
contribution (and future Guile contributions if you wish) to the FSF, or
you can choose not to:

   https://lists.gnu.org/archive/html/guile-devel/2022-10/msg8.html

Please take a look at the message above and let us know what you’d like
to do.  If you choose not to assign copyright, you’ll have to add
copyright lines for you (or whatever entity holds copyright on your
work) in the modified files.

Overall the changes LGTM; I have minor comments and suggestions:

Colin Woodbury  skribis:


 From 96856b184a507886db2c5c20323983ae125a6bdb Mon Sep 17 00:00:00 2001
From: Colin Woodbury 
Date: Mon, 19 Dec 2022 09:39:37 +0900
Subject: [PATCH 1/4] srfi-171: add twindow and various reducers

This adds a number of reduction primitives often seen in other languages
to Guile's SRFI-171 extensions.

Most critical may be `rfold`, which could be called the fundamental
reducer, as it's likely that all other reducers could be defined in
terms of it (though not all are). While `tfold` already exists in
Guile's SRFI-171 extension as a transducer, folding is in essence a
reduction. Also without a primative like `rlast` (also introduced here),
the results of `tfold` are difficult to consume. This is avoided by
providing `rfold` directly as a generalised means to collapse an entire
transduction down into a single value (i.e. the whole point of
reducers). `rfold` is also useful for the creation of ad-hoc reducers,
as any 2-arg function can be passed to it to fold the stream of values.

`rfirst`, `rlast`, and `rfind` are common idioms and so have been added.

The equivalent of `rmax` and `rmin` are easy to write manually via
`rfold`, but they have been provided here as a convenience in the same
spirit as `rcons`.

`rfor-each` also cannot be forgotten as a classic adaptation of its
SRFI-1 cousin.

Also added is `twindow`, handy for analysing groups of adjacent items.

[...]


 From 58e7ca2718a860ca2fb5692684d6d128a7c1ae75 Mon Sep 17 00:00:00 2001
From: Colin Woodbury 
Date: Tue, 20 Dec 2022 09:41:51 +0900
Subject: [PATCH 2/4] doc: add new SRFI-171 reducers to the manual

---
  doc/ref/srfi-modules.texi | 96 +--

[...]


 From 7b7538c61799fa0fa0e2fa18efba98b7de7da1ca Mon Sep 17 00:00:00 2001
From: Colin Woodbury 
Date: Wed, 21 Dec 2022 09:30:50 +0900
Subject: [PATCH 3/4] srfi-171: add unit tests for new functions

These tests mainly match the examples shown in the docs.
---
  test-suite/tests/srfi-171.test | 66 ++

We’d squash these three commits together to provide a single
self-contained commit with code and the corresponding tests and doc.

The convention in Guile is for commit logs to follow the ChangeLog style
(see ‘git log’ for examples).  If you’re not sure how to do that, I can
do it on your behalf as a welcome present.  ;-)


 From 87a74d106f11680c4924befb664d7ef685c16b06 Mon Sep 17 00:00:00 2001
From: Colin Woodbury 
Date: Thu, 22 Dec 2022 20:32:33 +0900
Subject: [PATCH 4/4] doc: added a guide for writing custom reducers

The guide previously explained what reducers were, but not the specifics
of how to write them yourself. This commits rectifies this.

Nice!


+++ b/doc/ref/srfi-modules.texi
@@ -5966,6 +5966,82 @@ Yield the maximum (or minimum) value of the 
transduction, or the
  @var{seed} value if there is none.
  @end deffn
  
+@subheading Writing your own reducers

+If you want to reduce some values via an ordinary function that you

Please capitalize section titles and leave a blank line below it (same
for the section that follows).


+However, if you want more customized behaviour (such as early
+termination and/or arbitrary manipulation of the input values) then
+you're free to write a reducer manually. To do so, we need to write a

Normally we leave two spaces after end-of-sentence periods, to ease
navigation in Emacs and please Texinfo (info "(texinfo) Ending a
Sentence").

Could you send updated patches?

Thanks for your work!

Ludo’.From f17a7480b972e192a21c67965ce5597cb3d4379d Mon Sep 17 00:00:00 2001
From: Colin Woodbury 
Date: Mon, 19 Dec 2022 09:39:37 +0900
Subject: [PATCH 1/2] srfi-171: Add twindow and various reducers

This adds a number of reduction primitives often seen in other languages
to Guile's SRFI-171 extensions.

Most critical may be `rfold`, which could be called the fundamental
reducer, as it's likely that all other reducers could be defined in
terms of it (though not all are). While `tfold` already exists in
Guile's SRFI-171 extension as a transducer,