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: 103376,c4003439e5ce36e1 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Converting access values Date: 07 Jan 2005 16:23:54 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: shell01-e.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1105133034 5061 69.38.147.31 (7 Jan 2005 21:23:54 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Fri, 7 Jan 2005 21:23:54 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:7548 Date: 2005-01-07T16:23:54-05:00 List-Id: Nick Roberts writes: > Mark Lorenzen wrote: > > > As I said in another posting, I am going for a design like this: > > > > type Buffer_Slice is > > record > > Data : Buffer_Ptr; > > First : Ada.Streams.Stream_element_Offset; > > Last : Ada.Streams.Stream_element_Offset; > > end record; > > ... > > It solves the problem, but exposes a bit more information to the clients > > than necessary. It is very easy for a client to address a slice outside > > the bounds: > > ... To avoid that exposure, you can make the Buffer_Slice type private, and provide the appropriate operations as subprograms. The Buffer_Slices package can easily enforce the desired bounds checking. Unfortunately, you then lose all the nice notations for dealing with arrays -- you have to say "Set_Nth_Element(X, I, Blah)" instead of "X(I) := Blah", or whatever. > Since you put it that way, I see your point. I suppose it is an area where > Ada fails to provide a level of abstraction that perhaps it should. It's > almost as if we want a new kind of access type, the 'slice access' type, > that can point to a slice of an array, e.g.: > > type Buffer_Slice is access range Stream_Element_Array; > > objects of which, when dereferenced, can be used anywhere a > Stream_Element_Array object can, and have the same attributes (First and > Last and so on). I don't agree with that approach. The underlying problem here is that private types cannot be made to mimic the predefined syntax. I can think of dozens of abstractions that are like arrays, where one would like to use array-like syntax. The Buffer_Slice thing that Mark Lorenzen wants is just one example. Sure, you could add that to the language directly, but then you haven't solved the general problem. The "right" solution, in my opinion, is to extend the "user-defined operators" idea to allow user-defined array-indexing, literals, aggregates, &c. A similar issue: Ada does not support arbitrary-range integers. Of course you can define a package to do it. And you can define "+", "*", &c to do the right thing. But then you lose constrained subtypes, case statements, integer literals, &c., all of which work fine on the *predefined* integers. - Bob