[cffi-devel] Extending defcfun and friends with extra options

[Green Bryan - bgreen]

I'm rather new to using lisp and, of course, cffi.  But, why not have someone pick cdecl or stdcall with as as option  to load-library?  Most libraries I have seen use one or the other, not both.  Apparently, a lot of windows libraries liked to use stdcall for compatibility with Visual Basic and such ilk.  Anything I can do to help?  I'm a newbie, but good work ethic..... 

-----Original Message-----
From: cffi-devel-bounces at common-lisp.net on behalf of Luís Oliveira
Sent: Tue 1/30/2007 1:52 AM
To: CFFI Development List
Subject: [cffi-devel] Extending defcfun and friends with extra options
 
Hello,

There are a couple of features people need -- namely stdcall and dll
namespaces -- that depend on the ability to pass options to defcfun,
foreign-funcall and defcallback. So we need to agree on a proper
syntax to do this. Bonus points if we can get backwards compatibility.

This has been discussed in the past regarding defcfun but I forget
what the conclusions were. Anyway, starting with the easiest:

  (defcallback (foo :opt1 ... :opt2 ...) :rettype ((arg1 :type1) ...)
     body)

That seems to be the obvious place to put the options for defcallback.
Any objections? defcfun, however, has some more possibilities:

  ;; #1 -- backwards compatible, similar to defcallback
  (defcfun (foo :opt1 ... :opt2 ...) :rettype
    (arg1 :type1)
    (arg2 :type2))

  ;; #2 -- backwards compatible, slightly funky syntax IMHO
  (defcfun foo :rettype
    (arg1 :type1)
    (arg2 :type2)
    :opt1 ...
    :opt2 ...)

  ;; #3 -- not backwards compatible, indentation looks odd when
  ;; there are no options present
  (defcfun foo :rettype
      ((arg1 :type1)
       (arg2 :type2))
    :opt1 ...
    :opt2 ...)


IIRC, I used to be prefer option #3 because that way we could cleanly
define the keyword arguments in the defcfun macro but lately I'm more
inclined towards #1 since it indents better and the syntax is similar
to defcallback. Also, #1 is backwards compatible; that's a plus, I
guess. I think James used to prefer option #2. Is that still true? I
don't completely dislike option #2.

And finally there's foreign-funcall. The syntax here should be pretty
obvious too:

  (foreign-funcall ("foo" :opt1 ... :opt2 ...) :type1 arg1 :type2 arg2 :rettype)

Except foreign-funcall also accepts a pointer, and in that case the
first argument is evaluated (unlike the case where the argument is a
string). I think
  (foreign-funcall ((some-form ...) :opt1 ... :opt2 ...) :type1 arg1
... :rettype)
looks a bit odd. Does that justify splitting such functionality off to
another macro foreign-funcall-pointer with a different syntax? I think
I'd rather avoid that.

Oh, and we need options for define-foreign-library too. Once again I'm
thinking we should place the options in the name argument:
(define-foreign-library (name :opt1 ... :opt2 ...) ...).

Comments and suggestions are most welcome.

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
_______________________________________________
cffi-devel mailing list
cffi-devel at common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel

***************************************************************************
The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be legally
privileged.

If the reader of this message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.

If you have received this communication in error, please resend this
communication to the sender and delete the original message or any copy
of it from your computer system.

Thank You.
****************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20070130/0053581a/attachment.html>