Re: Core Guile bindings

[Andy Wingo <wingo@pobox.com>]

On Wed 12 Oct 2016 20:18, Panicz Maciej Godek <godek.maciek@gmail.com> writes:

> I've noticed that Guile core contains some bindings that shouldn't
> necessarily be globally available. In particular, it provides a set of
> socket-related functions with very general names, such as "select" or
> "bind", that some programmers may want to use for their own purposes.
>
> It is obvious that those functions should not be a part of the core, and
> should be moved to some separate module, and so I wanted to ask whether
> there are any plans for doing so?

Besides everything that everyone said -- I actually think that it *is*
possible to migrate bindings over time.  In 2.2 I have moved the threads
exports (current-thread, call-with-new-thread, lock-mutex, etc) to
(ice-9 threads).  However when built with deprecated code (the default),
we also export these bindings in (guile).  They cause a deprecation
warning if you use them, telling you to change your program to
explicitly use (ice-9 threads).  So migration of this kind is possible;
even within the 2.2 series more code can be put into modules.

That said while I think reducing the set of default bindings is a good
it is not without tradeoffs.  Modularizing guile's core bindings isn't
really an active development focus.

Of course there are mitigations as well also; defining "select" in your
module works just fine, exporting it works fine, and users can resolve
the conflicts if needed.  You also have #:replace if you think that your
module should be the one making that decision.

Andy