Hello,
IIRC, the reason was the incompatibility with existing codes.
Each vendor had a different heuristic for guessing (best word
I can choose here) the type of a BOZ. So the vendors
preferred "either tell me or keep the same rules".
But you're right, nobody knew when it was first passed
just how big an issue it would be. (Read: "Everyone uses
IEEE 754 and I _need_ pi to 15.3 decimal places!" ;-)
Backward compatibility and all that.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
On Thu, 3 Oct 2002 07:49:53 -0700, Richard Maine
<[log in to unmask]> wrote:
>Jan van Oosterwijk writes:
> > One thing I would have liked is the disappearance of the restriction
> > of boz constants to DATA statements and INTEGERs ,
> > though the use of for example, REAL(Z'abcd') is a work around.
>
>A more liberal version allowing them to be used anywhere was passed
>and was in one revision of the draft. However it was cut down to
>the current one, which allows the above workaround. If I recall
>correctly, this was because of
>
>1. incompatabilities with existing vendor extensions. I recall
> being a little surprised that this point wasn't raised when the
> feature was added to the draft. Apparently many people either
> hadn't seen the incompatabilities or hadn't realized how much
> trouble they were likely to be. In any case, at the very the
> next meeting, people came back with the quite strong input that
> this was a big issue for several of the vendors (because there
> was lots of code that depended on the extensions).
>
> The extensions in question were essentially out of the question
> for the standard as they involved major technical issues like
> context dependence of expressions. I'm also not sure that all
> vendor versions of the extension were even consistent. In any
> case, just resolving this by adopting the extensions in question
> wasn't viable.
>
>2. There might have been some ambiguous cases. I don't recall for
> sure. I'm pretty sure that item 1 above was the major reason.
>
>By the way, for those on the list that might not have understood
>from the implication, the workaround that Jan cites above is
>allowed in the CD. That was basically the compromise that allowed
>boz literals in a few more places to improve their utility without
>getting into the morass that results when you try to allow them
>everywhere.
|