guile-user
[Top][All Lists]
Advanced

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

Re: Core Guile bindings


From: Andy Wingo
Subject: Re: Core Guile bindings
Date: Sun, 26 Feb 2017 19:30:39 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

On Wed 12 Oct 2016 20:18, Panicz Maciej Godek <address@hidden> 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



reply via email to

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