Re: ADA Popularity Discussion Request

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

On 08 Sep 2004 19:23:40 -0400, jayessay wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On 08 Sep 2004 12:26:54 -0400, jayessay wrote:
>> 
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>> The philosophy behind is that types are random artifacts of the
>>>> program,
>>> 
>>> No, this is also incorrect.  The real difference is that with dynamic
>>> typing _values_ have types _not_ variables.  Since _variables_ don't
>>> even exist at runtime, your type information is largely gone at
>>> runtime in static systems.
>> 
>> I suppose you are talking about polymorphic objects.
> 
> No, I'm not.  Simply put variable don't exist at runtime.  I'm talking
> about every value having its type with it.

But that's exactly what a [dynamically] polymorphic object is. Its value (a
class-wide value in Ada terms) carries the type tag with it. The type tag
determines the specific type. Note that this specific type is not the type
of the object. T and T'Class are different types in Ada. Note also that
there is still room for static checks here. Toy'Class and Gun'Class are
statically different types. So Baby.Take (Gun) will be a compile error.

>> 1. That statically typed languages cannot express polymorphism? This is
>> plainly wrong.
> 
> This is irrelevant as again, the type information is basically gone.
> You have certain limited RTTI abilities, but that is not the same.

Should it mean that dynamic polymorphism is not powerful enough for the
tasks ...., which ones? Note that nobody says that ADT theory in its
present state is complete. So to argue against its concrete implementations
in concrete statically typed languages would be rather wasting time.
Because everybody will agree that there are [many] problems. So your
argument should go beyond that. Namely: no static analysis of types in any
its form can be fundamentally useful. Here we go again....

>> 2. That all polymorphic values should be considered of same type ANY? This
>> is also wrong.
> 
> No, this is irrelevant.

Really? But then if you have different bases like Toy and Gun, you can use
this type information to *statically* ensure that no type of guns can be
ever given to a child. 

>> As Unchecked_Conversion does.
> 
> I guess i've forgotten this (never really used it much).  So, when
> 13.9(5) says an instance of this returns a value whose "representation
> is the same as that of the source,

ARM then continues to the list of conditions to be satisfied to make the
above true.

In other cases the result might be quite different. For example when you
convert between a general access and pool specific access types. Former are
probably fat pointers, latter could be tiny integers, depending on the
compiler, of course.

> how is that functionally different from a cast?

It is a cast.

>  I realize that can make a differnce at compile time, but
> where's the runtime difference?  Especially as there's no type at
> runtime.

How so? Types do exist at run-time. Consider it as if the *unused* type
information were optimized out.

>> is a part of the language, why the compiler should be prevented from
>> checking where it can?
> 
> It's _not_ prevented - it isn't _required_ to!

That's silly. Why not to require to check what could be checked? Compare
with your beloved tests. You can test, but not required to. Any difference?
No one, except that types as a concept have reached the level of formality
where they can be integrated into the language to support static analysis.
Which only means that the tests related to types and their relationships
are performed by the compiler. Pre- and post-conditions is another example
of tests which can be partially automated. The rest, TDD etc has not
reached that level. It is no more than a mere informal advise of good
programming practice. As such it by no means can supersede static analysis.

>> Again, having accepted types you cannot argue that to check them earlier is
>> worse than to check them later.
> 
> If you think I'm arguing that, you really haven't understood.  I'm not
> saying checking them "earlier" is somehow bad, I'm saying it is
> largely irrelevant in practice with dynamic typing because any type
> inconsistency is caught during development anyway!

"Any type inconsistency caught anyway" is either too strong to be true or
else it just means that there are no interesting types to check for
consistency. The latter returns us back to the starting point. Are you
using types in your software design?

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