Daniel Hartwig <mand...@gmail.com> writes:
> On 19 September 2012 03:59, Chris K. Jester-Young <cky...@gmail.com> wrote:
>> (define* (regexp-split pat str #:optional (limit 0))
>> […]
>> (reverse (if (zero? limit)
>> (drop-while string-null? final)
>> final))))
>>
>
> Please simplify this limit arg, removing the maybe-drop-empty-strings
> behaviour. Either positive limit or #f for all matches. It is
> trivial for the caller to remove the empty strings if desired, and
> simplifies the docs for regexp-split. Matching perl semantics is not
> necessarily desirable.
FWIW, I agree with Daniel. I dislike the complicated semantics of this
'limit' argument, which combines into a single number two different
concepts:
* What limiting mode to use:
[A] return 'limit' many fields at most
[B] return all fields
[C] return all fields except trailing blank fields
* How many fields, if using limiting mode [A].
Beyond matters of taste, I don't like this because it makes bugs less
likely to be caught. Suppose 'limit' is a computed value, normally
expected to be positive. Code that follows may implicitly assume that
the returned list has no more than 'limit' elements. Now suppose that
due to a bug or exceptional circumstance, the computed 'limit' ends up
being less than 1. Now 'regexp-split' switches to a qualitatively
different mode of behavior.
I'd prefer for a numeric limit to be interpreted in a uniform way. That
suggests that a non-positive 'limit' should raise an exception.
Limiting modes [B] and [C] could be indicated in a few different ways.
One possibility would be to pass special symbol values for the 'limit'
argument to indicate these two other modes.
Another possibility is to add a 'drop-right-while' procedure (analogous
to SRFI-1's 'drop-while'), and then users who want this could do:
(drop-right-while string-null?
(regexp-split ...))
Regards,
Mark
