From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.user Subject: Re: Core Guile bindings Date: Sun, 26 Feb 2017 19:30:39 +0100 Message-ID: <87fuj0u7n4.fsf@pobox.com> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1488133885 22829 195.159.176.226 (26 Feb 2017 18:31:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Feb 2017 18:31:25 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: "guile-user@gnu.org" To: Panicz Maciej Godek Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Feb 26 19:31:19 2017 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ci3bJ-0004kg-Oj for guile-user@m.gmane.org; Sun, 26 Feb 2017 19:31:17 +0100 Original-Received: from localhost ([::1]:47843 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ci3bK-00013s-FC for guile-user@m.gmane.org; Sun, 26 Feb 2017 13:31:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33883) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ci3au-00013m-F0 for guile-user@gnu.org; Sun, 26 Feb 2017 13:30:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ci3ar-0005EY-A7 for guile-user@gnu.org; Sun, 26 Feb 2017 13:30:52 -0500 Original-Received: from pb-sasl1.pobox.com ([64.147.108.66]:52851 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ci3ar-0005EU-6P for guile-user@gnu.org; Sun, 26 Feb 2017 13:30:49 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 8660260AE1; Sun, 26 Feb 2017 13:30:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=T2WAEy3xvnjPWc/tAn8vy3wM8xM=; b=wKtKbq 2C+UAdkm8xgA8vEtttp2RruB36UvM57MDjQ1CCsibNdeihb0kzibYOjLM4LI14Sh 86d/yGVxdC15g5nqLcL7Cs530xCsHC1/kwgM7Tx2BXDnpbpBRBseJ4Mp/bQZaG+m AVRSsJCDVQsolLp3K/6mKVf2E1Yc0ek65WlSg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=JPCPj3ySDuwvtZ8g+/mKlgi4BL9yEfnm CKgd2MolkzREmQ9WBNOUpjSuJNDUzKeJIX1Pzc/DB59/v5N/LOtMOFtdjHI4xVoS r6beNVllX4RXPH091un6O3lIHMUtZ2yeRQvLUJ6uX+K2MwRG6bOxSNJrpucZEJZd S+7pYkEyGfM= Original-Received: from pb-sasl1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 7DBBC60AE0; Sun, 26 Feb 2017 13:30:48 -0500 (EST) Original-Received: from clucks (unknown [88.160.190.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl1.pobox.com (Postfix) with ESMTPSA id 7061E60ADE; Sun, 26 Feb 2017 13:30:47 -0500 (EST) In-Reply-To: (Panicz Maciej Godek's message of "Wed, 12 Oct 2016 20:18:41 +0200") X-Pobox-Relay-ID: B12BE9EE-FC51-11E6-960F-CDEC6462E9F6-02397024!pb-sasl1.pobox.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 64.147.108.66 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:13323 Archived-At: On Wed 12 Oct 2016 20:18, Panicz Maciej Godek 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