Restructuring WG2

[John Cowan]

The current WG2 process has difficulties: in particular, it allows little to no parallelism, and imposes a single process structure on matters that could be structurally distinct.  I am therefore proposing to restructure the Working Group into a set of Committees as follows:

Committee F ("foundations"):  to work on what Daphne calls the "core language features", which I take to mean those which can't be portably implemented in Small + other core language features, with the exception of Committee E features.  These are Scheme-internal features: for example, syntax-case is a Committee F matter, because there is no analogue of it outside Scheme.

Committee B ("batteries"): features which can be portably implemented and are ones that mainstream application developers would expect to find in a standard (modulo the essential differences between Scheme and mainstream languages).

Committee E ("environment") works on interfaces with the process environment, including I/O.

Committee C ("cleanup/consistency"): has a mandate to make everything as consistent as practical.

All the work will be done in one of these Committees, although the number may grow.  Each Committee has a Chair who establishes the procedures used by that Committee.  The WG2 Chair will appoint Committee Chairs and can remove them, either on the Chair's own motion (e.g. the Committee Chair is out to lunch for a long period) or by appeal from the Committee members stating that they have lost confidence in their Chair.

I believe that this restructuring will provide sufficient flexibility without requiring a charter revision.

Comments?

[Arthur A. Gleckler]

On Sat, Mar 12, 2022 at 4:48 PM John Cowan <co...@ccil.org> wrote:

 

I believe that this restructuring will provide sufficient flexibility without requiring a charter revision.

Bravo.

[Amirouche Boubekki]

+1

--
Amirouche ~ https://hyper.dev

[Daphne Preston-Kendal]

Given that communication difficulties increase quadratically with the number of parties, and there were already concerns raised about how *two* groups working in parallel would communicate and cooperate effectively with each other, I’m unsure of the wisdom of making four groups out of two.

In particular, splitting the Large effort into batteries and environment seems fine (and an especially good idea if a particularly tricky feature such as a C FFI really might be back on the cards for the latter group, as you recently suggested). One could perhaps describe the two groups’ remits as being ‘embarrassingly parallel’. Splitting consistency from both Large and Medium seems like a bad plan, since one consistency committee will have to check up on the work of both of them. And consistency of the foundation is an important feature of the foundation in itself.

What I had envisaged was something like the following: the committee on ‘Medium’ (Foundation, or whatever we want to call it) works on its updates to the core of R7RS small, and is responsible for ensuring consistency in its own spec along the way. What it produces we could call ‘R7RS Large Volume I: Foundation Language’. In parallel, work continues on portable libraries, largely by adopting SRFIs as-written. When all or almost all libraries are ready, the Libraries committee cleans up the inconsistencies and idiosyncracies of the individual SRFIs. That turns into ‘R7RS Large Volume II: Standard Libraries’.

As I say, if the Libraries committee wants to become Batteries and Environment, fine; but I think each committee should be independently responsible for the consistency of its own results, rather than having an external consistency police.


Daphne

> --
> You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/CAD2gp_R2rXHV%3DybZgG%2BtPH6kDyNmth6d6K_8ePG%2BN%3Dmr8Rrw-Q%40mail.gmail.com.

[Marc Nieper-Wißkirchen]

I appreciate that John has suggested a new way to move forward. I
share the fears that Daphne has just raised, though.

But maybe R7RS Large is large enough so that the committees can work
rather independently, each producing something consistent in itself.
For example, say, Committee "B" includes (srfi 1) unchanged as (scheme
list). Now committee "F" may independently think that some pair/list
procedures are so fundamental (e.g. to implement other parts of the
foundations) that they would also want to include a list library. But
they may want a more axiomatic version of SRFI 1, ending up with a
specification of a library (foundation list). (Note: I don't recommend
"foundation" here; it is just a placeholder.) R7RS Large will then
ship with both (scheme list) and (foundation list) and Commitee "B"
can use (foundation list) to implement their larger (scheme list). (Of
course, to make source code understandable, Commitee "F" shouldn't
define a procedure "fold" that is fundamentally different to "fold" in
SRFI 1 using the same name.)

Am So., 13. März 2022 um 09:42 Uhr schrieb Daphne Preston-Kendal
<d...@nonceword.org>:

> To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/05F50265-0E2B-478C-935C-083EC5DE4AF7%40nonceword.org.

[Lassi Kortela]

Thanks for the continued efforts at dealmaking. I'm happy with the idea
that subcommittees can self-organize informally.

> Committee F ("foundations"):  to work on what Daphne calls the "core
> language features", which I take to mean those which can't be portably
> implemented in Small + other core language features, with the exception
> of Committee E features.  These are Scheme-internal features: for
> example, syntax-case is a Committee F matter, because there is no
> analogue of it outside Scheme.

This has the potential to take off if you can get someone from at least
one big R6 implementation and one big R7 implementation on board (the
holdouts of each standard, that is -- the joint R6+R7 implementers ought
to be easier to convince).

Could this work be carved out as a separate Medium document (name's not
that important) when it completes?

> Committee E ("environment") works on interfaces with the process
> environment, including I/O.

Can this be done outside the remit of Foundations?

[Lassi Kortela]

I too appreciate the continued dialogue.

But as you work out the scenarios, you keep running into the problems
I've been trying to warn about. And to solve them, you keep getting
closer to the solutions I suggested to begin with. You won't adopt those
solutions wholesale, which causes predictable problems, to which you
keep coming up with complicated workarounds. As you resolve the problems
with the workarounds, you get even closer to what I suggest.

> But maybe R7RS Large is large enough so that the committees can work
> rather independently, each producing something consistent in itself.

That will only work if we have a clear split between Medium and Large
(from the start, not at the end).

> For example, say, Committee "B" includes (srfi 1) unchanged as (scheme
> list). Now committee "F" may independently think that some pair/list
> procedures are so fundamental (e.g. to implement other parts of the
> foundations) that they would also want to include a list library. But
> they may want a more axiomatic version of SRFI 1, ending up with a
> specification of a library (foundation list). (Note: I don't recommend
> "foundation" here; it is just a placeholder.) R7RS Large will then
> ship with both (scheme list) and (foundation list) and Commitee "B"
> can use (foundation list) to implement their larger (scheme list). (Of
> course, to make source code understandable, Commitee "F" shouldn't
> define a procedure "fold" that is fundamentally different to "fold" in
> SRFI 1 using the same name.)

This makes total sense, _but_ requires the split between Medium and Large.

The inevitable problems with Large would be solved by going with Medium
+ something like Scheme Live, but I'm happy if you make Medium the main
standard and make Large an optional add-on for Medium.

>> Given that communication difficulties increase quadratically with the number of parties, and there were already concerns raised about how*two* groups working in parallel would communicate and cooperate effectively with each other, I’m unsure of the wisdom of making four groups out of two.

That's why I suggested the informal fork rather than another WG --
bureaucracy doesn't scale, and isn't necessary with this few people.

It's all about Scheme implementers. Whatever they like will be ratified
by the SC. Whatever they don't like is irrelevant either way.

>> In particular, splitting the Large effort into batteries and environment seems fine (and an especially good idea if a particularly tricky feature such as a C FFI really might be back on the cards for the latter group, as you recently suggested).

FFI / threads / networking will delay the standard by 2 more years, and
you'll probably ship a less compatible standard.

SRFI is the right place to work out the difficult environmental stuff.

SRFI 18 is proven, but does it work fine on JVM and CLR? Are there major
implementers who don't like it?

>> One could perhaps describe the two groups’ remits as being ‘embarrassingly parallel’.

To the extent that the Large libraries group does things right, its work
is orthogonal to the Medium group and most likely moves at a different
pace. Which raises the question of why the libraries group's work is
tied to a given RnRS number at all.

>> Splitting consistency from both Large and Medium seems like a bad plan, since one consistency committee will have to check up on the work of both of them. And consistency of the foundation is an important feature of the foundation in itself.

There's no way for something as large as Large to be consistent
aesthetically and ship on time.

Consistency in Medium is a good goal. Consistency within the Large
libraries is doable if you don't mind taking a long time.

Medium has failed at its main job if it takes a long time; it means
you're doing something too hard. 2-3 years is reasonable for it.

>> What I had envisaged was something like the following: the committee on ‘Medium’ (Foundation, or whatever we want to call it) works on its updates to the core of R7RS small, and is responsible for ensuring consistency in its own spec along the way. What it produces we could call ‘R7RS Large Volume I: Foundation Language’. In parallel, work continues on portable libraries, largely by adopting SRFIs as-written. When all or almost all libraries are ready, the Libraries committee cleans up the inconsistencies and idiosyncracies of the individual SRFIs. That turns into ‘R7RS Large Volume II: Standard Libraries’.

The amount of red tape is getting to the point where the names of the
documents themselves (Foundation Libraries, Volume I, etc.) should tell
you the work is not organized right.

The natural name of Foundation Libraries or Volume I is simply RnRS.
That's the main work. Large Libraries is unexplored territory, and
Environment is difficult-to-implement stuff that implementers can be
expected to disagree about.

[Daphne Preston-Kendal]

On 13 Mar 2022, at 11:33, Lassi Kortela <la...@lassi.io> wrote:

>> But maybe R7RS Large is large enough so that the committees can work
>> rather independently, each producing something consistent in itself.
>
> That will only work if we have a clear split between Medium and Large (from the start, not at the end).

That seems to be the consensus for what will actually happen.

> The inevitable problems with Large would be solved by going with Medium + something like Scheme Live, but I'm happy if you make Medium the main standard and make Large an optional add-on for Medium.

That is basically what will happen, I think. (Since you’re okay with this, I especially don’t understand your objection below to ‘Volume I’/‘Volume II’ nomenclature?)

>>> Given that communication difficulties increase quadratically with the number of parties, and there were already concerns raised about how*two* groups working in parallel would communicate and cooperate effectively with each other, I’m unsure of the wisdom of making four groups out of two.
>
> That's why I suggested the informal fork rather than another WG -- bureaucracy doesn't scale, and isn't necessary with this few people.

So any structure involving bureaucracy (which, as far as I can tell, you define as anything involving more than one person making the final decisions) is bad when the committee is big (because it ‘doesn’t scale’) *and* when the committee is small (because it ‘isn’t necessary’)?

We don’t want a benevolent dictator. As has been pointed out, such a concept doesn’t make sense in the context of a language with many implementations such as Scheme. Indeed, you even point out that the implementers are the ultimate arbiters. Even if we as a committee consisted entirely of implementers, we would still need a ‘bureaucracy’ to work out how we all agree.

>>> One could perhaps describe the two groups’ remits as being ‘embarrassingly parallel’.
>
> To the extent that the Large libraries group does things right, its work is orthogonal to the Medium group and most likely moves at a different pace. Which raises the question of why the libraries group's work is tied to a given RnRS number at all.
>

> [snip]

>
>>> What I had envisaged was something like the following: the committee on ‘Medium’ (Foundation, or whatever we want to call it) works on its updates to the core of R7RS small, and is responsible for ensuring consistency in its own spec along the way. What it produces we could call ‘R7RS Large Volume I: Foundation Language’. In parallel, work continues on portable libraries, largely by adopting SRFIs as-written. When all or almost all libraries are ready, the Libraries committee cleans up the inconsistencies and idiosyncracies of the individual SRFIs. That turns into ‘R7RS Large Volume II: Standard Libraries’.
>
> The amount of red tape is getting to the point where the names of the documents themselves (Foundation Libraries, Volume I, etc.) should tell you the work is not organized right.
>
> The natural name of Foundation Libraries or Volume I is simply RnRS. That's the main work. Large Libraries is unexplored territory, and Environment is difficult-to-implement stuff that implementers can be expected to disagree about.

R6RS has more-or-less the same split, albeit less well-executed. (As critics of the R5.97RS draft pointed out, one would expect the standard libraries to purely build on top of the base established by the main document, but in R6RS, the standard libraries document contains features and requirements, like syntax-case and set-car!, which actually imply changes to, or at least very restrictions on the ways you can implement, the semantics of the core language.)

In any case, there is a clear expressed desire from some people, such as Arthur and Amirouche, for an RnRS language with a rich standard library. They are willing to work to get their wish. Why are you trying to deny them what they want?


Daphne

[Daphne Preston-Kendal]

On 13 Mar 2022, at 11:45, Daphne Preston-Kendal <d...@nonceword.org> wrote:

> In any case, there is a clear expressed desire from some people, such as Arthur and Amirouche

I have received a private message from Amirouche suggesting that this was not the intention of his messages.

I apologize for the misrepresentation of his view, but I hope my point stands with regard to other WG2 members (including Arthur, and indeed me).


Daphne

[Amirouche Boubekki]

On Sun, Mar 13, 2022 at 12:01 PM Daphne Preston-Kendal
<d...@nonceword.org> wrote:
>
> On 13 Mar 2022, at 11:45, Daphne Preston-Kendal <d...@nonceword.org> wrote:
>
> > In any case, there is a clear expressed desire from some people, such as Arthur and Amirouche
>
> I have received a private message from Amirouche suggesting that this was not the intention of his messages.
>

My private message is unrelated to this conversation. I like the idea
of a RnRS language with a rich standard library.

[Lassi Kortela]

>> That will only work if we have a clear split between Medium and Large (from the start, not at the end).
> That seems to be the consensus for what will actually happen.

>> The inevitable problems with Large would be solved by going with Medium + something like Scheme Live, but I'm happy if you make Medium the main standard and make Large an optional add-on for Medium.
> That is basically what will happen, I think.

John's proposal gave me the impression that the Cleanup committee will
merge the other committees' work at the end. This implies Medium /
Foundation can't ship before Large since the libraries and environment
groups can find a late-stage need for breaking changes to Foundation.

> (Since you’re okay with this, I especially don’t understand your objection below to ‘Volume I’/‘Volume II’ nomenclature?)

They're not volumes of the same nature. I is core, II is something that
(if done right) is largely independent of a particular core version.

> So any structure involving bureaucracy (which, as far as I can tell, you define as anything involving more than one person making the final decisions) is bad when the committee is big (because it ‘doesn’t scale’)*and* when the committee is small (because it ‘isn’t necessary’)?

Bureaucracy works to the extent that work is routine.

> We don’t want a benevolent dictator. As has been pointed out, such a concept doesn’t make sense in the context of a language with many implementations such as Scheme. Indeed, you even point out that the implementers are the ultimate arbiters. Even if we as a committee consisted entirely of implementers, we would still need a ‘bureaucracy’ to work out how we all agree.

People took the "dictator" thing too literally. Think of "moderator" or
"diplomat" or "tie breaker" if that's better. People solve problems by
talking all the time. That works via personality. You get the right mix
of personalities and the outcome is good.

When you replace personalities with impersonal rules, that mainly works
for routine stuff. I find little in RnRS (Large or Medium) that is
routine. Most RnRS work falls under design; design is novel and complex.

>> That's the main work. Large Libraries is unexplored territory, and Environment is difficult-to-implement stuff that implementers can be expected to disagree about.

> R6RS has more-or-less the same split, albeit less well-executed. (As critics of the R5.97RS draft pointed out, one would expect the standard libraries to purely build on top of the base established by the main document, but in R6RS, the standard libraries document contains features and requirements, like syntax-case and set-car!, which actually imply changes to, or at least very restrictions on the ways you can implement, the semantics of the core language.)

John's delineation of the Foundation committee seems reasonable:
intricate stuff like syntax-case would go there. The proposed "Medium"
document would be basically this stuff, and would only slightly exceed
the scope of R6RS. (Maybe it should in some way be split into
sub-documents like R6 was, hopefully making dependencies between parts
easier to understand.)

I'd be surprised if the Environment group's work doesn't change the
Foundation language, though.

> In any case, there is a clear expressed desire from some people, such as Arthur and Amirouche, for an RnRS language with a rich standard library. They are willing to work to get their wish. Why are you trying to deny them what they want?

I consider a clean Medium + Large split to be an adequate compromise.

[Daphne Preston-Kendal]

On 13 Mar 2022, at 12:20, Lassi Kortela <la...@lassi.io> wrote:

> John's proposal gave me the impression that the Cleanup committee will merge the other committees' work at the end.

I, too, am awaiting clarification from John on how the Cleanup committee would work in practice. (Though I would find your interpretation, which you object to, better than mine, that the Cleanup committee works in parallel to the other three, changing their work while they do it.)

> When you replace personalities with impersonal rules, that mainly works for routine stuff. I find little in RnRS (Large or Medium) that is routine. Most RnRS work falls under design; design is novel and complex.

It worked for the R6RS, for the R7RS WG1, and (in a different form) for all RnRS where 2 ≤ n < 6.

> I'd be surprised if the Environment group's work doesn't change the Foundation language, though.

I don’t see why it should particularly. Can you elaborate?


Daphne

[Amirouche Boubekki]

Committee F (foundation) is new to me such as described in the chair
message [0].

I used to think committee C (cleanup/consistency) was the ultra-violet docket.

[0] https://groups.google.com/g/scheme-reports-wg2/c/RUEfZf_d3Nk

I still agree with Daphne [1] that we should have a central place
where to gather the work on R7RS to make it easier to track the work
of everybody.

[1] first point in the conclusion at
https://groups.google.com/g/scheme-reports-wg2/c/j5J7KTFa9vg

The idea I have is :

1) Re-use the current r7rs.org repository, and request that every
person involved register their fork in it, and possibly do pull
requests on github, or by email, or on this mailing list. So that we
keep the decentralized / distributed approach that we like, while
still being able to keep up with the changes, thanks to that gathering
point.

2) We redirect the existing github organization to r7rs.org, and archive them.

3) Start a draft of what the R7RS-large report will look like, on that
topic, I find the following paper interesting:
https://www.ics.uci.edu/~taylor/classes/121/IEEE86_Parnas_Clement.pdf

We work toward reconciliation, still I want to underline the fact that
my so-called "hostility" is toward closing the WG2 process "democracy
failed, let's bring back oligarchy" . That was my understanding of
some parts of the petition as it was stated two weeks ago. Regarding
scheme-live, on my side I do not consider scheme-live as a fork of
R7RS, to the contrary I think of it as a place where to gather
experimental libraries, to help make sure it is doable, portable, and
an antechamber toward SRFI, and possibly eventually R7RS.

[Marc Nieper-Wißkirchen]

Am So., 13. März 2022 um 12:58 Uhr schrieb Amirouche Boubekki
<amirouche...@gmail.com>:

> We work toward reconciliation, still I want to underline the fact that
> my so-called "hostility" is toward closing the WG2 process "democracy
> failed, let's bring back oligarchy" . That was my understanding of

> some parts of the petition as it was stated two weeks ago. [...]

Maybe we can agree that it is problematic to apply terms like
"democracy" or "oligarchy" in the first place to a process such as
R7RS is.

[John Cowan]

On Sun, Mar 13, 2022 at 4:42 AM Daphne Preston-Kendal <d...@nonceword.org> wrote:

In particular, splitting the Large effort into batteries and environment seems fine

I note that you implicitly assume that environment stuff can't possibly be part of the foundation.  Such an assumption (and the equal and opposite assumption that it can't possibly be part of the batteries) will both lead to neglect unless the environment has its own partisans.  Per contra, imperialist versions of F and B might battle over who gets to define the environment stuff; having E firmly committed should help prevent that (though I think it is inherently less likely).   I tried to word the remits so as to delineate clearly the F/B/E lines.

(and an especially good idea if a particularly tricky feature such as a C FFI really might be back on the cards for the latter group, as you recently suggested).

An FFI always involves glue, and it is a fundamental decision whether to have ugly Lisp glue or ugly Blub (any non-Lisp language) glue.  I don't think legislating this into a standard is a Good Thing.  Indeed, I don't know of any language with an actual standard that actually standardizes an FFI.  (PL/I and Ada are exceptions, but their data and control models are basically still Blub, so interfacing with Fortran and Cobol was easy to standardize.

One could perhaps describe the two groups’ remits as being ‘embarrassingly parallel’. Splitting consistency from both Large and Medium seems like a bad plan, since one consistency committee will have to check up on the work of both of them.

That's precisely why I proposed it.  The CL standard is a far superior product to what it would have been if it didn't have a cleanup committee whose remit was the consistency of the whole language.  It goes without saying (but goes even better when said!) that each committee should do its best to make its own output self-consistent, but that is not enough, for two reasons: consistency between committees is vitally important, and nobody should copy-edit their own work, as they will overlook obvious bloopers.  CL's cleanup committee ran after, rather than in parallel, with the main effort, but Committee C has plenty to do already.

And consistency of the foundation is an important feature of the foundation in itself. 

What I had envisaged was something like the following: the committee on ‘Medium’ (Foundation, or whatever we want to call it) works on its updates to the core of R7RS small, and is responsible for ensuring consistency in its own spec along the way. What it produces we could call ‘R7RS Large Volume I: Foundation Language’. In parallel, work continues on portable libraries, largely by adopting SRFIs as-written. When all or almost all libraries are ready, the Libraries committee cleans up the inconsistencies and idiosyncracies of the individual SRFIs. That turns into ‘R7RS Large Volume II: Standard Libraries’.

A foundation that doesn't hold up its superstructure isn't very useful; it's important that F takes feedback from B, both directly and mediated through C, very seriously indeed.  That is yet another reason why operating in secret, as Arne suggested, is such a bad idea: R6RS would have been much better (and much less of a shock) if it had not done so.

[Marc Nieper-Wißkirchen]

Am So., 13. März 2022 um 15:05 Uhr schrieb John Cowan <co...@ccil.org>:
>
>
>
> On Sun, Mar 13, 2022 at 4:42 AM Daphne Preston-Kendal <d...@nonceword.org> wrote:
>
>> In particular, splitting the Large effort into batteries and environment seems fine
>
>
> I note that you implicitly assume that environment stuff can't possibly be part of the foundation. Such an assumption (and the equal and opposite assumption that it can't possibly be part of the batteries) will both lead to neglect unless the environment has its own partisans. Per contra, imperialist versions of F and B might battle over who gets to define the environment stuff; having E firmly committed should help prevent that (though I think it is inherently less likely). I tried to word the remits so as to delineate clearly the F/B/E lines.

F will include R7RS-small so will include basic environment
procedures. Even if it wants to add two or three to top it off and to
make F a practicable usable language by itself (which I think is
important), I don't think it would clash with E or B or L (= the whole
project). See my example about (foundation list) and (scheme list) in
my post earlier today.

>> (and an especially good idea if a particularly tricky feature such as a C FFI really might be back on the cards for the latter group, as you recently suggested).
>
>
> An FFI always involves glue, and it is a fundamental decision whether to have ugly Lisp glue or ugly Blub (any non-Lisp language) glue. I don't think legislating this into a standard is a Good Thing. Indeed, I don't know of any language with an actual standard that actually standardizes an FFI. (PL/I and Ada are exceptions, but their data and control models are basically still Blub, so interfacing with Fortran and Cobol was easy to standardize.

One could argue that C has a standardized FFI (which exists because it
is a trivial layer on top of C). Through its extern "C" declarations,
C++ also has an FFI. Anyway, this remark was neither helpful nor
important.

For Scheme, I could imagine a basic FFI for systems that operate in a
hosted environment. It would have to be rather conservative, though,
and would not be the most efficient one for any given Scheme system.
But it could be enough to just call C code from a dynamically linked C
library.

>
>> One could perhaps describe the two groups’ remits as being ‘embarrassingly parallel’. Splitting consistency from both Large and Medium seems like a bad plan, since one consistency committee will have to check up on the work of both of them.
>
>
> That's precisely why I proposed it. The CL standard is a far superior product to what it would have been if it didn't have a cleanup committee whose remit was the consistency of the whole language. It goes without saying (but goes even better when said!) that each committee should do its best to make its own output self-consistent, but that is not enough, for two reasons: consistency between committees is vitally important, and nobody should copy-edit their own work, as they will overlook obvious bloopers. CL's cleanup committee ran after, rather than in parallel, with the main effort, but Committee C has plenty to do already.
>>
>> And consistency of the foundation is an important feature of the foundation in itself.
>>
>> What I had envisaged was something like the following: the committee on ‘Medium’ (Foundation, or whatever we want to call it) works on its updates to the core of R7RS small, and is responsible for ensuring consistency in its own spec along the way. What it produces we could call ‘R7RS Large Volume I: Foundation Language’. In parallel, work continues on portable libraries, largely by adopting SRFIs as-written. When all or almost all libraries are ready, the Libraries committee cleans up the inconsistencies and idiosyncracies of the individual SRFIs. That turns into ‘R7RS Large Volume II: Standard Libraries’.
>
>
> A foundation that doesn't hold up its superstructure isn't very useful; it's important that F takes feedback from B, both directly and mediated through C, very seriously indeed. That is yet another reason why operating in secret, as Arne suggested, is such a bad idea: R6RS would have been much better (and much less of a shock) if it had not done so.

I don't think that Arne necessarily meant operating in secret. In any
case, I agree. If B says that to implement BLA, they need the FOO
syntactic extension, say, F has to find a way to incorporate FOO or
has to come up with some other way to implement BLA. Vice versa, if B
adds QUUX to one of its libraries but such would clash with basic
principles by which F is shaped and developed, F has to warn B and
propose an alternative, etc.

[Dr. Arne Babenhauserheide]

Lassi Kortela <la...@lassi.io> writes:

>>> One could perhaps describe the two groups’ remits as being ‘embarrassingly parallel’.
>
> To the extent that the Large libraries group does things right, its
> work is orthogonal to the Medium group and most likely moves at a
> different pace. Which raises the question of why the libraries group's
> work is tied to a given RnRS number at all.

The libraries are not just API definitions, but also working code that
Implementers can drop-in when they support R7RS-small/-medium.

On a future version that code might not be optimal anymore. Its API
might not actually be a good match for an R8RS, if that provides new
capabilities which enable more elegant libraries.

Making this independent of an RnRS-Version would give up the chance to
provide consistency with R7RS without actually giving an advantage for
R7RS.

And it would not be able to reflect the split between R7RS-small and
R7RS-medium in the batteries, because that split is very likely to shift
in later RnRS-Versions.

So tieing this to an RnRS number enables higher consistency and
uniformity with the other parts of the standard.

Once a new version is started, it will be easy to use the R7RS batteries
as base and adapt them for the new version.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[Lassi Kortela]

> The libraries are not just API definitions, but also working code that
> Implementers can drop-in when they support R7RS-small/-medium.
>
> On a future version that code might not be optimal anymore. Its API
> might not actually be a good match for an R8RS, if that provides new
> capabilities which enable more elegant libraries.
>
> Making this independent of an RnRS-Version would give up the chance to
> provide consistency with R7RS without actually giving an advantage for
> R7RS.
>
> And it would not be able to reflect the split between R7RS-small and
> R7RS-medium in the batteries, because that split is very likely to shift
> in later RnRS-Versions.
>
> So tieing this to an RnRS number enables higher consistency and
> uniformity with the other parts of the standard.
>
> Once a new version is started, it will be easy to use the R7RS batteries
> as base and adapt them for the new version.

Unfortunately, these are excellent arguments against big libraries in
RnRS. RnRS ideally provides the bedrock that doesn't change. Once this
bedrock is big enough, change is inevitable (as you note).

[John Cowan]

On Sun, Mar 13, 2022 at 10:29 AM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

But it could be enough to just call C code from a dynamically linked C
library.

In order to talk to C, you need ways to handle C structs and unions and (much more complex) C defines and macros.  And then you are waist-deep in the Big Muddy.

 

[Dr. Arne Babenhauserheide]

Lassi Kortela <la...@lassi.io> writes:

> Unfortunately, these are excellent arguments against big libraries in
> RnRS. RnRS ideally provides the bedrock that doesn't change. Once this
> bedrock is big enough, change is inevitable (as you note).

Change between versions and change in implementations is inevitable.

If R7RS-large provides a strong and self-consistent standard to build
upon, then additions by implementations as well as SRFIs can extend
these libraries.

And when a time for R8RS comes, these incremental changes can be
harmonized and then baked into a new shared standard.

But if the standard is forever changing without larger checkpoints, then
no implementation can aim for lasting compatibility — and that way no
program can be known to be portable.

R7RS is one such checkpoint.

[Marc Nieper-Wißkirchen]

Not necessarily, John, when we are talking about a minimal FFI that
will at least enable us to implement some yet unportable SRFIs
portably even if not as maximal efficient as possible. The point is
that a minimal FFI only needs to be able to talk to some minimal
subset on the C side (which would also be standardized). To access
arbitrary C code, some glue (in the form of a shared object) probably
has to be written, but this is again portable (C code)!

[Dr. Arne Babenhauserheide]

Marc Nieper-Wißkirchen <marc....@gmail.com> writes:
> I don't think that Arne necessarily meant operating in secret.

I didn’t mean operating in secret, and I like the proposed structure.

[Marc Nieper-Wißkirchen]

Am So., 13. März 2022 um 18:25 Uhr schrieb Marc Nieper-Wißkirchen
<marc....@gmail.com>:

PS It's probably a good idea to move FFI discussions to another
thread. I would hope for a discussion where we start with spamming
ideas on how to make such a thing possible without ruling it out
beforehand. That discussion may lead to the conclusion that even a
minimal FFI won't be possible for F (or E), but it may also lead to
something that we think should be standardized.

[Martin Rodgers]

On 13/03/2022, John Cowan <co...@ccil.org> wrote:

> An FFI always involves glue, and it is a fundamental decision whether to
> have ugly Lisp glue or ugly Blub (any non-Lisp language) glue. I don't
> think legislating this into a standard is a Good Thing.

Agreed.

> Indeed, I don't
> know of any language with an actual standard that actually standardizes an
> FFI. (PL/I and Ada are exceptions, but their data and control models are
> basically still Blub, so interfacing with Fortran and Cobol was easy to
> standardize.

FWIW, Haskell 2010 talks about an FFI. I don't think this invalidates
your general point here, but (as I like to say) its an existance
proof. Apologies to any mathematicians reading this. ;)

https://www.haskell.org/onlinereport/haskell2010/haskellch8.html#x15-1490008

Apart from the first lines of Section 8.1, I suspect the spec may be
too specific to Haskell to be useful to WG2. How many Haskell
compilers are there? The number used to be greater than one, but
today?

Rather than refuting it, I think this supports your point.

[Linas Vepstas]

On Sun, Mar 13, 2022 at 3:42 AM Daphne Preston-Kendal <d...@nonceword.org> wrote:

Given that communication difficulties increase quadratically with the number of parties, and there were already concerns raised about how *two* groups working in parallel would communicate and cooperate effectively with each other, I’m unsure of the wisdom of making four groups out of two.

 If someone is interested only in F or in B or E or C, then they have a much smaller group to communicate with -- on average its (N/4)^2  communications instead of N^2  -- presumably, most people will not want to be active in most groups.

If you personally want to participate in all four groups, then .. well your workload is the same as before the split. But for others it would be less.

--linas

[Marc Nieper-Wißkirchen]

Am Mo., 14. März 2022 um 04:20 Uhr schrieb Linas Vepstas
<linasv...@gmail.com>:

Smaller groups also have the advantage that people will know each
other better. With the whole of WG2, it is that names show up, others
become silent, new names show up, etc, so at least for me it is not
really clear who is active on WG2 and whether we really form a typical
body that can represent the whole Scheme community and whether our
interests are shared by those outside WG2 or whether we are a good mix
to actually speaking for them.