From: Matt Wette <matt.wette@gmail.com>
To: Mark H Weaver <mhw@netris.org>
Cc: guile-user@gnu.org
Subject: Re: type friction C <-> scheme
Date: Sun, 11 Jun 2017 06:07:14 -0700 [thread overview]
Message-ID: <6547855C-753F-4C46-92EE-E6F6A2324B45@gmail.com> (raw)
In-Reply-To: <87d1ab3wfr.fsf@netris.org>
> On Jun 10, 2017, at 10:50 PM, Mark H Weaver <mhw@netris.org> wrote:
>
> Catonano <catonano@gmail.com <mailto:catonano@gmail.com>> writes:
>
>> 2017-06-10 0:33 GMT+02:00 Matt Wette <matt.wette@gmail.com>:
>>
>> I think Mike caught your real error: you were passing (list ‘* ‘int ‘*) and
>>> it wants (list ‘* int ‘*). `int’ 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 = 8
>>>
>>
>> yes, and
>>
>> scheme@(freexl common)> *
>> $14 = #<procedure * (#:optional _ _ . _)>
>
> '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
Yes. In the ffi-helper I’m working on, which is intended to help auto-generate ffi code from C headers, I use #:prefix to avoid clashes:
(define-module (cairo cairo)
#:use-module (ffi-help)
#:use-module ((system foreign) #:prefix ffi:)
#:use-module ((bytestructures guile) #:prefix bs:)
)
(define bs:struct bs:bs:struct)
…
;; cairo_matrix_t
(define cairo_matrix_t
(bs:struct
(list `(xx ,bs:double)
`(yx ,bs:double)
`(xy ,bs:double)
`(yy ,bs:double)
`(x0 ,bs:double)
`(y0 ,bs:double))))
(export cairo_matrix_t)
…
;; void cairo_line_to(cairo_t *cr, double x, double y);
(define cairo_line_to
(let ((f (ffi:pointer->procedure
ffi:void
(lib-func "cairo_line_to")
(list '* ffi:double ffi:double))))
(lambda (cr x y)
(let ((~cr ((unwrap-cairo_t* cr)))) (f ~cr x y)))))
(export cairo_line_to)
next prev parent reply other threads:[~2017-06-11 13:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-09 20:36 type friction C <-> scheme Catonano
2017-06-09 20:52 ` Mike Gran
2017-06-09 21:33 ` Catonano
2017-06-09 20:56 ` Matt Wette
2017-06-09 21:39 ` Catonano
2017-06-09 22:33 ` Matt Wette
2017-06-10 6:26 ` Catonano
2017-06-11 5:50 ` Mark H Weaver
2017-06-11 13:07 ` Matt Wette [this message]
2017-06-11 17:15 ` Catonano
2017-06-11 18:01 ` Matt Wette
2017-06-11 18:20 ` Catonano
2017-06-12 8:00 ` David Pirotte
2017-06-12 12:45 ` Matt Wette
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6547855C-753F-4C46-92EE-E6F6A2324B45@gmail.com \
--to=matt.wette@gmail.com \
--cc=guile-user@gnu.org \
--cc=mhw@netris.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).