Related articles |
---|
Using Bison and Delphi mikehahn@rogers.com (Mike Hahn) (2004-11-17) |
Re: Using Bison and Delphi vbdis@aol.com (2004-11-19) |
Re: Using Bison and Delphi mikehahn@rogers.com (Mike Hahn) (2004-11-20) |
Re: Using Bison and Delphi vbdis@aol.com (2004-11-26) |
Re: Using Bison and Delphi vbdis@aol.com (2004-11-28) |
Re: Using Bison and Delphi jeremy.wright@microfocus.com (Jeremy Wright) (2004-11-28) |
Re: Using Bison and Delphi mikehahn@rogers.com (Mike Hahn) (2004-12-05) |
Re: Using Bison and Delphi strohm@airmail.net (John R. Strohm) (2004-12-06) |
Ada use of parens vs brackets arnold@skeeve.com (Aharon Robbins) (2004-12-11) |
[2 later articles] |
From: | "Mike Hahn" <mikehahn@rogers.com> |
Newsgroups: | comp.compilers |
Date: | 20 Nov 2004 21:21:38 -0500 |
Organization: | Compilers Central |
References: | 04-11-060 04-11-071 |
Keywords: | Pascal, parse, yacc |
Posted-Date: | 20 Nov 2004 21:21:37 EST |
"VBDis" <vbdis@aol.com> wrote:
> The omission of punctuation between identifiers (dot operator,
> argument list separator...) may cause more trouble than it's worth -
> worth what at all? Since all tokens (identifiers...) must be separated
> somehow, it doesn't make a big difference whether the separation
> character is a space, dot, comma or whatsoever. Distinct separation
> characters, instead of only whitespace, also allow for easier parsing
> (less lookahead) and better diagnostics and error recovery.
I disagree that the omission of the Java dot operator (making it
implied) is a language flaw. If the first token (at the statement
level) is an identifier, then the parser knows that a procedure call
is coming. If the first token (at the expression level) is an
identifier, then the parser knows that a function call is
coming. Examples:
foo myproc (arg1, arg2,... );
= foo (bar myfunc (arg1, arg2,... ));
= foo (bar func1 (arg1, arg2,... ) func2 (arg1, arg2,... ));
The first statement calls the myproc procedure of the foo object. The second
statement calls the myfunc function of the bar object, and assigns the
result to the foo variable. The third statement calls func1, which returns
an object having a method called func2. It then calls func2, and assigns the
result to the foo variable.
Maybe doing it this way is slightly harder to parse, but it enhances
the simplicity of the language, in my opinion.
Mike Hahn
Return to the
comp.compilers page.
Search the
comp.compilers archives again.