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,e5eb8ca5dcea2827 X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Ada OO Mechanism Date: 1999/06/09 Message-ID: #1/1 X-Deja-AN: 487759001 References: <3749E9EC.2842436A@aasaa.ofe.org> <7id2eo$fag@drn.newsguy.com> <3749FF7D.F17CE16A@aasaa.ofe.org> <374AC676.F7AE0772@lmco.com> <7ieuja$5v9@news1.newsguy.com> <7ifd6l$bmf@sjx-ixn1.ix.netcom.com> <1999Jun8.151014.1@eisner> <375D9A3D.E1CCCC63@averstar.com> < <375E92CB.27850620@averstar.com> Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: nntp1.ba.best.com 928985317 203 bpr@206.184.139.136 MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-06-09T00:00:00+00:00 List-Id: 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 :-).