From: taylanbayirli@gmail.com (Taylan Ulrich Bayırlı/Kammer)
To: Panicz Maciej Godek <godek.maciek@gmail.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: Towards De-icing ice-9 modules.
Date: Sat, 13 Feb 2016 09:51:28 +0100 [thread overview]
Message-ID: <87y4aphu27.fsf@T420.taylan> (raw)
In-Reply-To: <CAMFYt2YjK-kGBkPAodkZrmzr-iRxoXxaBzxVR11t6PCwOVpq2g@mail.gmail.com> (Panicz Maciej Godek's message of "Fri, 12 Feb 2016 22:35:38 +0100")
Panicz Maciej Godek <godek.maciek@gmail.com> writes:
> 2016-02-12 21:41 GMT+01:00 Chad Albers <calbers@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
prev parent reply other threads:[~2016-02-13 8:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-12 20:41 Towards De-icing ice-9 modules Chad Albers
2016-02-12 21:14 ` Christopher Allan Webber
2016-02-12 21:18 ` Mark H Weaver
2016-02-12 21:37 ` Chad Albers
2016-02-12 21:57 ` Mark H Weaver
2016-02-12 22:09 ` Chad Albers
2016-02-13 3:04 ` Mark H Weaver
2016-02-12 21:35 ` Panicz Maciej Godek
2016-02-13 8:51 ` Taylan Ulrich Bayırlı/Kammer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y4aphu27.fsf@T420.taylan \
--to=taylanbayirli@gmail.com \
--cc=godek.maciek@gmail.com \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).