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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!newsfeed.fsmpi.rwth-aachen.de!news-1.dfn.de!news.dfn.de!news.uni-weimar.de!medsec1.medien.uni-weimar.de!lucks From: Stefan.Lucks@uni-weimar.de Newsgroups: comp.lang.ada Subject: Re: Functions vs constants Date: Thu, 24 Jul 2014 09:20:15 +0200 Organization: Bauhaus-Universitaet Weimar Message-ID: References: NNTP-Posting-Host: medsec1.medien.uni-weimar.de Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-673933544-1406186415=:24422" X-Trace: pinkpiglet.scc.uni-weimar.de 1406179225 15054 141.54.178.228 (24 Jul 2014 05:20:25 GMT) X-Complaints-To: news@pinkpiglet.scc.uni-weimar.de NNTP-Posting-Date: Thu, 24 Jul 2014 05:20:25 +0000 (UTC) X-X-Sender: lucks@debian In-Reply-To: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) Xref: news.eternal-september.org comp.lang.ada:21171 Date: 2014-07-24T09:20:15+02:00 List-Id: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-673933544-1406186415=:24422 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 23 Jul 2014, Randy Brukardt wrote: > I think you miss the point. This isn't something that one intentionally > writes (and "Error" is a terrible name just used for an example). But if = one > intends to reuse code, the client has no control over the naming of the > entities in the reused code. Moreover (and more important), the client > shouldn't break due to unrelated maintenance on some third-party code. > Especially if that third-party code decides to add something with the sam= e > name as something that you are already using. How could they know to avoi= d > it? It would be nice if Ada had a selective "use" clause, a bit like MODULA2's= =20 import: from Ada.Text_IO use Put, New_Line; Now the programmer could write Put("Hello"); New_Line; but would have to=20 resort to prefix notation for Ada.Text_IO.Put_Line("Hello"). This would keep your namespace free from any new identifiers the=20 maintainer of Ada.Text_IO can add to the package. (Yes, Ada.Text_IO isn't= =20 the best example for this issue ...) > One could imagine a rule "no use clauses of any kind, anywhere", but that= 's > not really practical (especially as it means no infix operator usage). What about allowing "use type " and "use all type ", but=20 not "use "? > In > the absence of that, you're going to be at risk for problems. Moreover, e= ven > if "prefixes are good", they also make code unreadable (particularly if y= ou > have lots of child packages). What about using rename? package PFS renames My_Project.Abstract_IO.Persistent_File_Storage; > SPARK avoids overloading because the original authors of the tools didn't > have enough knowledge of how to implement it. Claiming them not to "have enough knowledge" is unfair! SPARK has originally been written for Pascal, which doesn't support=20 overloading (or didn't at that time). So the designed their tools such=20 that they did heavily depend on subprogram's unique names. E.g., the=20 information the toolset did generate for a subprogram was stored in a file= =20 with the subprogram's name. When they changed to Ada, they didn't start from scratch, but used the=20 back-end they had originally written for Pascal. Adaption to beyond-Pascal= =20 properties of Ada clearly had a low priority for them. You could see that even in the output: When a hypothesis (i.e, a=20 precondition) required two entities to be different, the SPARK toolset's=20 output would use the Pascal symbol for not equal, rather than Ada'S "/=3D". While changing the output symbol would not have been a big issue, adapting= =20 to overloading clearly would imply a huge amount of work, with things=20 breaking all over the toolset. > They then explained that as a > "benefit", but the only benefit is that it simplified their tools. Agreed! ------ I love the taste of Cryptanalysis in the morning! ------ --Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universit=E4t Weimar, Germany-- --8323329-673933544-1406186415=:24422--