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!postnews.google.com!c13g2000cwb.googlegroups.com!not-for-mail From: "Upkeep" Newsgroups: comp.lang.ada Subject: Re: Converting access values Date: 11 Jan 2005 09:02:29 -0800 Organization: http://groups.google.com Message-ID: <1105462949.537976.40860@c13g2000cwb.googlegroups.com> References: NNTP-Posting-Host: 195.131.145.122 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1105462954 9542 127.0.0.1 (11 Jan 2005 17:02:34 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 11 Jan 2005 17:02:34 +0000 (UTC) User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: c13g2000cwb.googlegroups.com; posting-host=195.131.145.122; posting-account=c7OadgwAAABnP4X2K1gSJGjrL1h5D8O7 Xref: g2news1.google.com comp.lang.ada:7647 Date: 2005-01-11T09:02:29-08:00 List-Id: Robert A Duff wrote: > ... 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. I think that this problem can be solved by introduction of appropriate attributes. Something like this: 1) for literals: for T'Literal_Conversion use F; where F takes a literal (integer, string, etc) and returns T. 2) for array-indexing, constrained subtypes and case statements: for T'As_Discrete use F; where F takes an object of type T and returns a value of some discrete type. All that means that a feature of this kind (literals, indexing etc.) is provided for a particular private type if and only if the corresponding attribute is defined by appropriate "for ... use" definition for that type. Naturally, there arises the question of static (that is, compile-time) evaluation of those attributes (although they are sensible and useful even without this opportunity). Well, there may be some restrictions for the functions that implement those attributes - that permit (or facilitate static evaluation of these functions. And if those restrictions aren't satisfied then compiler can issue a warning, telling programmer that all relevant checks/transformations will be done dynamically (this warning may be suppressed by appropriate pragma). I'm not sure about wishes for aggregates, but I think that if all objects of the type T have the same size and this size is statically defined then the only problem may be that this size just is not known in right place because of visibility rules. But if it is not visible there then the use of access is essentially forced, because any other solution will violate (directly or indirectly) encapsulation of the private type to some degree. Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia