Email list hosting service & mailing list manager

The rest of the issues I found: Jim Rees (24 Feb 2016 17:48 UTC)
Re: The rest of the issues I found: Alex Shinn (29 Feb 2016 04:10 UTC)
Re: The rest of the issues I found: Jim Rees (29 Feb 2016 15:25 UTC)
Re: The rest of the issues I found: Jim Rees (29 Feb 2016 15:25 UTC)
Re: The rest of the issues I found: Alex Shinn (13 Mar 2016 07:37 UTC)
Re: The rest of the issues I found: Jim Rees (13 Mar 2016 15:17 UTC)

Re: The rest of the issues I found: Alex Shinn 29 Feb 2016 04:07 UTC

On Thu, Feb 25, 2016 at 2:35 AM, Jim Rees <xxxxxx@gmail.com> wrote:
>
>    - my first preference would be to return #f for consistency with prior
> Scheme practice.  It's
>      also so much easier to type "(if found ...)" than "(if (string-cursor<?
> string found
>      (string-cursor-end string)) ...)"  It is cumbersome to have to invoke a
> 3-argument procedure call to
>      process the result when testing a boolean comes for free.

Returning a cursor avoids type punning and has several
useful common idioms such as:

  (define (url-sans-tag url)
    (substring url 0 (string-find url #\#)))

In many cases you do just want to check existence, though,
for which case chibi provides `string-find?'.

If you want to check both, we could add a shortcut for checking
less than end:

  (string-cursor-valid? str cursor)

>    - There's some logic to returning where the cursor landed after deciding
> that the iterative
>      search has failed, so when searching the whole string, returning the
> post-end or pre-begin
>      cursor makes some sense.  But when searching a sub-range from START to
> END, this logic would
>      dictate returning END or (string-cursor-prev START) on not-found.  But
> this doc requires
>      returning the post-end or pre-begin cursor of the entire string
> instead.

This is what chibi does.

>   "If separator is an empty string, then the returned list contains a list
> of strings, each of which
>   contains a single character".  Does this mode make use of the LIMIT
> argument as well? The wording
>   and placement suggests it might bypass LIMIT's functionality, though it
> would be reasonable that
>   "hello" with limit 2 ==> ("h" "e" "llo").

I think this should obey LIMIT.

--
Alex