|Using Bison and Delphi email@example.com (Mike Hahn) (2004-11-17)|
|Re: Using Bison and Delphi firstname.lastname@example.org (2004-11-19)|
|Re: Using Bison and Delphi email@example.com (Mike Hahn) (2004-11-20)|
|Re: Using Bison and Delphi firstname.lastname@example.org (2004-11-26)|
|Re: Using Bison and Delphi email@example.com (2004-11-28)|
|Re: Using Bison and Delphi firstname.lastname@example.org (Jeremy Wright) (2004-11-28)|
|Re: Using Bison and Delphi email@example.com (Mike Hahn) (2004-12-05)|
|Re: Using Bison and Delphi firstname.lastname@example.org (John R. Strohm) (2004-12-06)|
|From:||Jeremy Wright <email@example.com>|
|Date:||28 Nov 2004 23:20:49 -0500|
|References:||04-11-060 04-11-071 04-11-078|
|Posted-Date:||28 Nov 2004 23:20:49 EST|
Mike Hahn wrote:
> "VBDis" <firstname.lastname@example.org> 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
Without distinct separators how does one parse the following
Is this one argument, a-b, or two arguments, a, and -b
Same applies to subscripts.
Incidentally, Cobol does not require seperators between subscripts. As
Cobol 85 restricted subscripts to "var [ +/- constant ]" one can
disambiguate, buts its messy and annoying.
Return to the
Search the comp.compilers archives again.