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: 103376,103b407e8b68350b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-04 01:54:16 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Anybody in US using ADA ? One silly idea.. Date: Tue, 04 Feb 2003 10:54:14 +0100 Message-ID: References: <1043938782.244443@master.nyc.kbcfp.com> <25ji3v8n915cnnnaqpjvm4f7i01a66r9pf@4ax.com> <1043949507.331484@master.nyc.kbcfp.com> <1044025336.3067@master.nyc.kbcfp.com> <1044033063.693737@master.nyc.kbcfp.com> <2b9s3vo3bbnaikqd6d4jpppfflfq2kbgfu@4ax.com> <1044278793.419261@master.nyc.kbcfp.com> <1044291655.564852@master.nyc.kbcfp.com> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 1044352455 39064024 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:33750 Date: 2003-02-04T10:54:14+01:00 List-Id: On Mon, 03 Feb 2003 12:00:55 -0500, Hyman Rosen wrote: >Dmitry A. Kazakov wrote: >> But this is an unsatisfactory definition. > >It satisfies me, so it is not unsatisfactory for everyone. OK, I knew people who made global weather simulation assuming that the planet Earth is flat. (:-)) >> It involves pointers and references, you have to define what they are. > >A (data) pointer is an object which holds the address of another object, >where "address" is an implementation-defined value which identifies one >particular object and no other. A reference is an alternate name for >an object. References and pointers are declared with a type which limits >the objects to which they may refer. What is the type of a pointer/reference? You have just started and already you have two sorts of citizens: objects that are pointers and objects that are not. How your definition would answer a very simple question whether a pointer to A is a subtype of A? In Ada an access type of an array is very much a subtype of the array, because it inherits the indexing operation: type A is array (Integer range <>) of Element_Type; type A_Ptr is access A; X : A_Ptr := ...; X (3..6) -- This is legal in Ada. What if some new language or even Ada, would push this idea further and make all type operations transparent for pointers? >> You have to admit that your "is a" does not work if there are no pointers. > >Fortunately, the programming language which I use has pointers. Not every object can be accessed through a pointer. Your definition is inconsistent with that. If I did not define an access type, then I loose subtyping relation? If the object is a bit in a packed array, then it is no more object? >> Is an integer in a register "is a" an integer in the memory, on a remote host? > >I don't care, as C++ regards integers as primitive types. >I have no interest at all in philosophical "is a", only >in methods of programming. Integer is a type. It is no matter whether it is primitive or not. To be "practical", your theory should work for all types. >> What does it mean "may call". > >In C++, it means that the pointer may appear to the left of a '->' >and the reference to the left of a '.', with the right-hand side >looking like a call - that is, a method name defined in the class >which is the static type of the pointer or reference or one of its >base classes, followed by parenthesized arguments. X * Ptr = 0; Ptr->Foo (); Here we may call, hence that incredible thing, which a null-pointer points to, is a subtype of X? >> In FORTRAN-IV you may call a function passing >> INTEGER*4 instead of REAL.*4! > >How nice for FORTRAN-IV. But not for your theory. FORTRAN-IV does no type checks. So you may call, but the result is nonsense. May call /= substitutable. >> It is much simplier just to say an instance of B is substitutable for >> a parameter where A is required. With further clarification what >> "substitutable" means. > >If it was much simpler we wouldn't be having this little chat. > >> But each procedure is related to the type of its parameters. > >Not for generics. Wrong. A generic procedure is polymorphic, so the type of its parameter (if it is a formal generic type) is not a specific type, but a type type. In C++ it is which denotes "set of any types which would go through the compiler", in Ada there are "private", "mod <>, "range <>" etc. >> This clearly violates DbC principle. > >If I attempt to instantiate a generic procedure with a type >which does not support the operations used, the code will >not even compile. How in the world can this be construed as >violating DbC? I didn't say that. I said that the idea that a type could be defined by a set of operations used in some [generic] body, is a bad one, and then it contradics to DbC, separating interface and implementation and number of other principles considered valuable for software development. >> The only contract of the procedure is that it takes > > an object of some known type > >Who made you God of what a contract is? Why is a set of >required operations a worse contract than a type? It is not worse it is same. A set of required operations defines a type. This type has to be *explicitly* specified. You propose to do this *implicitly* by the fact of using some of the operations in some bodies. It is no more a contract, if implementation details get involved. It is not a contract because no specification even exists. Moreover if you would still claim that this a contract, you would be unable to verify this "contract", because to check whether an operation is required is a halting problem. This is typical for C++, to use very simple, "practical" [at first look] ideas, which lead to a mess if you dig just a bit deeper. >> If you restrict this set of operation and want to expose > > this fact, then it is *another* type. > >Correct. But it would be mind-numbingly tedious to have to >name these types, and modify all the used types to adopt >the new interface, and to make adapters for the fundamental >types, and fortunately C++ doesn't require it. Huh, I remeber people claiming that it is tedious to declare an object, because the compiler has a nice rule that everything that has a name starting with I, J, K, L, M is an INTEGER. >In Ada, because of lack of MI, it wouldn't work at all. MI is nice to have, but it would not solve this. Operation disallowing could. However in most cases, one need just a careful software design instead of usual quick'n'dirty, which would be better to call "no more quick, but still dirty". >> They are not useless, they constitute the type. That's the point. > >They are useless because the procedure doesn't need them. >Why must the procedure specify that its parameters are >required to have operations that won't be used? What is >to limit this infinite set of possible but unused operations? --- Regards, Dmitry Kazakov www.dmitry-kazakov.de