Re: /free snafu

[Hans Boldt <boldt@xxxxxxxxxx>]

MWalter@xxxxxxxxxxxxxxx wrote:
> I've found a little problem with /free
>
> This statement is not OK:
>      delete = 'Y';
> However this one is:
>      eval delete = 'Y';
>
> You mean to tell me that the compiler can't see that this is an assignment
> instruction?

The compiler uses an LL(1) style (top-down) parser to parse 
expressions, as well as many statements in free-form calcs. To 
summarize the problem in differentiating possible parses, consider 
the following scenario: Let's say we didn't have reserved words and 
we've read "DELETE" so far. Is it an assignment statement, a delete 
statement, or a procedure call? We don't know yet. We read the next 
token, and we see we have "DELETE(", and we still can't tell what we 
have. Continuing, we see "DELETE(E", and still it could be any of 
the three alternatives. Then, we see "DELETE(E)", and guess what, it 
could still be any of the three choices! It's not until the next 
token that we can tell: a) "DELETE(E) =", b) "DELETE(E);", or c) 
"DELETE(E) NAME", "DELETE(E) (", or "DELETE(E) %KDS". (Also note 
that that last token could be several source records removed from 
the start of the statement.)

The difficulty in this is that you'd like to know as soon as 
possible which grammar rules to follow. Parsing a DELETE statement 
is clearly different than parsing an EVAL or CALLP. By the time you 
could tell the difference, you're well into the statement already. 
In the example above, for instance, the symbol E has a much 
different meaning in a DELETE statement than in the other alternatives.

Sure, the compiler could possibly be enhanced to be able to 
differentiate the cases. But it would involve a lot of fancy 
footwork, back-tracking, and back-patching, all of which would 
likely be error prone. To simplify the situation, we simply assume 
that if a statement begins with the name of a particular opcode, the 
name represents that opcode.

Cheers! Hans