Re: Anybody in US using ADA ? One silly idea..

[Hyman Rosen <hyrosen@mail.com>]

Dmitry A. Kazakov wrote:
> I do not see how this would make one substitutable for another.

This makes it possible to write code that works seamlessly with
the different kinds of string, as long as the operations used
are common to all of them. In C++ you just write your generic
method, and the compiler instantiates it for the types you
supply, without you having to tell it anything.

> Thunk code.

Huh? What does this mean? That thunk code needs to be generated
to do what you want? I know that. But things don't work this
way in Ada, C++, or Java, at least as far as I know about Ada.

> I do not want flawed implicit type conversions. I want sub- and
> supertyping. If an implementation of sub-/supertyping is based
 > on some conversions, I do not care.

But as I keep repeating, your concept of sub/supertyping is at odds
with the general understanding of this. When you describe what you
want, it looks like two-way type conversion is the only thing that
is necessaery, so it is natural to ask why inheritance should be
involved in this at all.

> procedure Query (X : in out Float);
>   -- The initial value is used as a default
> ...
>    I : Integer := 10;
> begin
>    Query (Float (I));

Cool. More stuff I didn't know about Ada. But to quote from the Ada RM,
     "If the target type is tagged, then an assignment to the view
      assigns to the corresponding part of the object denoted by
      the operand;"
so as I've been saying, Ada follows the conventional view that an
object is its base type(s), without any conversions needed. The
view conversion for a tagged type just winds up pointing at the
appropriate subobject.

Hmm. the same section continues
     "otherwise, an assignment to the view assigns to the object,
      after converting the assigned value to the subtype of the
      object (which might raise Constraint_Error);"

Ada experts - does this mean that each time the Query routine
above assigns a value to X it has to know that X is really a
view conversion of I, and check for error? Or can it just do
the check once at copy-out time? The former would seem to add
draconian complexity to subroutines.

> A given object may have only one type.

Says who?

> If C is A why memcpy does not work?

Because memcpy yields undefined behavior when copying
C++ objects around. On the other hand, X = Y will work
perfectly fine.

> subtype Positive is Integer range 0..Integer'Last;

You know, I used to think that C++ could benefit from having
Ada-like subranges. Thanks for opening my eyes :-)

> It is not better. My point was: we should check as much as possible at
> compile-time. Your point was: we should check only things actually
> used in the given program, as templates do. I gave you an example why
> it is a bad idea. You responded with another example. So the point
> stands.

I think I failed to understand your example, then.
You say that we should check as much as possible at
compile-time, but what does that mean? Perhaps I
should require that my types all be able to dance a
soft-shoe number, in case I have to give a demo of
my code to executives? You claim that there is benefit
in requiring that types support unused operations. I
don't see what that benefit is, or where you cut off
the infinite list of possible operations that a type
could conceivably support.