Dypgen C++ grammar

Dypgen C++ grammar

[skaller]

Is anyone interested in developing a C++ parser, possibly using
FrontC and/or CIL as the starting point, but using Dypgen
as the parser engine?

I have made some modification to FrontC/Cil to support
some C++ constructions, but Ocamlyacc (LALR1) just can't cope
with C++.

OTOH, Scott McPeak has a C++ grammar for Elkhound which is
a C++ based GLR engine, with BSD licence, so it may be possible
to adapt that.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Dypgen C++ grammar

[Christopher L Conway]

I would be extremely interested in a C++ parser for OCaml, especially
if it was largely compatible with CIL. The conventional wisdom is that
this is a lost cause, it's just too much work. E.g., in order to
handle real code, you'd need to support almost 30 years' worth of
language variants and historical compiler bugs that have become de
facto "features", etc.

Another approach would be to modify GCC so that it's intermediate
representation can be fed to outside tools. As a bonus, this would
provide support for Java, Fortran, and all the other languages
front-endsd in the GCC suite. Unfortunately, unless the GCC
maintainers have changed their position, this would require forking
the front end, though I suspect the changes required to implement this
are fairly minor. (See, e.g., this old discussion from the GCC list:
http://gcc.gnu.org/ml/gcc/2000-10/msg00103.html)

Chris

On 6/22/07, skaller <skaller@users.sourceforge.net> wrote:
> Is anyone interested in developing a C++ parser, possibly using
> FrontC and/or CIL as the starting point, but using Dypgen
> as the parser engine?
>
> I have made some modification to FrontC/Cil to support
> some C++ constructions, but Ocamlyacc (LALR1) just can't cope
> with C++.
>
> OTOH, Scott McPeak has a C++ grammar for Elkhound which is
> a C++ based GLR engine, with BSD licence, so it may be possible
> to adapt that.
>
> --
> John Skaller <skaller at users dot sf dot net>
> Felix, successor to C++: http://felix.sf.net
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

Re: [Caml-list] Dypgen C++ grammar

[David Hall]

On 6/22/07, Christopher L Conway <cconway@cs.nyu.edu> wrote:
> Another approach would be to modify GCC so that it's intermediate
> representation can be fed to outside tools. As a bonus, this would
> provide support for Java, Fortran, and all the other languages
> front-endsd in the GCC suite. Unfortunately, unless the GCC
> maintainers have changed their position, this would require forking
> the front end, though I suspect the changes required to implement this
> are fairly minor. (See, e.g., this old discussion from the GCC list:
> http://gcc.gnu.org/ml/gcc/2000-10/msg00103.html)
>

It's sort of already been done with GCC-XML:

"The purpose of the GCC-XML extension is to generate an XML
description of a C++ program from GCC's internal representation. Since
XML is easy to parse, other development tools will be able to work
with C++ programs without the burden of a complicated C++ parser."

http://www.gccxml.org/HTML/Index.html

-- David Hall

>
> On 6/22/07, skaller <skaller@users.sourceforge.net> wrote:
> > Is anyone interested in developing a C++ parser, possibly using
> > FrontC and/or CIL as the starting point, but using Dypgen
> > as the parser engine?
> >
> > I have made some modification to FrontC/Cil to support
> > some C++ constructions, but Ocamlyacc (LALR1) just can't cope
> > with C++.
> >
> > OTOH, Scott McPeak has a C++ grammar for Elkhound which is
> > a C++ based GLR engine, with BSD licence, so it may be possible
> > to adapt that.
> >
> > --
> > John Skaller <skaller at users dot sf dot net>
> > Felix, successor to C++: http://felix.sf.net
> >
> > _______________________________________________
> > Caml-list mailing list. Subscription management:
> > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> > Archives: http://caml.inria.fr
> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> > Bug reports: http://caml.inria.fr/bin/caml-bugs
> >
> >
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] Dypgen C++ grammar

[Lukasz Dobrek]

Hi,
as a side question sort of related to the topic, has anybody written perhaps a
parser for Fortran. I am every once a while forced to write some
numerical code in Java ( no comments please, I know ). I would like
to have a version of f2java, as adapting the output of f2c is a pain.

Regards,
Lukasz

On 6/22/07, David Hall <dlwh@stanford.edu> wrote:
> On 6/22/07, Christopher L Conway <cconway@cs.nyu.edu> wrote:
> > Another approach would be to modify GCC so that it's intermediate
> > representation can be fed to outside tools. As a bonus, this would
> > provide support for Java, Fortran, and all the other languages
> > front-endsd in the GCC suite. Unfortunately, unless the GCC
> > maintainers have changed their position, this would require forking
> > the front end, though I suspect the changes required to implement this
> > are fairly minor. (See, e.g., this old discussion from the GCC list:
> > http://gcc.gnu.org/ml/gcc/2000-10/msg00103.html)
> >
>
> It's sort of already been done with GCC-XML:
>
> "The purpose of the GCC-XML extension is to generate an XML
> description of a C++ program from GCC's internal representation. Since
> XML is easy to parse, other development tools will be able to work
> with C++ programs without the burden of a complicated C++ parser."
>
> http://www.gccxml.org/HTML/Index.html
>
> -- David Hall
>
> >
> > On 6/22/07, skaller <skaller@users.sourceforge.net> wrote:
> > > Is anyone interested in developing a C++ parser, possibly using
> > > FrontC and/or CIL as the starting point, but using Dypgen
> > > as the parser engine?
> > >
> > > I have made some modification to FrontC/Cil to support
> > > some C++ constructions, but Ocamlyacc (LALR1) just can't cope
> > > with C++.
> > >
> > > OTOH, Scott McPeak has a C++ grammar for Elkhound which is
> > > a C++ based GLR engine, with BSD licence, so it may be possible
> > > to adapt that.
> > >
> > > --
> > > John Skaller <skaller at users dot sf dot net>
> > > Felix, successor to C++: http://felix.sf.net
> > >
> > > _______________________________________________
> > > Caml-list mailing list. Subscription management:
> > > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> > > Archives: http://caml.inria.fr
> > > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> > > Bug reports: http://caml.inria.fr/bin/caml-bugs
> > >
> > >
> >
> > _______________________________________________
> > Caml-list mailing list. Subscription management:
> > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> > Archives: http://caml.inria.fr
> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> > Bug reports: http://caml.inria.fr/bin/caml-bugs
> >
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] Dypgen C++ grammar

[Taras Glek]

Hi Scott,
Why write yet another incomplete C++ parser? You can already get a very 
nice OCaml representation of a C++ program through olmar( 
http://www.cs.ru.nl/~tews/olmar/ ).
If that doesn't suit your needs, why not point out the problems and 
maybe work together to solve them? Parsing C++ is hard enough that there 
isn't a single complete open source C++ parser other than g++. 
Olmar/elsa represent the second best C++ parser and everybody else isn't 
even close. Unlike g++, elsa is designed to support more than just 
compilers (ie has a much nicer API) and has a more liberal license.

My understanding is that there are Cil people interested in making elsa 
work better with OCaml.

If the above doesn't suit you, your best bet would be to convert the 
elsa grammar into OCaml (elkhound already has some ml support), but that 
will mean redoing a serious amount of type resolution work.

Taras

skaller wrote:
> Is anyone interested in developing a C++ parser, possibly using
> FrontC and/or CIL as the starting point, but using Dypgen
> as the parser engine?
>
> I have made some modification to FrontC/Cil to support
> some C++ constructions, but Ocamlyacc (LALR1) just can't cope
> with C++.
>
> OTOH, Scott McPeak has a C++ grammar for Elkhound which is
> a C++ based GLR engine, with BSD licence, so it may be possible
> to adapt that.
>
>   

Re: [Caml-list] Dypgen C++ grammar

[skaller]

On Mon, 2007-06-25 at 14:26 -0700, Taras Glek wrote:
> Hi Scott,
> Why write yet another incomplete C++ parser? You can already get a very 
> nice OCaml representation of a C++ program through olmar( 
> http://www.cs.ru.nl/~tews/olmar/ ).

Because last I looked, olmar doesn't work, and that's
because Elkhound and Elsa, on which they're based, don't work.
By that I mean, there are bugs. 

> If that doesn't suit your needs, why not point out the problems and 
> maybe work together to solve them? 

Elkhound and Elsa are both C++ programs, which creates 
portability issues, and the team maintaining them refused 
to cooperate with my requirements.

My system Felix consists of an Ocaml based compiler,
which generates C++ sources.

I actually have a *fork* of Elkhound built in to the
compile and run time system for generating parsers,
but this doesn't apply to parsing Felix sources:
I'm currently switching from Ocamlyacc to Dypgen as a
parser.

Frankly .. I want an embeddable Ocaml code: binding
to a C++ built executable is tricky (you'd need to
use some crud like XML as an interchange format),
and it isn't extensible.

Using Frontc/Cil, which is *also* part of Felix,
is much better -- I have already embedded part of
the C parsing capabilities directly into the Felix compiler.

The bottom line is that I want code written in Ocaml
because I'm sooooo sick of portability hassles.. :)

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Dypgen C++ grammar

[Jon Harrop]

On Tuesday 26 June 2007 07:38:44 skaller wrote:
> The bottom line is that I want code written in Ocaml
> because I'm sooooo sick of portability hassles.. :)

Perhaps your best bet is to translate an existing grammar into OCaml:

  http://www.computing.surrey.ac.uk/research/dsrg/fog/CxxLexer.l
  http://www.computing.surrey.ac.uk/research/dsrg/fog/CxxTester.y

That is only 1,320 LOC.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?e

Re: [Caml-list] Dypgen C++ grammar

[Taras Glek]

skaller wrote:
> On Mon, 2007-06-25 at 14:26 -0700, Taras Glek wrote:
>   
>> Hi Scott,
>> Why write yet another incomplete C++ parser? You can already get a very 
>> nice OCaml representation of a C++ program through olmar( 
>> http://www.cs.ru.nl/~tews/olmar/ ).
>>     
>
> Because last I looked, olmar doesn't work, and that's
> because Elkhound and Elsa, on which they're based, don't work.
> By that I mean, there are bugs. 
>   
Right, and you expect to write a C++ parser without bugs that will 
compile everybody's weird C++?

If something is complicated and has bugs, it's typically much easier to 
fix bugs than to write a competing library.
Elsa has an some interesting design decisions, but it's a well-written 
library, I don't expect to see another C++ parser parser of this quality 
anytime soon.
>   
>> If that doesn't suit your needs, why not point out the problems and 
>> maybe work together to solve them? 
>>     
>
> Elkhound and Elsa are both C++ programs, which creates 
> portability issues, and the team maintaining them refused 
> to cooperate with my requirements.
>   
I don't see why anyone would cooperate with "requirements".  I think 
between me, the olmar maintainer and the oink maintainers we can reach a 
solution that benefits everybody.
> My system Felix consists of an Ocaml based compiler,
> which generates C++ sources.
>
> I actually have a *fork* of Elkhound built in to the
> compile and run time system for generating parsers,
> but this doesn't apply to parsing Felix sources:
> I'm currently switching from Ocamlyacc to Dypgen as a
> parser.
>
> Frankly .. I want an embeddable Ocaml code: binding
> to a C++ built executable is tricky (you'd need to
> use some crud like XML as an interchange format),
> and it isn't extensible.
>   
Yes, XML stuff is elsa is a deadead, but the olmar approach is a good one.
> Using Frontc/Cil, which is *also* part of Felix,
> is much better -- I have already embedded part of
> the C parsing capabilities directly into the Felix compiler.
>   
There is a big step from C to C++. I think you are underestimating the 
difficulty of it. I don't mean to imply that you don't know C++ as even 
Stroustroup mentioned you by name in his recent report on C++. I'm just 
saying that it's a lot of work.
> The bottom line is that I want code written in Ocaml
> because I'm sooooo sick of portability hassles.. :)
>
>   
Wouldn't we all like that :)

Taras

Re: [Caml-list] Dypgen C++ grammar

[Jon Harrop]

On Tuesday 26 June 2007 21:11:17 Taras Glek wrote:
> Right, and you expect to write a C++ parser without bugs that will
> compile everybody's weird C++?

Don't be ridiculous. We expect _you_ to write a bugless C++ parser! ;-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?e