[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: gnubol: problem 2.
I am not clear,
Does all this stuff of "escaping normal" syntax for FUNCTIONS handle the
case where a function is used a the starting position or length in reference
modification (or conditional expression) or several other places allowed in
the amended '85 Standard?
Bill Klein
wmklein <at> ix.netcom.com
> -----Original Message-----
> From: owner-gnu-cobol@wallace.lusars.net
> [mailto:owner-gnu-cobol@wallace.lusars.net]On Behalf Of
> RKRayhawk@aol.com
> Sent: Monday, December 27, 1999 4:06 PM
> To: gnu-cobol@lusars.net
> Subject: Re: gnubol: problem 2.
>
>
> 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.
--
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.