| Pete Dashwood 2007-08-28, 9:55 pm |
|
Karl Kiesel" <Karl.Kiesel@fujitsu-siemens.com> wrote in message
news:fb115t$6kc$1@nntp.fujitsu-siemens.com...
> "William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
> news:e4EAi.169153$Bo7.88986@fe07.news.easynews.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.
[color=darkred]
> Bill,
> that is just the problem I see here! The STD2002 defines a sequence of
> separate stages of compilation (see chapter 7)
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
> manipulation) may need information that can only be obtained from the
> later stage (compilation): expressions within >>IF and >>EVALUATE
> directives may be formed using literals (for example see STD2002 7.2.7.1
> syntax rule 1) and i did not find any rule, that forbids using a constant
> in place of a literal in these expressions. Therefore, to complete the
> text manipulation stage, a compiler must be able to evaluate constant
> conditional expressions in directives, but this is impossible, if a
> constant is involved, beause processing (ie recognition and especially
> determining the value) of such a constant entry is definitely part of the
> later stage - but this stage can not be entered unless the previous stage
> has been completed!
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.
> In this sense, using constants within directives is a form of 'forward
> reference'; If the concept of stages within the STD2002 is to be kept -
> and I would not like to give it up! - constant entries are a problem that
> make implementaion rather hard, if not impossible.
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."
|