Re: regexp-split for Guile

[Mark H Weaver]

Daniel Hartwig <address@hidden> writes:
> On 19 September 2012 03:59, Chris K. Jester-Young <address@hidden> 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