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 Mark H Weaver (29 Apr 2016 22:29 UTC)
Re: SRFI 130 and SRFI 115 interaction William D Clinger (04 May 2016 15:16 UTC)

Re: SRFI 130 and SRFI 115 interaction Alex Shinn 28 Apr 2016 12:01 UTC

On Thu, Apr 28, 2016 at 9:31 AM, John Cowan <xxxxxx@mercury.ccil.org> wrote:
> I'm planning to add a new paragraph to SRFI 130 explaining how it should
> interoperate with SRFI 115 if both are present in the same implementation.
> I think the first sentence should be uncontroversial, but the second
> sentence may require some discussion.
>
>     In a Scheme implementation that provides both this SRFI and
>     SRFI 115 : Scheme Regular Expressions, the procedures of SRFI
>     115 that accept start and end index arguments must be modified
>     to also accept start and end cursor arguments.  Furthermore, the
>     procedures regex-match-submatch-start and regex-match-submatch-end
>     must return cursors rather than indexes.
>
> Alternatively, the "must" in the second sentence could be replaced by
> "should" or even "may", since it is possible to do conversions with
> string-cursor->index and string-index->cursor, which are identity
> functions if their arguments are an index or cursor respectively.
> As yet another possibility, two new interfaces could be provided,
> regex-match-submatch-start-cursor and regex-match-submatch-end-cursor.

I think "should" is sufficient.  Changing the return values
to be cursors will simply break code.  I like the new procedures
returning cursors, but feel uncomfortable 1) changing the exports
in a finalized SRFI and 2) having those exports be variable
depending on whether or not another SRFI is supported.

--
Alex