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



Jon Paris wrote:
>> The explanation given is that free-form is too hard to parse.

Where did you get this "explanation" Joe?  The fact that the syntax checker
wasn't working was quite a surprise to me - perhaps because I tend to verify
so frequently I just hadn't noticed.  It strikes me as a (hopefully)
temporary aberration caused by a resource shortage.  Much like the horrible
state of the V5R2 RPG documentation in CODE (haven't checked in jLPEX) which
omits a whole bunch of stuff like %KDS and has a number of simple errors
like the bits on using a DS as a result field.

Jon: Where did Joe get that? Probably from one of my postings on MCPressOnline. The URL is:


http://www.mcpressonline.com/mc?128%40%40.6ae739e2%21SearchMark=1%231

(MCPressOnline's URL's are a bit of a pain since they don't properly encode the query string. urllib.quote() comes in handy in situations like this.)

For those without web access, I'll repeat my answer here:

=================================================================
Syntax checking of free-form RPG?

Short answer: It doesn't.

Why not? The problem is that if the syntax checker were asked to check a line in a free-form calc, it would have to scan backwards through the source to find the beginning of the statement. Because of the continuation rules for free-form statements, the rules for end-of-line comments, and the rules for continuing literals, the only way to properly find the beginning of the statement would be to scan back all the way to the beginning of the /FREE block and then scan forwards. The delay in this operation might well be quite noticable if the current /FREE block was big.

On the other hand, since you don't have to worry about coding things in particular columns, and since there's not much syntax checking for expressions anyways, syntax checking for free-form statements probably wouldn't give you much benefit anyways, even if we could come up with a way to quickly identify the beginning of the statement.

Cheers! Hans
=================================================================

To summarize:

1) Doing a fast syntax check of a free-form statement may well be impossible because of the syntax rules of the language. The delay in checking would steadily increase as the size of your /free block grows.

The problem is to try to locate the beginning of a statement from some arbitrary point in the source. Think about scanning backwards to locate the previous semi-colon. If you find a semi-colon, how can you tell that it's not within a comment or a character literal? Or, if you find an apostrophe, how can you tell if it begins or ends a literal? If you could come up with some algorithm, would it work for syntactically invalid source as well as valid source? (There's no point is syntax checking if you know your source is good already!)

2) Syntax checking would provide less benefit for free-form calcs than for fixed-form calcs anyways simply because the syntax rules are less restrictive.

3) As I'm sure you already know, in development, more emphasis is being placed on improving the workstation based tools.

Cheers! Hans



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.