Of course it's the right thing to do, but by changing the return type of regex-match-submatch-{start,end}, this change puts new requirements on portable code using srfi-115 (must vs should vs may notwithstanding).   

I think at the very least, an addendum should be added there (srfi 115) to cover this.

On Thu, Apr 28, 2016 at 6:21 PM, srfi.schemers.org mailing list <xxxxxx@simplelists.com> wrote:
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)

SRFI 130 and SRFI 115 interaction by John Cowan (28 Apr 2016 00:31 UTC)
Reply to list

    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.

    If there are comments or objections, please raise them now.

    --
    John Cowan http://www.ccil.org/~cowan xxxxxx@ccil.org
    At the end of the Metatarsal Age, the dinosaurs abruptly vanished.
    The theory that a single catastrophic event may have been responsible
    has been strengthened by the recent discovery of a worldwide layer of
    whipped cream marking the Creosote-Tutelary boundary. --Science Made Stupid

Re: SRFI 130 and SRFI 115 interaction by Alex Shinn (28 Apr 2016 12:01 UTC)
Reply to list

    On Thu, Apr 28, 2016 at 9:31 AM, John Cowan 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

Re: SRFI 130 and SRFI 115 interaction by Shiro Kawai (28 Apr 2016 12:11 UTC)
Reply to list

    One concern is the case that if existing code externalizes returned indexes
    of those procedures, e.g. writing it to data file and passing to other programs.
    Even the implementation have external representation of cursors, the reader
    of such data file may not be a Scheme program.  Then such library would
    simply breaks with the change.
    OTOH, srfi-115 is relatively new, so we may just bet there's no  such libraries
    yet.  However, for the externalization purpose, there should be a procedure
    that's guaranteed to return integer codepoint index.

    On Thu, Apr 28, 2016 at 2:01 AM, Alex Shinn <xxxxxx@gmail.com> wrote:
    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

To unsubscribe from this list please goto http://www.simplelists.com/confirm.php?u=zVLszNQO2yhXXVQWCw1xuqC4R9i2Wngr