[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Core Guile bindings,
Andy Wingo <=