[cffi-devel] Re: various

[Luis Oliveira]

Kenny Tilton <ktilton at nyc.rr.com> writes:
> I got a couple of warnings from ACL:
>
> Warning: :call-direct ignored; no argument types specified.
> ; While compiling (:TOP-LEVEL-FORM "openal-lib2.lisp" 10554) in
>   C:\0dev\cl-openal\openal-lib2.lisp:
>
> Why the Hell are they not reporting on which defun? I will go digging
> to see if I can find which, but it may not matter.

That 10554 is probably the file position. Does Allegro's editor have
a goto-char command?


> I think there is a problem here in that the raw entry
> |%cffi-foreign-function/ALUTUNLOADWAV| is not really an inviting way
> to code raw calls to the API. Maybe I am wrong on this--perhaps the
> idea is that one would relatively rarely want to convert values
> explicitly and then call the raw function, so it is OK to make users
> write something like:
>
> (defun alutunloadwav-raw (a1 a2 a3 a4)
> (|%cffi-foreign-function/ALUTUNLOADWAV a1 a2 a3 a4)
>
> But is that raw name reliable between CFFI releases?

It is not inviting at all, nor is it reliable because only Allegro,
Lispworks and Corman Lisp will have this "raw" function. The other lisps
will have a call to %foreign-funcall inside the DEFUN.

In your particular example, since the types are built-in and don't have
any translators, it doesn't a "raw" function is not necessary anyway
since after macroexpansion the DEFUN looks something like this:

(defun alutunloadwav (anonymous1 anonymous2 anonymous3 anonymous4)
  (LET ((#:G1114 ANONYMOUS1))
    (LET ((#:G1115 ANONYMOUS2))
      (LET ((#:G1116 ANONYMOUS3))
        (LET ((#:G1117 ANONYMOUS4))
          (LET ((#:G1122
                 (|%cffi-foreign-function/ALUTUNLOADWAV| #:G1114 #:G1115
                  #:G1116 #:G1117)))
            #:G1122)))))

I have an idea to get rid of all those LETs by the way. (Is it worth the
trouble though?)

The only advantage using |%cffi-foreign-function/ALUTUNLOADWAV| directly
is that it would get inlined by Allegro's compiler. I suppose one could
(declaim '(inline alutunloadwav)) though, that won't work in Allegro
because its compiler ignore inline declarations, but it'll work in
Lispworks. (this reminds me that CFFI should probably be inlining the
raw function in Lispworks's case.)

Anyway, the problem really is that other Lisps won't have a raw function
so I suppose the user should define a raw foreign function with DEFCFUN
(ie. one with built-in types only, or other types which have no
translators) if necessary.


> What I did with my FFI utils was reserve the C name for raw functions
> and use the Lispified name for functions which autoconverted
> parameters and return values. I also allowed for pre- and
> post-processing.

Ah, how does this pre/post processing work in Hello-C? Does it allow for
stuff CFFI's translators don't? Or is it more convinient?


-- 
Luis Oliveira
luismbo (@) gmail (.) com
Equipa Portuguesa do Translation Project
http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=pt