Hi Artyom,

Thank you so much for this SRFI! Despite my love for Scheme, my heart
has long ached for the various benefits of (explicit) static typing. In
my daydreams of what this would look like, I have come up with syntax
very similar to `define-checked` and `lambda-checked`, and thus I was
very excited to learn of this SRFI! So excited that I'm commenting on a
draft SRFI for the first time ;)

I have several pieces of feedback about the specific proposals.

Firstly: I see others have mentioned the ambiguity of error
recommendations. I want to return to this topic and reiterate that
there should be no ambiguity in the specification. If an existing
implementation has a clashing name with contradictory behavior, that's
the implementation's problem, not yours. As I understand it, SRFIs are
prescriptive; only the Reports are intended to be descriptive.
Explicitly state that failed type checks error at compile-time or in
debug mode, and are permitted to not error during normal
interpretation, assuming that is your preferred behavior. If it's not
your preferred behavior, be equally explicit about what *is* your
preferred behavior. This SRFI is yours to do with as you please. If
implementors want to change it or ignore it, that's their prerogative.

With regards to the prefix/postfix question: choose either one, but
don't have both. Speaking from Guile experience, having similar
procedures which take arguments in different orders has resulted in
cumulative hours of lost time trying to track down obscure errors only
to realize the issue is argument order. There's no reason to introduce
this inconsistency in a new API. (I recommend postfix syntax since that
is the most common notation in this document.)

On the topic of ambiguity in new APIs: `check-arg` should not accept a
rest list. Either have a required final argument or rely on SRFI-227 to
define an optional final argument; don't leave it ambiguous.
Additionally, rest lists can introduce unnecessary runtime overhead,
weakening the goal of performance. When making that change, I recommend
renaming `value` to `arg` and giving the final argument a more precise
name. This makes it clear what, exactly, is checked and what the final
argument is for.

Continuing on the topic of syntax: it is more logical for
`opt-lambda-checked` to require that all optional arguments be checked
than that all checked arguments be optional. I can more easily imagine
situations where one desires a required, checked argument alongside
optional arguments than required, unchecked arguments alongside
optional, checked ones. Requiring type checking on optionals is
minimally onerous because at least one exemplar of the optional is
provided anyway, meaning the type should already be known. This would
change the argument syntax for optionals to `(name predicate
optional)`, allowing required arguments to take the form `name` as well
as `(name predicate)`.

On editing and layout: the documents contains a lot of unnecessary
information. "Design Decisions," for example, should be excluded. Where
some information is applicable to "Rationale," it should go there, and
the rest should be cut. (I would only keep a short statement that this
document balances the goals of performance, correctness, and
minimalism.) In particular, you don't need to explain why a feature has
been left out or takes a specific shape. Discussions on these topics
are captured for posterity in the SRFI's mailing list archive. The
exception here is the question of rest arguments. Since this subject is
directly related to the implementation, you should merge the "Design
Decisions" section about rest arguments with the caveat under
"Implementation." I'm not very familiar with the norms of SRFI
sections, but the resulting discussion may belong under "Issues."

(Tangential: could you not use SRFI-1's `all` to ensure that at least
homogenous rest arguments properly type check? I haven't looked at the
implementation, and the requirement that rest arguments be homogenously
typed may be onerous.)

Semi-related: use more formal language in the "Prior Art" section. In
particular, the sentence, "Magnificent times we live in—Scheme
implementations reaching the level of big ones," is needlessly polemic.
It implies that Scheme is not one of the "big ones;" that is, that it's
not a "real" programming language or that it is at least not an
important one. These ideas are demonstrably false, and I doubt you
intended to imply them in the first place. That said, "Prior Art" feels
similar to "Design Decisions" as an unnecessary implementation detail
of the SRFI document rather than relevant to the content thereof, and
should similarly be excluded.

On the topic of wording: this document needs some copy editing before
finalization. There are two major issues: wording and flow, and
formality. With regards to wording and flow, a recurring pattern is
breaking apart what would normally be one sentence into two or more.
Most commonly, most (all?) sentences beginning "Which" should be part
of the preceding sentence. Many other sentences beginning with
prepositions should similarly be part of the preceding sentence or
otherwise worked into surrounding sentences. Some examples of formality
issues are the use of abbreviations ("utils" instead of "utilities"),
opinion statements (mostly in "Design Decisions" and "Prior Art"), and
conversational tone.

All in all, I adore this SRFI. In particular, I commend the use of
predicates and their related idioms for the purposes of type checking.
This approach minimizes new syntax while ensuring flexible and explicit
gradual typing -- all in forms already familiar to most Schemers. I am
very excited for this SRFI, with or without the inclusion of my
recommendations!

Thanks again for your work on this!
-Juli