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.89.100 with SMTP id bn4mr734013wib.7.1359481913903; Tue, 29 Jan 2013 09:51:53 -0800 (PST) Path: bp2ni4551wib.1!nntp.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!ecngs!feeder2.ecngs.de!78.46.240.70.MISMATCH!weretis.net!feeder4.news.weretis.net!texta.sil.at!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: Tue, 29 Jan 2013 18:51:52 +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> In-Reply-To: X-Enigmail-Version: 1.5 Message-ID: <51080c38$0$6561$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 29 Jan 2013 18:51:53 CET NNTP-Posting-Host: 40573c7f.newsspool4.arcor-online.net X-Trace: DXC=cXkaJb2CW^OAa;:RKVJ>LE4IUKJLh>_cHTX3jM_;D15B^Q@dJ X-Complaints-To: usenet-abuse@arcor.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Date: 2013-01-29T18:51:53+01:00 List-Id: 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?