| William M. Klein 2007-08-28, 9:55 pm |
| Pete,
For example,
The '02 Standard allows for
COPY "literal-name". *> previously this was an extension
Suppose you had
Copy XYZ.
And within a member LMN, you had
01 XYZ Constant Value "LMN".
but you didn't have any copy member XYZ.
As the '02 Standard currently stands (and *if* you allow constants to be used in
the text manipulation stage), then it APPEARS that the Standard would require an
implement to copy in the member "LMN" *before* it could know that "XYZ" was
actually a constant name with the value "LMN".
Does this help you understand what this problem is?
--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5jjs1vF3ua30hU1@mid.individual.net...
>
>
> Karl Kiesel" <Karl.Kiesel@fujitsu-siemens.com> wrote in message
> news:fb115t$6kc$1@nntp.fujitsu-siemens.com...
>
> I have followed most of this stuff with bewilderment. Perhaps someone can
> explain in simple, clear, terms (I know that's proven very difficult for J4
> people in the past, but, please do try...I'm not stupid, and you have my full
> attention :-)) exactly what the problem is here?
>
> I've only ever worked on one COBOL compiler but I can assure you that forward
> references are NOT a problem. The "text manipulation" phase you refer to is
> the parsing phase and this is normally an extraction of simplexes ("simple
> expressions", usually in a tokenized or coded form) from COBOL source. If
> forward references are encountered, a placeholder is inserted and the second
> pass of the parser updates the simplexes, with what were previously forward
> references but have now been tokenized and stored. In the third pass,
> addresses are assigned to simplex constants and variables. No problem.
>
> So is it that the 2002 standard requires a particular approach? Why would it?
> Implementation should be left to implementors. Having constants in a Constant
> Section or having literals embedded in code should not be problematic to a
> compiler writer.
>
> As for the "vicious circle" that Karl describes where the "text manipulation"
> cannot be complete until information from subsequent passes is obtained,
> that's the bit I am having difficulty with. Why would an implementor paint
> himself into a corner? In my experience, they don't.
>
>
> Why does it?
>
> I confess, I haven't read the standard, but if that is the case, why would a
> Standards committee close down the options of an implementor? Why should the
> standard even be talking about "phases of compilation" that have no bearing on
> an end user and are properly the province only of the implementor?
>
> Is this where the problem is arising?
>
> I can't speak for others, but if I was still in the business of writing and
> maintaining COBOL compilers, and I found something in a standard that
> curtailed my options, I'd simply ignore it. Risk non-compliance? How is it
> non-compliant if everything required to be implemented, is achieved? (HOW it
> is achieved is no business of the Standards committee...)
>
> End users don't care (especially if it is the only compliant compiler
> available :-)) how many passes the compiler takes as long as their code is
> compiled correctly. Do you seriously think anyone would eschew a 2002
> implementation because it didn't follow the compilation phases "required" by
> the standard (which, in my opinion, shouldn't even be addressing compilation
> phases anyway)?
>
> There seems to be some serious confusion here between WHAT (definitely the
> province of the Standards committee) and HOW, (definitely the province of the
> implementor). Or am I just missing something?
>
>
>
> but the earlier stage (text
>
> This is blatant nonsense. If that's in the standard then no-one in their
> right mind would try and implement it as written. (Funny, 2002 compliant COBOL
> compilers are not exactly thick on the ground...).
>
> A vendor who was seriously committed to producing such a compiler would simply
> not use this approach. Why can the later stage not be entered until the
> earlier stage is complete? Of course it can. That's what multiple passes,
> placeholders, and cleanup phases are all about.
>
>
>
> Ah, maybe Karl has offered a clue in the above.
>
> "If the concept of stages within the STD2002 is to be kept - and I would not
> like to
> give it up! "
>
> Maybe that's what I am missing. Perhaps a quick summary of what these stages
> are, and what benefits accrue from implementing according to them, might shed
> some light on what this thread is discussing. I have enough respect for Karl
> to recognise that if he is reluctant to give them up, there are probably good
> reasons; I'd just like some instances as to what those reasons might be...
>
> If a documented approach in a standard means that implementors won't implement
> the product, then the Standard needs to change.
>
> My contention is that it should never have documented or mandated
> implementation approaches in the first place. Perhaps an Appendix of
> suggestions for implementors, but no way a mandated Standard. (Unless there is
> some really important benefit from this approach, that I am missing.)
>
> BOTTOM LINE:
>
> As far as I can see (unfettered by any mandated approach in the Standard)
> there is no technical difficulty with implementing anything that has been
> discussed here, forward references, dependent phases, CONSTANTS, Globals or
> not.
>
> So what exactly is the problem?
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."
>
|