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

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

On Tue, 04 Feb 2003 10:56:30 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> What is the type of a pointer/reference?
>
>"Pointer to OtherType"/"Reference to OtherType"

Is pointer to other type a type? If yes, then your definition has to
define what does it mean to be a subtype of a pointer object. Which
would produce pointers to pointers. The next round will give us
pointers to pointers to pointers. Etc.

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

But staticness has no impact on my definition of subtyping. While
according to your definition, static objects cannot be subtypes,
because there cannot be pointers to most of them, especially to ones
eliminated by the compiler.

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

Really? In Ada:

type A is access all B;
subtype Sub_A is A;

Now you will say that this is not OO. (:-)) Fine, here is OO:

type A is access all B'Class;
type Sub_A is access all B;

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

I see no difference. If an operation can be applied to the pointer
then it is an operation on the pointer, then pointer is a subtype.

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

Unlike C++, Ada can class-wide objects on the stack. So one can have
dispatch even for "objects itself":

declare
   X : A'Class := Read;
begin
   Foo (X); -- This dispatches

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

The source of the problem above is not abstract ideas, but rather lack
of them. Which leads to two very non-abstract mistakes:

1. OO has something to do with pointers and references
2. The language (C++) has no by-copy in out parameters

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

OK, but one should have a theory to develop a language and a compiler
for it. Even C++ is based on some theory (I suppose on a wrong one
(:-))

>> X * Ptr = 0;
>> Ptr->Foo ();
>
>There are semantic restrictions on pointers that make the above illegal.

Even better, should this mean that your definition involves program
semantics? It would be indeed very "practical" to have same code
either having subtypes or not depending on the program application
area!

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

Thus your definition is limited by some number of chosen languages. I
suppose the set includes C++. Which language else?

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

Fairly enough.

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

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