Re: Ada standard and maximum line lengths

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 29.01.13 17:58, Niklas Holsti wrote:
> On 13-01-29 17:29 , Georg Bauhaus wrote:
>> On 29.01.13 13:31, Niklas Holsti wrote:
>>> Even for hypothetical SW of some sort that generates Ada source code
>>> automatically, I think it very unlikely that it would generate
>>> identifiers of that length, since Ada identifiers can be qualified and
>>> sorted into packages etc. much more flexibly than is the case for linker
>>> symbols.
>>
>> GNAT writes similar identifiers into object files, and
>> the same hysterical raisins spoil the cake. At least the
>> names---those to be exported to other compilers---seem shorter
>> if package hierarchies are not used extensively.
> 
> So what? These are *linker symbols*, not Ada (source) identifiers. I
> don't understand why you bring them into a discussion of source-code
> identifier lengths.

Linker symbols reappear in source text.

Off the island of GCC-only systems, for example. While it might
seem perfectly clear that language L defines a type of specific
objects that have primitive operations, there is no way to express
this in standard Ada. Fallback: linker symbols, function libraries,
and implementation-defined pragmas.

So, linker symbols are two-sided creatures: on the one side, they
are intended for use by linkers; on the other side, they reappear
in source text, even when "just in a pragma" or some such.
And not portably, at that, thereby destroying the value of
standardization of, for example, Ada and C++.

> In many cases, for example for the C++ symbol that you gave, the symbols
> are not even lexically legal Ada identifiers.
> 
>> Alas, the problem of exceedingly long names in object files
>> can be worked around by allowing lengthy identifiers in source
>> text.
> 
> Incomprehensible. Is there a "not" missing somewhere in that sentence?

By the response above, I need to accept long identifiers in
practice; it is a fact that compilers support the reality
of excessively long identifiers and so these reappear in source
text, because(!) language design is only infrequently responsive
to anything outside the fence; it seems a happy coincidence when
some of the respective teams join to talk about the effects
of the fence. I recall that, just recently, modernization, and
correction, of Ada's Fortran compatibility was considered because
someone took initiative. Just that.

So no, the above sentence is not missing a "not": the lack of
advancement in linking is worked around by allowing terribly
simplistic naming to reappear in source text:

   valid standard C++ program     valid standard Ada program
              |                             |
                              _
                              |  (non-standard pragmas)
                              _
                 /                       \
            compilers A+B            compilers C+E
                 |                       |
                OK                      NOK

The same valid programs, translated on the same platform, can
be rejected because the program needs to imports the long,
non-standard, non-portable names.

So it seems obvious that there is an opportunity for
improvement and modernization of linking by addressing
naming in programs written in Ada, C++, and practically
related languages. We have type theory. We have objects.
What we don't have is types at the object code level
("object code. Ha!"). But could we?

Hence, what will a .o/.obj files look like if both C++ and
Ada wanted to let programmers write "normal length" identifiers
for cross-language types, say?

Going back to my initial question. Suppose linker symbols
were structured. Won't the rather technical need for allowing
long identifiers in Ada source text just vanish?