Panicz Maciej Godek <godek.mac...@gmail.com> writes: > 2016-02-12 21:41 GMT+01:00 Chad Albers <calb...@neomantic.com>: > > > Hi, > > > In my attempt to assist the guile project, I thought I would share > a document on a plan to migrate some of the ice-9 modules into a > more intuitive, yet to be decided, namespace. Before I proposed a > technological plan, I have begun really an audit of what ice-9 > modules are available (and undocumented), and other modules that > guile ships with. (there are some secrets down there). > > Hi, > maybe I'm on a bit conservative side, but as far as I can tell, there > is a recurring suggestion is to rename modules called (ice-9 xxx) as > (guile xxx). > While I do agree that the "ice-9" name isn't particularly intuitive, > it does provide a metaphor that grasps the idea that inspired Guile. > > Beside this little difference -- that "ice-9" might be slightly > unobvious to newcommers -- I see no cognitive advantage in that > renaming, while there is a huge disadvantage of breaking backwards > compatibility of many programs that use Guile. > > If the modification was to be meaningful, we should group modules into > logical categories -- for example, rename (ice-9 and-let-star) to > (syntax and-let*), (ice-9 threads) to (control threads) and (ice-9 > readline) to (utils readline), for instance.
I like the idea but if we do this we might want to add 'guile' in front of each (like (guile syntax and-let*), (guile control threads), etc.) since we share a namespace with RnRS libraries. > What I think would be a cooler idea is to provide a mechanism for > automatically fetching the required modules (in their required > versions) from specified git repositories, so that once a program is > written, one wouldn't have to worry about its dependecies. > > It would also be nice to have a tool that would be able to trace the > modifications in the source code to see whether it contains any > changes that could break the existing functionality compared to some > earler version. > > (this would probably be difficult to do in general, but perhaps there > are some common use cases that could be easily covered) > > Best regards, > Panicz Taylan
