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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site ncsu.UUCP Path: utzoo!linus!decvax!mcnc!ncsu!mauney From: mauney@ncsu.UUCP (Jon Mauney) Newsgroups: net.lang,net.lang.ada Subject: Re: Abstraction In Ada Message-ID: <2629@ncsu.UUCP> Date: Mon, 25-Jun-84 12:45:10 EDT Article-I.D.: ncsu.2629 Posted: Mon Jun 25 12:45:10 1984 Date-Received: Tue, 26-Jun-84 06:22:54 EDT References: <1979@mit-eddi.UUCP> <5400007@ea.UUCP> <7506@umcp-cs.UUCP>, <2144@mit-eddie.UUCP> <2620@ncsu.UUCP>, Re: Abstraction In Ada Organization: N.C. State University, Raleigh List-Id: Q: Is it possible to have a good data abstraction mechanism AND stack allocation of objects? A: It depends on whom you believe: >>> To do a good job with data abstraction, you really need >>> heap-based allocation with automatic garbage collection. >>> Ada doesn't support this. >> I don't see how this follows, except that lack of a >> garbage-collected heap restricts your ability to implement an >> ADT using a garbage-collected heap. There are advantages and >> disadvantages to heap allocation of data objects; I don't see >> how they relate to abstraction. > If data abstraction is done right, data types that are added to the > languange should look just like data types that are already built into > the language. Stack-based allocation doesn't work right because you > have to know how much space you will use before you use it. This is not > very abstract. You might not know how much space you need. The truth of the above statement depends on the binding of the word "you". It is unavoidable that someone must know how much space to allocate for a data object; the question is how widespread must that knowledge be? In CLU, only the defining cluster need know the concrete size of an object, since variables are always pointers to objects. This promotes good independence of modules, but: since variables are not automatically bound to data objects, each data type must provide a create function that must be explicitly called to allocate space (yuck, ugly!). Ordinary assignment statements merely copy pointers; to get an identical copy of an object you must call a function (yuck, ugly!). Since variables are pointers, there are lots of aliases; unexpected side effects can only be prevented by restrictions on the language or coding style. In Ada, variables are automatically allocated on the stack, just like in Pascal and C (ah! comfortable familiarity. keep that nasty future away as long as possible). This means that the users of an abstract type must know how big it is. But who is it that has to know? Certainly not the programmer -- programmer's don't ordinarily take an active role in allocating space. The compiler has to know. Therefore, the interface for an abstraction must be available before any code using the abstraction can be compiled. The same is true of any language, else how could the compiler know what operations are defined for the type. The difference is that the concrete representation must be included in the interface, and all code using an abstraction must be recompiled whenever the representation is changed. The restrictions on order of compilation can be made transparent to the programmer by providing an automatic 'make' facility. In short, complications in the compiler are traded against stack allocation of data. The benefits of the trade-off may be debated, but I do not see a great impact on the actual program code. > I will demonstrate by example. Let's say that you want to implement a > bignum (integer with arbitrary size) abstraction. In order to be > abstract, the bignum data type should be just as first class as any > other number type. If you use stack-based allocation, you will have to > worry about reserving the right amount of space in advance. But gee, > you don't have to do this with number types that are built in. If you > use heap-based allocation with explicit dealocation, you will have to > worry about dealocating a bignum when you are finished with it. But > gee, you don't have to do this with number types that are built in. Like I said, not having a garbage-collected heap makes it hard to implement those types for which you want a garbage-collected heap. This is independent of the abstraction issue. I find CLU to be a simple and powerful language. I find Ada to be a complicated and powerful language. In general, I prefer less complicated languages. But your specific complaints make no sense to me. -- _Doctor_ Jon Mauney, mcnc!ncsu!mauney \__Mu__/ North Carolina State University (I give up. What does 'I' mean?)