Apologies for the delay and missing people's comments
in the last draft, I've been struggling to find time to work
on this. Please do double-check my work!
Until it is updated on the SRFI site you can find the
This includes the long name forms as discussed, plus
(char-set "letters") which is equivalent to ("letters").
I've also decided to go ahead and change => to ->. The
feedback from IrRegex users was that it wasn't enough
of a gain, but for IrRegex I will continue to support both
forms indefinitely. I'll try to help with any porting needed
in public code, but users of this syntax in unpublished
code will need to replace existing uses when porting to
SRFI 115.
I had been leaving all issues open to give a chance
for late comers to comment on them, but for simplicity
am now considering the following resolved:
* => should have been ->.
Renamed, as described above.
* How to integrate with the PCRE regular _expression_ library?
There will be 3 procedures, sre->pcre, pcre->sre and pcre,
the latter of which will compile to the same regexp type.
Details to be worked out in a separate SRFI.
* Omitting dsm, posix-string and blank.
There were no objections.
* "|" and "&" kept with "or" and "and" aliases.
One person was not fond of |\||, but there were no
strong objections.
* Omitting IrRegex utility patterns.
No objections, we can provide utilities in separate libraries.
* API uses string indices.
No objections.
* Unicode as the default.
No objections.
* No general Unicode properties.
No objections, a Unicode properties library is intended which
should provide the necessary char-sets.
* regexp->sre is frequently requested in IrRegex.
Now included.
* SREs with embedded SRFI 14 char-sets can't be written
and read back in portably.
No objections, mollified with char-set->sre. There's also
been much discussion in general of extensible read/write
syntax for R7RS.
--
Alex