Re: gnubol: problem 2.

[RKRayhawk@aol.com]

In a message dated 12/27/99 3:09:33 PM EST, tej@melbpc.org.au writes:

<< 
 > (FUNCTION X (A (B))) You must apply the rules
 > associated
 > with the external definition of the function's signature to know if the
 > source code is right.
 
 Let's say X takes two numeric parameters, but A is an array of
 numerics. The error is ambiguous. It could be 'a should have
 array index specified' or 'X needs two parameters'. Now if B is
 not a valid array index expression, it is even worse. It should
 be clear, the programmer believes, that he forgot the array
 index. This is where the ambiguous syntax messes you up. C++ and
 Fortran have the same problem. It affects programmer productivity
 because error messages get very speculative.
 
 Tim Josling
  >>

You are right. But the list idea may still be useful to us. The question, in 
part, is how much should be done in syntax, and how much in semantics? The 
EVALUATE WHEN clause topology is instructive here, even though it seems far 
afield, it is a comparable design challenge.

In any given situation how many ALSO phrases are allowed in a WHEN clause?  
It depends upon the information presented dynamically by the source code in 
the list of 'subjects' in the EVALUATE header.  Well, that does not sound 
like a grammar rule.  And even if the header has five subjects, we need to 
stay on our feet when we see twenty in a WHEN clause. So that maybe has to go 
onto a list that is either shunted at the limit, or scanned afterwards for 
proper 'form' (min and max count). Once we begin to abstract that we see 1) 
it could be done in syntax or semantics or a little of both, and 2) it is not 
entirely unlike the function call problem. 

(In a mild way the requirement is comparable to the USING clause parsing 
requirements, where we have a possibility of doing some signature checking, 
which regrettably is not supported in the standard. And also I don't think we 
can get munged on something like
   ... USING 
         data_name
         (am_I_data_ref_or_subscript)
         data_name
but that too is worth cogitating. Yet even though we do not have CALL 
signature check 
requirements in the syntax area, we may need that for runtime debugging 
support, ... or is that too dreamy?  If not we have a number of specialized 
data list review needs, and we may wish to generalize the solution, which 
could help in function argument validation).    
   
If I see the problem you are talking about with function arguments, then 
probably we should reduce the pieces of the arguments under much more 
reductive rules than normal data references, and let manual code in actions 
or semantics decide how to put it back together.

So the answer is use different rules. Normal data references attempt to shift 
open paren on to an array reference, function arguments do not, they reduce, 
and function arguments also look for expression like references such as (B) 
as an item on the list.

The alternative to manual code in the actions (or semantics interpolation of 
the list) is to have a complete enumeration of all functions in the grammar, 
which may be feasible today, but I don't know what legacy that leaves.

Those familiar with standards in process may wish to comment on how much the 
list of standard FUNCTIONs is about to expand

It may be possible to get a better handle on this if we begin to think of the 
FUNCTION grammar as distinct from the rest of the procedure division grammar. 
The way the standards decisions have been made the FUNCTION token is really 
an escape sequence. The problem may look different if we consider the basic 
parser's job as real simple, assemble a symbol and token list, wake up the 
great FUNCTION processor in the sky, punt and wait for a return.
(although 'wait' implies non parallel design).


From a syntactic point of view FUNCTIONS are a fifth DIVISION.

In your early work, you may want to disengage from the FUNCTION arguement 
problem. Much of the tool kind of ambiguity will disappear if the grammar for 
FUNCTIONS can not see the rules in the procedure division grammar, and 
vice-versa.

For intermeditate deployment, you can even consider implementing any FUNCTION 
that does not partake of array reference strangeness in the main parser (only 
to be torn out later).  In the end, the main procedure division parser could 
just be the escape sequence detector, and the other parser could do the real 
work.  

Before embarking on that strategy we merely need to resolve IF there are 
inline and or out-of-line semantics or standards or preferences for 
FUNCTIONs. If it is not necessary to be able to emit FUNCTION invocations 
inline (that is part a) and not necessary to semantically imbed FUNCTION code 
proper inline (that is part b) to be compliant with the standard then we can 
construct the basic parser with the assumption that both these parts will be 
handled with indirect addresses by semantics, and the entirety of the parsing 
of FUNCTION invocation can wait until the entire procedure division is done 
(by the main parser), or otherwise be an asynchronous (and pottentially 
parallel) process (harp harp harp!).


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.