Re: gnubol: subsets

[RKRayhawk@aol.com]

In a message dated 11/18/99 10:12:35 PM EST, mck@tivoli.mv.com writes:

<< Semantics does create additional information,
 however.  Addresses are recorded in the symbols as a side effect of
 storage allocation, for example.
  >>
Let me amplify one possible meaning here. Syntax then gets perhaps as far as 
length calculation, perhaps at detail level, perhaps recursively and summing 
up.  Syntax can gather attributes relating to boundary alignment (like 
SYNC/SYNCHRONIZED). 

Some other alignment, packing or memory management issues might be a fit 
subject for syntax, and therefore maybe placed in SYMT by syntax. But if so 
only that information that is derrivable from compile time parms, that is, 
visible at the 'source'  level. But generally any hardware orientation is out 
of bounds for syntax.

(( a way to think about any of these things might be that syntax can emit 
'requests' for physical attributes, but we may need to keep it out of the 
resolution of the request. For example, syntax may not know if SYNC is 4 byte 
boundaries or 8. But it could well know the difference between a compile time 
parameter that says 4 from one that says 8 and from one that says bag the 
sync feature today)).


Beyond the data division to which I understand your comments to be keenly 
focused, this address fault line helps clarify the syntax responsibilities in 
the procedure division. Whenever syntax veers into the thicket of where is 
the procedure, where is the called program, where is the data, it is off 
course. This will require a tokenization of reference in the stream from the 
parser(s) to sematics. Can this be accomplished with SYMT id, or is it harder.

One thing that falls out of this as a possible guideline for syntax is that 
the location of something is not necessarily syntactically diagnosable (as 
far as design).  Yet of course it might be done easily.  For example certain 
nested programs might not be able to see eachother or eachothers data; but 
the erroneous reference might occur. I am somewhat in favor of trapping that 
kind of thing syntactically, it being a lexical scope issue. I do not presume 
anyone agrees, but if we do, then we need to be careful of our meanings in 
use of words like location. Maybe semantics kind of location is cardinal 
values, and syntax is symbol visibility.  We tend to think of the lexer as 
lexical and the parser as syntactic, but the whole front-end is preoccupied 
with lexical scope. Location in the sense of pargraphs within sections (or 
not) is also a syntactic concern. Thus I am suggesting that lexical scope is 
outfront of semantics; physical location is outback of syntax.

With continued clear posts such as yours we shall certainly be able to 
establish a divide between syntax and semantics that relegates location as a 
huge task strictly to semantics.


Best Wishes,
Bob Rayhawk


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