[gambit-list] Converting uint32 to scheme object

Hendrik Boom hendrik at topoi.pooq.com
Wed Jan 6 23:55:09 EST 2016


On Wed, Jan 06, 2016 at 11:44:51PM -0500, Marc Feeley wrote:
> You are arguing that you can’t do much better than Lua’s FFI if you 
> don’t have a compiler (code generator?) to generate the glue code.  
> That seems to be an artificial constraint, because it is possible to 
> implement such a code generator!

It's hard to implement a portable code generator.  The generated code 
tends to e achinee-dependent.

But the real prolem here is that C lacks an essential feature.  Lisp got 
it right.  In Lisp you can call a statically unknown function with an 
arbitrary list of arguments.

>  My point is that, for the user of the system, it is better when the 
process of checking types, number of parameters, heap overflow 
conditions, exception raising, etc are automated.  When the process is 
not automated, these things are not typically done by the user (or are 
done incorrectly or not completely) because it is tedious and error 
prone to check all conditions.

Completely agree.

-- hendrik

> 
> Marc
> 
> > On Jan 6, 2016, at 11:25 PM, Hendrik Boom <hendrik at topoi.pooq.com> wrote:
> > 
> > On Wed, Jan 06, 2016 at 11:00:26PM -0500, Marc Feeley wrote:
> >> I can see a few problems with the glue code you wrote to interface your C function to Lua:
> >> 
> >> - it isn’t checking that the number of parameters received by the function is correct
> >> - it isn’t checking that the first parameter is a pointer of type TIFF*
> >> - it isn’t checking that the first parameter is not NULL
> >> - it doesn’t appear to do the right thing when val is a uint32 with the upper bit set (I suspect it will return a negative integer)
> >> - if there is a type error (say the second parameter is not an integer), will there be a precise error message or exception indicating that the second parameter was not of the right type? can the exception be caught in Lua?
> >> - I suspect that lua_pushinteger may allocate memory (for a bignum or flonum?), so what happens if this allocation causes the heap to overflow? can this be caught in Lua?
> >> 
> >> In this particular example, Gambit’s glue code is not much longer than the one for Lua, but it doesn’t suffer from these issues.  For a typical function with simple types for parameters and result, Gambit’s FFI does not require any glue code.
> > 
> > Let me guess that your FFI accomplishes its goals by generating and 
> > compiling C code.  You can do a lot that way.
> > 
> > I believe that Lua was originally an interpreter written in portable C, 
> > and there was no mechanism in C to call a statically unknown function 
> > with a statically unknown number of parameters of statically unknown type. 
> > C is not the only language with this problem, and the Lua C interface is 
> > about as good as you can get under this constraint.
> > 
> > I don't know if there is such a mechanism now; I've heard that there are 
> > such gcc extensions, but that's not as portable as one might like.
> > 
> >> 
> >> So as you can probably tell, I’m more enclined to qualify Lua’s FFI as “simple” and not “brilliant”… :-)
> > 
> > A simplicity born of necessity.
> > 
> > Gambit had entirely different constraints.  Didn't it originate as a 
> > compiler from Scheme to C?
> > 
> > -- hendrik
> > _______________________________________________
> > Gambit-list mailing list
> > Gambit-list at iro.umontreal.ca
> > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
> 



More information about the Gambit-list mailing list