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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable 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!news.glorb.com!news.agarik.com!usenet-fr.net!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: "Alexander E. Kopilovich" Newsgroups: comp.lang.ada Subject: Re: Converting access values Date: Wed, 12 Jan 2005 07:56:39 +0300 (MSK) Organization: Cuivre, Argent, Or Message-ID: References: NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: melchior.cuivre.fr.eu.org 1105506023 82222 212.85.156.195 (12 Jan 2005 05:00:23 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Wed, 12 Jan 2005 05:00:23 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: In-Reply-To: ; from Robert A Duff at 11 Jan 2005 16:37:18 -0500 X-Mailer: Mail/@ [v2.45 MSDOS] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Gateway to the comp.lang.ada Usenet newsgroup" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , X-Original-Content-Transfer-Encoding: 7bit Xref: g2news1.google.com comp.lang.ada:7673 Date: 2005-01-12T07:56:39+03:00 Robert A Duff wrote: > > 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. > > I don't think that quite works. For example, I don't see how it allows > me to write a case statement on an expression of type > Arbitrary_Range_Integer -- I can't merely convert it to Standard.Integer > and do the case on that. Well. I thought about the case where the expression at the top is of some discrete type, and only particular branches are related to the private type. But if the expression at the top is of the private type then there can be ambiguity - generally there can be several different reductions of the private type to different discrete types (that is, with separate "for...use" statement for each). Therefore a particular reduction must be chosen for the expression at the top - the corresponding discrete type must be given there. I think that syntactically usual type conversion notation may be the best choice there. > > 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). > > If I were designing such a language, I think I would place restrictions > on the T'Literal_Conversion thing so that it *can* be evaluated at > compile time. Not a suppressable warning, but a normal legality rule. > > That's because I don't want an innocuous looking thing like: > > 123 > > to be able to raise an exception at run time. If there's something > wrong with that literal, I want a compile-time error. Well, I'm not sure about that, maybe you are right. But anyway, I think that it will be useful to annotate this feature of a function - that it can be evaluated in compile-time - explicitly, by use of 'constant' keyword: ... return constant T; > > 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. > > I've lost you there. I don't see why it has anything to do with size. Well, as I said, I was unsure about the wishes for the aggregates; I guessed that you meant using an object of the private type as a member of a record, and apparently this my guess was wrong - your "aggregate" was a verb, not a noun -;) > I was thinking of something like: > > for T'Aggregate use F; > > where F takes whatever parameters it likes, and does whatever it likes, > and returns an object of type T. Then: > > X := (A, B, C); > > (I'd prefer [A, B, C], actually) would simply be a shorthand for: > > X := F(A, B, C); Well, no problem with it, except one: if F can do anything than why we are thinking of it as of an "aggregation"? It is more like "computation" rather than "aggregation". I think that there should be some severe restrictions for F there, which will justify use of the term and the notation. For example, there may be following restriction: T is a record and the parameters of F correspond to the members of this record But this seems, perhaps, too severe restriction... maybe it should be somehow relaxed. It depends on intended uses, and I don't see them clear enough. Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia