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,799e6e37c90ca633 X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Future Ada language revisions? Date: 1998/10/03 Message-ID: #1/1 X-Deja-AN: 397418827 References: <6um7on$db5$1@nnrp1.dejanews.com> Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: 907441760 26095 bpr 206.184.139.136 MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-10-03T00:00:00+00:00 List-Id: On 2 Oct 1998, Robert I. Eachus wrote: > In article <6um7on$db5$1@nnrp1.dejanews.com> bpr5549@my-dejanews.com writes: > > > PS: In case anyone is wondering, my main peeve is the restriction > > on out mode function parameters, which I just don't understand, > > even when I'm trying to open minded. I have yet to hear a good > > defense of this restriction, so if anyone has one, I'm all ears, > > errr, eyes. > > I don't have strong feelings either way here, with a slight bias > toward allowing it in interfaces to make interfacing to C easier. Thanks Robert! I was starting to regret my PS, since it was generating more heat than light, and distracting people from the main question in the subject line, but this reply saved me (and others) from having to dredge up the discussions. I take it that you use "interfaces" above to mean foreign function interfaces, so that Robert Dewar's suggestion of encouraging the adoption of GNAT's pragma Export_Valued_Procedure would be a satisfactory solution. > (Flame retardant: Of course in C you can't have a function that > changes a function parameter, but the workaround it to require the This is true with the exception of the increment/decrement operators ++, and --. I don't frequently use these for their value in my own C code, so I don't miss them much in Ada. I do miss the ?: ternary operator, and the "op=" forms though, and I wish Ada had something similar (op:= perhaps?), but I digress. > But let me give the reasoning from the winning side: There are > four cases where functions with side-effects are needed. > > 1) Memoizing functions, like random number generators. This can be > done neatly enough in Ada, but in fact the twin requirements of Annex > A semantics and good performance make this a little tricky. However, > users are unlikely to have to deal with any case as tough as the A.5.2 > generators. (The tough part is A.5.2(46): "Any storage associated with > an object of type Generator should be reclaimed on exit from the scope > of the object.") I agree that its unlikely, but that seems to me to be a weak argument in favor of a language restriction rather than a style guideline. > 3) Functions which are operations of an object, with side effects > on that object. The solution here is to make the complete object type > an access type, and hide that fact completely from outside users. The > introduction of finalization in Ada 95 vastly simplifies the amount of > work to do this right in Ada 95. Yes, this is nice, though I (perhaps wrongly) feel that this solution is kind of heavy in terms of performance costs, especially if I want to have side-effecting functions on objects with value semantics. > 4) Interfacing to languages which permit functions to modify > parameters directly. The prime case is PL/I. (I like PL/I, I've > written a lot of code in PL/I, including parts of three Ada > compilers.) Of course, PL/I is relatively much less popular than it > was when Ada 83 was standardized. The pragma solution is fine here in any case. > So in every case where it is needed, the drawbacks are much less in > Ada 83. On the other hand, if you do pull a fast one in Ada and write > a function with a side effect, READERS of the code will be very > surprised, and may miss the intent of the function, and certainly the Eh? READERS will look at the interface to the function and see an out mode parameter, so they'll only be surprised if they don't read the spec. "Against stupidity the gods themselves contend in vain", right? > fact that such a call could have side effects or change its > parameters. So allowing such functions has a distributed cost in > shops where no functions with side effects are ever written. I see "distributed cost" has become overloaded now ;-). I think if a shop had a rule of "no access mode" or no "_Type" in type names or whatever there is also a similar cost, but I don't think that means that should be language rules enforcing restrictions here. -- Brian