SRFI 130 and SRFI 115 interaction John Cowan (28 Apr 2016 00:31 UTC)
Re: SRFI 130 and SRFI 115 interaction Alex Shinn (28 Apr 2016 12:01 UTC)
Re: SRFI 130 and SRFI 115 interaction Shiro Kawai (28 Apr 2016 12:11 UTC)
Re: SRFI 130 and SRFI 115 interaction Alex Shinn (28 Apr 2016 23:56 UTC)
Re: SRFI 130 and SRFI 115 interaction William D Clinger (29 Apr 2016 15:03 UTC)
Re: SRFI 130 and SRFI 115 interaction John Cowan (03 May 2016 16:16 UTC)
Re: SRFI 130 and SRFI 115 interaction Mark H Weaver (29 Apr 2016 22:32 UTC)

Re: SRFI 130 and SRFI 115 interaction John Cowan 03 May 2016 16:16 UTC

William D Clinger scripsit:

> Better yet, SRFI 130 should specify different names, so SRFI 130
> and SRFI 115 could be used together without having to rename any
> procedures.

I agree that changing the results of already-defined procedures (as
opposed to extending the types of their arguments) is a Bad Thing,
and I have abandoned that idea.

The difficulty with simply incorporating the new names into SRFI 130 is
that they are meaningful only if an implementation of SRFI 115 also exists
on the system.  Conformance, therefore, would have to be conditional,
which in itself isn't a problem.  However, the requirement to provide an
implementation is problematic.  I do not want the sample implementation
of SRFI 130 to depend on SRFI 115 for the sake of these two procedures.

I will go with the requirement to accept cursors as well as indexes,
but leave the two index-returning procedures alone.

> If the proposed change is inessential, leave it out.  Some future
> SRFI could specify the cursor-returning procedures that would then
> augment SRFI 115 and SRFI 130 instead of making a muddle of both.

I suppose that is the best that can be done.  As I hope both SRFI 115
and SRFI 130 will be included in the Red Edition, I'll start SRFI 135
at once and try to get it included in the Orange Edition.

> It's okay to have SRFIs that augment prior SRFIs by adding new
> things.  If we had more such SRFIs, there might be less perceived
> need to describe so many procedures in each new SRFI, allowing
> experience to become more of a guide.

Good point.

Mark H Weaver scripsit:

> Instead, how about requiring the addition of new procedures
> 'regex-match-submatch-start-cursor' and
> 'regex-match-submatch-end-cursor' that return cursor-or-false?

The problem with that idea is namespace pollution.  When you import what
purports to be an implementation of SRFI 115, you have a right to expect
that only the names mentioned in SRFI 115 are bound by doing so.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Lope de Vega: "It wonders me I can speak at all.  Some caitiff rogue
did rudely yerk me on the knob, wherefrom my wits yet wander."
An Englishman: "Ay, belike a filchman to the nab'll leave you
crank for a spell." --Harry Turtledove, Ruled Britannia