From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA15779; Sun, 6 Jun 2004 20:49:33 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA15791 for ; Sun, 6 Jun 2004 20:49:31 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from eposta.kablonet.com.tr ([62.248.102.66]) by concorde.inria.fr (8.12.10/8.12.10) with SMTP id i56InTSH007736 for ; Sun, 6 Jun 2004 20:49:29 +0200 Received: (qmail 93693 invoked by uid 1007); 6 Jun 2004 18:58:18 -0000 Received: from exa@kablonet.com.tr by eposta.kablonet.com.tr by uid 0 with qmail-scanner-1.21 (clamdscan: 0.70-rc. Clear:RC:0(81.214.24.132):. Processed in 11.015107 secs); 06 Jun 2004 18:58:18 -0000 Received: from unknown (HELO orion) (exa@kablonet.com.tr@81.214.24.132) by 0 with SMTP; 6 Jun 2004 18:58:06 -0000 From: Eray Ozkural Reply-To: erayo@cs.bilkent.edu.tr Organization: Bilkent University CS Dept. To: skaller@users.sourceforge.net Subject: Re: [Caml-list] Efficient C++ interfacing? Date: Sun, 6 Jun 2004 21:44:54 +0300 User-Agent: KMail/1.6.51 Cc: John Goerzen , ronniec95@lineone.net, caml-list References: <40800C10000A6ABC@mk-cpfrontend-4.mail.uk.tiscali.com> <20040606033327.GA23341@complete.org> <1086505241.16811.625.camel@pelican.wigram> In-Reply-To: <1086505241.16811.625.camel@pelican.wigram> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406062144.55004.exa@kablonet.com.tr> X-Miltered: at concorde with ID 40C36739.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; eray:01 ozkural:01 caml-list:01 interfacing:01 2004:99 00,:99 2004:99 eray:01 ozkural:01 kde:01 kde:01 haskell:01 model:01 moc:99 frontc:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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) 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