At 6:47 PM -0500 16/3/03, CBFalconer wrote:
Grant Jacobs wrote:
... snip ...
As an aside, it makes me think that the const, type and var section probably could have been designed to have an "end" keyword to avoid this sort of thing (when Pascal was first designed, that is); this isn't a suggestion, just a idle thought. Something like:
const-begin <const declarations> const-end type-begin <type declarations> type-end
This way later development of new things like operator = ... wouldn't impact on the declaration sections, as they'd have one unique end-point "for all time".
They do, at least in standard Pascal. Parsing is something like:
WHILE NOT (nextsym IN [typesy, varsy, procsy, funcsy, beginsy]) DO BEGIN (* parse a constant *) END; and an extension, to avoid the order dependance of ISO 7185, is to add 'constsy' to the above set of terminators.
What the operator = ... ambiguity appears to be doing (to me!) is adding to the list in the in above. If you add an end symbol, the list becomes just one item: the end symbol and nothing else,. You don't have to know how other block/sections start, just how your current block/section ends, e.g.
while not ( nextsym = blockendsym ) do begin (* parse elements of that type of block *) end ;
This would make the const declaration section independent of whatever else evolves in other sections. So if you were to add other things like operator = ..., there would be no need to revise the parsing of the preceding section. (Basically, the end-set for a section becomes a single fixed item, rather than a list of start-sets for whatever sections could follow.)
(I hope understand the 'operator = ...' construct correctly, as I've never used it. In Frank's example it appears to occur in the function/procedure declaration section and thus would extend the list in the loop guard above.)
All of this is sort-of off topic... but fun :-) Excuse my degression...
Grant