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 < mario.goul...@gmail.com> wrote: > Hi, > > On Wed, 20 Feb 2013 14:46:20 -0600 Jim Ursetto <zbignie...@gmail.com> > 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 >
_______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
