× 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.



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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.