Re: [Caml-list] Efficient C++ interfacing?

[Eray Ozkural <exa@kablonet.com.tr>]

On Sunday 06 June 2004 10:00, skaller wrote:
> On Sun, 2004-06-06 at 13:33, John Goerzen wrote:
> > On Sun, Jun 06, 2004 at 03:31:04AM +0300, Eray Ozkural wrote:
> > > Skaller, as a KDE developer I beg you. Please do it for Qt and KDE as
> > > well.
> >
> > The other nice thing is this: if we get Qt bindings, then OCaml
> > suddenly becomes a viable language for developing embedded
> > applications thanks to Qt/Embedded.  That would be excellent.
>
> Well, there are two obstacles at the moment:
>
> (1) Flxcc can't parse C++ yet

I had started writing a modern top-down C++ parser using the combinatorial 
parser library Parsec in Haskell, but I had failed due to lack of time with 
the project. I had stumbled upon the two major C++ ambiguity resolutions 
which require the parser to know something about the semantics early on and 
was frustrated with the amount of work required... Let me know how I can help 
with this. There are freely available parser models [LL(k), not LR(k)] which 
we can build upon. I think I was following the model from tendra but it's 
been ages, now I see that I've written about 15k of Parsec code, I think I've 
had a fair amount of C++ parser experience sometime in the past :)

There is also the language extensions of Qt MOC, but after doing C++ it would 
be possible to cope with a few simple keywords.

> (2) Flxcc can't target Ocaml yet

This one wouldn't be hard.

> Parsing C++ - templates is quite easy:
> I've already made the mods to Frontc parser.
> However, the parse tree is processed by Cil,
> which does some complex transformations to regularise
> the representation, and modifying that isn't so easy.
> Cil handles the whole of C, whereas we actually only need
> to process interfaces -- expressions could be useful
> (default arguments, template arguments, and typeof)

So, you do have a rudimentary C++ parser?

> Generating Ocaml should be easy. However the program
> will need to be factored to have a selectable backend.
> It will need to do a bit more work than the Felix
> backend however: Ocaml has separate compilation,
> Felix doesn't. Ocaml can't do general recursion,
> Felix has trouble doing anything else.

Ok.

> But I have no doubt it can be done, even if the
> result isn't perfect.

I guess so, too. I dropped my project when I saw SWIG adding Ocaml support. 
They even have some Qt examples in their new manual. Again, I have no idea 
how well their stuff works. I used SWIG only once, and that was because a 
compile required it.

> What's needed is developers.
> Wrapper generators need extensive testing by experts in
> the wrapped libraries, and the code has to be lifted
> out of Felix and put into a new project (and then
> Felix will have to re-integrate it).

Yes. However, doing this wrapper generator is considerably valuable. For 
instance, if we can add Qt C++ syntax support, then we can target every KDE 
program installed!

> I guess we need 4 developers to start off.
> And a better name than 'flxcc' before registering
> a new project :)

You find the name. I think this list will be a good place to recruit 
developers :) I will try to contribute. I was trying to find a way to 
contribute to KDE in a useful way now that Qt 4 will feature MVC support that 
I was working on :)

Cheers,

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://malfunct.iuma.com
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

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