From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Re: Guile foreign object interface Date: Tue, 07 Mar 2017 21:02:53 +0100 Message-ID: <877f40svma.fsf@gnu.org> References: <1644439317.409814.1488469678720.ref@mail.yahoo.com> <1644439317.409814.1488469678720@mail.yahoo.com> <87shmpcibe.fsf@gnu.org> <87r32988we.fsf@pobox.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1488916994 24310 195.159.176.226 (7 Mar 2017 20:03:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 7 Mar 2017 20:03:14 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: guile-user@gnu.org, guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Mar 07 21:03:08 2017 Return-path: Envelope-to: guile-devel@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 1clLK4-0005IW-Ht for guile-devel@m.gmane.org; Tue, 07 Mar 2017 21:03:04 +0100 Original-Received: from localhost ([::1]:52434 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clLKA-000173-Fu for guile-devel@m.gmane.org; Tue, 07 Mar 2017 15:03:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clLK3-00014i-6b for guile-devel@gnu.org; Tue, 07 Mar 2017 15:03:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1clLK1-0007Yr-LL for guile-devel@gnu.org; Tue, 07 Mar 2017 15:03:03 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clLJw-0007Xr-VM; Tue, 07 Mar 2017 15:02:57 -0500 Original-Received: from reverse-83.fdn.fr ([80.67.176.83]:35312 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1clLJw-0004Yy-1L; Tue, 07 Mar 2017 15:02:56 -0500 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 17 =?utf-8?Q?Vent=C3=B4se?= an 225 de la =?utf-8?Q?R?= =?utf-8?Q?=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <87r32988we.fsf@pobox.com> (Andy Wingo's message of "Tue, 07 Mar 2017 15:21:37 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.lisp.guile.devel:18997 gmane.lisp.guile.user:13445 Archived-At: Howdy! Andy Wingo skribis: > On Tue 07 Mar 2017 14:44, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> I think Mark made two kinds of comments back then: >> >> 1. There were suggestions about the API itself, nothing deep: >> . >> Andy, do you know if they=E2=80=99ve been addressed? > > There were a couple points I think: > > In > > SCM scm_make_foreign_object_type (SCM name, SCM slot_names, > scm_t_struct_finalize finalizer); > > Mark suggested it should be "scm_t_struct_finalizer". I.e. with an r. > I can agree but scm_t_struct_finalize is a type that's already in 2.0; > it's just being re-used here. That said we can do the new name + > typedef + eventually deprecate the old name dance. Good point; given the type is already there in 2.0, I=E2=80=99d be in favor= of keeping it as is (without the =E2=80=98r=E2=80=99). > He also suggested to get rid of some type punning, and indeed now we > have: Perfect. >> 2. A general concern about =E2=80=9CAPI churn=E2=80=9D and our ability= to support the >> SMOB API in the future, which I can sympathize with: >> . >> >> Essentially, (1) it should be easy for people to migrate from SMOBs >> to foreign objects (I think it=E2=80=99s largely a matter of >> documentation), and (2) existing code that uses the documented SMOB >> API should just work in 2.2, possibly with a deprecation warning. > > I am not so sure about about this one. I think it's not accurate to > characterize beginning to replace a 25-year-old C API (SMOBs) as > "churn". I think the point is that there=E2=80=99s lots of code out there that rely = on SMOBs and we shouldn=E2=80=99t break it overnight, precisely because that A= PI is this old. Of course, I agree that pushing users towards an improved API is the right thing long term, no argument here. > I will get to Mark's point specifically in a minute but regarding your > points I believe that (1) is somewhat under-documented; the > documentation is more oriented towards new users than migrating users; > we can improve here; and (2) should work fine (the old API is still > there, not even any deprecation warnings currently). Sounds good. > I think Mark's desire (if I understand it) was for the new API to > completely replace the old in all forms, specifically in support for > mark procedures. I really think that (a) we should not support the SMOB > mark procedure interface, as it's both horrible and insufficient for a > moving collector, and (b) that until we have a moving collector (?), we > shouldn't attempt to speculatively standardize anything in this regard. > Basically the arguments from here: > > https://lists.gnu.org/archive/html/guile-devel/2015-11/msg00003.html > > There's still the SMOB API if you need mark procedures, basically, but > hopefully you don't (e.g. when porting GDB to 2.0 I was able to remove > them; they're less necessary in 2.x than they were in 1.8). Some users > still need them, which is why SMOBs are still around :) Understood. I think we=E2=80=99ve achieved our goal if code that is not ready to migrate works the same as with 2.0, which should be the case AIUI. So, green lights for me. :-) Thank you, Ludo=E2=80=99.