On 05/12/2022 0:08, Lassi Kortela wrote:
> Thanks for the feedback, Wolf! Good to hear from another regular.
>
>> Weasel words, as the Wikipedians say.
>
> You're right. I chose my words poorly.
>
>> I don’t believe that this is a “general sentiment”.
>
> General sentiment by many. Not by all.
>
> Why do people keep saying I claim to represent a consensus of schemers?
> Scheme rarely has a consensus on anything.

I disagree strongly with this sentiment. Scheme has a consensus on
_most_ things, and the parts that were thrown through by a vote, against
the wishes of most implementations (eg, R6), did not end up being enduring.

>
>> I won’t try to be
>> a barometer of public opinion, but I will say that the opposition to
>> SRFI has been from a small but vocal minority.
>
> I haven't seen wholesale opposition to SRFI from any serious schemer.
> The opposition is "please don't stuff every idea into SRFI", not "the
> SRFI process has no good uses".
>
>> But what do you want from SRFI?
>
> Focus on relatively mature and proven proposals over new and
> experimental ones. The 90 day deadline implies SRFI should put the
> finishing touches on things, not be an incubator of new ideas.
>

It seems to me that some of this is perhaps due to a fundamental
misunderstanding of the genesis of SRFIs.

SRFI - Scheme Request For Implementation

This consists of two primary roles, in my understanding.

1) When there is an extant library or set of functionality in a given
implementation, that people find useful and that has been discussed, the
author can propose it more formally for other implementations to
implement, and expose it to review by the wider community. It seems to
me that many, if not most, of the early SRFIs were formed in this way,
and that at least some of the more recent ones came from this. These are
the ones that there is generally less discussion regarding and that tend
to be finalised fairly quickly.

2) During the pre-R6 days, SRFIs took on an additional role - that of
experiment on which the community as a whole debates. These are the ones
that tend to be extended repeatedly, and are often withdrawn or reformed.

Both geneses play an important part in the overall Scheme ecosystem. The
former gives a rich set of functionality that can be shared between
Schemes. The latter gives a public forum for discussion of new concepts.
Both fall under the rubric of 'Request For Implementation', either as a
proposal for wider use or as a question of whether something is worth
implementating.

This is a healthy means of discussion, implementation and
standardisation, all in one, and that not everything can be resolved
quickly - and not everything stands up to public review - is a mark of
the process working, and working usefully. In the general case, new
concepts are accepted quickly only if they're already in general use -
in which case the discussion may have already spanned years - or if
they're not really accepted at all - that is, there's no discussion,
debate etc regarding them and people can't be bothered to comment.

The only problem in the process of a whole is 'abandoned' SRFIs - ones
in which the author cannot be contacted, and so they hang on without
discussion, finalisation or withdrawl. Arthur, primarily, has done an
excellent job of trying to prevent this, with some changes to the
process over the last few years so that things don't get bogged down
infinitely.

I fundamentally disagree with your understanding of the 90 day deadline.

> Less importantly, focus on things that are difficult to implement in a
> portable and efficient way.
>

By definition, what you are proposing is contradictory. If it's
difficult to implement in a portable and efficient way (which is by
itself frequently contradictory), it will generate more discussion, and
is less likely to be finished in small time. It's also unlikely that the
proposal will be mature or portable before the discussion between
implementors.

> The main (but not only) point of Scheme Review is to try and pick up
> some of the rest (which is very good work, but IMHO not done in the
> right context) so that SRFI could get back to what it does best. A
> process with a broader scope and no deadlines is a better incubator.
>

Are you familiar with the concept of 'design paralysis'? A process with
broad scope and no deadlines will never finish anything. :)

> NB: Scheme Review is a "carrot, not stick" approach. I can't stop
> anybody from submitting SRFIs if they want to.
>
> I propose Scheme Review, and did the grunt work to get it started, for
> the same reason as all the other projects: because nobody else stepped
> up to the plate! My method is to do the work others won't do, and take
> the flak others won't take, to solve problems. I continually ask others
> to do share in this work but generally they don't, so it befalls on me.
> Then people say that I don't get things done, lol, apparently because I
> don't get ten people's work done by myself.
>

Perhaps the reason why people don't get involved is that there's no need
for the additional processes on top of the extant, working ones?
Developing/maintaining distributions is a huge amount of work.
Participating in the SRFI process is also a large amount of work (thank
you again, Arthur!). Adding more duplication of effort - parallel
processes with the same outcome - multiplies fragmentation and reduces
the amount of time to get useful things done.

>> You alternate between suggesting ways
>> of fixing supposed problems and hinting at SRFI’s impending doom in the
>> face of your alternatives. SRFI is not likely to commit suicide: the
>> problems are overstated, and there is no question that more work has
>> been done here than under the Scheme Live or Scheme Review banners.
>> If you want these projects to succeed, I suggest you collaborate with
>> SRFI instead of attacking it.
>
> I already "collaborate with" SRFI. I've written several of them, given
> copious feedback on many more, and just helped Arthur modernize the
> tooling. Over 100 commits to the srfi-common repo, started
> https://github.com/srfi-explorations, etc.
>
> None of the SRFI alternatives I propose are intended to replace its core
> function. Where did that idea come from?
>
> This debacle is a storm in a teacup from my point of view.
>
> I've made strong criticisms of R7RS-large, and I empathize very well
> with anyone who's upset about them. There can be only one RnRS, and if
> someone suggests something not to your liking, you should be upset.
>
> But I don't understand what's the fuss with the other projects. Nobody's
> closing down SRFI or hijacking it. Scheme.org is painstakingly designed
> to be as neutral as possible. Scheme Live or Scheme Review shouldn't be
> a threat to anybody, especially if vaporware.
>

Again, it's a question of necessity and allocation of resources. There
is no convincing case that such things are necessary, and there are
strong arguments that they are not.

> Some say "show me the code" as if Scheme's main problem is lacking code.
> The main problem is ideas, not code.
>

No. The main problem is how to implement ideas usefully _within the
context of the concept of the language_. The disagreements or
compromises regarding what this means - the concept of the language and
its future shape - form the basis of the dissatisfaction with R6 and
R7-large (at least in my opinion).

Scheme is interesting in that there's the idea of something being
'unschemey', and this is a valid form of criticism. One does not say
'this is un-C-ey' or 'un-pythony' (at least, not as far as I'm aware).
That the core language, whatever this means, remains 'schemey' and
relevant is a primary concern - not whether ideas are proposed quickly
or slowly.

> Or "nothing came from your proposal" as if I'm supposed to transform an
> entire language community by myself in a couple of years.
>
> Or "you haven't been here long enough". But people who have been here
> long enough disagree widely among themselves.
>
> I alternate between different proposals because over the long term they
> are equivalent. I'm a big picture guy; I want go in a general direction.
> E.g. instead of starting Scheme Review we could restructure SRFI to
> accommodate the same stuff, or start an even broader Lisp Review. What I
> want to do at this level of detail is whatever other people are willing
> to go along with. I pitch something that would work whenever there is an
> opening. If I can draw an arc from any of these alternatives to the same
> long-term outcome, it doesn't matter which one to start with.
>
> Another thing I don't understand is the split sentiment that one the one
> hand my ideas are useless and will probably go nowhere, and on the other
> hand they somehow seem to be a threat. Aren't those mutually exclusive?
>

No one is claiming that they're a threat in and of themselves, as far as
I'm aware. My argument, at least, is that they're a tax on the
community's time and effort that could be better spent elsewhere.

> Could they be threatening because there's something there? E.g. with
> "RnRS and SRFI are doomed to succeed" I meant that's where the
> evolutionary arc points. If you keep things on the current track you'll
> get that outcome entirely without my involvement. Not because these
> processes as planned are mistaken, but because they're being used in a
> way that follows the letter of the plan but not the spirit.

I have no idea to what you are referring with 'evolutionary arc points'.

Scheme exists. It will continue to exist, we all hope, and continue to
be useful and relevant in the family of languages as a whole. How to
keep its character - for it to still be Scheme, and not just another
functional language - is, in my opinion, at least one of the major
reasons why the processes are the way they are, why they have been
established this way. Deviations from this have resulted in serious
problems in the past, some of which are still causing issues today. We
are all hoping and trying to resolve these, but parallel processes are
not, imho, the right way to go about doing so.

-elf