public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
To: ttn@gnu.org
Cc: gcc@gcc.gnu.org
Subject: Re: C/C++ front-end extension a la SWIG?
Date: Thu, 29 Jun 2000 13:43:00 -0000	[thread overview]
Message-ID: <200006292023.WAA01313@loewis.home.cs.tu-berlin.de> (raw)
In-Reply-To: <200006291544.IAA32009@revel.glug.org>

> 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

  parent reply	other threads:[~2000-06-29 13:43 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-28 17:24 thi
2000-06-29  0:45 ` Martin v. Loewis
2000-06-29  1:14   ` Mark Mitchell
2000-06-29  6:25     ` Daniel Berlin
2000-06-29 10:36       ` Mark Mitchell
2000-06-29 10:54         ` thi
2000-06-29 11:29           ` Mark Mitchell
2000-06-29  8:48   ` thi
2000-06-29 11:58     ` Andi Kleen
2000-06-29 12:22       ` Daniel Berlin
2000-06-29 12:24         ` Andi Kleen
2000-06-29 12:28           ` Daniel Berlin
2000-06-29 13:43     ` Martin v. Loewis [this message]
2000-06-29 15:09       ` Daniel Berlin
2000-07-05 17:48 Mike Stump
2000-07-06 11:19 ` Laurent Guerby
2000-07-10 17:17 ` thi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200006292023.WAA01313@loewis.home.cs.tu-berlin.de \
    --to=martin@loewis.home.cs.tu-berlin.de \
    --cc=gcc@gcc.gnu.org \
    --cc=ttn@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).