caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: "Brandon J. Van Every" <vanevery@indiegamedesign.com>
Cc: caml-list <caml-list@inria.fr>
Subject: RE: [Caml-list] swig like library...
Date: 25 Apr 2004 06:11:56 +1000	[thread overview]
Message-ID: <1082837516.9537.114.camel@pelican.wigram> (raw)
In-Reply-To: <OOEALCJCKEBJBIJHCNJDOEGOHBAB.vanevery@indiegamedesign.com>

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


  reply	other threads:[~2004-04-24 20:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-23 14:36 Michael
2004-04-23 15:07 ` Richard Jones
2004-04-23 15:47 ` Kenneth Knowles
2004-04-24  1:50 ` skaller
2004-04-24 17:12   ` Brandon J. Van Every
2004-04-24 20:11     ` skaller [this message]
2004-04-25  1:24       ` art yerkes
2004-04-25  2:56         ` skaller
2004-04-27  5:02           ` [Caml-list] " Jeff Henrikson
2004-04-25  9:11         ` [Caml-list] " Yamagata Yoriyuki
2004-04-25 10:30           ` skaller
2004-04-26 15:17           ` art yerkes
2004-05-17 17:03             ` Yamagata Yoriyuki
2004-04-23 15:48 HENRIKSON, JEFFREY
2004-04-24 19:16 ` art yerkes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1082837516.9537.114.camel@pelican.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@inria.fr \
    --cc=vanevery@indiegamedesign.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).