[Chicken-janitors] Re: #281: promote irregex to full unit

[Chicken Trac]

#281: promote irregex to full unit
-----------------------------------------------------------------------+----
 Reporter:  zbigniew                                                   |       
Owner:       
     Type:  enhancement                                                |      
Status:  new  
 Priority:  minor                                                      |   
Milestone:  4.6.0
Component:  core libraries                                             |     
Version:  4.5.x
 Keywords:  regex irregex movin-on-up to-the-east-side deluxe-apt sky  |  
-----------------------------------------------------------------------+----

Comment(by zbigniew):

 Replying to [comment:1 felix]:
 > I understand the motivation and it really makes things easier to use,
 but I'm not entirely happy with this change: I regard irregex as a pure
 "engine" (a replacement or previous regex engines used in chicken). That
 the irregex API is exposed just for convenience or performance (and it
 would be better not to expose it at all, but since its there, its there).
 By doing so, chicken users depend on it, which would make a replacement
 (not planned at all, though) impossible. Ieally, the irregex API should be
 an extension.
 >
 > Let's talk about this more before making a decision.

 Here is my rationale.  Primarily, you already have Chicken users relying
 directly on the irregex API, because the irregex API is superior.
 Although I still use some regex calls when it is easier, I also rely on
 the irregex API in almost all new code.  regex provides access to basic
 functions and includes SRE support, but it does not include important
 functionality such as regex-fold and especially substitution using a
 procedure as the target instead of a string (this feature is critical).
 Yes, the irregex API is still changing, and we are even running an old
 version, but it's still worth using it.

 Let's do a Gedankenexperiment and imagine the regex backend is not tied to
 irregex.  Then

 1. If irregex becomes an extension, how can a core unit (regex) depend on
 it?
 2. If we extend the regex API to provide everything that irregex does,
 does it become just a version of irregex with an incompatible API?
 3. Must any replacement engine guarantee SRE support?

 I actually appreciate your argument because I have occasionally pined for
 the days of PCRE (!) -- as it is much, much faster than irregex.  However,
 despite that, I have come to rely on SREs and some features of the irregex
 API.  My patch just tried to codify existing user practice, but I'm not
 wedded to it.

 So, let's discuss our options.

-- 
Ticket URL: <http://www.irp.oist.jp/trac/chicken/ticket/281#comment:3>
Chicken Scheme <http://www.call-with-current-continuation.org/>
Chicken Scheme is a compiler for the Scheme programming language.