[erlang-questions] Type-tagged FFI interface

[Raimo Niskanen]

Aah, I see! As we say in swedish - I did not hear the beauty in the
crow's song. Then the tagged calls would be implemented in Erlang
and themselves call the untagged BIFs.

The name ffi:untagged_call feels awkward, though.



On Thu, Sep 13, 2007 at 10:23:51AM +0200, Alceste Scalas wrote:
> Il giorno gio, 13/09/2007 alle 09.30 +0200, Raimo Niskanen ha scritto:
> > I thought [the Erlang FFI proposal] was very thought through,
> > and complete, but apparently it will benefit from more input from
> > erlang-questions to settle a bit.
> 
> I definitely agree, and that's why I didn't send the draft to EEPs list
> yet...  Anyway thanks for having adopted it!
> 
> 
> > Oh, and I have a suggestion about the actual ffi:call/2,3 functions.
> > Personally I would prefer an interface with tagged values:
> > 
> >     ffi:call(Port, {ReturnType,Function}, [TaggedVal]) ->
> >             {ReturnType,term()}
> >         ReturnType = type_tag()
> >         TaggedVal  = {type_tag(),Val}
> >         Val        = term()
> >         type_tag() = uchar|schar|...|pointer|size_t|ssize_t
> > 
> > e.g
> > 
> >     Pointer = {pointer,PointerVal} =
> >         ffi:call(Port, {pointer,malloc}, [{size_t,1024}]),
> >     void = ffi:call(Port, {void,free}, [Pointer]),
> > 
> > This would make the code more readable (resembling the C calls) IMHO,
> > and make the ffi values more self-contained; a return value can
> > directly be passed to another ffi function.
> 
> A tagged interface would be *very* nice, and more type-safe --- but it
> would be a performance killer, too [1].
> 
> Maybe something like this would be a good compromise:
> 
>      1. move ffi:call/3 and ffi:call/2 to ffi.erl (part of the Erlang
>         kernel library?), with the tagged interface you are proposing;
>      2. rename the "old" FFI BIFs to something like ffi:untagged_call/3
>         and ffi:untagged_call/2.
> 
> In general, every FFI function could have a "standard" and recommended
> version implemented in Erlang, that will support (and check) the type
> tags.  The "real FFI work" would be performed by the untagged_ BIFs.
> Developers may choose between the tagged and untagged interfaces,
> depending on the performance/safety/readability tradeoff they're looking
> for.
> 
> What do you think?
> 
> Regards,
> 
> alceste
> 
> Notes:
> 
>   [1] The current FFI interface is tuple-based on pourpose: it avoids
>       unrolling lists when counting function call parameters, and
>       Erlang terms are handled with very simple pointer arithmetics.
> -- 
> Alceste Scalas <alceste@REDACTED>
> CRS4 - http://www.crs4.it/

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB