From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: Identifying what's usable in installed headers [was Re: RFC: Foreign objects facility] Date: Tue, 29 Apr 2014 20:33:39 +0200 Message-ID: <878uqougsc.fsf@pobox.com> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1398796445 31452 80.91.229.3 (29 Apr 2014 18:34:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Apr 2014 18:34:05 +0000 (UTC) Cc: guile-devel To: Doug Evans Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Apr 29 20:34:00 2014 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WfCqt-0008Ml-Hd for guile-devel@m.gmane.org; Tue, 29 Apr 2014 20:33:59 +0200 Original-Received: from localhost ([::1]:51800 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfCqt-0006JG-4X for guile-devel@m.gmane.org; Tue, 29 Apr 2014 14:33:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfCqn-0006J7-CD for guile-devel@gnu.org; Tue, 29 Apr 2014 14:33:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WfCqg-0004bF-8x for guile-devel@gnu.org; Tue, 29 Apr 2014 14:33:53 -0400 Original-Received: from a-pb-sasl-quonix.pobox.com ([208.72.237.25]:49692 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfCqg-0004b4-4f for guile-devel@gnu.org; Tue, 29 Apr 2014 14:33:46 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 9E1571058A; Tue, 29 Apr 2014 14:33:45 -0400 (EDT) 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=RLdemrCWYdJZmpO3l0UXNrcDX9c=; b=c7hyjj CuK6Rdzu3oHP7UF3fnxCyVbacLXPoboEN1d1Q9iwNArRv1/lXXuMFi3AFm7IFKSh eBIpRQlKp3o7bMnfezHFB/5nedjG/IxOOaWZmjJlnh4DYc0WrYOTLiXsJTRftPgL +ZbwxHkrLIqWnN2/mg2uOl+YbHofg/qxBUo+Y= 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=MR2VX0SEmwexL2GsrX2l1vcrXE/w7B+1 fm7Xwidban+0UXymk1pwwCi9mtyDNIR2D2cZ8CgIR+waspNYB8DCOFlY39GuUUSa RwBk0cPsFgaR5xbVlSYBucWzS6pjnGR+6Z6J3vL7Zd3hO7Ib8K2zVP140N09PilU +7jkQAaAYPo= Original-Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 910DB10589; Tue, 29 Apr 2014 14:33:45 -0400 (EDT) Original-Received: from badger (unknown [88.160.190.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id A7B7510588; Tue, 29 Apr 2014 14:33:42 -0400 (EDT) In-Reply-To: (Doug Evans's message of "Tue, 29 Apr 2014 09:33:04 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Pobox-Relay-ID: CA823646-CFCC-11E3-BA10-6F330E5B5709-02397024!a-pb-sasl-quonix.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 208.72.237.25 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17119 Archived-At: Hi! On Tue 29 Apr 2014 18:33, Doug Evans writes: > On Sun, Apr 27, 2014 at 6:17 AM, Andy Wingo wrote: >> >> [...] >> 7) There is legacy code out there that uses e.g. SCM_SETCDR to set >> smob fields. (This is terrible, but it exists: >> https://github.com/search?q=SCM_SETCDR+smob&ref=cmdform&type=Code >> for an example.) (This SMOB case is egregious because the smob is being accessed with pair macros -- using macros is fine of course.) > While function declarations are markable as being internal/external in > published headers (SCM_INTERNAL vs SCM_API), macros are not. > IWBN to solve this problem for macros too. If it's in a header and a > user can get it to work, s/he may just use it - some macros are indeed > usable, so how does one easily know while reading headers (users will > do that a lot) which are legitimately usable and which are not? One can guard macros in #ifdef BUILDING_LIBGUILE, and it's possible to deprecate them as well by #defining them to invoke SCM_DEPRECATED functions. So in short, as a user, you would know if we wanted to deprecate something, and anything that's there is fair game, technically. So that's the minimum API stability barrier. The higher barrier is appearing in the documentation. > [P.S. I'm not sure if SCM_SETCDR is still intended to be usable, I > wouldn't mind deprecating it, and only publishing the function > versions. I can imagine it being ubiquitous enough in existing code > that that's not possible, even if one wanted to. At any rate that's a > separate discussion. Its presence in the foreign object discussion > just reminded me of macros in headers.] This might be a good idea. Of course deprecation churn is still unpleasant, so it would have to be a case of actively getting in the way of some other Guile hacking before SCM_SETCDR could be deprecated in favor of the (inline) function versions. Cheers, Andy -- http://wingolog.org/