Re: Required Metrics

["Robert I. Eachus" <rieachus@earthlink.net>]

Robert Dewar wrote:
 
> You missed the point. There was a requirement that if you
> support lines of length N, you must also support identifiers
> of length N, including externally visible names of length N.
> It is impractical in most environments to allow arbitrary
> length for identifier names.

   No, I didn't miss the point, since at Honeywell we did have a
compiler that ran into exactly this problem.  The compiler used a hash
table with the actual identifier strings stored in the heap. 
Originally, the only limit on identifier length was imposed by the type
of text file used for the source file.  This limit was always shorter
than the limit imposed by the compiler (none) or by the size of memory
on the machine used to compile the program.  We could pass the ACVC test
on the largest DPS-6 machines with the maximum line length set to
2**16-4, which was the longest line allowed if you used a special file
type.  However, on the low end machines, that ACVC test would fail to
compile when it couldn't allocate one of the long identifiers.  In this
case, we could have broken the test up into several parts, but it was
much easier to require a smaller maximum line length--I'd have to look
but I think we used 8K--so that all validations were identical.  (Later,
I think DDC changed their front-end to store the identifier strings in a
file and just keep the hash table in memory.  But the Line length limit
stayed.)

    So I do personally know that in at least one case, this ACVC test
did force a compiler limitation.  And we did fix this in Ada 95--you are
allowed to have different limits on identifier size and line length. 
(And I do mean we.  I remember giving an example where requiring 255
instead of 254 would cause problems, and you (Robert Dewar) suggested
250, since there was no particular reason not to choose a decimal, not
binary, round number.)

    Hmmm.  Just remembering a different effect of this rule in Ada 83. 
There were some ACVC floating point tests that had long numeric
literals.  The length of these literals depended on the number of digits
allowed in a floating point type declaration.  I remember at least one
compiler choosing not to support extended floating point since their
compiler couldn't support numeric literals as long as required by those
tests.  (Does anyone remember?  Was that the ALS?  It certainly was a
VAX targeted compiler.)  In any case choosing a "short enough" maximum
line length negated the problem.