Re: Announce: Grace project site operational

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

On Mon, 20 May 2002 13:08:16 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
> > The idea of a generic is: let's substitute A for X
> > and see if the compiler will eat that.
>
>In the same way that a procedure is: let's substitute
>V for P and see if the compiler will eat that.

Not the compiler, but CPU. A substitution happens at run time. But the
main difference is how fine you can specify what can be substituted.
For subroutines we have the whole type system to specify that. Now
consider generics. Presently it is a very restricted set of formal
generic types that is supported. At the same time they match almost
everything.

>Clearly,
>you dislike generics so you invent extra-linguistic
>nomenclature to claim that one language construct is
>within the language while another is not.

I claim that, because, everything can be made generic. In C++ there
are generic types and subroutines. In Ada there are generic packages.
One can easily invent generic variables, literals, if-then-else or
whatsoever. Generics are alien to the language. One need them only
when the type system is underdeveloped.

>> Because dimensioned values are not unrelated. Their types are
>> siblings, having a common supertype, and very often we need objects of
>> that supertype.
>
>Why is a kilometer at all related to an hour?
>Why do they need a common supertype?

Because, there is a gauge that can show both. Because there is a data
base which is able to store measures with their dimensions, etc.

>>  an unconstrainted subtype of Measure shall keep the
>> discriminant, while a constrained one shall not. Same with tags,
>> class-wide objects have one, specific ones do not.
>
>What good is a "specific" tagged object without a tag?

Why a specific object should have a tag? It is specific, so its tag is
*statically* known. Keeping its tag is wasting resources. One reason
why this might be needed is re-dispatch, which itself is very
suspicious. Another is: if specific objects are relatively big and
passed by reference, then it makes no difference to have tag in them.

>> your macro expansions (:-)) will probably eat even more.
>
>The C++ versions reduce to plain arithmetic. Object sizes
>are the same as the unadorned value representation.

Yes, as long plain arithmetic is all what you do. If you start to
develop a real system upon generic units, you will have to make all
subroutines dealing with generic measurements also generic. The impact
will be catastrofic. Consider a generic matrix package built on
generic units. Then you start to instantiate a matrix inversion
subroutine for all sizes, units you need. Instantiate some
optimization subroutines, etc. Good luck!

>> How big will be your application, if all possible
> > subroutines dealing with units will be instantiated?
>
>Only the ones used get instantiated. If it turns out
>that too many routines are generated, the solution is
>to write a dynamic version and let the generic ones
>just call the dynamic one -

Why not to have a solution that does this from the very start?

>> The moral of the story is that no real system
> > uses 100% static or 100% dynamic checks.
>
>This is not true. Many real systems use only static checks.

How many? (:-))

I suppose we both have no figures. In automotive industry it is almost
0%. For instance, many hardware I/O protocols transfer units along
with values, so you just have no known units.

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