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

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

[Fritz Wuehler]

> Sure but this is a C++ code generator

No, see the Overview.
"OpenC++ is a toolkit for C++ translators and analyzers."

> I want to process data with OCaml

Oh, I thought Felix wanted to be bootstrapped.
Since Felix is so C++ friendly it should be
easy to drop OpenC++ in to help bootstrapping.
Seems a waste to write a C++ parser in Ocaml
that has to be rewritten in Felix later.

This thing was designed to do what Felix
does, make (C++)++ languages.  It can also
for example deal with Qt's non-C++ issues,
which is just another (C++)++.

The main thing is, no matter what end goal -
this tool gives you a semantic model of the
C++ code, that you can then interface to OCaml
or whatever language you want.  Treat it like
any other library.

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

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

[skaller]

On Wed, 2004-06-09 at 01:02, Fritz Wuehler wrote:

> > I want to process data with OCaml
> 
> Oh, I thought Felix wanted to be bootstrapped.

It does, eventually. however, to do that
I would have to write some very complex
code in an unstable language (Felix).
[At the moment, Ocaml is better for writing
compilers in :]

> Since Felix is so C++ friendly it should be
> easy to drop OpenC++ in to help bootstrapping.
> Seems a waste to write a C++ parser in Ocaml
> that has to be rewritten in Felix later.

Sure but you're effectively suggesting to use
OpenC++ and which means building a representation
using C++ code.

> This thing was designed to do what Felix
> does, make (C++)++ languages.  It can also
> for example deal with Qt's non-C++ issues,
> which is just another (C++)++.

Felix isn't a (C++)++ language syntactically:
the syntax is unambiguous LALR(1) .. :)

You are right I suspect I could write the
wrapper generator in C++ instead of Ocaml,
and then leverage OpenC++ to do the
parsing. There are also several other C++ parsers
including part of CERN's ROOT system.

However this complicates the tool chain quite
a lot. The wrapper generator excluding the parser
is only a few hundred lines of code at the moment.
The C parser is a bit bigger, but I didn't write it.

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

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

[Eray Ozkural]

On Tuesday 08 June 2004 18:02, Fritz Wuehler wrote:
> > Sure but this is a C++ code generator
>
> No, see the Overview.
> "OpenC++ is a toolkit for C++ translators and analyzers."

Good. I had checked out OpenC++ but I don't know the current state so let me 
ask.

1. Is it 100% ISO C++ compatible?
2. How easy would it be to write the kind of translator we want?

Regards,

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

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

[£ukasz Dobrek]

On Tue, Jun 08, 2004 at 11:49:18PM +0300, Eray Ozkural wrote:
> Date: Tue, 8 Jun 2004 23:49:18 +0300
> From: Eray Ozkural <exa@kablonet.com.tr>
> Subject: Re: [Caml-list] Re: Efficient C++ Interfacing?
> To: Fritz Wuehler <fritz@spamexpire-200406.rodent.frell.eu.org>
> Cc: caml-list@inria.fr
> 
> On Tuesday 08 June 2004 18:02, Fritz Wuehler wrote:
> > > Sure but this is a C++ code generator
> >
> > No, see the Overview.
> > "OpenC++ is a toolkit for C++ translators and analyzers."
> 
> Good. I had checked out OpenC++ but I don't know the current state so let me 
> ask.
> 
> 1. Is it 100% ISO C++ compatible?
Nope, appart of the fact that I have not seen a 100% ISO compatibile
compiler yet, this one is for shure not one of them. 

I watched it once carefully, now I don't remember so well all the
problems, but for the record:
- It won't parse namespaces aliases. 
        ( namespace identifier = org_namespace_name ; )
- It's mechanism of type resolution is not supporting typedefs.
- It's mechanism which is suppose to find for a member template function 
  definition its declaration in the class definition, will not work 
  if the names of the template parameters differ in this two cases:
   template< class T >
   class A 
   {
    int f();
    } 

    template<class NOT_T>
    int A<NOT_T>::f(){ return 1 ; }

there was more but It is all I could find out again now. 

Anyway I think it is an excellent project and can be very usefull.

In hope it helps 

Lukasz Dobrek

-- 
Dr. Lukasz Dobrek
www.dobrek.de

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

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

[Eray Ozkural]

On Wednesday 09 June 2004 00:19, £ukasz Dobrek wrote:
> On Tue, Jun 08, 2004 at 11:49:18PM +0300, Eray Ozkural wrote:
> > Date: Tue, 8 Jun 2004 23:49:18 +0300
> > From: Eray Ozkural <exa@kablonet.com.tr>
> > Subject: Re: [Caml-list] Re: Efficient C++ Interfacing?
> > To: Fritz Wuehler <fritz@spamexpire-200406.rodent.frell.eu.org>
> > Cc: caml-list@inria.fr
> >
> > On Tuesday 08 June 2004 18:02, Fritz Wuehler wrote:
> > > > Sure but this is a C++ code generator
> > >
> > > No, see the Overview.
> > > "OpenC++ is a toolkit for C++ translators and analyzers."
> >
> > Good. I had checked out OpenC++ but I don't know the current state so let
> > me ask.
> >
> > 1. Is it 100% ISO C++ compatible?
>
> Nope, appart of the fact that I have not seen a 100% ISO compatibile
> compiler yet, this one is for shure not one of them.
>
> I watched it once carefully, now I don't remember so well all the
> problems, but for the record:
> - It won't parse namespaces aliases.
>         ( namespace identifier = org_namespace_name ; )
> - It's mechanism of type resolution is not supporting typedefs.
> - It's mechanism which is suppose to find for a member template function
>   definition its declaration in the class definition, will not work
>   if the names of the template parameters differ in this two cases:
>    template< class T >
>    class A
>    {
>     int f();
>     }
>
>     template<class NOT_T>
>     int A<NOT_T>::f(){ return 1 ; }
>
> there was more but It is all I could find out again now.

Okay, thank you very much for the information. The member template function 
bug should not matter too much, because as discussed in another thread, 
interfacing C++ templates from ocaml is awkward and unreliable, it seems 
practically impossible at the moment. I wonder what the INRIA team thinks 
about it, is it theoretically impossible to interface C++ template functions? 
The other bugs do not sound nasty, but in a large library, a host of typedefs 
and aliases are likely to be found. Namespaces aren't used like as in boost, 
in Qt/KDE libs, but I expect their use to increase (as in KDevelop code), and 
there is probably a lot of typedefs (although I can't tell just how much in 
the interfaces), especially the latter would be a serious problem.

I think the best for me is to try these parsers systematically on the target 
code, and see if they fail. There does not seem a better recourse. The ANTLR 
C++ parser seems impressive, it's said to actually parse MFC libraries IIRC, 
it was also being used in KDevelop (the C++ support is a critical component 
apparently). The only sad thing about these systems is that they are not 
written in ocaml. :) 

> Anyway I think it is an excellent project and can be very usefull.
> In hope it helps

Thanks again. I'm now getting the impression that I need to complete my 
self-training of ANTLR parser generator as well as OpenC++.

Best Regards,

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

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

[skaller]

On Tue, 2004-06-29 at 05:58, Eray Ozkural wrote:
>  The only sad thing about these systems is that they are not 
> written in ocaml. :) 

An Earley parser is easy to make, RD even easier
although it's a bit harder in that case to get the
grammar right.

The main problem is handling the silly identifier/typename
distinction, which is easy to do .. and hard to *undo*:
forgetting things is vital for a functional parser.
Tying the lexer and parser together solves this problem.

I assume performance isn't as vital to you as actually
parsing the input. Earley seems quite feasible for C++,
since in practice there are enough 'stopping symbols'
to restrict the O(n^3) performance problem to small
enough n to be practical.

The bottom line here is that it is a lot of work
to elaborate all the grammar productions, especially
if you want to take MSC/gnu extensions into account
and handle "C" as well (since C has distinct
rules for some things like enums and nested classes).

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

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

[Eray Ozkural]

On Tuesday 29 June 2004 04:35, skaller wrote:
> On Tue, 2004-06-29 at 05:58, Eray Ozkural wrote:
> >  The only sad thing about these systems is that they are not
> > written in ocaml. :)
>
> An Earley parser is easy to make, RD even easier
> although it's a bit harder in that case to get the
> grammar right.
>
> The main problem is handling the silly identifier/typename
> distinction, which is easy to do .. and hard to *undo*:
> forgetting things is vital for a functional parser.
> Tying the lexer and parser together solves this problem.
>
> I assume performance isn't as vital to you as actually
> parsing the input. Earley seems quite feasible for C++,
> since in practice there are enough 'stopping symbols'
> to restrict the O(n^3) performance problem to small
> enough n to be practical.
>
> The bottom line here is that it is a lot of work
> to elaborate all the grammar productions, especially
> if you want to take MSC/gnu extensions into account
> and handle "C" as well (since C has distinct
> rules for some things like enums and nested classes).

I'd studied Earley parsers in an NLP course. I've no idea if it would be so 
much easier than an ANTLR or OpenC++ parser, though. Is it because we 
wouldn't have to factor the grammar or some other improvement in 
specification? Would we be able to maintain semantic predicates a la ANTLR 
easily? (The lead developer of ANTLR seems to suggest writing a C++ parser is 
a crafty, difficult thing regardless of which parser technology you 
choose...)

Regards,

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

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

[Ethan Lee Aubin]

skaller <skaller@users.sourceforge.net> wrote:
> An Earley parser is easy to make, RD even easier
> although it's a bit harder in that case to get the
> grammar right.

Also of interest might be the ocaml backend for the Elkhound GLR
parser at http://www.cs.berkeley.edu/~smcpeak/elkhound/ .  There is an
associated C++ parser, but I don't have any experience with it. - EA

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

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

[skaller]

On Wed, 2004-07-07 at 11:02, Eray Ozkural wrote:
> On Tuesday 29 June 2004 04:35, skaller wrote:
> > On Tue, 2004-06-29 at 05:58, Eray Ozkural wrote:
> > >  The only sad thing about these systems is that they are not
> > > written in ocaml. :)
> >
> > An Earley parser is easy to make, RD even easier
> > although it's a bit harder in that case to get the
> > grammar right.

> I'd studied Earley parsers in an NLP course. I've no idea if it would be so 
> much easier than an ANTLR or OpenC++ parser, though. 

ANTLR and OpenC++ have several disadvantages .. not being written
in Ocaml is a rather nasty one for you and me. Not having control
of the project is also an issue, especially if you're building
something which you want to give to clients who have to build it
in turn ..


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

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

[skaller]

On Mon, 2004-06-07 at 21:46, privacy.at Anonymous Remailer wrote:
> 
> Open-source C++ parser:
> 
> http://opencxx.sourceforge.net

Sure but this is a C++ code generator.. in the first
instance I want to process data with Ocaml :)

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

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

[privacy.at Anonymous Remailer]

Open-source C++ parser:

http://opencxx.sourceforge.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