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

[Chicken Trac]

#281: promote irregex to full unit
-----------------------------------------------------------------------+----
 Reporter:  zbigniew                                                   |       
Owner:  felix   
     Type:  enhancement                                                |      
Status:  assigned
 Priority:  major                                                      |   
Milestone:          
Component:  core libraries                                             |     
Version:  4.5.x   
 Keywords:  regex irregex movin-on-up to-the-east-side deluxe-apt sky  |  
-----------------------------------------------------------------------+----
Changes (by felix):

 * cc: felix (removed)
 * cc: ashinn (added)
  * owner:  => felix
  * priority:  minor => major
  * status:  new => assigned
  * milestone:  4.6.0 =>


Comment:

 Replying to [comment:3 zbigniew]:
 >
 > 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.

 Ok. I accept that the API is much better. But then we should go the whole
 way, and deprecate (and much later remove) the old regex API.

 > 1. If irregex becomes an extension, how can a core unit (regex) depend
 on it?

 I meant the irregex module. It would still be there, but the import
 library could be available seperately. Just to suggest that it is
 optional. Probably silly, well.

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

 Yes. I was not suggesting that. The current regexp API is nothing to be
 proud of and there is no need to put more work into it.

 > 3. Must any replacement engine guarantee SRE support?

 Yes.

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

 I think the best option is to add irregex as a unit, as you suggested,
 deprecate (but keep) the regex API, move extra-functionality into other
 units, add the irregex documentation to the manual and upgrade irregex to
 a newer version. This will make irregex a crucial component of chicken.

 I also will start working on optimizing it.

 I could use help with some of these things.

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