Re: newbie can't get exceptions to work!

["Samuel T. Harris" <u61783@gsde.hou.us.ray.com>]

Laurent Guerby wrote:
> 
> Brian Rogoff <bpr@shell5.ba.best.com> 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!"