Comments on SRFI 135 draft 2 Sudarshan S Chawathe (14 Jun 2016 01:24 UTC)
Re: Comments on SRFI 135 draft 2 William D Clinger (14 Jun 2016 13:14 UTC)
Re: Comments on SRFI 135 draft 2 John Cowan (15 Jun 2016 00:48 UTC)

Comments on SRFI 135 draft 2 Sudarshan S Chawathe 14 Jun 2016 01:24 UTC

Here are some minor comments on SRFI 135 Draft #2 (2016/6/11).  A
couple of items, marked '(fixed?)', are probably fixed now based on
recent messages.

  * textual-any: I am not sure if the description guarantees that
    textual-any will stop evaluating pred on its textual argument
    after the first time pred returns true. It seems intuitive, and
    seems implicit in the description of the return value, but perhaps
    could be made explicit.

  * textual-tabulate (and textual-count): I'm guessing the argument
    order chosen here (different from that of textual-filter) is for
    SRFI-13 and SRFI-130 compatibility (over SRFI-1 compatibility).  I
    mention it just in case that is not the intention.

  * (fixed?) The sample implementation exports text-tabulate, not
    textual-tabulate.  The name text-tabulate seems preferable because
    the returned value is always a text, not just textual.

  * (fixed?) Should textual-unfold be called text-unfold (and
    similarly for textual-unfold-right)?  (The sample implementation
    exports the textual- names.)

  * textual-length and textual-ref: I believe the description should
    read "... are generalizations of text-length and text-ref...".

  * textual-pad and textual-pad-right: Should "characters of textual"
    read "characters of textual from start to end" (or similar) given
    the (optional) start and end arguments?  Perhaps that is implied
    by some earlier text.  A similar comment applies to
    textual-trim[-right|-both].

  * text<? and friends: Are implementations encouraged to use
    compatible orderings for texts and strings (given the Note and
    Rationale paragraphs)?

  * textual-append: Should there be a guarantee of the result not
    sharing storage with any string arguments (similar to the
    guarantee for textual-concatenate)?

  * textual-concatenate-reverse: Regarding the optional final-textual,
    what is the motivation for including an 'end' argument but not a
    corresponding 'start' argument?  (I guess this is really a SRFI-13
    question.)  I suspect I'm unaware of some important idiomatic
    usage here.

Regards,

-chaw