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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-ArrivalTime: 2003-04-28 11:15:31 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.java.advocacy,comp.object,comp.lang.ada Subject: Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP Date: Mon, 28 Apr 2003 13:16:16 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3E4E8F8C.9C096985@adaworks.com> <9fa75d42.0302250710.5549baaf@posting.google.com> <3E5C7033.BD5DC462@adaworks.com> <9fa75d42.0302260618.7506cba7@posting.google.com> <3E5CF5C6.84822F57@adaworks.com> <8qkczsAcGcn+Ew83@nildram.co.uk> <3EA04A1E.CAFC1FEF@adaworks.com> <9fa75d42.0304221126.7112b7d5@posting.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.java.advocacy:62840 comp.object:62212 comp.lang.ada:36699 Date: 2003-04-28T13:16:16-05:00 List-Id: Robert A Duff wrote in message ... >Yes, by "L-value", I meant on the left-hand side of an assignment, or an >'out' parameter, or similar things. If X(1..80) is just syntactic sugar >for a function call Slice(X, 1, 80) or Slice(X, First => 1, Last => 80), >then it would be little trouble for the Ada compiler. And I would think >it would be but a minor convenience for the programmer. > >But when slices are used as L-values, there are various interactions >with packing and whatnot that cause compiler complexity. I certainly agree with that, but slices as L-Values is one of the more useful features of Ada, because they allow you to do efficient operations safely that otherwise would have to be done much more verbosely AND inefficiently. Virtually any string manipulation needs L-Value slices. For instance, I constructed a normalized URL by allocating a large string for the URL, and then copying in the parts as they are identified: ... Len := Last - First + 1; if Next_Len > Final_URL'Last then Set_Bad_Command_Result; return; end if; Final_URL(Next .. Next+Len) := Info.Command(First .. Last); ... (Note that the check is needed only if we want to do something other than raise Constraint_Error if the URL is excessively long. In this case, we want to return a Bad_Command result to the client.) Another example is using slices to expand a buffer (the Janus/Ada compiler does this a lot): declare New_Buffer : Buffer_Type; begin New_Buffer := new Buffer_Contents(1 .. Buffer'Last + Expansion_Amount); New_Buffer (1 .. Buffer'Last) := Buffer.all; Free (Buffer); Buffer := New_Buffer; end; This generates some checking (all of which can be eliminated) and then memory-to-memory copying, without any extra overhead. In theory, a compiler could optimize a loop the same way, but I've never seen it done for a case like this one (where both items are access to unconstrained arrays, so there is a lot of descriptor manipulation and virtually all of the values are not known at compile time). Eliminating the checking in a loop is very hard (it requires algebraic propogation), and that's necessary (but not sufficient) to convert the loop into direct memory operations. Randy.