Re: [Chicken-hackers] [PATH] fix for srfi-13 string-trim-right start parameter

[Alex Shinn]

On Sat, Jan 11, 2014 at 2:04 PM, John Cowan <address@hidden> wrote:

Mario Domenech Goulart scripsit:

> As as I understand it, (string-trim-right "abc  " char-whitespace? 1)
> should trim "bc  ", not that it should trim "abc  " then substring it
> from 1.

That's correct, but in fact what's happening here is that the
reference version is effectively ignoring the start argument altogether.
The code figures out where the new right end should be and then returns
a substring; unfortunately, the start argument passed to substring is
always 0.  The patch changes it to start, which eliminates this bug.

FWIW Mario's interpretation would also require the start

argument to be used, but in a different way - the trimming

would have to be restricted to characters after the start:

  (string-trim-right "abc    " char-whitespace? 4) => "abc "

Presumably for the trim to be a trim and not a splice of

some sort, it would always truncate past end:

  (string-trim-right "abc    def" char-whitespace? 4 6) => "abc "

The only thing to conclude is that the ref impl is buggy,

and the spec ambiguous, but it does not directly follow

which fix is correct.

I think the API looks like a premature optimization.

I can see the argument for start/end args to avoid

consing in certain procedures, but you're consing

regardless here, and the semantics is overly confusing.

Anyway, I don't have much of a preference, but I

think the literal interpretation of "restrict [...] action

to the indicated substring" implies what Mario expects,

and is also more useful since it can't be duplicated just

by taking a substring first.  On the other hand, it's more

confusing.

-- 

Alex