Re: Using Bison and Delphi

"Mike Hahn" <mikehahn@rogers.com>
20 Nov 2004 21:21:38 -0500

          From comp.compilers

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]
| List of all articles for this month |

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


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.