Email list hosting service & mailing list manager

Advanced file port operations: please review. John Cowan (01 Nov 2019 23:01 UTC)
Re: Advanced file port operations: please review. hga@xxxxxx (02 Nov 2019 00:14 UTC)
Re: Advanced file port operations: please review. John Cowan (02 Nov 2019 02:19 UTC)
Re: Advanced file port operations: please review. hga@xxxxxx (02 Nov 2019 15:43 UTC)
Re: Advanced file port operations: please review. John Cowan (02 Nov 2019 18:15 UTC)
SRFI 177 as a dependency for keywords in other places Lassi Kortela (02 Nov 2019 23:00 UTC)
Re: SRFI 177 as a dependency for keywords in other places Marc Nieper-Wißkirchen (03 Nov 2019 08:33 UTC)
Re: SRFI 177 as a dependency for keywords in other places Marc Nieper-Wißkirchen (06 Nov 2019 10:21 UTC)
Re: SRFI 177 as a dependency for keywords in other places Marc Nieper-Wißkirchen (09 Nov 2019 13:13 UTC)
Re: Advanced file port operations: please review. Shiro Kawai (02 Nov 2019 10:15 UTC)
Re: Advanced file port operations: please review. John Cowan (02 Nov 2019 14:36 UTC)
Port settings Lassi Kortela (02 Nov 2019 10:28 UTC)
Re: Port settings John Cowan (02 Nov 2019 14:00 UTC)
Re: Port settings Lassi Kortela (02 Nov 2019 14:13 UTC)

SRFI 177 as a dependency for keywords in other places Lassi Kortela 02 Nov 2019 23:00 UTC

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