×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
