Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] swig like library...
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: skaller <skaller@u...>
Subject: RE: [Caml-list] swig like library...
On Sun, 2004-04-25 at 03:12, Brandon J. Van Every wrote:
> skaller wrote:
> >
> > However SWIG isn't very satisfactory.. I'm thinking of
> > writing an Ocaml program for building wrappers.
> 
> What is so unsatisfactory about SWIG that you would start a new effort
> and avoid improving SWIG? 

First, I do not have CVS access to SWIG,
and David Beazly has been singularly uncooperative
despite the promise in the release notice welcoming
contributors. 

(a) refused my language module

(b) refused to incorporate dynamic loading patch
which would have allowed independent development of it

(c) failed to fix minor preprocessing bug posted
to the bug tracker

Second, the technology used to implement it is very weak:
the core is written in very unsafe C in a style emulating
Python dynamic typing -- it doesn't even bother to use
ctors/dtors to manage memory. Many of the functions
are mutators when they should have been purely functional.

Thirdly, despite saying he is interested in input
automation, and despite working right now on C++ parsing,
SWIG is very weak on the input side. A significant
part of my SWIG language module spends its time
'undoing' or bypassing SWIG machinery.

My requirement is to automatically process a large number 
of C/C++ header files. When I say 'large' I really mean LARGE. 
I mean all the include files in /usr/include plus an arbitrary
collection of client specific files. Annotations are OK,
but not for every single function! The process must
be platform independent (that's the whole point of it).

I have no need for 90% of the Swig machinery.
Much of SWIG is devoted to type mapping, providing
functions to remodel class methods as functions
so they can be lifted into the target as method again.
Quite a bit focuses on  crossing complex API boundaries.
I have no need for any of that: my target language
uses the C/C++ object model directly. I don't need
'API interface glue' because my target generates C++
source code: its not an interpreter.

SWIG fails to handle BASIC conversions: there is no mechanism
for handling callbacks, for example. It isn't able
to pattern match well enough to detect distinctions
I require .. it actively gets in the way of some
of the ones I wish to detect.

The bottom line is: it isn't that hard to reach a point
where writing a C parser in Ocaml is easier than
hacking about with badly written C and an uncooperative
project manager .. especially when several Ocaml
projects already have a what would appear to be
a superior parser (eg the Cilly parser, which passes
exhaustive stress testing and handles GNU extensions).

Right now my own project is broken by this problem.
I need bindings for common libraries: a new
language is useless without a library.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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