From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,8143b93889fe9472 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.91.114 with SMTP id cd18mr16496wib.2.1359685108761; Thu, 31 Jan 2013 18:18:28 -0800 (PST) Path: bp2ni9320wib.1!nntp.google.com!feeder1.cambriumusenet.nl!82.197.223.103.MISMATCH!feeder3.cambriumusenet.nl!feed.tweaknews.nl!194.109.133.81.MISMATCH!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!newspeer1.nac.net!newspump.sol.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.datemas.de!feeder.erje.net!eu.feeder.erje.net!eweka.nl!lightspeed.eweka.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Wed, 30 Jan 2013 00:12:53 +0100 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ada standard and maximum line lengths References: <8dfcf819-e1d0-4578-a795-a4bf724b5014@googlegroups.com> <5107b329$0$6556$9b4e6d93@newsspool4.arcor-online.net> <5107eaed$0$6566$9b4e6d93@newsspool4.arcor-online.net> <51080c38$0$6561$9b4e6d93@newsspool4.arcor-online.net> In-Reply-To: Message-ID: <51085776$0$6637$9b4e6d93@newsspool2.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 30 Jan 2013 00:12:54 CET NNTP-Posting-Host: 81b7ffd2.newsspool2.arcor-online.net X-Trace: DXC==9Sii=ccoh[YI9]OHn9o5^A9EHlD;3YcR4Fo<]lROoRQ8kFejVXGK]XdSCI\c]SRnTYebio?T X-Complaints-To: usenet-abuse@arcor.de Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2013-01-30T00:12:54+01:00 List-Id: 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.