Re: Time for a new release? 3.1.2?

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?

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

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

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