Tentative list of features to be considered by Committee F

[John Cowan]

Sublist 1 (by dpk)

From the Red Edition:
• possibly (scheme comparator) as comparators a form a useful basis as a lingua franca for making data-structure operations type-generic, though they have been criticized [JC: an important part of thi

From the Tangerine Edition: perhaps SRFI 160? [JC: (srfi 160 base) can be implemented portably but not very efficiently, whereas the other (srfi 160 *) libraries can be left to Committee B]

From the Yellow Edition:
• syntax-case; to be extended by low-level syntax object destructuring procedures (; possibly to be defined in the spec in terms of Flatt's sets of scopes rather than Dybvig's marks and substitutions as in R6RS (the two models are semantically equivalent, but the former is simpler and more elegant imo)
• syntax parameters
• splicing-let{rec,}-syntax
• identifier-syntax [JC: Is it possible to implement identifier-syntax on top of syntax-case?  If so, should be moved to Committee B]
• identifier properties
• identifier aliasing

Additional syntax features:
• Auxiliary syntax keywords from SRFI 206

Misc additional features:
• Delimited continuations from SRFI 226
• Continuation marks from SRFI 226, with concomitant guarantees on the tail-position semantics of parameterize etc.
• A condition system (from R6RS? with restarts?)
• Record type inheritance (unifying SRFI 99 and R6RS?)
• Procedural record-type creation and reflection (ditto?)
• Some kind of guarantee on the performance of string-ref
• Require implementations to support form-feed as whitespace
• Procedure tags a la SRFI 229, though I would prefer a key-value mapping associated with procedures rather than just one slot, so that you can do multiple things with them
• Attempt to unify the R6RS and R7RS library systems, perhaps by supporting ‘library’ simply as a more concise alternative to ‘define-library’ when cond-expand and friends aren’t needed.

Perhaps more controversial:
• Keyword datums a la SRFI 88 (though on reflection I think Kawa and Racket got it right by making them non-expressions, which implies changing procedure call evaluation semantics somehow)
• Basic threading a la SRFI 18, maybe with atomic operations from SRFI 230. (Optional?) [JC: Unclear what "basic" means.  SRFI 18 has three parts: threads, condition variables, timeouts.  I think condition variables are too low-level.]

Changes vs R7RS small: Review all ‘is an error’ and RFC 2119 ‘should’, ‘may’ instances etc. and decide when and how to tighten them up. I have a preliminary list of such cleanup cases, but it’s far from complete.  [Committee C]

[Is exact R6RS compatibility to be a requirement of R7-Large, or only a guideline?]

Sublist 2 by JC:

Custom macro transformers a la SRFI 147

Syntax-rules extensions a la SRFI 149

Syntax-case extensions to make Small's syntax-rules implementable in syntax-case.

Callable record types: instances of these types can be called as procedures.

Extended exact real numbers:  1/0 for exact positive infinity, -1/0 for exact negative infinity, and 0/0 for exact NaN.  See SRFI 73.

Mutable global environments: see <https://github.com/johnwcowan/r7rs-work/blob/master/EnvironmentsMIT.md>.

R7RS-large-specific library declarations: see <https://github.com/johnwcowan/r7rs-work/blob/master/LibraryDeclarationsCowan.md>

Interface declarations: see <https://github.com/johnwcowan/r7rs-work/blob/master/InterfacesCowan.md>

Comments?

[Vincent Manis]

I strongly support the restructuring proposed by John. This seems to go
in exactly the right direction.

As for Marc's proposed list, it seems reasonable enough to me, assuming
that all of the items in it are amenable to committee B. Also, I would
like to take R6RS compatibility off the table, as that opens up a huge
can of worms.

I hereby offer myself as a member (NOT the Chair) of Committee C.

-- v

[Daphne Preston-Kendal]

On 13 Mar 2022, at 02:08, John Cowan <co...@ccil.org> wrote:

> From the Tangerine Edition: perhaps SRFI 160? [JC: (srfi 160 base) can be implemented portably but not very efficiently, whereas the other (srfi 160 *) libraries can be left to Committee B]

I forgot: require the full numeric tower.

> Sublist 2 by JC:
>
> Custom macro transformers a la SRFI 147

We have already implicitly adopted this, since it is required for syntax-case.


Daphne

[Marc Nieper-Wißkirchen]

Am So., 13. März 2022 um 02:45 Uhr schrieb Vincent Manis <vman...@gmail.com>:

[...]

> that all of the items in it are amenable to committee B. Also, I would
> like to take R6RS compatibility off the table, as that opens up a huge
> can of worms.

Can you explain what you exactly mean by this?

Eventually, R6RS compatibility might prove to be unachievable but
precluding it from the beginning sounds premature to me (and
politically unwise). In principle, the R7RS Large language is large
enough to be able to encompass R6RS as well without much work on the
implementer's side. (In some sense, this is similar to the C++
language, which also includes the C standard header files. Recently I
converted a code basis in C to C++ and that wasn't hard and
incremental adoption of C++ features was made possible. GCC's code
basis starting from 4.8 is another example - and non-trivial.)

[Martin Rodgers]

On 13/03/2022, Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:

> Eventually, R6RS compatibility might prove to be unachievable but
> precluding it from the beginning sounds premature to me (and
> politically unwise). In principle, the R7RS Large language is large
> enough to be able to encompass R6RS as well without much work on the
> implementer's side.

I agree that there being able to translate R6RS code into R7RS should
be a goal, even if such translations require considerable effort. I
believe it is already (BTDT, as I've said already) but I accept that
some things, like syntax-case, may eventually help with that.

However, I don't think we should underestimate the risks. I'll say
more about that below.

> (In some sense, this is similar to the C++
> language, which also includes the C standard header files. Recently I
> converted a code basis in C to C++ and that wasn't hard and
> incremental adoption of C++ features was made possible. GCC's code
> basis starting from 4.8 is another example - and non-trivial.)

I lost track of the changes being made to C++ in the late 90s. Writing
code in the language was already a challenge for many C++ programmers
by 1995. I recall one programmer talking about the difficulty of
finding a book that was in sync with a compiler that was in sync with
the language. I later began seeing open source C++ code breaking
because of the rapid changes. I.e. we were already translating C++
code into C++.

So, in that sense there is some small similarity to the situation the
Scheme community now find itself. I began using Guile back in the 1.x
days. I can painfully recall seeing code for Guile 1.4 break after
upgrading to 1.6, nevermind 2.0. The Guile 3.x API doesn't appear so
different from the 2.2 API, so I doubt there's nearly as much
breakage. Perhaps the slow move to Guile 3.x is due to 2.x
dependancies, but it might simply be that, so far, there are
insufficently compelling reasons to make that move.

For me, the justification for moving from 2.2 to 3.x is simply R7RS
Small. A "Foundation" set of libraries *with code* could then be added
to give Guile better support for R7RS. However, the R6RS support has
been there for some time now.

I still see Guile code from the 1.4 era listed as available. Not all
of that code has been updated. The projects themselves are orphans. It
will only run with that dead version of Guile. So the code in those
projects is also dead. Perhaps "zombie" might be a better term, as
they're still treated as if the code can be used. Well, technically
yes, but only with great effort.

The Python community has its own issues. Some members are stil
grumbling that their Python 2 code is broken, but I can remember
Python 1. How much of *that* code was broken? I still see python2
debian packages, so at least Python code from more than a decade ago
can still be run on today's computers with ease. Simply install the
required packages.

I hope we can find similar solutions to the R6RS/R7RS differences. I
think most of us are in agreement on the core issues and goals. My
personal belief is that the limit on how much WG2 can and should do
may be lower than some others, and that this isn't a problem. The
Scheme community can resolve those issues as successfully as other
languages communities have. Given the nature of the Scheme languages,
perhaps we can do so with *more* success.

The size of a language community may be another important issue. The C
community is larger than any of the other communities I've mentioned.
The ANSI and ISO standards are now old enough to be creating some
schisms. One schism at least is becoming a major problem within that
community. I hope they too can resolve their issues.

Not least because many Scheme systems are written in C and/or generate
C code. Schisms are dangerous.

[Lassi Kortela]

> Eventually, R6RS compatibility might prove to be unachievable but
> precluding it from the beginning sounds premature to me (and
> politically unwise).

There already are a few combined R6 + R7 implementations, and Clinger's
and Kato's papers are encouraging.

It's probably impossible to keep the formal semantics of R6 and R7 in
the same spec. But it ought to be possible to find new semantics such
that practical R6 and R7 code both keep working.

(We can expect tricky edge cases in semantics that affect almost no
practical code; IMO compatibility in those parts can be ignored.)