unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
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)




  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).