Re: Ada standard and maximum line lengths

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

On 29.01.13 20:54, Niklas Holsti wrote:

Upfront, my question was about the possible effects of
enforcing shorter identifiers  on the programming
profession.  I venture to read Robert Duff's recent post
as: that is a tool/setting to put into programmers' hands
if they want it, and otherwise there should be no limits.

>> Linker symbols reappear in source text.
>
> Show an example, please, where it is necessary to write a linker symbol
> verbatim as an Ada identifier.

Sure. I'll assume that the subject of good lengths of identifiers
shouldn't be argued in a stick-to-the-letter (200) fashion.

You have mentioned old Fortran's 6 characters, so lets go crazy
and start with doubling this, twice, to 24 characters per identifier.

This is from Win32Ada:

   function CreateDialogIndirectParamW

Ouch. 26 characters. You have mentioned that 32 is uncomfortable,
so 24 certainly is more uncomfortable. Still, the Win32 bindings
show that most programmers want these foreign names to be just
like the originals. So, there is a need to not impose a lower
bound that excludes unchanged Win32 identifiers.

(I vaguely remember that there were two OS/2 bindings. One
copied the names of the C style object oriented OS/2 API.
The other binding offered packages, one for each name space
prefix found in the C style function identifiers. TTBOMK,
programmers preferred the former and found the latter confusing.)

Alternatively, if I assign an Ada identifier a foreign function
using pragma Import, and choose a shorter Ada identifier of
character content different from the string, I create an indirection
and that is always hard to trace. Understandably, there should
be as much of a 1:1 correspondence as possible. This is all the
more true the more compilers arrive at handling exceptions across
language boundaries. It is necessarily puzzling to see an exception
trace mention a name that cannot be found in the source text.
(Because a pragma Import has assigned a different, shorter name.)

The issue is present both ways. Say, I export this to C++:

    procedure A.B.C.Foo (Arg : T) is
       Flop : exception;
    begin
       ...
    end Foo;

And assume that compilers involved can handle exceptions across
language boundaries. With A, B, and C standing for identifiers
of average length, when Foo is mangled function library style,
what should the C++ side catch if Foo is "naturally" mapped to

  __adaE_A...__B...__C...__Foo?

Chances are that a limit on lengths of C++ identifiers will require
an assignment of a different exception identifier with the help
of #pragma or __attribute__. There is no standard way to address
this. *But*! There could be a standard way to address this, if
the profession is offered an incentive to move away from library
style name mangling.

Third, GNAT.

When GNAT started to support ISO/IEC 10646 ("universal characters"),
GNAT's upper bound on identifier lengths had to be lifted. Even
in the sense that line length implies identifier length: There
are names in the Unicode character database that have made the
source files exceeded GNAT's upper bound on line lengths (79).

A unicode character's name is not a linker symbol, but still it
is a name from a "library" of characters that is "imported".

> Sure, this is a poor mess and should be improved.

Yes.

> But it has nothing to do with limits on identifier length in Ada.

Yes, it does: practical naming enforces a lower bound on names,
as seen.

>> 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?
>
> There has never been, and is not now, such a need.

That's only formally true presuming
- the indirection tables of pragma Import do work well and
-  stick-to-the-letter interpretations of "200" and
-  "most programs".
But practically, names of imported subprograms import the risk of
hitting _any_ (project or compiler) limit on identifier lengths
when these foreign entities should not be renamed.