Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #28315

Re: Parser

Show all headers | View raw

On 4/29/2014 3:15 PM, Roedy Green wrote:
> On Mon, 28 Apr 2014 11:30:45 +0200, Silvio <silvio@internet.com>
> wrote, quoted or indirectly quoted someone who said :
>
>>
>> The fact that a no such keywords exist does not make parsing slower by
>> definition. In the Java case it unlikely that such keywords would make
>> parsing faster. The language grammar defines how fast a parser can be.
>> Although the Java grammar is not strictly LALR(x) Java can be parsed
>> pretty left-to-right with the use of some simple tweaks and assumptions
>> to prevent expensive things like backtracking
>
> Consider how far you have to parse into definition to tell if you have
> a variable or a method definition.

A hand-written recursive-descent parser (which is what almost all 
production compilers use, since you can't get good error messages out of 
an automatic parser generator and you don't want to write anything other 
than recursive-descent by hand) can easily disambiguate it. You start by 
parsing a specifier sequence, then a type, then the name, and you call 
this set a declarator. The distinction between a method and a variable 
is that a method is immediately followed by a ( paren whereas a variable 
can be followed by a ,, =, or ;.

[Java 1.0 is definitely LALR(1). Someone claims to have a Java 5 LALR(1) 
grammar, and I think Java 7 is LALR(1) as well. Don't know about Java 8. 
It also slightly depends on whether or not you consider, e.g., 
inappropriate specifiers to be syntactic or semantic issues.]

> An IDE could insert visible markers to mark the begins and end of
> things. I must waste at least an hour a day trying to figure out which
> { } balances with what.  It is not a task my eyes can do, especially
> when the other half is offscreen.
>
> Another solution would be a SCID which would not let you cut/copy
> paste an unbalanced block of code.  You would think of program as
> composed on units -- like plumbing, not a stream of characters.

Neither of these tasks require much parsing, just lexing and keeping 
track of balanced [/</{/( tokens. Unlike C or C++, it's basically 
illegal to construct program fragments that correspond to single AST 
productions that have mismatched parentheses.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Parser Roedy Green <see_website@mindprod.com.invalid> - 2014-04-27 15:46 -0700
  [LONG POST] Re: Parser Jeff Higgins <jeff@invalid.invalid> - 2014-04-27 19:59 -0400
    Re: [LONG POST] Re: Parser Jeff Higgins <jeff@invalid.invalid> - 2014-04-27 20:00 -0400
    Re: [LONG POST] Re: Parser Roedy Green <see_website@mindprod.com.invalid> - 2014-04-28 02:09 -0700
  Re: Parser Silvio <silvio@internet.com> - 2014-04-28 11:30 +0200
    Re: Parser Roedy Green <see_website@mindprod.com.invalid> - 2014-04-29 13:15 -0700
      Re: Parser Joerg Meier <joergmmeier@arcor.de> - 2014-04-29 22:55 +0200
        Re: Parser Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-05-05 08:13 +0000
      Re: Parser Jeff Higgins <jeff@invalid.invalid> - 2014-04-29 18:28 -0400
        Re: Parser Jeff Higgins <jeff@invalid.invalid> - 2014-04-29 18:35 -0400
      Re: Parser Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-04-29 17:31 -0500
      Re: Parser Simon Lewis <simonlewis2001@gmail.com> - 2014-04-30 15:13 +0200

csiph-web