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

[Hyman Rosen <hyrosen@mail.com>]

Dmitry A. Kazakov wrote:
> What is the type of a pointer/reference?

"Pointer to OtherType"/"Reference to OtherType"

> You have just started and already you have two sorts  of citizens:
 > objects that are pointers and objects that are not.

Yes, so? Obviously, as soon as you define any static type, you will
have objects which are of that type and objects which are not.

> How your definition would answer a very simple question whether a
> pointer to A is a subtype of A?

It will answer "no"? Pointers are never (OO) subtypes of anything.

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

Then there would be an implicit dereference of the pointer before
the operation is applied. There is no reason to impute all of the
operations to the pointer itself.

> Not every object can be accessed through a pointer.

Correct for the usual definition of pointer on typical hardware.

> Your definition is inconsistent with that.

No.

> If I did not define an access type, then I lose subtyping relation?

Not exactly. If you are not using a pointer or reference to an object,
then you are simply using the object itself. Then you know its actual
most-derived type, and its full set of available operations. If you
invoke an operation of one of its base classes, then when the compiler
calls that method, it will pass in a pointer to the base subobject and
then you are back in pointer-land. In C++, you get your pointers for
free :-)

> If the object is a bit in a packed array, then it is no more object?

Correct. In fact, the C++ standard library specifies a specialization
for vector<bool> that works that way, giving sub-byte access. This is
universally considered to be a mistake. The reason to consider such
bits as second-class citizens is for simplicity of implementation. You
could force the definition of bit-level pointers, and classes that took
only four bits of space and so forth, but that doesn't map neatly onto
typical hardware, so the C and C++ approach is not to do that. If it
messes up someone's abstract ideas, too bad.

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

I don't have a theory. If I write code that does operations on an
integer, the compiler generates assembly language that does the
work.

> X * Ptr = 0;
> Ptr->Foo ();

There are semantic restrictions on pointers that make the above illegal.
I can quote C++ standardese at you about when a pointer is derefernceable,
but I don't see what that has to do with anything.

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

That's nice. Why am I supposed to care about FORTRAN? I don't have a
theory. I haven't defined substitutable.

> 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.

That's a matter of opinion. The clear utility of this approach in C++
is an argument against your claim. I don't use DbC, it's not clear to
me that meaningful contracts can be specified for complex tasks, and
I don't care at all about abstract theories of how to program. I think
that contracts have exactly the same problems as correctness proofs and
similar ideas, namely that the statement of what you want is exactly as
complex as the problem you're trying to solve, and therefore is exactly
as likely to be incorrect as the program itself.

> Huh, I remeber people claiming that it is tedious to declare an object

In C++ there would also be the additional complexity of defining how
a set of operations could be defined, because of all the overloading
and implicit conversion rules. A simple "a + b" can mean a large number
of different things depending oon the types involved. Whether that's
good or bad, it is nevertheless an additional obstacle which prevents
such "operation contracts" (C++ gurus call them "concept checks") from
being required.