> In fact the "signature" part has the Erlang semantic:
> * given a set of concrete arguments,  (i.e. their number and types are known)
> * iterate top-to-bottom through all the "signature" variants, and
> * the first variant which matches the concrete arguments (i.e. they
> are of the same type, and possibly taking into account optional and
> rest variants),
> * is the one that should be considered for those concrete arguments;

That seems simple and effective at first glance :)

> I think separate files is easier to integrate various tools and workflows.

OK, let's do that. It's starting to seem the cleanest approach to me
also (those combined signatures in one of my earlier messages looked
quite hairy).

We could go with the multi-file approach sketched earlier (filenames up
for debate):

* srfi-123.html (SRFI HTML)
* srfi-123-info-add.scm (human-written general information additions)
* srfi-123-info.scm (auto-merged general info from HTML and additions)
* srfi-123-args.scm (auto-extracted Lisp-style signatures from HTML)
* srfi-123-types.scm (human-written static type specifications)

I could auto-generate the `srfi-123-args.scm` files that have the
Lisp-style arg lists. If it helps, you could use those as a basis for
making the type-signature files faster.

> Syntaxes (i.e. "macros") have a different "signature" syntax, one very
> similar to the actual `syntax-rules` syntax.

That's cool. So we could also house syntax definitions in both files.
And write the cross-checking tool eventually to verify that they match.