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!news.stack.nl!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Your wish list for Ada 202X Date: Thu, 27 Mar 2014 17:06:20 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1395957980 4089 69.95.181.76 (27 Mar 2014 22:06:20 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 27 Mar 2014 22:06:20 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:19011 Date: 2014-03-27T17:06:20-05:00 List-Id: "Shark8" wrote in message news:x9RYu.3020$XJ3.767@fx09.iad... I seem to have lost the rest of this, here's the reply to the rest: ... >> I think the problem is mainly going to be political rather than >> technical. >> The solution requires defining a large set of new packages that echo >> functionality already in the language, and that would not be used by the >> sorts of safety-critical applications that the paying customers use. >> (They're not using Text_IO or Unbounded_Strings or Directories or ...). >> That's going to make changes in this area a tough sell, I fear. Hope I'm >> wrong. > > That's rather sad; I'd hope for Ada to be a technically superior > language -- IMO, it already is in several respects... but that's no reason > to slack off and not strive for higher quality. Keep in mind that Standards of all sorts are as much political as technical. If there is no political will (as with ASIS), the technical part doesn't matter. Most vendors have not had much demand for Wide_Character etc., so the interest in it is lukewarm at best. One example: I've never been able to convince anyone to write any ACATS tests on internationalization in identifiers -- so there are none. (As such, I wouldn't depend on it working the same in different compilers.) > ------------ > Any comment on idea #2 or #3? #2 looks like lipstick on a pig to me - as you know my thinking on interfaces. If we really were going to extend multiple inheritance (something I'd personally be against), I'd suggest just allowing it everywhere -- in which case abstract types do everything you want and interfaces per-se become unnecessary. There are nasty semantic problems with that, and it would probably cause serious incompatibilities -- but I see little point in duplicating the functionality. #3 I don't understand. If you want the index/cursor, use that form. If you don't need it, then use the object form. I can't see any sensible way of using the index/cursor without knowing the type/number of indexes/cursors -- and if you need to know that, you already know enough to use the index/cursor form. We already have attributes and functions so you don't need to mention the actual bounds, so I don't see any gain here. i.e. for E of Arr_Obj loop E := Arr_Obj(E'Index + 1) + E; end loop; is already assuming a lot about the type and form of the index. Why hide that then? for I in Arr_Obj'range loop Arr_Obj(I) := Arr_Obj(I+1) + Arr_Obj(I); end loop; is a lot clearer as to what's going on. Even better if we adopted the in-place add attribute: for I in Arr_Obj'range loop Arr_Obj(I)'Add (Arr_Obj(I+1)); end loop; Randy.