English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] dynamically loading C functions
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-03-06 (18:03)
From: Chris Hecker <checker@d...>
Subject: Re: [Caml-list] dynamically loading C functions

>Do you indeed support returning functions from C? OK, so you need to
>distinguish more than the OCaml type tells. For example by having two
>functions of type 'a t -> 'b t -> ('a -> 'b) t: one to use between
>arguments and another for the final result.

Right, I thought of that, and I also thought of having a special token in the "type stream" that indicates a return value.  Neither of these are quite as natural as I'd like, though.  I think having a @@-> that you use between args and return isn't terrible, but it's just even more syntax to make this harder to use and more error prone.  :)  The get_function could raise an exception if every function in the specification didn't have a return type specifed, though.

I've got it wired up to use the Bigarray ('a,'b) kind stuff now, so the caml function and the c function type signatures parallel each other as ('aa,'ab) t -> ('ba,'bb) t -> ('aa -> 'ba,'ab -> 'bb) t (and I can reuse the Bigarray type hierarchy, although I don't know how to get access to the internal definitions of the Bigarray abstract types which I need to actually return the information, I think...or maybe not, so I may need to copy them, which sucks...sometimes having "#include<>" is useful  ;).

As for whether I need to support returning functions, all of this is relative.  I would really like to just solve the entire problem at once, if possible.  I'd like to make this work for generic dynalinking, but the very case I was going to use first (wglGetProcAddress) does actually return a function pointer.  :)


To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr