Re: Your wish list for Ada 202X

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote:

> On 14-04-12 11:20 , Dmitry A. Kazakov wrote:

>> I don't deny
>> existence of the problem. I am against the solution, which is inherently
>> unsafe and constraining (precludes by-copy semantics).
> 
> But class-wide operations which contain dispatching calls also preclude
> by-copy semantics, don't they?

Not at all. There is no problem for a class-wide operation to act on
by-copy types.

A by-copy class-wide object is a tuple (tag, type-specific value). Upon
dispatch the value is passed copy-in/copy-out to the type specific
operation.

> A class-wide operation, in my view, is just like a primitive operation
> except that (1) (re-)dispatching is implicit and automatic for all calls
> to primitive operations of the parameter object (because the parameter
> is a class-wide type) and (2) the operation cannot be overridden.

There is no re-dispatching in a class-wide operation. It is defined on
class-wide objects, so it simply neither dispatch nor re-dispatch.
 
> (This is why I don't understand your and Randy's abhorrence of
> re-dispatching -- to me, there is no basic difference between
> dispatching calls in class-wide operations, and re-dispatching calls in
> primitive operations.)

The difference is in types involved. A body of a primitive operation is
defined on a particular specific type. A re-dispatch within the body
breaks this type contract by calling an operation defined on *another*
type. This is an untyped behavior.
 
>> The concept should somehow play together with the notion of polymorphic
>> operation defined on the class (set of types). Between these two ends:
>> independent bodies of a primitive operation and single body of a class-wide
>> operation, there lies a whole spectrum of unexplored possibilities.
> 
> I feel that my use of re-dispatching gives me something like that. And I
> don't see the problems in re-dispatching that you and Randy worry about.

Untyped programming style has known problems. The point is not that an
improperly typed program could not expose correct behavior. Of course it
can, "it worked to me" is never an argument. One could design a working
program directly in machine code. That does not imply that this would be a
good idea.

>> Then I try to maintain the "no
>> abstraction inversion" rule, i.e. never call a "higher-level" operation
>> from a "lower-level" one.
> 
> Yes, same here.

But re-dispatch would be exactly this kind of inversion. Remember, no
higher-level operation is primitive, since I make all higher-level
operations class-wide or else self-contained.

>> And, I am not a language
>> designer anyway. I am a programmer. As a programmer, from my experience
>> with Ada, I tell the language designers that they got it all wrong since
>> Ada 2005. I don't want yet another dynamically typed or functional
>> language. I need a language for software engineering. More static checks,
>> more means to make static checks possible. The whole language should
>> revolute around helping restructuring my programs in order to support
>> static checks. No Constraint_Error to me, please!
> 
> That's a good goal, but I don't think it should be the only goal for Ada.
> 
> Ada's problem and challenge is that it very ambitiously aims to combine
> high-level, expressive, and therefore somewhat dynamic language features
> with predictable, efficient execution as required for critical embedded
> systems.

It depends on your understanding of dynamic features. To me it is all OK to
have dynamic features (AKA generic programming) under certain conditions.
One is that the language remains typed. Ada 95 solved that by introducing a
separate type for class-wide objects. Another is that generalized contracts
remain statically checked. Again, it is partially so, because Ada 95
guaranteed that dispatch never fail, an operation is either inherited or
else requires overriding. There is no gaps in the dispatching table (except
for missing MD). But Ada 83 missed that goal when introduced
Constraint_Error for discriminated types, array bounds, overflows without
means to check exception contracts statically. Ada 2005/2012 broke things
even further by adding dynamic constraints, predicates etc.

A related requirement is that whatever categories the language introduces
they must be spelt as objects, types, operations. The language must be
well-structured. Ada 85/95 was, though it had no so much typed things, like
ranges and attributes. Ada 2005/2012 ruined much of that.

> I think that it will be more and more difficult to extend and evolve Ada
> in both directions (high-level, expressive, dynamic; vs. low-level,
> predictable, static) without in practice dividing the language into two:
> a "high-Ada" and a "low-Ada", with some compilers targeting the high and
> others the low.

I don't believe in this separation. To me dynamic vs. static is not high
vs. low. In first place, there is no fully dynamic system. For any given
system observed as dynamic, you can always lump together involved objects,
call the result a type and things become static again.

So, the requirement is that you can have your dynamic things as much you
want, but you MUST introduce an explicit named type for the resulting set
of objects. Just as Ada 95 did with T'Class.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de