chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Using irregex safely & responsibly


From: Alex Shinn
Subject: Re: [Chicken-users] Using irregex safely & responsibly
Date: Mon, 11 Oct 2010 13:17:49 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (darwin)

Jim Ursetto <address@hidden> writes:

> There is some inconsistency in the docs:
>
> irregex-match-num-submatches: Returns the number of numbered
> submatches that are defined in the
> irregex or match object.
> irregex-match-valid-index?: Returns {{#t}} iff the {{index-or-name}}
> named submatch or index is defined in the {{match}} object.
>
> But below, *-valid-index? says undefined when *-num-submatches says defined:

Not quite, *-valid-index? says "invalid", not "undefined".

*-num-submatches just tells you the total number of
submatches that are defined in the regexp, regardless of
what has been matched, and irregex-match-num-submatches on a
match result will always return the same result as
irregex-num-submatches on the corresponding regexp.

> The valid-index? predicate does not return a boolean #t value:
>
> #;9> (irregex-match-valid-index? m 3)
> 0

It returns #t for this in the upstream irregex.

> I prefer the old behavior for consistency because if irregex tells me
> that 3 submatches exist, I expect to be able to access them without an
> exception being thrown.

*-valid-index? just states whether the submatch _may_ exist.

We could add a utility irregex-match-matched-index? to test
if a specific index was successfully matched.

An index which could never be a valid submatch should
arguably always throw an error.

An index which is valid, but failed to match, could either
throw an error or return #f.  The -index and -substring
operations are inconsistent in this respect, so we should
fix that.

It may be good to provide both sets, with a /default version
analogous to SRFI-69 hash-table-ref and
hash-table-ref/default:

  (irregex-match-substring <m> <invalid-i>)    => error
  (irregex-match-substring <m> <unmatched-i>)  => error

  (irregex-match-substring/default <m> <invalid-i> #f)    => error
  (irregex-match-substring/default <m> <unmatched-i> #f)  => #f

Thoughts?

-- 
Alex



reply via email to

[Prev in Thread] Current Thread [Next in Thread]