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 William D Clinger 29 Apr 2016 15:03 UTC
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. > > If there are comments or objections, please raise them now. I don't think SRFI X should presume to revise SRFI Y. If the proposed change is essential for SRFI 130, then SRFI 130 should specify the affected procedures, taking care to point out their incompatibility with the corresponding procedures of SRFI 115. Better yet, SRFI 130 should specify different names, so SRFI 130 and SRFI 115 could be used together without having to rename any procedures. 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. 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. Will