Related articles |
---|
Writing a recursive descent parser in C bilbo@volcanomail.com (2001-11-29) |
Re: Writing a recursive descent parser in C spinoza1111@yahoo.com (2001-12-03) |
Re: Writing a recursive descent parser in C joachim_d@gmx.de (Joachim Durchholz) (2001-12-07) |
Re: Writing a recursive descent parser in C lingolanguage@hotmail.com (Bill Rayer) (2001-12-07) |
Re: Writing a recursive descent parser in C dr_feriozi@prodigy.net (SLK Parsing) (2001-12-07) |
Re: Writing a recursive descent parser in C alexc@world.std.com (2001-12-11) |
Re: Writing a recursive descent parser in C spinoza1111@yahoo.com (2001-12-11) |
From: | alexc@world.std.com (Alex Colvin) |
Newsgroups: | comp.compilers |
Date: | 11 Dec 2001 21:05:08 -0500 |
Organization: | The World Public Access UNIX, Brookline, MA |
References: | 01-11-146 01-12-008 01-12-020 |
Keywords: | C, parse |
Posted-Date: | 11 Dec 2001 21:05:08 EST |
>I'm interested that some 4GLs mix up the scanning and parsing stages.
>What 4GLs do you consider to be most deficient in this way? And what
i'm not sure whether Perl5 is 4GL or 5GL or what, but
If any list operator (such as print) or any named
unary operator (such as chdir) is followed by a
left parenthesis as the next token on the same line,
the operator and its arguments are taken to be of
highest precedence, just like a normal function call.
The rule is: if it *looks* like a function call,
it is a function call.
I'm not sure that it's deficient, but it can be tricky.
Come to think of it, I've never seen a grammar for perl.
--
mac the naïf
[Perl has an incredibly ugly and irregular grammar. The most amazing
thing about it is that perl programs invariably parse the way you think
they will. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.