[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Towards De-icing ice-9 modules.

From: Taylan Ulrich Bayırlı/Kammer
Subject: Re: Towards De-icing ice-9 modules.
Date: Sat, 13 Feb 2016 09:51:28 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]