Summary
irregex-match with `look-ahead` doesn't behave like the example in the docs
Metadata
- Id: cdd9dbb0caea36994bbeb762df4ae693d4560b73
- Trac id: 1065
- Type: defect
- Reporter: evhan
- Owner:
- Cc:
- Status: closed
- Component: core libraries
- Estimated difficulty:
- Resolution: fixed
- Priority: major
- Milestone: 4.9.0
- Version: 4.8.x
- Changetime: 2013-11-16 13:23:33 UTC
- Created: 2013-11-16 06:02:33 UTC
- Keywords: irregex
Description
The docs for the irregex unit give the following example:
(irregex-match '(: "regular" (look-ahead " expression")) "regular expression") => #<match>
But that currently returns #f. This is true for irregex proper as well (tested with a handful of different Schemes).
Changes and comments
[2013-11-16 10:43:09 UTC] sjamaan changed milestone from someday to 4.9.0
[2013-11-16 10:43:09 UTC] sjamaan wrote:
To be fixed before 4.9.0
[2013-11-16 13:23:33 UTC] sjamaan changed status from new to closed
[2013-11-16 13:23:33 UTC] sjamaan set resolution to fixed
[2013-11-16 13:23:33 UTC] sjamaan wrote:
This is actually correct, and not a bug: irregex-match returns a match only if the full string matches the regex (ie, the regex is implicitly anchored at the start and end). Your regex here does a lookahead on " expression", but does not actually consume that part.
If you use irregex-search, it'll return the expected value. So this is a documentation bug; I've fixed it upstream and added a few tests for positive/negative look-ahead and look-behind, just in case :)
Found a bug in the chunk handling of look-behind while working on these tests, so thanks for that!