<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7232.39">
<TITLE>RE: [cffi-devel] Extending defcfun and friends with extra options</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=2>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.....<BR>
<BR>
-----Original Message-----<BR>
From: cffi-devel-bounces@common-lisp.net on behalf of Luís Oliveira<BR>
Sent: Tue 1/30/2007 1:52 AM<BR>
To: CFFI Development List<BR>
Subject: [cffi-devel] Extending defcfun and friends with extra options<BR>
<BR>
Hello,<BR>
<BR>
There are a couple of features people need -- namely stdcall and dll<BR>
namespaces -- that depend on the ability to pass options to defcfun,<BR>
foreign-funcall and defcallback. So we need to agree on a proper<BR>
syntax to do this. Bonus points if we can get backwards compatibility.<BR>
<BR>
This has been discussed in the past regarding defcfun but I forget<BR>
what the conclusions were. Anyway, starting with the easiest:<BR>
<BR>
(defcallback (foo :opt1 ... :opt2 ...) :rettype ((arg1 :type1) ...)<BR>
body)<BR>
<BR>
That seems to be the obvious place to put the options for defcallback.<BR>
Any objections? defcfun, however, has some more possibilities:<BR>
<BR>
;; #1 -- backwards compatible, similar to defcallback<BR>
(defcfun (foo :opt1 ... :opt2 ...) :rettype<BR>
(arg1 :type1)<BR>
(arg2 :type2))<BR>
<BR>
;; #2 -- backwards compatible, slightly funky syntax IMHO<BR>
(defcfun foo :rettype<BR>
(arg1 :type1)<BR>
(arg2 :type2)<BR>
:opt1 ...<BR>
:opt2 ...)<BR>
<BR>
;; #3 -- not backwards compatible, indentation looks odd when<BR>
;; there are no options present<BR>
(defcfun foo :rettype<BR>
((arg1 :type1)<BR>
(arg2 :type2))<BR>
:opt1 ...<BR>
:opt2 ...)<BR>
<BR>
<BR>
IIRC, I used to be prefer option #3 because that way we could cleanly<BR>
define the keyword arguments in the defcfun macro but lately I'm more<BR>
inclined towards #1 since it indents better and the syntax is similar<BR>
to defcallback. Also, #1 is backwards compatible; that's a plus, I<BR>
guess. I think James used to prefer option #2. Is that still true? I<BR>
don't completely dislike option #2.<BR>
<BR>
And finally there's foreign-funcall. The syntax here should be pretty<BR>
obvious too:<BR>
<BR>
(foreign-funcall ("foo" :opt1 ... :opt2 ...) :type1 arg1 :type2 arg2 :rettype)<BR>
<BR>
Except foreign-funcall also accepts a pointer, and in that case the<BR>
first argument is evaluated (unlike the case where the argument is a<BR>
string). I think<BR>
(foreign-funcall ((some-form ...) :opt1 ... :opt2 ...) :type1 arg1<BR>
... :rettype)<BR>
looks a bit odd. Does that justify splitting such functionality off to<BR>
another macro foreign-funcall-pointer with a different syntax? I think<BR>
I'd rather avoid that.<BR>
<BR>
Oh, and we need options for define-foreign-library too. Once again I'm<BR>
thinking we should place the options in the name argument:<BR>
(define-foreign-library (name :opt1 ... :opt2 ...) ...).<BR>
<BR>
Comments and suggestions are most welcome.<BR>
<BR>
--<BR>
Luís Oliveira<BR>
<A HREF="http://student.dei.uc.pt/~lmoliv/">http://student.dei.uc.pt/~lmoliv/</A><BR>
_______________________________________________<BR>
cffi-devel mailing list<BR>
cffi-devel@common-lisp.net<BR>
<A HREF="http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel">http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel</A><BR>
<BR>
</FONT>
</P>
<pre>***************************************************************************
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.
****************************************************************************
</pre></BODY>
</HTML>