Hi Juli,

> 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'm glad we're aligned and congrats with the first (stellar!) piece of
feedback on here!

> 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. 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.

Well, I'm thinking a wide range of implementations here. Starting from
PreScheme with its C generation and Stalin with its unforgiving
compilation; and ending with more or less DWIM-y Guile or Kawa. The
former would likely treat the check mismatch as undefined behavior or
break in horrible ways, while the latter are sanely expected to raise
errors. And that's just one axis of the implementation alignment (think
compiled vs. interpreted, embedded vs. hosted, platform specifics
etc.). I'm trying to accommodate all the potential implementations here
and I'm sacrificing the exactness of "error" behavior for that, readily.

> As I understand it, SRFIs are
> prescriptive; only the Reports are intended to be
> descriptive.

My point of view differs here: I'm trying to perceive SRFIs as standards
too, with all the SRFI-compliance talk meaning something one can rely
on. And that's why I'm trying to avoid too narrow of a specification in
the part of errors—I want implementations to be SRFI-253-compliant even
if they have UBs on failed checks. That's the goal.

I realize that this inexactness is quite unsatisfying, but my attempts
at bringing support for this SRFI to multiple implementations did show
significant differences in how typing is handled and I want to preserve
this practice.

My preference is already expressed in the "it is an error" explanation
paragraph, and I personally find it a good middle ground. Suggesting
errors, while giving space for UBs.

> With regards to the prefix/postfix question: choose either one, but
> don't have both.

Well, both places (check-arg and values-checked) that are questionable
in regards of prefix/postfix clash are this way for historic
reasons. I'm trying to preserve the existing practice from other Lisps
and existing implementation/SRFI-specific primitives in these.

But you've definitely prompted me to think again about how
values-checked can be improved!

> 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.

Yes! I'll reword it to make it an optional "caller" argument. A long
overdue change, really...

> 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)`.

That's a tricky one. Your suggestion actually makes things clearer and
is consistent with the rest of SRFI, that's for sure. I'll try to
implement that. I'm also considering removal of opt-lambda-checked,
because there's too many questionable parts about it in the context of
this SRFI. But that'd have to wait, I guess.

> On editing and layout: the documents contains a lot of unnecessary
> information. "Design Decisions," for example...

I'll remove it, the whole section is indeed me naysaying against my own
decisions 😅

> (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.)

It's possible to type-check rest arguments, including with SRFI-1. The
problems with doing so are:

- It's syntactically tricky, because one can't add a (name predicate)
  list as a tail argument, because it will be interpreted as a plain
  list to append as the last cdr:

> '(a b c d . (name predicate?))
$1 = (a b c d name predicate?)

- It requires more involved list-of checks, preferably the ones
  integrated into the SRFI (otherwise rest argument checking is a weird
  special case raising suspicion), which opens a way for more complex
  check combinators. These are non-goals for the SRFI.

> Semi-related: use more formal language in the "Prior Art" section.

Yes, that's a good remark. I'll fix that.

> 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.

Oh, that's a quirk of my writing style indeed.
I'm splitting sentences.
I'll fix that, as it may indeed look jarring.

> 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.

Right, these are harder to weed out. I'll do my best.

Actually, I'm okay with (sane) editing pull requests if anyone wants to
fix some really nasty parts. I'm not a native English speaker with all
this implies.

> 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 for all your feedback! You're helping with making the SRFI
better. I'll integrate your comments and hopefully you can use SRFI-253
soon 🖤

Thanks,
--
Artyom Bologov
https://aartaka.me