Re: C/C++ front-end extension a la SWIG?

Re: C/C++ front-end extension a la SWIG?

[Mike Stump]

> Date: Wed, 28 Jun 2000 17:21:39 -0700
> From: thi <ttn@revel.glug.org>

> i understand gcc backend is unlikely to be librarified (from reading
> the thread: http://gcc.gnu.org/ml/gcc/2000-01/msg00257.html ), but
> how about the C/C++ front-end?  what i'd like is to be able to
> integrate guile w/ the parser so as to be able to map .h
> declarations to make glue code.

> this is similar to what swig ( http://www.swig.org ) currently does,
> but i'm thinking it would be better to use the widely used and
> tested parser from gcc than the swig parser, which does not grok
> many C++isms.

> does this make sense?  is there anyone working on something like
> this?  would this kind of work be harmful to the free software
> community?  is there a better approach (that allows me to use the
> gcc parser)?

How about this, we settle on something like swig, and have gcc/g++
generate swig friendly data into a file, and then have swig read that
file and generate what it needs to.  The xref stuff in the compiler
might be worth dusting off, it might be kinda like what one wants
(I've not thought about this much, I've not studied swig).  Should be
fairly low maintenance, can be used/reused for other languages
(GNU Fortran/GNU Ada...)

Re: C/C++ front-end extension a la SWIG?

[Laurent Guerby]

> Should be fairly low maintenance, can be used/reused for other
> languages (GNU Fortran/GNU Ada...)

GNU Ada already generates full xref information in simple text files
(that are used by the Emacs Ada mode for navigating, and various msic
tools). 

Also in the Ada case, there is a standard called ASIS that defines an
Ada API to access to all the compiler information about a program, and
GNU Ada provides an implementation called ASIS for GNAT.

I don't know the situation on the GNU Fortran side.

-- 
Laurent Guerby <guerby@acm.org>

Re: C/C++ front-end extension a la SWIG?

[thi]

   From: Mike Stump <mrs@windriver.com>
   Date: Wed, 5 Jul 2000 17:47:55 -0700 (PDT)

   How about this, we settle on something like swig, and have gcc/g++
   generate swig friendly data into a file, and then have swig read that
   file and generate what it needs to.  The xref stuff in the compiler
   might be worth dusting off, it might be kinda like what one wants
   (I've not thought about this much, I've not studied swig).  Should be
   fairly low maintenance, can be used/reused for other languages
   (GNU Fortran/GNU Ada...)

this sounds ideal.  i suppose the next step would be for me to grab gcc
source and have a look around...  could you recommend where to begin?

thanks,
thi

C/C++ front-end extension a la SWIG?

[thi]

hello gcc list,

i understand gcc backend is unlikely to be librarified (from reading the
thread: http://gcc.gnu.org/ml/gcc/2000-01/msg00257.html ), but how about
the C/C++ front-end?  what i'd like is to be able to integrate guile w/
the parser so as to be able to map .h declarations to make glue code.

this is similar to what swig ( http://www.swig.org ) currently does, but
i'm thinking it would be better to use the widely used and tested parser
from gcc than the swig parser, which does not grok many C++isms.

does this make sense?  is there anyone working on something like this?
would this kind of work be harmful to the free software community?  is
there a better approach (that allows me to use the gcc parser)?

thanks,
thi

Re: C/C++ front-end extension a la SWIG?

[Martin v. Loewis]

> does this make sense?

In my opinion, separating the C++ front-end from gcc is
pointless. What you get is more or less the parser, and the g++ parser
is not something you want to use unless you really have to. There are
a number of other good C++ parsers - I'd consider those first if I
needed one for a project.

Regards,
Martin

Re: C/C++ front-end extension a la SWIG?

[Mark Mitchell]

>>>>> "Martin" == Martin v Loewis <martin@loewis.home.cs.tu-berlin.de> writes:

    >> does this make sense?

    Martin> In my opinion, separating the C++ front-end from gcc is
    Martin> pointless. What you get is more or less the parser, and
    Martin> the g++ parser is not something you want to use unless you
    Martin> really have to. There are a number of other good C++
    Martin> parsers - I'd consider those first if I needed one for a
    Martin> project.

I rather strongly disagree -- at least if we're talking about the
future.

The G++ parser will always be very useful for one thing: parsing the
code the same way that G++ does.  For example, one can imagine hooking
it into GDB so that you could type C++ expressions at GDB for
interpretation; GDB would use the G++ front-end to parse the
expression, and then interpret the tree structure.  A source-browser
designed to work with G++ could use the G++ parser, and be sure to
handle G++ extensions and bugs just like G++.

As the parser itself (in the sense of the bison bits) are replaced
(and they will be, they will be) then this will become even more
useful.

There is no reason the G++ front-end cannot be as useful in the free
software community as the EDG front-end has been in other communities,
for example.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: C/C++ front-end extension a la SWIG?

[Daniel Berlin]

> 
> I rather strongly disagree -- at least if we're talking about the
> future.
> 
> The G++ parser will always be very useful for one thing: parsing the
> code the same way that G++ does.  For example, one can imagine hooking
> it into GDB so that you could type C++ expressions at GDB for
> interpretation; GDB would use the G++ front-end to parse the
> expression, and then interpret the tree structure.

I've looked at doing this before, to fix a few p roblems with the gdb
expression evaluator.
The parser is too much of a mess, no offense.

< A source-browser
> designed to work with G++ could use the G++ parser, and be sure to
> handle G++ extensions and bugs just like G++.
>

Same here, except the parser is also too slow for my taste.
> As the parser itself (in the sense of the bison bits) are replaced
> (and they will be, they will be) then this will become even more
> useful.

I agree here.
Please, for the love of god, replace the parser.
> 
> There is no reason the G++ front-end cannot be as useful in the free
> software community as the EDG front-end has been in other communities,
> for example.

I wait for the day.
> 
> --
> Mark Mitchell                   mark@codesourcery.com
> CodeSourcery, LLC               http://www.codesourcery.com
> 

Re: C/C++ front-end extension a la SWIG?

[Mark Mitchell]

>>>>> "Daniel" == Daniel Berlin <dan@cgsoftware.com> writes:

    >>  I rather strongly disagree -- at least if we're talking about
    >> the future.
    >> 
    >> The G++ parser will always be very useful for one thing:
    >> parsing the code the same way that G++ does.  For example, one
    >> can imagine hooking it into GDB so that you could type C++
    >> expressions at GDB for interpretation; GDB would use the G++
    >> front-end to parse the expression, and then interpret the tree
    >> structure.

    Daniel> I've looked at doing this before, to fix a few p roblems
    Daniel> with the gdb expression evaluator.  The parser is too much
    Daniel> of a mess, no offense.

I'm not insulted.

What you say is becoming considerably less true.  It is one of
CodeSourcery's long-term goals to split out the G++ front-end in a
considerably cleaner way.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: C/C++ front-end extension a la SWIG?

[thi]

   From: Mark Mitchell <mark@codesourcery.com>
   Date: Thu, 29 Jun 2000 10:36:21 -0700

   >>>>> "Daniel" == Daniel Berlin <dan@cgsoftware.com> writes:

       Daniel> I've looked at doing this before, to fix a few p roblems
       Daniel> with the gdb expression evaluator.  The parser is too
       Daniel> much of a mess, no offense.

   I'm not insulted.

   What you say is becoming considerably less true.  It is one of
   CodeSourcery's long-term goals to split out the G++ front-end in a
   considerably cleaner way.

if i read you correctly, "is becoming" means ongoing work.  is this work
public?  (how can i help?)

thanks,
thi

Re: C/C++ front-end extension a la SWIG?

[Mark Mitchell]

>>>>> "thi" == thi  <ttn@revel.glug.org> writes:

    thi> if i read you correctly, "is becoming" means ongoing work.

Yup.

    thi> is this work public?  (how can i help?)

Yup.  Submit patches to make it look more like what you think it
should. :-)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: C/C++ front-end extension a la SWIG?

[thi]

   From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
   Date: Thu, 29 Jun 2000 09:40:24 +0200

   In my opinion, separating the C++ front-end from gcc is pointless.
   What you get is more or less the parser, and the g++ parser is not
   something you want to use unless you really have to.  There are a
   number of other good C++ parsers - I'd consider those first if I
   needed one for a project.

any particular recommendations?

btw, is the undesirability of the gcc C++ parser related to its
implementation or to its interface (or both)?  if the implementation is
bad but the interface is ok, perhaps over time the code will change so
that both are ok.

thi

Re: C/C++ front-end extension a la SWIG?

[Andi Kleen]

thi <ttn@revel.glug.org> writes:

>    From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
>    Date: Thu, 29 Jun 2000 09:40:24 +0200
> 
>    In my opinion, separating the C++ front-end from gcc is pointless.
>    What you get is more or less the parser, and the g++ parser is not
>    something you want to use unless you really have to.  There are a
>    number of other good C++ parsers - I'd consider those first if I
>    needed one for a project.
> 
> any particular recommendations?

OpenC++ and the Tendra C++ frontend look reasonably clean (the later is writen
using a strange lexer/parser generator though) OpenC++ uses a bison parser, but
it seems to use much less hacks than the g++ frontend to parse the difficult
parts in C++'s syntax.

Both do not parse all g++ language extensions.


-Andi 

Re: C/C++ front-end extension a la SWIG?

[Daniel Berlin]

> 
> OpenC++ and the Tendra C++ frontend look reasonably clean (the later is writen
> using a strange lexer/parser generator though) OpenC++ uses a bison parser, but
> it seems to use much less hacks than the g++ frontend to parse the difficult
> parts in C++'s syntax.
> 
> Both do not parse all g++ language extensions.
> 

Um, what?
OpenC++ uses a hand coded, very nice, LL(k) (k= mostly 1, occasionally
2) C++ parser.
It's acutally a great example of how to hand code a C++ parser.

TEndra uses their own parser generateor, which is very difficult to
understand.


> 
> -Andi 
> 

Re: C/C++ front-end extension a la SWIG?

[Andi Kleen]

On Thu, Jun 29, 2000 at 12:21:55PM -0700, Daniel Berlin wrote:
> > 
> > OpenC++ and the Tendra C++ frontend look reasonably clean (the later is writen
> > using a strange lexer/parser generator though) OpenC++ uses a bison parser, but
> > it seems to use much less hacks than the g++ frontend to parse the difficult
> > parts in C++'s syntax.
> > 
> > Both do not parse all g++ language extensions.
> > 
> 
> Um, what?
> OpenC++ uses a hand coded, very nice, LL(k) (k= mostly 1, occasionally

Not the version I have here:

 -rw-r--r--   chiba/parc      38678 openc++-2.3/src/parser.y


It is still a relatively nice parser (the backtracing via the lexer is not too
complicated) 


-Andi

Re: C/C++ front-end extension a la SWIG?

[Daniel Berlin]

> 
> Not the version I have here:
> 
>  -rw-r--r--   chiba/parc      38678 openc++-2.3/src/parser.y
> 
> 
> It is still a relatively nice parser (the backtracing via the lexer is not too
> complicated) 

That version is quite a few years old.
Try 2.5.8, just released 6/26

/*
   C++ Parser

   This parser is a LL(k) parser with ad hoc rules such as
   backtracking.

   r<name>() is the grammer rule for a non-terminal <name>.
   opt<name>() is the grammer fule for an optional non-terminal <name>.
   is<name>() looks ahead and returns TRUE if the next symbol is <name>.
*/


> 
> 
> -Andi
> 

Re: C/C++ front-end extension a la SWIG?

[Martin v. Loewis]

> any particular recommendations?

I know one of them was announced to comp.lang.c++.moderated or
comp.std.c++ not too long ago - but I forgot the details.

> btw, is the undesirability of the gcc C++ parser related to its
> implementation or to its interface (or both)?  if the implementation is
> bad but the interface is ok, perhaps over time the code will change so
> that both are ok.

Depends on where you put the interface. The part that leads up to tree
generation is excellent - it has been proven that the same interface
can be used for multiple programming languages, and that from that
interface, middle-end and back-end can generate to many target chips.

If you put the interface before tree generation (i.e. in the set of
functions called and used by the parser proper), then this is likely
to change when the parser is replaced.

So if you want to take the g++ front-end as a whole, then I would
agree with Mark - that might be certainly useful, and could get well
the same position as the EDG front-end.

Rethinking it, a parser only (i.e. a syntax analyser) for C++ cannot
work at all. You always need semantical analysis to find out what the
type names are, or you couldn't tell apart cases like

  a*b;
  c<d,e>f;

Readers familiar with C++ but not too familiar with C++ parsing are
encouraged to find two completions of this program, so that each line
means something completely different in each program :-)

That, in turn, means that you need a significant part of the g++ front
end - in fact, there isn't much you could leave out.

Regards,
Martin

Re: C/C++ front-end extension a la SWIG?

[Daniel Berlin]

> 
> Rethinking it, a parser only (i.e. a syntax analyser) for C++ cannot
> work at all. You always need semantical analysis to find out what the
> type names are, or you couldn't tell apart cases like
> 
>   a*b;
>   c<d,e>f;
> 
> Readers familiar with C++ but not too familiar with C++ parsing are
> encouraged to find two completions of this program, so that each line
> means something completely different in each program :-)
> 
> That, in turn, means that you need a significant part of the g++ front
> end - in fact, there isn't much you could leave out.

Right, in the case of G++, you'd be better off doing a "syntax only" pass,
and walking the tree.

It also depends on how much analysis you need to do.
If you are trying to make a SWIG like generator, you don't need to
actaully parse/analyze the function bodies, only the definitions.

In the case of C++ source to soure translators, which is what he's
talking about, he'd be better off working within the framework of
OpenC++, which was built for this sort of thing, and does handle all the
proper analysis.

It specifically lets you do the kind of walking/transforming he's kinda
looking to do.

> > Regards,
> Martin
>