[Larceny-users] ffi support for Integer to float

[Eduardo Cavazos]

Hello,

Example using 'gl':

(glColor4d 1 1 1 1)

Of course, this produces an error since the 'glColor4d' expects double
arguments.

However, it's no fun to litter the code with 'exact->inexact'. Another
approach I take is to do (+ 0.0 n).

So my question is, in the future, will the ffi work such that numeric
conversions such as these happen automatically? If not, then I suppose
the solution is a "higher level" library which does things like:

(define (gl-color r g b a)
(glColor4d (exact->inexact r)
(exact->inexact g)
(exact->inexact b)
(exact->inexact a)))

will be in order.

It seems like integer->float conversions seem conservative while the
reverse isn't prudent.

Ed

[Felix Klock]

Ed-

Post by Eduardo Cavazos
However, it's no fun to litter the code with 'exact->inexact'. Another
approach I take is to do (+ 0.0 n).
So my question is, in the future, will the ffi work such that numeric
conversions such as these happen automatically? If not, then I suppose

I am not planning to change the semantics of the current conversion
routines.

However, the FFI is extensible; you can add new type-descriptors with
corresponding conversions. So you could add a 'int-or-double type
that converts fixnum inputs into flonums before passing the result
along to the lower layer routines.

The current Larceny documentation does not describe these relatively
new features properly (sorry), but you can look at section 4.2.2 of
the paper I presented at the Scheme Workshop last fall for some
information about how to go about doing this:

http://www.ccs.neu.edu/home/pnkfelix/Published/klock-ffi-schemeworkshop-2008.html

I also have been meaning to take some time to compare your gl
interface to the one that I hacked up some time ago. The main
difference between us, I suspect, are that I use Larceny's define-c-
info form to extract the various constants from the header file, while
your code writes the values explicitly as Scheme definitions (which
seems to be an entirely acceptable approach for a library like OpenGL
where the values of the constants do not change over time).

-Felix

[Eduardo Cavazos]

I use Larceny's define-c-info form to extract
the various constants from the header file

One drawback to 'define-c-info' is the dependency on a header file. It's
common for operating systems to have a library file (.so or .dll)
available but not the corresponding header.

[Felix Klock]

Ed (cc'ing larceny-users)-

Post by Eduardo Cavazos

I use Larceny's define-c-info form to extract
the various constants from the header file

One drawback to 'define-c-info' is the dependency on a header file. It's
common for operating systems to have a library file (.so or .dll)
available but not the corresponding header.

That's absolutely true; the intended development model is that the
developer hooking into the foreign code (and who is supposed to have
these headers installed) is the one using define-c-info; the developer
is then expected to ship compiled .fasl files to the end-client as
part of the complete library interfacing with the foreign code.

This "drawback" is hard to avoid in most cases; foreign libraries that
require references to constants but do not standardize their values
(nor provide procedural interfaces to extract their values) require
someone in the development chain to extract information from the
header file in some manner.

OpenGL falls under the category of a foreign library that standardizes
the values of relevant constants in the interface. OpenGL strikes me
as a library that was designed to be accessed from a large family of
languages (as opposed to just C). So using define-c-info is not
necessary here; I did not mean to imply otherwise.

-Felix