Re: Announce: Grace project site operational

[Hyman Rosen <hyrosen@mail.com>]

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

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

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

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

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

template<typename Stream, typename RepType>
Stream &print(Stream &out, const RepType &value, int mass, int distance, int time)
{ /* similar to earlier version */ }
template<typename Stream, typename RepType, int Mass, int Distance, int Time>
Stream &operator<<(Stream &out, const Unit<RepType, Mass, Distance, Time> &u)
{ return print(out, u.value, Mass, Distnace, Time); }

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