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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,79bbf7e359159d0d X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-04-11 11:42:03 PST Path: supernews.google.com!sn-xit-03!supernews.com!logbridge.uoregon.edu!titan03.ksc.nasa.gov!niven.ksc.nasa.gov!usenet From: "Samuel T. Harris" Newsgroups: comp.lang.ada Subject: Re: newbie can't get exceptions to work! Date: Wed, 11 Apr 2001 13:33:49 -0500 Organization: Raytheon Aerospace Engineering Services Message-ID: <3AD4A38D.B418FA6E@gsde.hou.us.ray.com> References: <9ao1if$cq9$1@taliesin.netcom.net.uk> <3ACFC902.115624A1@mindspring.com> <86u23yszjo.fsf@acm.org> <86wv8sfwec.fsf@acm.org> <86puej8gbu.fsf@acm.org> Reply-To: samuel_t_harris@raytheon.com NNTP-Posting-Host: sstf-fw.jsc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.7 [en] (X11; U; IRIX64 6.2 IP19) X-Accept-Language: en Xref: supernews.google.com comp.lang.ada:6779 Date: 2001-04-11T13:33:49-05:00 List-Id: Laurent Guerby wrote: > > Brian Rogoff writes: > > Well, I'm doing what I can on the OCaml mailing list to get nice little > > features of Ada adopted. In the case of labeled and optional arguments, > > it's a lot tougher in OCaml than Ada, which has type inference and higher > > order functions. If you look at the recent discussions on the mailing > > list, Jacques Garrigue (the label inventor and main proponent) is laying > > out the alternatives and it looks like the only way to get commuting > > labels is to have labels be non-optional. I don't like that. > > I see label and optional arguments being two separate issue. If you do > only labels, it shouldn't cause any problem at all, you can even > disallow overloading with only label changes while keeping most of the > interesting thing about labels (call site clarity). But even keeping > overloading should be near trivial. > > Optional argument are a whole different beast, and I think much less > useful, and I think likely to cause trouble. > > Is it that the conjunction of both feature is being considered and > hence the problems (my advice would be to just drop optional > arguments), or am I missing something obvious? > Agreement here (mostly). Say a subprogram has an optional parameter. The parameter is optional because the subprogram specification has a default expression for the parameter specification. It is a trivial refactoring to define a new subprogram of the same name and the same argument profile except it is missing the optional argument. The new subprogram's body is a one-liner calling the first subprogram while supplying the default expression. The first subprogram is changed to exclude the default expression. One can even pragma inline the new subprogram. This refactoring causes NO code changes on callers. So, what did the optional argument (i.e. default parameter initial expression) buy me in the first place? 1. The default expression can be an important for its documentation value and not is effect of making the parameter optional. 2. What if I have a subprogram with many optional parameters? The above subprogram refactoring needs to provide new subprograms for every combination of present and missing parameters. That can be alot of subprograms. 3. Using optional parameters employs a conservation of declarations. One declaration handle two variations. Imaging package ada.text_io being specified with two of every put and get routine because the form parameter is optional. As counter-point to the above benefits of optional parameters, consider a real problem we experienced. Using the VADS Ada compiler, we extensively use the current_exception.exception_name function call. Migrating to Apex we were pleased to find it defines just such a call so we did not feel a problem on this portability issue. That is until I discovered, through Apex complaining about it, that some of our code uses a subprogram rename declaration and that this subprogram rename declaration would not compile because Rational had added an optional parameter to current_exception.exception_name. This clearly shows that a subprogram with an optional parameter is NOT semantically equivalent to two subprograms, one with and one without, said parameter. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!"