A Sane Proposal, or Why It's A Good Idea To Stop And Think

[elf]

Hi all.

Has anyone realised yet that the whole bent of the R7-large, R7-medium,
etc etc etc is not going to do what its supposed aims are?

The goal of these projects is to create some kind of standard library to
allow interoperability.

It won't work.

All this will do is increase the size of the base with which people are
working. As soon as someone wants to do something interesting outside of
this, they will still (likely) be building on implementation-specific
constructs.

Further, the cost of this is locking the language as a whole into
today's thoughts for libraries.

I consider this to be a massive mistake, not to mention entirely
un-schemey (and unseemly, given the current level of discourse).

I propose the following means of solving the actual problem motivating
all of these projects, in order:

1) A very clean means of defining modules/libraries, including
dependencies, interactions, download location, update characteristics, etc.

2) A centralised CPAN/CTAN/hex/whatever node.js is using today/pip type
repository. This will enable modules to actually work interoperably
everywhere, given 1), and will lead the implementations to
adopt/modularise any implementation-specific features

3) Networking - the implementations will need something working, and if
this is unified, it makes the above easier, but it can actually be put
off until the earlier ones are complete, as most implementations already
have some kind of network system in place. The biggest question with
this is whether network sockets are ports, and if so, how to modify the
ports abstraction to handle two-way controlled IO with OOB data.

4) FFI - this can REALLY be put off, but just as a note, this should be
in the form of per-language interfaces, that is, c->scheme, scheme->c,
c++->scheme, scheme->c++, scheme->java, java->scheme, etc. Trying to
unify this into a single massive FFI is doomed to conceptual and actual
failure.

I submit that we should start with R5RS, the last universally agreed
upon standard, layer on libraries and networking, with reference to a
centralised library repo, and go from there. I further submit that the
cost of trying to maintain perfect compatilibity with R7 and
(especially) R6 is far lower than the cost of rewriting the code to fit
a new system.

The role of the SRFI process in this cannot be underestimated, both as a
means of discussing the above interfaces, and for creating standard
libraries to be added to the repo. That said, obviously not everything
in the repo will be an SRFI, nor is it necessary to do so - but there
are certain types of more standardised functionality or (more
importantly) base-level language modifications that can only be solved
by the excellent work done through the SRFIs.


The floor is now open to flames and rebuttals. Thank you. :)

-elf

PS - As a further note, the level of discourse between people who have
not actually written implementations, are not responsible for
implementations, have very little skin in the game in terms of
production level code or SRFIs, etc should perhaps be a little less ...
rigid towards those with decades of experience working in and with
Scheme at all levels. I am not singling out any names, but the whole
reason I am proposing this before writing it up as SRFIs myself is to
try to cut the gordian knot that has been created recently in the
discourse, with threats backed up by nothing and general unpleasantness.

[elf]

I forgot to add namespace separation as part of 1), apologies.

[Martin Rodgers]

On 13/03/2022, elf <e...@ephemeral.net> wrote:

> Has anyone realised yet that the whole bent of the R7-large, R7-medium,
> etc etc etc is not going to do what its supposed aims are?
>
> The goal of these projects is to create some kind of standard library to
> allow interoperability.
>
> It won't work.

Maybe that's why John made his proposal. A small, self-consistant set
of libraries that use only R7RS Small will avoid all problems. So I
would say many SRFIs won't work because they depend on many features
not in Small. Some of them are not consistant with each other.

> All this will do is increase the size of the base with which people are
> working. As soon as someone wants to do something interesting outside of
> this, they will still (likely) be building on implementation-specific
> constructs.

Your definition of "interesting" may be the problem. I prefer *useful*
as the primary criterion. It has no such problem. Useful libraries
written in R7RS Small. Build a set of libraries consistant with each
other. That could be the "Foundation" set. Then build another set
upon that and Small.

For years I felt that was how WG2 should be doing R7RS Large. So I can
sympathise with many of the arguments and points made recently.
However, as I've begun using the Large libraries, and also importantly
*integrating* those libraries into one modestly consistant set based
on the reference implementations for the corresponding SRFIs, I've
found various self-consistancy issues.

I'm using a (scheme small) library to import and re-export
*everything* in the Small library set. No conflicts. While my (scheme
large) library reveals many conflicts. I resolved all of them by
modifying the the implementation code. E.g. ensuring that (scheme
hash-table) and (scheme comparator) use the same two string hashing
procedures. This is a trivial change and AFAICT breaks nothing.

So I doubt that any path forward that ignores self-consistancy at this
basic level - can you import sets of the libraries without getting
conficting definitions? - *then* you will at least have some cleanup
issues.

John's proposal to restructure WG2 includes a cleanup sub-committee,
which I support. WG2 will need something like that or else, as you
suggest,
neither Medium nor Large "will work" i.e. integrate without serious conflicts.

> Further, the cost of this is locking the language as a whole into
> today's thoughts for libraries.

I believe its way too early to talk about locking anything, except the
Small set. Changes there will risk breaking existing code. See John's
point about closed-source code. We may not see that code - its not
available to us - but it still exists. An absence of evidence is not
proof of absence. Small has been published, implementated. There's
plenty of proof of *that*. We should assume that some programmers are
using even if they don't speak up here.

BTW, I'm one of those users. I *am* speaking up. Please don't break my
code. Please don't break the code of others who are not (yet) speaking
up. They'll be real unhappy if and when they discover WG2 didn't
consider the value of their code. It won't necessarily mean they'll
abandon R7RS or their codebase. It may already be far too late to do
that.

I recently mentioned the issues in the C world in another post. There
are some unhappy C programmers out there. They seem to feel betrayed,
but I can't speak for them. I can only observe that they exist and C11
is a problem for them.

> I consider this to be a massive mistake, not to mention entirely
> un-schemey (and unseemly, given the current level of discourse).

I consider creating a schism to be a massive mistake. Please beware.
The Scheme community really doesn't need that.

> I propose the following means of solving the actual problem motivating
> all of these projects, in order:
>
> 1) A very clean means of defining modules/libraries, including
> dependencies, interactions, download location, update characteristics, etc.

We already have most, if not all, of that. Not everyone in the Scheme
community accepts such things. Not everyone in any language community
seems to accept such things. However, I can see some degree of success
in this area in the Haskell community, so I believe that attempting
your proposal has some merit.

> 2) A centralised CPAN/CTAN/hex/whatever node.js is using today/pip type
> repository. This will enable modules to actually work interoperably
> everywhere, given 1), and will lead the implementations to
> adopt/modularise any implementation-specific features

It *may* do that. It could be argued that the SRFI repo already does
this, but I noted above, there are some unfortunate inconsistancies.
So while I believe your second proposal has some merit, I must ask:
what's different now? If this hasn't this already been done, how will
happend - and succeed - in the future?

Well, I suggest the existing work and progress of WG2 will naturally
support your proposal, but is independant of anything WG2 may do. You
don't need anything from WG2 to make it happen. Instead you need
widespread support and involvement of the Scheme community. I doubt
very much WG2 can help directly with that beyond giving that community
a language it can accept and use. Everything in your proposal depends
on WG's success.

> 3) Networking - the implementations will need something working, and if
> this is unified, it makes the above easier, but it can actually be put
> off until the earlier ones are complete, as most implementations already
> have some kind of network system in place. The biggest question with
> this is whether network sockets are ports, and if so, how to modify the
> ports abstraction to handle two-way controlled IO with OOB data.

Please see my earlier points about building sets on libraries. Please
also see John Cowan's proposal for restructuring WG2. Your third
proposal fits into John's proposal. One of his suggest sub-committees
could tackle this. Perhaps a networking sub-sub-committee?

A even simpler approach: try writing a networking SRFI. Build on
existing work and let the Scheme community judge its merit. Then WG2
will have something to work with. I've believed for years - decades -
that this may be how the Scheme community succeeds. When the practical
requirements of the community are met, we see this reflected in the
SRFIs being supported and used. We can actually *see* this in the code
that is available, both in the SRFI repo and in implementations
supporting those SRFIs.

> 4) FFI - this can REALLY be put off, but just as a note, this should be
> in the form of per-language interfaces, that is, c->scheme, scheme->c,
> c++->scheme, scheme->c++, scheme->java, java->scheme, etc. Trying to
> unify this into a single massive FFI is doomed to conceptual and actual
> failure.

I'm going to assume you're aware of SRFI 198. (If not, you should be
now I've mentioned it.) What does this SRFI fail to do that your
proposal will address?

> I submit that we should start with R5RS, the last universally agreed
> upon standard, layer on libraries and networking, with reference to a
> centralised library repo, and go from there. I further submit that the
> cost of trying to maintain perfect compatilibity with R7 and
> (especially) R6 is far lower than the cost of rewriting the code to fit
> a new system.

R5RS was not universally agreed upon. It was however widely supported.
That's not the same thing. Since then R6RS has also become widely
supported. R7RS Small is in the process of becoming widely supported.

Perfect compatilibity is an impossible goal. Many R5RS systems weren't
even compatilible with each other. Many of them still exist and their
incompatitiblities may still exist. I don't know. I write very R5RS
code today. I test it on very few systems. However, I see a lot of
R5RS code still being used and supported. See the SRFI repo for many
examples.

Also see the SRFI repo for examples of R6RS and R7RS code. See the
three hash table SRFIs and how the SRFI 125 and SRFI 126 reference
implementations build on an earlier hash table SRFI. I think they show
how all three can co-exist in an pure R7RS system. R5RS and R6RS
systems maybe have higher requirements. See real systems for examples.

As I've said here before, I believe Chibi and Larcent, perhaps even
Guile, are existance proofs that there is no problem here.

> > The role of the SRFI process in this cannot be underestimated, both as a
> means of discussing the above interfaces, and for creating standard
> libraries to be added to the repo.

Agreed.

> That said, obviously not everything
> in the repo will be an SRFI, nor is it necessary to do so - but there
> are certain types of more standardised functionality or (more
> importantly) base-level language modifications that can only be solved
> by the excellent work done through the SRFIs.

See my earlier points.

> The floor is now open to flames and rebuttals. Thank you. :)

No flames here. Maybe some rebuttals. Definitely many questions.

> PS - As a further note, the level of discourse between people who have
> not actually written implementations, are not responsible for
> implementations, have very little skin in the game in terms of
> production level code or SRFIs, etc should perhaps be a little less ...
> rigid towards those with decades of experience working in and with
> Scheme at all levels. I am not singling out any names, but the whole
> reason I am proposing this before writing it up as SRFIs myself is to
> try to cut the gordian knot that has been created recently in the
> discourse, with threats backed up by nothing and general unpleasantness.

I hope none of that "unpleasantness" you see has come from me,
nevermind "threats".

I personally see little that I find unpleasant and can recall no
threats. Perhaps some disagreeable posts, but hardly unpleasant or
threatening - with one small exception, which was offensive, and I
immediately addressed that a few days ago.

So I appreciate your postscript. I merely point out that you may not
see everyone's code. I personally value the code written by *users* of
a language. I'm not comparing that value with the code of
implementations. I'm simply saying we won't see every Scheme
implementation. We might not even see the code compiled by every
Scheme. However, some of us can recall real world code created by such
systems and seen people pay for it and use it. I think that also has
value.

Thanks.

[John Cowan]

On Sun, Mar 13, 2022 at 1:12 PM Martin Rodgers <mcro...@gmail.com> wrote:

Maybe that's why John made his proposal. A small, self-consistant set
of libraries that use only R7RS Small will avoid all problems. So I
would say many SRFIs won't work because they depend on many features
not in Small. Some of them are not consistant with each other.

The point of Foundation is to provide stuff (like syntax-case) that can't be done by Small alone, because Small makes really minimal assumptions about the host Schemes.  Likewise, Environment can't be done by Small alone.

 

Your definition of "interesting" may be the problem. I prefer *useful*
as the primary criterion. It has no such problem. Useful libraries
written in R7RS Small. Build a set of libraries consistant with each
other.  That could be the "Foundation" set.

That's Batteries, not Foundation.  The libraries in Red and Tangerine are all Batteries except the ephemerons library, which is Foundation.

 

the reference implementations for the corresponding SRFIs, I've
found various self-consistancy issues.

Unsurprising.  However, the SRFI libraries are not *reference* implementations, because they don't define what the behavior is supposed to be: they are only sample implementations, proofs of concept.   So changing them is perfectly fine.

I'm using a (scheme small) library to import and re-export
*everything* in the Small library set. No conflicts. While my (scheme
large) library reveals many conflicts. I resolved all of them by
modifying the the implementation code. E.g. ensuring that (scheme
hash-table) and (scheme comparator) use the same two string hashing
procedures. This is a trivial change and AFAICT breaks nothing.

A good example.

BTW, I'm one of those users. I *am* speaking up. Please don't break my
code. Please don't break the code of others who are not (yet) speaking
up.

As the C Rationale puts it: Code is important, implementations are not.  If you look at the list of incompatibilities between R5RS and either R6RS or R7RS, you can see how short it is.

I recently mentioned the issues in the C world in another post. There
are some unhappy C programmers out there. They seem to feel betrayed,
but I can't speak for them. I can only observe that they exist and C11
is a problem for them.

I believe the problem isn't with C11 or any specific version of the Standard ; it's with the fact that older C compilers gave particular meanings to what the Standard says is undefined behavior (equivalent to Scheme "is an error"), and programmers had come to rely on those.  In particular, code that dereferences a pointer before checking that it is not null will in the right circumstances fail to do the null check at all, because the compiler reasons as follows: The pointer is either null or not null.  If it is not null, then the test is unnecessary.  If the pointer is null, the behavior is undefined, so the compiler need not consider this case.  Therefore the null check is redundant and is (at gcc -O2 or higher) removed from the compiled code.  Oops, security hole.

Please see my earlier points about building sets on libraries. Please
also see John Cowan's proposal for restructuring WG2. Your third
proposal fits into John's proposal. One of his suggest sub-committees
could tackle this. Perhaps a networking sub-sub-committee?

Networking will be the responsibility of E, at least at the TCP/IP level.

A even simpler approach: try writing a networking SRFI. Build on
existing work and let the Scheme community judge its merit.

We actually have one: SRFI 106.  It has some problems, but those can be fixed.

> PS - As a further note, the level of discourse between people who have
> not actually written implementations, are not responsible for
> implementations, have very little skin in the game in terms of
> production level code or SRFIs,

That would describe me!  Nonetheless, I agree with your point.

[Marc Nieper-Wißkirchen]

Am So., 13. März 2022 um 21:42 Uhr schrieb John Cowan <co...@ccil.org>:

> On Sun, Mar 13, 2022 at 1:12 PM Martin Rodgers <mcro...@gmail.com> wrote:

[...]

>> Your definition of "interesting" may be the problem. I prefer *useful*
>> as the primary criterion. It has no such problem. Useful libraries
>> written in R7RS Small. Build a set of libraries consistant with each
>> other. That could be the "Foundation" set.
>
>
> That's Batteries, not Foundation. The libraries in Red and Tangerine are all Batteries except the ephemerons library, which is Foundation.

I think this is a bit too narrowly considered. An efficient
implementation of SRFI 125, for example, needs support from the
Foundation, so it has to provide either a minimal hash table interface
or some building blocks needed to implement efficient hash tables (in
particular eq? and eqv? based ones). Hashmaps of SRFI 146 could also
need some support from the Foundation.

I would also consider very general interfaces like that of SRFI 128
that are supposed to be used pervasively as possible candidates for
the Foundation. But that has to be decided on a case-by-case basis, I
think, and probably cannot be answered conclusively beforehand.

Finally, it makes sense to consider stripped-down versions of some
large libraries, e.g. SRFI 1, as part of the foundation if they are
helpful for implementing the Foundation libraries themselves. E.g. a
predicate like every (or for-all as it is known in R6RS) is often very
useful in syntax-case fenders.

As I wrote earlier, one way to achieve this without any problems is to
give Foundation its own library namespace. Using the placeholder name
foundation for the moment, we would have, say, (foundation
syntax-case) with a (relatively) minimal set of syntax and procedures
to support syntax-case. The large language (or rather group B in this
case) can then define the library (scheme syntax-case) that reexports
all from (foundation syntax-case) but more procedures and syntax (the
batteries) as well.

Marc

[Martin Rodgers]

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

> The point of Foundation is to provide stuff (like syntax-case) that can't
> be done by Small alone, because Small makes really minimal assumptions
> about the host Schemes. Likewise, Environment can't be done by Small
> alone.

Yes, of course. Apologies. I should have said Batteries.

Clearly I had a "senior moment." ;)

>> Your definition of "interesting" may be the problem. I prefer *useful*
>> as the primary criterion. It has no such problem. Useful libraries
>> written in R7RS Small. Build a set of libraries consistant with each
>> other. That could be the "Foundation" set.
>>
>
> That's Batteries, not Foundation. The libraries in Red and Tangerine are
> all Batteries except the ephemerons library, which is Foundation.

I see the fixnum and flonum libraries as more F than B, but I agree
that portable libraries may be defined. By this reasoning, ephemerons
can also be B. In fact, that's exactly how I'm defining it. I believe
ephemerons can be fully supported using Guile's weak pairs and weak
hash tables, but I'm unable to effectively test this. I'm content to
use the portable reference implementation on systems where a better
definition is absent.

>> the reference implementations for the corresponding SRFIs, I've
>> found various self-consistancy issues.
>>
>
> Unsurprising. However, the SRFI libraries are not *reference*
> implementations, because they don't define what the behavior is supposed to
> be: they are only sample implementations, proofs of concept. So changing
> them is perfectly fine.

How else may we describe the R5RS implementation of SRFI 143? The text
itself calls this an implementation, but the code is portable R5RS,
which has no fixnum-specific procedures. The text for SRFI 159
explicitly calls the portable R7RS code a reference implementation.

> I'm using a (scheme small) library to import and re-export
>> *everything* in the Small library set. No conflicts. While my (scheme
>> large) library reveals many conflicts. I resolved all of them by
>> modifying the the implementation code. E.g. ensuring that (scheme
>> hash-table) and (scheme comparator) use the same two string hashing
>> procedures. This is a trivial change and AFAICT breaks nothing.
>>
>
> A good example.

Thanks.

>> BTW, I'm one of those users. I *am* speaking up. Please don't break my
>> code. Please don't break the code of others who are not (yet) speaking
>> up.
>
>
> As the C Rationale puts it: Code is important, implementations are not. If
> you look at the list of incompatibilities between R5RS and either R6RS or
> R7RS, you can see how short it is.

I was talking about making changes to R7RS Small. Not the differences
between the various Scheme reports.

> I recently mentioned the issues in the C world in another post. There
>> are some unhappy C programmers out there. They seem to feel betrayed,
>> but I can't speak for them. I can only observe that they exist and C11
>> is a problem for them.
>>
>
> I believe the problem isn't with C11 or any specific version of the
> Standard ; it's with the fact that older C compilers gave particular
> meanings to what the Standard says is undefined behavior (equivalent to
> Scheme "is an error"), and programmers had come to rely on those. In
> particular, code that dereferences a pointer before checking that it is not
> null will in the right circumstances fail to do the null check at all,
> because the compiler reasons as follows: The pointer is either null or not
> null. If it is not null, then the test is unnecessary. If the pointer is
> null, the behavior is undefined, so the compiler need not consider this
> case. Therefore the null check is redundant and is (at gcc -O2 or higher)
> removed from the compiled code. Oops, security hole.

Yes, the exploitation of "nasal demons" by compilers such as GNU C.
ISTR signed int overflow and underflow is another ambiguous area.

However, I was talking about schisms within a language community. My
point was merely that a change to a language definition lead to a
problem. That it depends on compilers exploiting that change supports
my point, I believe, rather than refuting.

> > Please see my earlier points about building sets on libraries. Please
>> also see John Cowan's proposal for restructuring WG2. Your third
>> proposal fits into John's proposal. One of his suggest sub-committees
>> could tackle this. Perhaps a networking sub-sub-committee?
>>
>
> Networking will be the responsibility of E, at least at the TCP/IP level.
>
>> A even simpler approach: try writing a networking SRFI. Build on
>> existing work and let the Scheme community judge its merit.
>>
>
> We actually have one: SRFI 106. It has some problems, but those can be
> fixed.

Sagittarius, Ypsilon and Mosh support it, but how many others? Enough
to make it a starting point for E?

[Arthur A. Gleckler]

On Sun, Mar 13, 2022 at 3:07 PM Martin Rodgers <mcro...@gmail.com> wrote:

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

 

How else may we describe the R5RS implementation of SRFI 143? The text
itself calls this an implementation, but the code is portable R5RS,
which has no fixnum-specific procedures. The text for SRFI 159
explicitly calls the portable R7RS code a reference implementation. 

Sorry, that was before I added a step to my finalization checklist to make sure that we did not use that term.  We now say "sample implementation" or just "implementation" instead.  I hadn't yet realized that "reference implementation" had become a term of art with a specific meaning.

In any case, the rule for SRFIs has always been that the document, not the implementation, is normative, i.e. defines what is correct.

[Martin Rodgers]

On 13/03/2022, Arthur A. Gleckler <a...@speechcode.com> wrote:

>> How else may we describe the R5RS implementation of SRFI 143? The text
>> itself calls this an implementation, but the code is portable R5RS,
>> which has no fixnum-specific procedures. The text for SRFI 159
>> explicitly calls the portable R7RS code a reference implementation.
>>
>
> Sorry, that was before I added a step to my finalization checklist to make
> sure that we did not use that term. We now say "sample implementation" or
> just "implementation" instead. I hadn't yet realized that "reference
> implementation" had become a term of art with a specific meaning.
>
> In any case, the rule for SRFIs has always been that the document, not the
> implementation, is normative, i.e. defines what is correct.

Apologies. I didn't mean to imply that the code defined the SRFI.
Clearly it can only implement it. I'll take care to avoid the word
'reference' and instead say sample implementation.

Thanks.

[Lassi Kortela]

> Using the placeholder name
> foundation for the moment, we would have, say, (foundation
> syntax-case) with a (relatively) minimal set of syntax and procedures
> to support syntax-case. The large language (or rather group B in this
> case) can then define the library (scheme syntax-case) that reexports
> all from (foundation syntax-case) but more procedures and syntax (the
> batteries) as well.

I'd expect the majority of schemers outside WG2 to want the (scheme foo)
library to refer to the Foundation version (or even the Small version).

This comes back to my suggestion of putting the Large libraries into
(scheme large <foo>) or some such.

Or perhaps (scheme <foo> large)?

[Dr. Arne Babenhauserheide]

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

>> Using the placeholder name
>> foundation for the moment, we would have, say, (foundation
>> syntax-case) with a (relatively) minimal set of syntax and procedures
>> to support syntax-case. The large language (or rather group B in this
>> case) can then define the library (scheme syntax-case) that reexports
>> all from (foundation syntax-case) but more procedures and syntax (the
>> batteries) as well.
>
> I'd expect the majority of schemers outside WG2 to want the (scheme
> foo) library to refer to the Foundation version (or even the Small
> version).

I’m not sure about that. Why do you think so?

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

[Marc Nieper-Wißkirchen]

Am Mo., 14. März 2022 um 07:32 Uhr schrieb Dr. Arne Babenhauserheide
<arne...@web.de>:

>
>
> Lassi Kortela <la...@lassi.io> writes:
>
> >> Using the placeholder name
> >> foundation for the moment, we would have, say, (foundation
> >> syntax-case) with a (relatively) minimal set of syntax and procedures
> >> to support syntax-case. The large language (or rather group B in this
> >> case) can then define the library (scheme syntax-case) that reexports
> >> all from (foundation syntax-case) but more procedures and syntax (the
> >> batteries) as well.
> >
> > I'd expect the majority of schemers outside WG2 to want the (scheme
> > foo) library to refer to the Foundation version (or even the Small
> > version).
>
> I’m not sure about that. Why do you think so?

Large already uses names like (scheme list), (scheme hash-table), etc.
So unless you want to retroactively change the existing colored
editions of R7RS Large, Foundation needs a new prefix. It could even
be rnrs or std.

For the majority of Schemes outside WG2, the large libraries probably
make the most sense because they have the batteries included.

[Marc Nieper-Wißkirchen]

Am So., 13. März 2022 um 23:07 Uhr schrieb Martin Rodgers <mcro...@gmail.com>:

> I see the fixnum and flonum libraries as more F than B, but I agree
> that portable libraries may be defined. By this reasoning, ephemerons
> can also be B. In fact, that's exactly how I'm defining it. I believe
> ephemerons can be fully supported using Guile's weak pairs and weak
> hash tables, but I'm unable to effectively test this. I'm content to
> use the portable reference implementation on systems where a better
> definition is absent.

Ephemerons really belong to the core together with a requirement that
rules out the trivial implementations (the R7RS already has a similar
requirement with respect to proper tail calls).

Moreover, as part of Foundation, some underspecification currently in
SRFI 124 can be removed by adding a definition of "referenced" to the
core semantics of the language.

> > As the C Rationale puts it: Code is important, implementations are not. If
> > you look at the list of incompatibilities between R5RS and either R6RS or
> > R7RS, you can see how short it is.
>
> I was talking about making changes to R7RS Small. Not the differences
> between the various Scheme reports.

We need minor changes to R7RS Small, but these will be even less than
the incompatibilities between R5RS and either R6RS or R7RS.

> > I recently mentioned the issues in the C world in another post. There
> >> are some unhappy C programmers out there. They seem to feel betrayed,
> >> but I can't speak for them. I can only observe that they exist and C11
> >> is a problem for them.
> >>
> >
> > I believe the problem isn't with C11 or any specific version of the
> > Standard ; it's with the fact that older C compilers gave particular
> > meanings to what the Standard says is undefined behavior (equivalent to
> > Scheme "is an error"), and programmers had come to rely on those. In
> > particular, code that dereferences a pointer before checking that it is not
> > null will in the right circumstances fail to do the null check at all,
> > because the compiler reasons as follows: The pointer is either null or not
> > null. If it is not null, then the test is unnecessary. If the pointer is
> > null, the behavior is undefined, so the compiler need not consider this
> > case. Therefore the null check is redundant and is (at gcc -O2 or higher)
> > removed from the compiled code. Oops, security hole.
>
> Yes, the exploitation of "nasal demons" by compilers such as GNU C.
> ISTR signed int overflow and underflow is another ambiguous area.
>
> However, I was talking about schisms within a language community. My
> point was merely that a change to a language definition lead to a
> problem. That it depends on compilers exploiting that change supports
> my point, I believe, rather than refuting.

The C language didn't change in this regard. Compilers just became better.

In any case, I think this is a better example of "don't use a language
you don't understand" :).

Marc

[John Cowan]

On Sun, Mar 13, 2022 at 6:07 PM Martin Rodgers <mcro...@gmail.com> wrote:

 

I see the fixnum and flonum libraries as more F than B, but I agree
that portable libraries may be defined.

Fair enough.  

By this reasoning, ephemerons
can also be B. In fact, that's exactly how I'm defining it. I believe
ephemerons can be fully supported using Guile's weak pairs and weak
hash tables, but I'm unable to effectively test this.

The question is whether we need weak pairs at all; my view is that, despite their slightly higher storage cost, we should always use ephemerons, as they affirmatively prevent memory leaks.

I'm content to
use the portable reference implementation on systems where a better
definition is absent.

The portable implementation is "Don't do anything", which really isn't suitable for R7RS-Large.

Sagittarius, Ypsilon and Mosh support it, but how many others? Enough
to make it a starting point for E?

I don't think that matters.  SRFI 170 should be implementable over any Posix library.  As the Rationale says, it was based on Scheme 48 because that was a politically neutral choice.

[John Cowan]

On Mon, Mar 14, 2022 at 3:20 AM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

We need minor changes to R7RS Small,

Can you itemize, or at least exemplify?

[Marc Nieper-Wißkirchen]

Am Mo., 14. März 2022 um 17:58 Uhr schrieb John Cowan <co...@ccil.org>:

>> We need minor changes to R7RS Small,
>
>
> Can you itemize, or at least exemplify?

The minor change that is a must is the expansion algorithm for
top-level programs and library bodies because the R7RS small spec is,
strictly speaking, incompatible with the syntactic extensions we voted
in. (The R6RS people thought long to get this right.)

I currently don't see any other area where we need an amendment
(barring R7RS errata we want to make official as part of large) but it
could be that committee F exhibits some further minor edge case. I
would say that it is committee F's job to write down the amended
semantics, to deprecate what's problematic, and to show a way to
handle legacy code.

I don't think that this is problematic or even surprising given that
it didn't happen in reality that the small and the large language were
being developed in parallel.