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