This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ANSIfy cp/parser.c


Vladimir Makarov wrote:-

> I do believe it too.  I don't want to start a flame.  With my point of
> view the combined parser is reflection of the belief that nobody is
> interested in only C compiler and the most people is interested in
> C/C++.  C++ started as a small extension of C and now C is a tiny part
> of C++.  If this belief is not true, than the separate C front-end
> results in more manageable and reliable C front-end.

Agreed.  I'm not anti-C++, I just want the best C and C++ front ends
possible.

> Do you use a compiler-compiler?  If you are writing it manually (usging
> recursive functions), then how are you going to implement syntactic
> error recovery?  What quality of the recovery do you can achieve this
> way?

I think reasonably good recovery is possible.  Just because something
is recursive descent doesn't mean you have to make it textbook 100%
recursive descent.  For example, my current expression parser unifies all
of cast-expression, unary-expression and primary-expression, but keeps
postfix-expression separate, because that makes it easy to handle a
'(', which can start 3 things: parenthesized expression, a compound
literal, or a cast.  Without unification you need backtracking or
something nasty.

However, I've not seen what error recovery is like, because I'm nothing
like that far yet 8-)  However, do you think the EDG front end's give
bad diagnostics?  IMO they're better than any other compiler I've seen
and they use RD.

> IMHO, you can not achieve a good syntactic error recover without an
> explicit parser stack.  Also I think that the current computers permit
> to implement a minimal cost error recovery now (actually the slowdown
> occurs if a syntax error is found).  Such implementation needs a
> backtracking to evaluate different alternatives of the recovery.

Let's see.

> Also it is good to have C parser as an abstract component.  It could use
> it not only for gcc (it might result in creation of another free C
> compiler -- it is good for gcc to have another free c compiler as a
> competitor).

Indeed.  I think GCC needs competition; it's getting a bit fat and lazy.

> You can ignore these ideas and questions - it is your implementation.  I
> know how front-end implementation is difficult and boring. 

Au contraire, I'm finding it fun and interesting.  But I've not done it
before, and I've not studied CS, so it's not old-hat to me.

Neil.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]