Re: Towards De-icing ice-9 modules.

[Taylan Ulrich Bayırlı/Kammer]

Panicz Maciej Godek <address@hidden> writes:

> 2016-02-12 21:41 GMT+01:00 Chad Albers <address@hidden>:
>
>     
>     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