|
Hans, thanks for the very concise explanation. Thanks, Mark Mark D. Walter Senior Programmer/Analyst CCX, Inc. mwalter@xxxxxxxxxx http://www.ccxinc.com Hans Boldt <boldt@xxxxxxxxxx> To: rpg400-l@xxxxxxxxxxxx Sent by: cc: rpg400-l-bounces@xx Subject: Re: /free snafu drange.com 06/25/2003 08:24 AM Please respond to RPG programming on the AS400 / iSeries 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 is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.
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.