> Adding open-file to SRFI 170 with keywords is a no-brainer, I think: we'll
> say that 170 depends on 177, and rig the ballot so that a vote for 170 is a
> vote for 177 as well.  I did this with 128 in the Red Edition; it's
> appropriate whenever a SRFI's interface, as opposed to its implementation,
> depends on another SRFI.

Interesting.

I wonder how SRFI 177 dependencies should be declared. I intended it to
have just the macros. The macros implement keyword argument semantics
that are basically independent of the API in the SRFI. But since the API
surface is very small with only 2 macros, maybe it does no harm to have
the SRFI itself as a dependency for some things.

> What to do about the R[567]RS procedures is more difficult.  Because of
> call/kw they aren't just drop-in replacements as I had originally intended.
> I think the simplest thing is to make the fdes->port functions
> keyword-based.

SRFI 177 is deliberately designed so that keyword lambdas can be called
like ordinary lambdas when no keywords are given to them.

So for example a keyword lambda:

(call-with-output-file string proc [settings-as-keyword-arguments])

Can always be called as

(call-with-output-file string proc)

just like RnRS `call-with-output-file`.

Only if you want to give some keywords, do you need to use `call/kw`:

(call/kw call-with-output-file string proc :exclusive #t)

Of course, if you know you only need to support a particular Scheme
implementation and it has native keywords, you could leave out the call/kw.

The advantage of full compatibility with native `lambda` really becomes
apparent in scenarios like this RnRS interoperability thing.