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

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

On Mon, 03 Feb 2003 12:00:55 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> But this is an unsatisfactory definition.
>
>It satisfies me, so it is not unsatisfactory for everyone.

OK, I knew people who made global weather simulation assuming that the
planet Earth is flat. (:-))

>> It involves pointers and references, you have to define what they are.
>
>A (data) pointer is an object which holds the address of another object,
>where "address" is an implementation-defined value which identifies one
>particular object and no other. A reference is an alternate name for
>an object. References and pointers are declared with a type which limits
>the objects to which they may refer.

What is the type of a pointer/reference? You have just started and
already you have two sorts of citizens: objects that are pointers and
objects that are not.

How your definition would answer a very simple question whether a
pointer to A is a subtype of A? In Ada an access type of an array is
very much a subtype of the array, because it inherits the indexing
operation:

type A is array (Integer range <>) of Element_Type;
type A_Ptr is access A;

X : A_Ptr := ...;

X (3..6) -- This is legal in Ada.

What if some new language or even Ada, would push this idea further
and make all type operations transparent for pointers?

>> You have to admit that your "is a" does not work if there are no pointers.
>
>Fortunately, the programming language which I use has pointers.

Not every object can be accessed through a pointer. Your definition is
inconsistent with that. If I did not define an access type, then I
loose subtyping relation? If the object is a bit in a packed array,
then it is no more object?

>> Is an integer in a register "is a" an integer in the memory, on a remote host?
>
>I don't care, as C++ regards integers as primitive types.
>I have no interest at all in philosophical "is a", only
>in methods of programming.

Integer is a type. It is no matter whether it is primitive or not. To
be "practical", your theory should work for all types.

>> What does it mean "may call".
>
>In C++, it means that the pointer may appear to the left of a '->'
>and the reference to the left of a '.', with the right-hand side
>looking like a call - that is, a method name defined in the class
>which is the static type of the pointer or reference or one of its
>base classes, followed by parenthesized arguments.

X * Ptr = 0;

Ptr->Foo ();

Here we may call, hence that incredible thing, which a null-pointer
points to, is a subtype of X?

>> In FORTRAN-IV you may call a function passing
>> INTEGER*4 instead of REAL.*4!
>
>How nice for FORTRAN-IV.

But not for your theory. FORTRAN-IV does no type checks. So you may
call, but the result is nonsense. May call /= substitutable.

>> It is much simplier just to say an instance of B is substitutable for
>> a parameter where A is required. With further clarification what
>> "substitutable" means.
>
>If it was much simpler we wouldn't be having this little chat.
>
>> But each procedure is related to the type of its parameters.
>
>Not for generics.

Wrong. A generic procedure is polymorphic, so the type of its
parameter (if it is a formal generic type) is not a specific type, but
a type type. In C++ it is <class X> which denotes "set of any types
which would go through the compiler", in Ada there are "private", "mod
<>, "range <>" etc.

>> This clearly violates DbC principle.
>
>If I attempt to instantiate a generic procedure with a type
>which does not support the operations used, the code will
>not even compile. How in the world can this be construed as
>violating DbC?

I didn't say that. I said that the idea that a type could be defined
by a set of operations used in some [generic] body, is a bad one, and
then it contradics to DbC, separating interface and implementation and
number of other principles considered valuable for software
development.

>> The only contract of the procedure is that it takes
> > an object of some known type
>
>Who made you God of what a contract is? Why is a set of
>required operations a worse contract than a type?

It is not worse it is same. A set of required operations defines a
type. This type has to be *explicitly* specified. You propose to do
this *implicitly* by the fact of using some of the operations in some
bodies. It is no more a contract, if implementation details get
involved. It is not a contract because no specification even exists.
Moreover if you would still claim that this a contract, you would be
unable to verify this "contract", because to check whether an
operation is required is a halting problem. This is typical for C++,
to use very simple, "practical" [at first look] ideas, which lead to a
mess if you dig just a bit deeper.

>> If you restrict this set of operation and want to expose
> > this fact, then it is *another* type.
>
>Correct. But it would be mind-numbingly tedious to have to
>name these types, and modify all the used types to adopt
>the new interface, and to make adapters for the fundamental
>types, and fortunately C++ doesn't require it.

Huh, I remeber people claiming that it is tedious to declare an
object, because the compiler has a nice rule that everything that has
a name starting with I, J, K, L, M is an INTEGER.

>In Ada, because of lack of MI, it wouldn't work at all.

MI is nice to have, but it would not solve this. Operation disallowing
could. However in most cases, one need just a careful software design
instead of usual quick'n'dirty, which would be better to call "no more
quick, but still dirty".

>> They are not useless, they constitute the type. That's the point.
>
>They are useless because the procedure doesn't need them.
>Why must the procedure specify that its parameters are
>required to have operations that won't be used? What is
>to limit this infinite set of possible but unused operations?

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de