From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.user Subject: Re: type friction C <-> scheme Date: Sun, 11 Jun 2017 01:50:00 -0400 Message-ID: <87d1ab3wfr.fsf@netris.org> References: 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 1497160240 16124 195.159.176.226 (11 Jun 2017 05:50:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Jun 2017 05:50:40 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) Cc: guile-user@gnu.org, Matt Wette To: Catonano Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Jun 11 07:50:36 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 1dJvlj-0003qU-GH for guile-user@m.gmane.org; Sun, 11 Jun 2017 07:50:35 +0200 Original-Received: from localhost ([::1]:32933 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dJvln-00031R-4w for guile-user@m.gmane.org; Sun, 11 Jun 2017 01:50:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40259) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dJvlP-00031K-Rs for guile-user@gnu.org; Sun, 11 Jun 2017 01:50:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dJvlM-0003rU-Q5 for guile-user@gnu.org; Sun, 11 Jun 2017 01:50:15 -0400 Original-Received: from world.peace.net ([50.252.239.5]:41622) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dJvlM-0003rP-Ko for guile-user@gnu.org; Sun, 11 Jun 2017 01:50:12 -0400 Original-Received: from pool-72-93-31-241.bstnma.east.verizon.net ([72.93.31.241] helo=jojen) by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dJvlL-000610-Lr; Sun, 11 Jun 2017 01:50:11 -0400 In-Reply-To: (catonano@gmail.com's message of "Sat, 10 Jun 2017 08:26:41 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 50.252.239.5 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:13800 Archived-At: Catonano writes: > 2017-06-10 0:33 GMT+02:00 Matt Wette : > > I think Mike caught your real error: you were passing (list =E2=80=98* = =E2=80=98int =E2=80=98*) and >> it wants (list =E2=80=98* int =E2=80=98*). `int=E2=80=99 is a variable = defined by guile. >> > > And isn't `*' a variable defined in guile too ? > > >> >> scheme@(guile-user)> (use-modules (system foreign)) >> scheme@(guile-user)> int >> $1 =3D 8 >> > > yes, and > > scheme@(freexl common)> * > $14 =3D # 'int' is a variable exported by (system foreign) whose sole purpose is to represent a foreign type. '*' is something completely different, namely a procedure to multiply numbers. IMO, it would be a nasty hack for the FFI to check specifically for a multiplication procedure and interpret that as a pointer type. > I took a look at the guile-gcrypt code again > > it's full of things like > > '(* * ,int ,size_t *) > > that is, only asterisks (pointers) are quoted > > Other types are not > > So this must be an established convention > > It just seems unconsistent to me I agree that it's inconsistent, but '* is shorter than any descriptive variable name that we might have chosen for this purpose, and pointers are common enough to warrant a short name. On the other hand, if we had used symbols uniformly for all foreign types, then it would have been impossible to bind your own type names (e.g. for struct types) without adding a global registry of foreign types, which would have various nasty problems such as the potential for collisions between unrelated libraries. Regards, Mark