[erlang-questions] Type-tagged FFI interface

[Alceste Scalas]

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/