[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | John Max Skaller <skaller@o...> |
| Subject: | Re: [Caml-list] Possible use for camlp4 |
Daniel de Rauglaudre wrote:
>>Hmm.. can camlp4 generate C?
>>
>What do you mean by "generate C"? Can you specify, give examples?
>
Input:
CBINDING fred:int -> int = fred($1) ENDBINDING
output #1:
extern int fred_binding(int x) { return fred(x); } /* generated C
function */
output #2:
external fred:int ->int = "fred_binding"; (* ocaml stub *)
The idea is a file of hand written bindings which generate the C code
necessary to wrap a C library. There are two outputs: the C glue code
and the ocaml binding definitions.
The point is to use camlp4 to make it easier to write the C glue code,
by inventing some language syntax which knows about the garbage
collector, heap format, the macros needed to do all that, etc.
That is, the glue code isn't generated *automatically* from a C interface,
like with SWIG. Instead, you have to write the glue code by hand,
as you do now. The difference is that you write it in a slightly
higher level language than the ugly and error prone C/Ocaml macros
system. In addition, the 'simplified' way of using those macros is sometimes
very inefficient. [eg, making parameters and local variables gc roots
when there is no need]
Just as an example: the keyword 'interruptible' might mean
to use enter/leave blocking section macros.
That is: my suggestion is to design a language CamlCGlue,
which generates C code to bind ocaml to C libraries,
and implement it using camlp4.
BTW: this thought was prompted by the debate as to whether
camlp4 belongs in the standard distribution or not, and unrelated
discussion about building bindings to C libraries.
If there is one thing that Ocaml is perceived as needing more
than anything else for industrial use, it's bindings to more C libraries.
At present, writing them is very very expensive, and maintaining
them is an even worse problem if the target C library is evolving
eg GTK. So .. why not use ocamlp4 to help reduce the problem?
--
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners