comp.lang.ada
 help / color / mirror / Atom feed
From: mauney@ncsu.UUCP (Jon Mauney)
Subject: Re: Abstraction In Ada
Date: Mon, 25-Jun-84 12:45:10 EDT	[thread overview]
Date: Mon Jun 25 12:45:10 1984
Message-ID: <2629@ncsu.UUCP> (raw)
In-Reply-To: 2620@ncsu.UUCP


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?)

      parent reply	other threads:[~1984-06-25 16:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1979@mit-eddi.UUCP>
     [not found] ` <5400007@ea.UUCP>
     [not found]   ` <7506@umcp-cs.UUCP>
     [not found]     ` <2144@mit-eddie.UUCP>
1984-06-18 19:28       ` Abstraction In Ada Jon Mauney
1984-06-22  7:47         ` Doug Alan
1984-06-25  2:15           ` brad
1984-07-17 10:34             ` garbage collection Eric Smith
1984-06-25 16:45         ` Jon Mauney [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox