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