Re: AW: gnubol: SEARCH and EVALUATE (IBM COBOL for MVS)

[RKRayhawk@aol.com]

In a message dated 12/13/99 5:39:10 PM EST, SiedentopC@Alte-Leipziger.de 
writes:

<< 
  ==000016==> IGYPS2112-E The "EVALUATE" verb did not have a matching scope
 terminator.  A scope
                          terminator was inserted on line 24.  The execution
 results may not be
                          correct.
  >>

I would like to note in passing that this particular vendor is flagging 
several distinct situations with a single error number: IGYPS2112. 

It may be easily possible for us to make distinctions, we will defnitely need 
specific code to detect specific implied terminations. This is noteworthy 
because the implied termination of an EVALUATE without a WHEN OTHER probably 
should not be recovered, where as it may be reasonable to recover whilst 
trapping an implied terminator for an EVALUATE that does have that alternate 
clause. 

If we had a gnubol error message system that externalized the severity code 
we could flag the implied end of an EVALUATE that has a clarifying WHEN OTHER 
clause (W level message in IBM parlance), and error out the more hopeless 
case (E level message in IBM parlance).

I am confident the whole discussion is way out ahead of the actual grammar 
work, and do not mean to insult the hardworkers there on with presumptuous 
dreams about fancy diagnostics capability. But to be truthful I we actually 
do any of this we could actuall set the standard and set it right. That may 
be worth doing as a matter of pride.  

I would suggest not only a different error number for the two distinct 
EVALUATE implied end, but I would make each conditional potent verb have a 
different error number when getting implicated.  That would set up the 
possibility that a user can set some (for example all the EVALUATE wierdos) 
to Error rejects, while allowing certain others as Warning extensions. That 
would be in keeping with the UNIX config tradition. But there is more.

Really there is a separate, small but important, legitimacy issue here when 
nesting like family verbs unconditionally. We do not have to actually code 
this much sophistication in the begining, but if we isolate the implied ends 
uniquely for each verb; we can eventually also detect when like verbs are 
being nested in the implied end situations and acutally flag those with yet 
another specifc user configurable error code.

If we generalize enough and start on a path of external control of the 
diagnostic severity, future workers could enhance this in a way that deals 
with the very refined issues of deeply nested implied end. In other words, if 
we open Pandora's box, _maybe_, we should accept responsibility for setting 
up a plan to return any escaping monsters.

We do not have to do all this work to set the proper ground work. I am saying 
specifically that implied end to an arithmetic could be a different message 
then implied end to an I/O. The user, if she is into config culture, would 
probably like that. In a similar vain I am saying that implied end to a one 
part EVALUATE (any number of WHENs is still just the single front part), can 
be a distinct diagnostic number from implied end of a two part EVALUATE. The 
grammar has to be that complex to be robust (do you see how that eases the 
pain).

Later we can start to make fancy distinctions, like an implied end to ADD 
within and implied end to ADD is perhaps a different message number. Later I 
am saying.  That is one of Pandora's monsters. A config afficionado who wants 
that back in the box might modify our default release severity code from W to 
an E.  

There are complications in some of these situations, I am not saying code for 
these today. But even an implied end to a single part EVALUATE is not 
necessarily bad, depending upon context. If we have the right groundwork, 
later resources might be able to distinguish when this weak EVALUATE is 
reducing in harmless conditions, and tag it with a specific message that can 
optionally own a Warning attribute. And still also detect when the reduction 
occurs in destructive situations, like within another EVALUATE or within a 
SEARCH.

We do not have to code that much complexity now. But in a sense there is a 
ethical issue here between us and the users of the tool. If we consider 
opening Pandora's box, we might be the ones responsible for atleast 
specifying how to get specifically offensive monsters back in.

In general I think we should be circumspect about same verb nesting (when all 
unterminated), but we have a code base issue (small put relevant to the 
success criteria of getting folks to use this thing). Yet I do not think that 
nested EVALUATEs within EVALUATEs are evil. And I wonder if it might not be 
useful to allow dual branched unterminated EVALUATEs to reduce successfully 
and go to code gen (under user controlled config).

It is a strange thing to say, but I believe in the lazy programmer. They are 
real and they represent an economy.  Stated differently major organizations 
face the difficult fact that there are not enough unlazy people. That has 
economic implications.  

The grammar has to be complex anyway. We can explicate the more refined error 
codes later. We already must be able to detect every kind of 'lazy' 
unterminated situation inside of every possible nesting.  If we are somewhat 
specific about the error codes now, we could be more specific later on.

Best Wishes,
Bob Rayhawk
RKRayhawk@aol.com

--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.