Re: Ada OO Mechanism

[Brian Rogoff <bpr@shell5.ba.best.com>]

On Wed, 9 Jun 1999, Tucker Taft wrote:

> Brian Rogoff wrote:
> > ...
> > This kind of problem is solved in some languages, like Common Lisp and
> > Dylan, with multiple value return and others, like ML and Haskell, with
> > tuples. Was the prospect of such a mechanism for Ada considered (yes I'm
> > sure :-) and if so why was it rejected? Seeing as Ada has aggregates, it
> > seems to me that multiple value return would also have been a feature.
> 
> In Ada, multiple value return is not significantly different
> from returning a record.  However, the problem we are trying
> to solve is not multiple value return, but rather returning
> objects of size unknown at compile-time without using the heap.

Yes, I know. I can understand why it makes sense that a record cannot 
contain unconstrained types, but I don't understand why a suitable 
generalization of Ada's ability to return unconstrained types could not be 
made to solve the problem being discussed *without* forcing a heap based
mechanism on Ada. An example might be returning two strings on the stack.

> Common Lisp, Dylan, ML, and Haskell all rely heavily on heap-based
> mechanism, and what is passed around are references (or tuples
> of references).

It was an unfortunate choice of example languages, but I think you'll
agree that the reliance on the heap is mostly an implementation issue, at
least in the case of ML (*). Sorry for the confusion, I just don't know of
any system programming languages with multiple value return. 

Incidentally, I'm not suggesting that this would be a good idea for Ada, I 
am just interested in whether it was discussed and if so what were the
reasons for not doing it. I can think of a few myself...

>  References, and records or arrays of references,
> are no problem in Ada either.  The challenge is to avoid the heap,
> and I believe Ada goes further than almost any language in accomplishing
> that. But as pointed out, there are some limitations, which result
> in the heap being necessary when things get too complicated.

Agreed. 

> > Using access params here to simulate functions with out params looks really
> > ugly to me.
> 
> Access parameters are the Ada 95 way to give functions "out" parameters.
> It has the advantage of making the OUT parameters quite visible, thanks
> to the use of 'Access at the call point.  Note that many languages don't
> support OUT parameters at all.  All they support is passing references.

Sure, in C I don't mind doing this, but when I write Ada my "Ada mindset" 
is such that this seems like a "workaround". If it really was a good idea 
to make out parameters visible then I'd imagine I should always use
'Access since (as Robert Dewar likes to point out) we should favor the 
reader and maintenance programer over the writer. That doesn't mean that 
I won't often do this, just that unless I had a very good reason for
avoiding heap access I'd use one of the other workarounds. 

-- Brian

(*) There are ML compilers which don't use garbage collectors, relying on
a technique called region inference which (roughly speaking) use a  
mark-release style allocator with mark and release points inferred
automatically. 

Its also true that Ada's avoidance of the heap is also implementation
dependent. Ada=>JVM compilers probably hit the heap quite a bit :-).