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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,611f4b10cbf9af69 X-Google-Attributes: gid103376,public From: dgibson@cayman.cis.ohio-state.edu (david scott gibson) Subject: Re: Redefinition of Equality (Long) Date: 1996/10/04 Message-ID: <533aebINNfat@cayman.cis.ohio-state.edu>#1/1 X-Deja-AN: 187569734 references: <52hgmoINN7tg@snoopy.cis.ohio-state.edu> <324FD267.954@cis.ohio-state.edu> <531ng6$frs@nntpa.cb.lucent.com> organization: The Ohio State University, Department of Computer and Information Science newsgroups: comp.lang.ada Date: 1996-10-04T00:00:00+00:00 List-Id: In article <531ng6$frs@nntpa.cb.lucent.com>, Kenneth Almquist wrote: >How about the following? Borrowing the term from C++, we define > > pragma Mutable(T); > >which causes "in" parameters of type T to be passed using "in out" >conventions and prevents constants of type T from being stored in >read-only storage. Now we allow "in" parameters to be modified, >but only if > > 1) The type is mutable. > > 2) The full type is visible. In other words, an "in" parameter > of a type declared "private" cannot be modified by a function > or procedure which is outside the package declaring the type. Would you allow an "in" mode formal of a mutable type to be used as an actual corresponding to another "in" mode parameter in a call to an operation declared outside the package? That is, could the (concrete) value indeed be modified by an outside operation, but only if that operation also saw that the type in question was marked as mutable? >This last suggestion may be overkill, since most abstract data types >will not require pragma Mutable. Self-ordering data structures such >as splay trees are one example. Data structures which cache the >results of recently performed queries are another. Data structures >which are implemented using other data structures whose access methods >contain state is a third. Good examples. I'm working on a general framework for specifying and implementing components in Ada. I don't want it to rule out any implementations such as these and swapping-base implementations. >(In this regard, Dave's example of a Set >data type using a List data type seems to have been misunderstood by >some people. The point of his example was that his List type did >not allow you to determine which elements were in the list without >modifying the list.) Right (except that it was the Set type which did not allow you to determine its elements without modification). >None of these three types of data structures are >common, so the support that the language provides for implementing >them is not critical. In the swapping-base paradigm I'm working with, it is common to "decompose" an object and then put it back together without changing its abstract value (and without any copying). To implement this scheme in Ada using functions would probably require all non-built-in types to be mutable in the sense you suggest. > What is important is the ability to separate >interface from implementation. I want to be able to take a table >package and replace a hash table with a splay tree--without modifying >the public part of the package specification. Absolutely! Programming languages should fully support this. Dave dgibson@cis.ohio-state.edu