> I'm happy to have the SRFI repositories be the home of these files if
> they don't change, collectively, more than every few months — or more
> often when they're new.
>
> For a while, the eggs <https://wiki.call-cc.org/eggs> for some of
> Chicken Scheme's SRFI implementations were stored in the SRFI
> repositories.  However, that became a problem because they were changing
> so often, for reasons that were to do with Chicken and not with the
> SRFIs.  Because of that, I asked the Chicken folks to host their own
> repos for those SRFIs, giving them complete control and relieving me of
> responding to countless pull requests.
>
> So I do have a limit.  Still, it would be great to have all this
> information, which applies to all Scheme implementations, gathered
> together with the corresponding SRFIs.  So let's start with that assumption.

Very informative. So in practice Ciprian and others who develop the type
signatures would maintain Git clones of the SRFI repos and send pull
requests to the origin repos in batch every now and then?

> If I recall, Ciprian's format is extensible, so we could start by
> extracting, one way or another, simple type signatures, then add more
> information as Ciprian and others produce it.

If we are going to developing the static type signatures in the same
S-expression file where the straightforward transcribed stuff lives,
then we just have to come up with some compromise on its format :) We
could also have them in different S-expression files, but I think it's
better if we work to find a way to fit everything in one file in such a
way that everyone is mostly satisfied. It causes less duplication, is
more likely to be correct, and is probably easier to maintain long-term.

The first conundrum with the argument signatures is that the Lisp
tradition tends to think a function has only one signature (possibly
with optional args) and the names are the main thing, like:

     (make-vector k [fill])

Whereas the functional tradition likes to emphasize types and break it
down to the possible type combinations like a case statement:

     (make-vector
      ((range-length-zero) -> vector-empty)
      ((range-length-zero any) -> vector-empty)
      ((range-length-not-zero) -> vector-not-empty)
      ((range-length-not-zero any) -> vector-not-empty))

Unfortunately, the functional signatures are notoriously hard to read
for people from other traditions because the types are so detailed and
the argument names are omitted or de-emphasized.

We would have to find some notation that combines these quite opposing
traditions. We could also write them separately, but any duplication is
a chance for discrepancy.

Ciprian, have you already thought a lot about how to combine these
representations? The syntax you have so far looks like it's directly
from the functional tradition. Did you come to the conclusion that this
would be the best one?