Email list hosting service & mailing list manager

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 Mark H Weaver 29 Apr 2016 22:29 UTC

John Cowan <xxxxxx@mercury.ccil.org> writes:

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

IMO, the requirement in the last sentence above is unacceptable.
Changing "must" to "should" or "may" would not make it acceptable.  Such
an incompatible change must not be suggested.  Existing code, or even
future code written to use SRFI-115 without knowledge of SRFI-130, will
expect 'regex-match-submatch-start' and 'regex-match-submatch-end' to
return integer-or-false, as promised by SRFI-115.

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?

     Regards,
       Mark