Re: CONSTANT ENTRY (was "forward" references (was: COBOL subscript range c

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:9%iBi.22098$1J4.81@fe06.news.easynews.com...
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:13db2kuoft2919a@corp.supernews.com... 
> <more snip> 
>
> Now, when we get away from these references in the "text manipulation
> stage" - which I think everyone agrees SHOULD be prohibited, we then get
> to the "more resources required to figuour out what is required" issue,
> that Rick mentions here. I think it is clear that the '02 Standard *does*
> place such a requirement on the implementer - and as far as I can tell
> everyone in J4 and Karl also agree this requirement is placed on the
> implementer.  This *CAN* be done and a conforming compiler must do it.

The requirement that is placed on the implementor is that the function
described be implemented as specified. (That's what a "standard" is for.) A
fair corollary to this is that it should be POSSIBLE to implement as
specified. (No one said it has to be easy...although that is obviously
desirable.)
What you're saying above seems to bear this out, so there shouldn't be a
problem.

What I see happening here is people straying into second guessing what an
implementor needs to do in order to comply.

This is presumptuous and pointless. There may exist an implementor somewhere
who has techniques and approaches that are not in general use, may even take
an entirely different approach that renders the whole issue a non-issue.
Just because something is a "problem" to one operson doesn't mean it is a
"problem" to "everyone".

(I have made considerable amounts of money by doing what was considered
"impossible" by some... so I am very wary about putting this label on
anything. More often than not, when computer people describe something as
"not possible" what they are really saying is: "I don't know how to do it.".
It is only impossible if the reason why it is impossible can be shown (as
with a circular reference) and even then, caution is required. (It MIGHT be
possible to solve even this by a different approach...)

<aside...skip this if you don't like anecdotes>

In my impetuous youth I realised that sometimes programming problems can be
solved by adopting completely different and unexpected strategies.  De Bono
calls it "lateral thinking" but it really doesn't matter what you call it...
After having a few successes in this area I became persuaded that "nothing
was impossible". I had a Scottish friend who had a wicked sense of humour
and was also very insightful. After excitedly explaining my latest triumph
to him he sat back and sipped his whisky. "So you think nothing is
impossible?" I again launched into an exposition about attitude, and the
power of Human ability to overcome all obstacles etc. etc. When I paused he
looked at me and said: "Hang your arse out the window, then go down the road
and throw stones at it." That was 40 years ago and I remember it like it was
yesterday. :-)

</aside...skip this if you don't like anecdotes>

The Standard should confine itself to defining requirement. If, by accident
or design it has strayed from that, then it should be set straight.

If it hasn't, then it simply needs to be clarified.


> As someone who both helped develop the '02 Standard and eventually
> expressed my opposition to its final approval, I can safely state that
> this standard places MANY "very expensive" requirements on the implementer
> (many of which would provide minimal pay-back to the eventual user).  This
> is why the current direction is to make some new '02 fetures OPTIONAL in
> the next revision (if any).  Consider the Exception Handling RESUME
> statement and STANDARD ARITHMETIC (using an arbitrary intermediate data
> type that doesn't exist in the language) as prime examples.
>
> There is (to me) a major difference between (obvious?) defect in the
> specification (like the COPY constant-name one) and "difficult but not
> impossible to implement" requirements like using TYPE statements before
> the corresponding TYPEDEF.

That makes complete sense to me.

Thanks for that, Bill.

Pete.
--
"I used to write COBOL...now I can do anything."