Re: [Chicken-users] New string manipulation module
Fellow Chicken advocates, I'm pleased to announce that the string manipulation egg, now titled s, is available with chicken-install. Thanks again to all those who helped familiarize me with the Chicken way of doing things. And thanks to those unnamed people on IRC that helped with countless newbie questions. It seems that the Chicken community has lived up to its reputation of being friendly and welcoming. Consider me an advocate for both the language and the community from this point forward. Documentation for the egg is available at: http://wiki.call-cc.org/eggref/4/s The source is maintained on github at: https://github.com/n3mo/s Cheers! Nicholas ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
On Wed, Feb 20, 2013 at 1:24 PM, Dan Leslie d...@ironoxide.ca wrote: Nice work, contributions are greatly appreciated. :) Since you're asking for constructive feedback, two things come to mind: It's a matter of taste, but IMHO it's schemier that *descriptive-variable*is preferable to *desc-var*, so in your case *s-foo* could easily be *string-foo*. However, I would drop the prefix altogether, as Chicken supports renaming on import. So *string-foo* would become *foo* and any prefixing is left up to the user of your library. I'm not certain what you intended by 'official', but if you meant that you'd like to see it packaged with Chicken then perhaps you should consider switching the license to Chicken's license. Mind you, GPL3 eggs are happily accepted, but note that many folks won't touch them for various reasons. However, if this is a port of an elisp library then likely re-licensing is not an option. I would love to package this under the BSD license, but as far as my limited knowledge is concerned, it seems that I must keep the GPL3 license of the original elisp package. If someone is aware of an alternative solution, please speak up and I'll change things accordingly. Anyhow, thanks for the hard work and the contribution! And welcome to Chicken-land, come join us on IRC if you get a chance. Thanks! It's been a joy working with the chicken community so far :) - Nick ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
On Feb 20 2013, Mario Domenech Goulart wrote: 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? I'd disagree. I feel that using the (personally *much* appreciated) rename feature chicken provides to disambiguate at the users choice would be the best way to deal with this kind of matter. Adding this simple statement doesn't make much of a difference to your source code. However *not* having the feature at hand and have to rename all identifiers manually when you want to exchange one implementation for another is a real burden. I've been in this situation often enough. My boiler-plate solution is to create yet another module which imports all of the prefixed (in this case this would be the s- prefixed stuff), bind them to the names sans prefix and export again. Then ipon import rename as god intended. This makes a yet another file to maintain as trade off for a single s-expression containing three symbols… add1 (except if there is an `exchange' procedure in the API). :-) Mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
Jörg F. Wittenberger scripsit: I've been in this situation often enough. My boiler-plate solution is to create yet another module which imports all of the prefixed (in this case this would be the s- prefixed stuff), bind them to the names sans prefix and export again. Then ipon import rename as god intended. I've proposed a new type of import specifier to go with prefix, namely drop-prefix. Rather than prefixing all names, this removes the prefix from any names that have it. This would be a Good Thing to add to Chicken; Chibi already has it, and it is part of a proposal for R7RS-large. -- Why are well-meaning Westerners so concerned that John Cowan the opening of a Colonel Sanders in Beijing means co...@ccil.org the end of Chinese culture? [...] We have had http://www.ccil.org/~cowan Chinese restaurants in America for over a century, and it hasn't made us Chinese. On the contrary, we obliged the Chinese to invent chop suey.--Marshall Sahlins ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
I've proposed a new type of import specifier to go with prefix, namely drop-prefix. Rather than prefixing all names, this removes the prefix from any names that have it. This would be a Good Thing to add to Chicken; Chibi already has it, and it is part of a proposal for R7RS-large. That would be incredibly handy. -Dan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
On Feb 21, 2013, at 1:50 PM, Jörg F. Wittenberger wrote: On Feb 20 2013, Mario Domenech Goulart [well, actually, I, Jim] wrote: 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? I'd disagree. I feel that using the (personally *much* appreciated) rename feature chicken provides to disambiguate at the users choice would be the best way to deal with this kind of matter. You're totally free to do so, it seems there is no one right answer, and my opinion has changed even between eggs. Adding this simple statement doesn't make much of a difference to your source code. However *not* having the feature at hand and have to rename all identifiers manually when you want to exchange one implementation for another is a real burden. In this case the implementation is essentially of the s.el API, not a generic strings library, and so an alternate implementation of the API could just as easily be prefixed s-* to indicate the s.el API with different underlying code. Jim ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
On Feb 21, 2013, at 2:04 PM, John Cowan wrote: I've proposed a new type of import specifier to go with prefix, namely drop-prefix. Rather than prefixing all names, this removes the prefix from any names that have it. This would be a Good Thing to add to Chicken; Chibi already has it, and it is part of a proposal for R7RS-large. I think regex rename would be more general. Jim ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
On Feb 21 2013, Mario Domenech Goulart wrote: On 21 Feb 2013 20:50:16 +0100 Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: On Feb 20 2013, Mario Domenech Goulart wrote: 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? I'd disagree. Notice that what you quoted was not written by me. Sorry. Dunno how that happend. Currently I'm typing half-blind. Awaiting cataract surgery in a few weeks. Best wishes. Mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
Jim Ursetto scripsit: I've proposed a new type of import specifier to go with prefix, namely drop-prefix. Rather than prefixing all names, this removes the prefix from any names that have it. This would be a Good Thing to add to Chicken; Chibi already has it, and it is part of a proposal for R7RS-large. I think regex rename would be more general. Of course it would, and the Perl substitute command would be more general still. For that matter, you could allow an arbitrary Scheme procedure to be provided. But drop-prefix is dead simple, has precedent, and is easy to understand and use. -- John Cowan http://www.ccil.org/~cowan co...@ccil.org The native charset of SMS messages supports English, French, mainland Scandinavian languages, German, Italian, Spanish with no accents, and GREEK SHOUTING. Everything else has to be Unicode, which means you get only 70 16-bit characters in a text instead of 160 7-bit characters. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
Dan Leslie scripsit: Of course it would, and the Perl substitute command would be more general still. For that matter, you could allow an arbitrary Scheme procedure to be provided. But drop-prefix is dead simple, has precedent, and is easy to understand and use. Why not have both? Okay, let's do it backwards. No precedent. Harder to implement. Harder to document. Harder to use. Ticket #988 filed for drop-prefix. Feel free to file your own ticket or prepare your own patch. -- We are lost, lost. No name, no business, no Precious, nothing. Only empty. Only hungry: yes, we are hungry. A few little fishes, nassty bony little fishes, for a poor creature, and they say death. So wise they are; so just, so very just. --Gollumco...@ccil.org http://ccil.org/~cowan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
Of course it would, and the Perl substitute command would be more general still. For that matter, you could allow an arbitrary Scheme procedure to be provided. But drop-prefix is dead simple, has precedent, and is easy to understand and use. Why not have both? -Dan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
On 2/21/13 9:55 AM, Nicholas Van Horn wrote: On Wed, Feb 20, 2013 at 1:24 PM, Dan Leslie d...@ironoxide.ca mailto:d...@ironoxide.ca wrote: I'm not certain what you intended by 'official', but if you meant that you'd like to see it packaged with Chicken then perhaps you should consider switching the license to Chicken's license. Mind you, GPL3 eggs are happily accepted, but note that many folks won't touch them for various reasons. However, if this is a port of an elisp library then likely re-licensing is not an option. I would love to package this under the BSD license, but as far as my limited knowledge is concerned, it seems that I must keep the GPL3 license of the original elisp package. If someone is aware of an alternative solution, please speak up and I'll change things accordingly. I am not a lawyer, what follows is not legal advice, etc. ... It's possible to change the license by clean room reverse engineering the library, since the new code would (from a legal standpoint) not be a copy or derivative of the original code. To do that: someone who has not seen any of the contaminated source code (i.e. the original library or your port) reimplements the library from scratch based only on a general description of the original library's API and behavior, (e.g. your README file). Then, they can attach any license they wish to the new code. This approach is typically used to reverse engineer proprietary software, for example to create an open source clone. But there's no reason it couldn't be used to create a clone of another open source library with a different license. The downside is that it might be considered rude or disrespectful by some people in the open source community, especially if you use the exact same library name and function names as the original. On the other hand, this library is so simple and obvious that I think it would be very silly for anyone to be offended by it being cloned. - John ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] New string manipulation module
I'm new to Chicken (and scheme for that matter), but I'm eager to contribute. I've been working on several text processing projects for which I've ported an Emacs-lisp string manipulation library to Chicken. The strings module provides many convenient string manipulation procedures (including new procedures not ported from the original elisp library). Each procedure is documented with examples. Beyond their immediate convenience, (I think) they present the user with a consistent API for working with strings. I am eager to share this as an official egg, but being new to scheme I have likely violated common practices. I share the preliminary module here in the hopes that someone will find it useful. I welcome any feedback with respect to changes in implementation/behavior, as well as missing functionality that you would like to see added. The module is packaged to be distributed as an egg, but it is currently only available at: https://github.com/n3mo/strings Thanks, Nicholas Van Horn ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
Nice work, contributions are greatly appreciated. :) Since you're asking for constructive feedback, two things come to mind: It's a matter of taste, but IMHO it's schemier that /descriptive-variable/ is preferable to /desc-var/, so in your case /s-foo/ could easily be /string-foo/. However, I would drop the prefix altogether, as Chicken supports renaming on import. So /string-foo/ would become /foo/ and any prefixing is left up to the user of your library. I'm not certain what you intended by 'official', but if you meant that you'd like to see it packaged with Chicken then perhaps you should consider switching the license to Chicken's license. Mind you, GPL3 eggs are happily accepted, but note that many folks won't touch them for various reasons. However, if this is a port of an elisp library then likely re-licensing is not an option. Anyhow, thanks for the hard work and the contribution! And welcome to Chicken-land, come join us on IRC if you get a chance. Thanks, -Dan On 2/20/2013 9:36 AM, Nicholas Van Horn wrote: I'm new to Chicken (and scheme for that matter), but I'm eager to contribute. I've been working on several text processing projects for which I've ported an Emacs-lisp string manipulation library to Chicken. The strings module provides many convenient string manipulation procedures (including new procedures not ported from the original elisp library). Each procedure is documented with examples. Beyond their immediate convenience, (I think) they present the user with a consistent API for working with strings. I am eager to share this as an official egg, but being new to scheme I have likely violated common practices. I share the preliminary module here in the hopes that someone will find it useful. I welcome any feedback with respect to changes in implementation/behavior, as well as missing functionality that you would like to see added. The module is packaged to be distributed as an egg, but it is currently only available at: https://github.com/n3mo/strings Thanks, Nicholas Van Horn ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
Hi Nicholas, On Wed, 20 Feb 2013 12:36:22 -0500 Nicholas Van Horn vanhorn...@gmail.com wrote: I'm new to Chicken (and scheme for that matter), but I'm eager to contribute. I've been working on several text processing projects for which I've ported an Emacs-lisp string manipulation library to Chicken. The strings module provides many convenient string manipulation procedures (including new procedures not ported from the original elisp library). Each procedure is documented with examples. Beyond their immediate convenience, (I think) they present the user with a consistent API for working with strings. I am eager to share this as an official egg, but being new to scheme I have likely violated common practices. I share the preliminary module here in the hopes that someone will find it useful. I welcome any feedback with respect to changes in implementation/behavior, as well as missing functionality that you would like to see added. The module is packaged to be distributed as an egg, but it is currently only available at: https://github.com/n3mo/strings Very nice. Thanks for sharing. I really think you should make it available as an egg. Although s may not sound very appealing to users who already know the srfi-13 API, it can still be useful for newcomers that know s and want to get started on Scheme (or port some code for it) or even for those Scheme users that for some reason don't like the API provided by srfi-13. Some random comments: * procedures from the data-structures unit are usually faster than the similar ones ones from srfi-13 (some of them provide similar features). For example, I'd implement s-starts-with? using data-structures' substring-index[-ci] instead of srfi-13's string-prefix[-ci]?, or string-chomp for s-chop-suffix. * maybe drop the dependency on the regex egg and use the built-in unit irregex? * if you intend to publish your code as an egg, it would be nice to have the documentation in the Chicken Wiki format, so it can be indexed by chickadee (http://api.call-cc.org). Best wishes. Mario -- http://parenteses.org/mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
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 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? Ultimately, since there are no official guidelines for naming, it's up to you and your users. Jim On Feb 20, 2013, at 11:36 AM, Nicholas Van Horn wrote: I'm new to Chicken (and scheme for that matter), but I'm eager to contribute. I've been working on several text processing projects for which I've ported an Emacs-lisp string manipulation library to Chicken. The strings module provides many convenient string manipulation procedures (including new procedures not ported from the original elisp library). Each procedure is documented with examples. Beyond their immediate convenience, (I think) they present the user with a consistent API for working with strings. I am eager to share this as an official egg, but being new to scheme I have likely violated common practices. I share the preliminary module here in the hopes that someone will find it useful. I welcome any feedback with respect to changes in implementation/behavior, as well as missing functionality that you would like to see added. The module is packaged to be distributed as an egg, but it is currently only available at: https://github.com/n3mo/strings Thanks, Nicholas Van Horn ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
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
