Re: Your wish list for Ada 202X

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 14-04-19 00:28 , Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
> news:brdegqFi62jU1@mid.individual.net...
>> ...
>> Well, I use redispatching only when I think that the operation being
>> called is well specified and is or will be carefully implemented for
>> each type in the class, as appropriate for that type. Same difference :-)
> 
> If you truly believe that you can "well specify" and "carefully implement" 
> everything in your system, well, you're a better man than me. :-)

No, no... I should have made it explicit in the quoted text that what "I
think" is not always correct, and of course I make errors (maybe I
should have written "when I hope" instead of "when I think"). But the
errors don't seem more likely to occur in redispatching calls than in
other calls. This may be because tagged types are not yet the core of my
applications, so my dispatching and redispatching operations are usually
not very complex.

> One of 
> the things that attracted me to Ada in the first place is that it forces me 
> to specify enough that it prevents many of my worst impulses.

I learned programming with Algol and did not encounter C until I had
experienced various forms of BASIC, COBOL, and Fortran (plus a few
assembly languages). This shielded me, I think, from being tempted to
use C-style short-cuts. So, perhaps unusually, I don't feel at all
constrained by Ada's requirements on explicitness, careful
specification, and strong typing.

> I doubt I'd ever get a lengthy C program to work!

I feel a lot more confident in my Ada code than in my C code.

>>> ... (I think it would be
>>> much better if all inheritance was explicit; but to be practical that 
>>> would
>>> require a rather different syntax than Ada uses, and thus such a thing 
>>> would
>>> not make sense in an Ada perspective.
>>
>> To make inheritance explicit, it seems to me that each inherited
>> operation must be declared for the derived type, with its full profile,
>> perhaps as
>>
>>   inherited procedure Foo (X: in T; ....);
>>
>> This would require just one new reserved word, "inherited", and does not
>> feel like a "rather different syntax". Did you have something else in 
>> mind?
> 
> The problem with this sort of syntax is that it's really wordy

Yes indeed.

> and tends to 
> obscure the important issues (which is not the exact profile, as least 
> unless you have a resolution problem). Remember all of the people that used 
> renames to avoid using use clauses for Ada 83? (Maybe not, that was a long 
> time ago.) They often had bugs like:
>    function "+" (Left, Right : P.Big_Int) return P.Big_Int renames P."-";
> where the profile is obscuring the critical differences.

Been there, done that (bugs too), with TLD Ada for a MIL-STD-1750B.

(The bugs usually arose through copy-paste mistakes, where one needed to
rename both "+" and "-" but forgot to change both occurrences of "+" to
"-" in the pasted copy of the renaming for "+")

> I'd prefer a much simpler declaration of inheritance, something like:
>    type Child is new Parent with ...
>       with inherits => Foo, Bar, Blech;
> 
> where names not listed are hidden from all visibility unless overridden.

This form would probably strongly discourage overloaded operation names.

> Whether that's enough or if some alternative with optional profiles is 
> necessary, I don't know. Most operations aren't overloaded, after all, so 
> the profile is just noise.

I have quite a few overloaded primitive operations, perhaps because I
tend to use named association in all calls so that the parameter names
extend and clarify the brief operation name.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .