Browse thread
yacc style
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | skaller <skaller@u...> |
| Subject: | Re: [Caml-list] yacc style |
On Fri, 2005-01-28 at 13:28, Erik de Castro Lopo wrote: > On 28 Jan 2005 12:14:39 +1100 > skaller <skaller@users.sourceforge.net> wrote: > > > On Fri, 2005-01-28 at 08:39, Erik de Castro Lopo wrote: > > > > > > Yes, normally the parser generates a parse tree which is then > > > passed to the semantic analyser for semantic checking. > > > > Unfortunately this is useless in the common case > > of needing to parse C. > > I'm happy to take your word for it John, but I'd like to know > why. Sure: there are several contexts, but one is that: (X)(Y)(Z) could mean either ((X)(Y))(Z) or (X)((Y)(Z)) depending on whether Y is a type, in which case (Y)(Z) is a cast, or an expression, in which case (Y)(Z) is a function application. The precedences of casts and function applications in C are different. Function calls bind more tightly than casts, so (int)(f)(x) means cast the result of f(x) to an int, whereas (g)(a)(b) means apply g(a) to b .. assuming g,a,b are not typenames .. :) Smly (f)(x,y,z) comma is a separator if f is a function, if f is a typename its a cast, and (x,y,z) is an expression value 'z'... :) I guess there is more, and C++ is worse, but this is enough to be as confused as a one token lookahead context free parser would be .. :) -- 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