Re: [Chicken-users] New string manipulation module

[Nicholas Van Horn]

Thanks for all of the great feedback. Based on the loose consensus so far, here's my plan: 

I will

* rename the module to "s" rather than "strings"
* retain the current "s-" prefix for procedures
* rewrite the documentation in Chicken Wiki format (or convert from markdown directly? One can wish...)
* re-implement using irregex rather than the regex egg
* re-implement using unit data-structures over srfi-13 where possible (thanks for this excellent performance tip-- I would never have known)
* Release the finished product as an egg. By "official", I had only meant "an egg installable by chicken-install," as opposed to "some random module on github."

Thanks again for everyone's help.
- Nick

On Wed, Feb 20, 2013 at 4:35 PM, Mario Domenech Goulart <address@hidden> wrote:

Hi,

On Wed, 20 Feb 2013 14:46:20 -0600 Jim Ursetto <address@hidden> wrote:

> I think it sounds good as an official egg; although there's a lot of
> overlap with SRFI-13 it's not bad to have another API.
>
> The main thing I'd suggest if making it official is that, as a port
> of the s library, to name it something like "s" or "s-strings"
> instead of "strings", since the latter sounds like it would be the
> de-facto strings library for chicken.  By convention as a port of
> s.el I think "s" is the most appropriate name.  But I'm not sure if
> anyone else would agree.  (Just don't name it "slib"!)

I agree.

> I also think it's ok to keep the explicit s- prefix on your
> procedures.  Although Chicken does support module prefixing, having
> procedures like "join", "matches?", "equals?" and "match" in the
> first place is not very descriptive, and may conflict with
> commonly-used names.  However, "titlecase" is immediately obvious.
>  One option is to disambiguate the names, like "string-join" or
> "join-strings", and "string-match" or "match-string".  Another is to
> keep the s- prefix, which is a natural grouping.  Or you could
> require the user to prefix on import, but if that's always needed due
> to conflicts, why make them go through the extra step?

add1 (except if there is an `exchange' procedure in the API). :-)

Mario
--
http://parenteses.org/mario