Time for a new release? 3.1.2?

Time for a new release? 3.1.2?

[Duncan Mak]

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

Hello Per,

It's been over two years since the last release (3.1.1, 2020-01-16), I
count 72 commits made to the master branch since then.

Would it be a good time to make a 3.1.2 release soon?


Thanks!

-- 
Duncan.

Re: Time for a new release? 3.1.2?

[Per Bothner]

On 9/28/22 10:53, Duncan Mak via Kawa wrote:
> Hello Per,
> 
> It's been over two years since the last release (3.1.1, 2020-01-16), I
> count 72 commits made to the master branch since then.
> 
> Would it be a good time to make a 3.1.2 release soon?

Might as well call it 3.2.

It would be helpful if someone went through the changes
(using 'git log' and **/ChangeLog) to summarize what has
change in a format suitable for doc/news.texi.

Also make a note of where the manual needs to be updated.

Minor tweaks and bug fixes don't need to be mentioned.

-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Time for a new release? 3.1.2?

[Arvydas Silanskas]

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

I can go over it on Sunday, if no one else does it by then.

Arvydas

2022-09-29, kt, 07:38 Per Bothner <per@bothner.com> rašė:

>
>
> On 9/28/22 10:53, Duncan Mak via Kawa wrote:
> > Hello Per,
> >
> > It's been over two years since the last release (3.1.1, 2020-01-16), I
> > count 72 commits made to the master branch since then.
> >
> > Would it be a good time to make a 3.1.2 release soon?
>
> Might as well call it 3.2.
>
> It would be helpful if someone went through the changes
> (using 'git log' and **/ChangeLog) to summarize what has
> change in a format suitable for doc/news.texi.
>
> Also make a note of where the manual needs to be updated.
>
> Minor tweaks and bug fixes don't need to be mentioned.
>
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/
>

Re: Time for a new release? 3.1.2?

[Arvydas Silanskas]

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

I propose to pause a bit; I remembered one thing that irked me quite a bit,
and that is the failing test suite. I think it would be prudent to fix it
first before the release. As part of the hacktober festive theme, I'll try
to sit down and find time to make a pull request on the matter soon.

Arvydas

2022-09-29, kt, 18:18 Arvydas Silanskas <nma.arvydas.silanskas@gmail.com>
rašė:

> I can go over it on Sunday, if no one else does it by then.
>
> Arvydas
>
> 2022-09-29, kt, 07:38 Per Bothner <per@bothner.com> rašė:
>
>>
>>
>> On 9/28/22 10:53, Duncan Mak via Kawa wrote:
>> > Hello Per,
>> >
>> > It's been over two years since the last release (3.1.1, 2020-01-16), I
>> > count 72 commits made to the master branch since then.
>> >
>> > Would it be a good time to make a 3.1.2 release soon?
>>
>> Might as well call it 3.2.
>>
>> It would be helpful if someone went through the changes
>> (using 'git log' and **/ChangeLog) to summarize what has
>> change in a format suitable for doc/news.texi.
>>
>> Also make a note of where the manual needs to be updated.
>>
>> Minor tweaks and bug fixes don't need to be mentioned.
>>
>> --
>>         --Per Bothner
>> per@bothner.com   http://per.bothner.com/
>>
>

Re: Time for a new release? 3.1.2?

[Arvydas Silanskas]

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

The test suite had been fixed. But then one other thing popped into my mind
-- how about the R7RS large red and tangerine support? The SRFIs required
seem to be very straightforward, not requiring any pervasive compiler
hacking but simply defining some simple libraries. I know R7RS large colors
down the road will start including various non-portable / more invasive
requirements, but we can decide if we want to support those when we get
there.

2022-10-03, pr, 14:36 Arvydas Silanskas <nma.arvydas.silanskas@gmail.com>
rašė:

> I propose to pause a bit; I remembered one thing that irked me quite a
> bit, and that is the failing test suite. I think it would be prudent to fix
> it first before the release. As part of the hacktober festive theme, I'll
> try to sit down and find time to make a pull request on the matter soon.
>
> Arvydas
>
> 2022-09-29, kt, 18:18 Arvydas Silanskas <nma.arvydas.silanskas@gmail.com>
> rašė:
>
>> I can go over it on Sunday, if no one else does it by then.
>>
>> Arvydas
>>
>> 2022-09-29, kt, 07:38 Per Bothner <per@bothner.com> rašė:
>>
>>>
>>>
>>> On 9/28/22 10:53, Duncan Mak via Kawa wrote:
>>> > Hello Per,
>>> >
>>> > It's been over two years since the last release (3.1.1, 2020-01-16), I
>>> > count 72 commits made to the master branch since then.
>>> >
>>> > Would it be a good time to make a 3.1.2 release soon?
>>>
>>> Might as well call it 3.2.
>>>
>>> It would be helpful if someone went through the changes
>>> (using 'git log' and **/ChangeLog) to summarize what has
>>> change in a format suitable for doc/news.texi.
>>>
>>> Also make a note of where the manual needs to be updated.
>>>
>>> Minor tweaks and bug fixes don't need to be mentioned.
>>>
>>> --
>>>         --Per Bothner
>>> per@bothner.com   http://per.bothner.com/
>>>
>>

Re: Time for a new release? 3.1.2?

[Shawn Wagner]

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

I've ported a lot of SRFIs to Kawa at
https://gitlab.com/shawn_w/kawalib/-/tree/master though I'm not sure if any
of them are included in Red or Tangerine.

On Fri, Oct 21, 2022 at 2:02 AM Arvydas Silanskas via Kawa <
kawa@sourceware.org> wrote:

> The test suite had been fixed. But then one other thing popped into my mind
> -- how about the R7RS large red and tangerine support? The SRFIs required
> seem to be very straightforward, not requiring any pervasive compiler
> hacking but simply defining some simple libraries. I know R7RS large colors
> down the road will start including various non-portable / more invasive
> requirements, but we can decide if we want to support those when we get
> there.
>
> 2022-10-03, pr, 14:36 Arvydas Silanskas <nma.arvydas.silanskas@gmail.com>
> rašė:
>
> > I propose to pause a bit; I remembered one thing that irked me quite a
> > bit, and that is the failing test suite. I think it would be prudent to
> fix
> > it first before the release. As part of the hacktober festive theme, I'll
> > try to sit down and find time to make a pull request on the matter soon.
> >
> > Arvydas
> >
> > 2022-09-29, kt, 18:18 Arvydas Silanskas <nma.arvydas.silanskas@gmail.com
> >
> > rašė:
> >
> >> I can go over it on Sunday, if no one else does it by then.
> >>
> >> Arvydas
> >>
> >> 2022-09-29, kt, 07:38 Per Bothner <per@bothner.com> rašė:
> >>
> >>>
> >>>
> >>> On 9/28/22 10:53, Duncan Mak via Kawa wrote:
> >>> > Hello Per,
> >>> >
> >>> > It's been over two years since the last release (3.1.1, 2020-01-16),
> I
> >>> > count 72 commits made to the master branch since then.
> >>> >
> >>> > Would it be a good time to make a 3.1.2 release soon?
> >>>
> >>> Might as well call it 3.2.
> >>>
> >>> It would be helpful if someone went through the changes
> >>> (using 'git log' and **/ChangeLog) to summarize what has
> >>> change in a format suitable for doc/news.texi.
> >>>
> >>> Also make a note of where the manual needs to be updated.
> >>>
> >>> Minor tweaks and bug fixes don't need to be mentioned.
> >>>
> >>> --
> >>>         --Per Bothner
> >>> per@bothner.com   http://per.bothner.com/
> >>>
> >>
>

Re: Time for a new release? 3.1.2?

[Arvydas Silanskas]

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

I'd like to bump a question, would we want to add (for the time being
considering only red and tangerine) R7RS-large support? I'm fine with doing
necessary work as far as human resources go, but I want to know that this
is a direction that people agree with.

Shawn, thank you for sharing. Even if it doesn't make it to kawa core,
these libraries will be useful to have in personal projects.

2022-10-27, kt, 07:51 Shawn Wagner <shawnw.mobile@gmail.com> rašė:

> I've ported a lot of SRFIs to Kawa at
> https://gitlab.com/shawn_w/kawalib/-/tree/master though I'm not sure if
> any of them are included in Red or Tangerine.
>
> On Fri, Oct 21, 2022 at 2:02 AM Arvydas Silanskas via Kawa <
> kawa@sourceware.org> wrote:
>
>> The test suite had been fixed. But then one other thing popped into my
>> mind
>> -- how about the R7RS large red and tangerine support? The SRFIs required
>> seem to be very straightforward, not requiring any pervasive compiler
>> hacking but simply defining some simple libraries. I know R7RS large
>> colors
>> down the road will start including various non-portable / more invasive
>> requirements, but we can decide if we want to support those when we get
>> there.
>>
>> 2022-10-03, pr, 14:36 Arvydas Silanskas <nma.arvydas.silanskas@gmail.com>
>> rašė:
>>
>> > I propose to pause a bit; I remembered one thing that irked me quite a
>> > bit, and that is the failing test suite. I think it would be prudent to
>> fix
>> > it first before the release. As part of the hacktober festive theme,
>> I'll
>> > try to sit down and find time to make a pull request on the matter soon.
>> >
>> > Arvydas
>> >
>> > 2022-09-29, kt, 18:18 Arvydas Silanskas <
>> nma.arvydas.silanskas@gmail.com>
>> > rašė:
>> >
>> >> I can go over it on Sunday, if no one else does it by then.
>> >>
>> >> Arvydas
>> >>
>> >> 2022-09-29, kt, 07:38 Per Bothner <per@bothner.com> rašė:
>> >>
>> >>>
>> >>>
>> >>> On 9/28/22 10:53, Duncan Mak via Kawa wrote:
>> >>> > Hello Per,
>> >>> >
>> >>> > It's been over two years since the last release (3.1.1,
>> 2020-01-16), I
>> >>> > count 72 commits made to the master branch since then.
>> >>> >
>> >>> > Would it be a good time to make a 3.1.2 release soon?
>> >>>
>> >>> Might as well call it 3.2.
>> >>>
>> >>> It would be helpful if someone went through the changes
>> >>> (using 'git log' and **/ChangeLog) to summarize what has
>> >>> change in a format suitable for doc/news.texi.
>> >>>
>> >>> Also make a note of where the manual needs to be updated.
>> >>>
>> >>> Minor tweaks and bug fixes don't need to be mentioned.
>> >>>
>> >>> --
>> >>>         --Per Bothner
>> >>> per@bothner.com   http://per.bothner.com/
>> >>>
>> >>
>>
>

Re: Time for a new release? 3.1.2?

[Per Bothner]

On 12/6/22 01:07, Arvydas Silanskas wrote:
> I'd like to bump a question, would we want to add (for the time being considering only red and tangerine) R7RS-large support? I'm fine with doing necessary work as far as human resources go, but I want to know that this is a direction that people agree with.

I think the R7RS-large process is off-track, and is unlikely to reach any useful destination
without a fundamental course-correction. Piling on more and more different-but-similar
libraries is not the way to do a programming language in the 21st century.  Even Common Lisp
realized that different differently-named functions for every useful data-type is not
good language design.

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.

I am not the only one who feels this way, as you can see from the SRFI/R7RS mailing lists.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Time for a new release? 3.1.2?

[Damien Mattei]

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

Hello,
if the SRFI 105 (curly infix) is ported to Kawa i could easily release a
Scheme+ version for Kawa as i already did it for Guile and Racket:
https://github.com/damien-mattei/Scheme-PLUS-for-Guile
i have little understanding of the implementation of SRFI 105 but i succeed
in implementing it for Racket indeed:
https://github.com/damien-mattei/Scheme-PLUS-for-Racket
https://pkgd.racket-lang.org/pkgn/package/Scheme-PLUS-for-Racket

SRFI 105 and scheme+ could be interesting as language for Kawa

Damien


On Thu, Jan 5, 2023 at 10:34 PM Per Bothner <per@bothner.com> wrote:

>
>
> On 12/6/22 01:07, Arvydas Silanskas wrote:
> > I'd like to bump a question, would we want to add (for the time being
> considering only red and tangerine) R7RS-large support? I'm fine with doing
> necessary work as far as human resources go, but I want to know that this
> is a direction that people agree with.
>
> I think the R7RS-large process is off-track, and is unlikely to reach any
> useful destination
> without a fundamental course-correction. Piling on more and more
> different-but-similar
> libraries is not the way to do a programming language in the 21st
> century.  Even Common Lisp
> realized that different differently-named functions for every useful
> data-type is not
> good language design.
>
> 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.
>
> I am not the only one who feels this way, as you can see from the
> SRFI/R7RS mailing lists.
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/
>

Re: Time for a new release? 3.1.2?

[Lassi Kortela]

> I think the R7RS-large process is off-track, and is unlikely to reach 
> any useful destination
> without a fundamental course-correction. Piling on more and more 
> different-but-similar
> libraries is not the way to do a programming language in the 21st 
> century.  Even Common Lisp
> realized that different differently-named functions for every useful 
> data-type is not
> good language design.
> 
> 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.
> 
> I am not the only one who feels this way, as you can see from the 
> SRFI/R7RS mailing lists.

Thank you for saying this, Per. Agreed on all counts.

We just had another round of discussions on the SRFI lists. Like the 
earlier ones, it went nowhere. The core group cannot examine its own 
flaws. I'm leaving and starting alternatives.

Re: Time for a new release? 3.1.2?

[Sascha Ziemann]

> 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.
Any ideas?

Re: Time for a new release? 3.1.2?

[Lassi Kortela]

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

Re: Time for a new release? 3.1.2?

[Arvydas Silanskas]

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

Re: Time for a new release? 3.1.2?

[Lassi Kortela]

> 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

Modularity is the only way forward for RnRS.

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

The disagreements are about style as well as complexity.

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

Yes. R6RS also added fixnum procedures.

The existing specific procedures have to be kept for backward 
compatibility. Whether new ones should be added is another matter.