Re: _import in a functor

On Tue, Feb 2, 2016 at 8:49 AM, Phil Clayton <[email protected]> wrote:
> (I thought I had already asked about this issue but I can't find or remember
> any answer.  Sorry if it's a duplicate.)
>
> It appears that _import can't be used inside a functor when the types of the
> imported function depend on the functor's arguments.  See attached example.
> Building with
>
>   mlton -default-ann 'allowFFI true' import_in_functor.sml
>
> gives
>
> Error: import_in_functor.sml 3.13.
>   Invalid type for _import.
>     int32 * t -> unit
> compilation aborted: elaborate reported errors
>
> Is that intentional behaviour and something I should work around?

It is intentional, in as much as we want to ensure that any functor
that type checks at its declaration site will necessarily type check
at every application site (that is, when we re-type-check the functor
body with the actual argument at its use site).

In your example, if you had

  structure S2 = F (type t = int -> int)

then that would not work, since "int -> int" is not a valid FFI type
and the re-type-checking would result in the "Invalid type for
_import" error message.

Also, there are few cases where the same C function would work with
multiple different SML types, so I wouldn't expect that there are very
many situations where you could exploit an ability to include an
_import in a functor.  The one exception is when the C function is
taking a void* argument, for which multiple SML types have that same
runtime C representation.  See,
https://github.com/MLton/mlton/issues/53 for a similar proposal.  In
that scenario, you might use something like:

functor F (type t  val toPtr : t -> MLton.Pointer.t) = struct val f =
_import "c_fun" : int * MLton.Pointer.t -> unit; end

Now the application site need not know the details of or provide the
right _import; instead, it simply witnesses how to convert to the
generic FFI type.

Another potential problem with _import-s in functors is that they
would be expanded to multiple _import-s overall, one for each functor
application.  Each of those _import-s, with the same C function name,
would result in a distinct C prototype (in the C codegen; no
prototypes needed in the native codegens), which is often an error for
the C compiler.

-Matthew

-- 
You received this message because you are subscribed to the Google Groups "MLton-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140