Re: Comments William D Clinger (07 Jun 2016 15:02 UTC)
Re: Comments John Cowan (07 Jun 2016 16:04 UTC)

Re: Comments William D Clinger 07 Jun 2016 13:45 UTC

Takashi Kato wrote:

> I have couple of minor comments for the SRFI.

Thank you.

> - Shouldn't text->utf16 and utf16->text accept/require endian? Or at least
>   specify which endian it returns?

Yes.  That's the fourth bullet item in the issues.

> - Most of the procedures accept textual object but names start text. I found
>   this a bit confusing since if procedures start type- prefix, usually they
>   take that type of objects.

All of the procedures that accept either a text or a string
could be renamed from text-* to textual-*.  That's an easy
change, but we should make that change in the next draft if
we're going to do it.  So I'd appreciate it if people would
weigh in on whether they'd prefer a consistent textual-* to
the current names.

> - Shouldn't text-index-right, text-skip, and text-skip-right return idx
>   instead of k? Or should text-index return k since Rationale says it may
>   return invalid index of the textual object?

The entry for text-index should say it returns k, not idx.
Thank you for spotting that.

> - Why text-index, text-index-right, text-skip, and text-skip-right return
>   only idx or k? Shouldn't they return idx-or-false like corresponding SRFI-13
>   procedures?

SRFI 130 broke with SRFI 13 on this, so SRFI 135 can't be
consistent with both SRFI 13 and with SRFI 130.  I chose
consistency with SRFI 130, but that may have been a wrong
choice.  Now that I think about it, I suspect that choice
was made in SRFI 130 because returning the end cursor on
failure is a cheap way to compute the end cursor as a
by-product of the search.

Personally, I prefer idx-or-false as in SRFI 13.  I'll add
that as an issue.

> - It might be even more convenient if text-concatenate-reverse also takes
>   start argument.

The arguments for text-concatenate-reverse, taken from SRFI
130, are already pretty funky.  I'm inclined to resist making
this change unless there's a compelling use case, which I'm
not seeing at the moment.

> - On references, both R6RS libraries and rationale don't have space. (I first
>   saw Srationale.) It might be more friendly if there's space in between.

Right.  I've fixed that in my local copy so it will go into
the next draft.

Will