Re: Incompatible types for array conversion

[Georg Bauhaus <bauhaus@futureapps.invalid>]

On 22.07.15 03:19, hreba wrote:
> I have a generic vector package:
>
> generic
>     dim:        positive;
>     type Real is digits <>;
> package Vectors is
>     type Vector is array (1..dim) of Real;
>     function "*" (a: Vector; b: Real) return Vector;
> end Vectors;
>
> In another package I want to model the definition of a (physical) position vector by its direction and module:
>
> (...)
> Now my attempt to define this function:
>
>     function "*" (l: Direction; r: Length) return Position is
>     begin return Positions."*"(Position(l), r); end "*";
>
> gets me the error message in the subject line.
>
> Do I have to convert the vector element by element in a loop or is there a more elegant way?

There are ways to have the implementation perform exactly
the operations needed to produce the result that is needed.
Nothing inelegant in that; on the contrary, I find the
attempt to convert a Direction into a Position rather disturbing!

That's exactly turning the accidental relationship due to
assumed similarity of component types into a relationship
of Direction and Position that does not exist in the physical world.
Type error ;-) caused by assumptions about the implementation
dictating specification.

In this sense, I'd say that Niklas' suggestion, while technically
working, would be papering over a conceptual mistake. (Well,
that is what elegance is about, isn't it?)

Vectors."*" announces to multiply a Vector of Reals by a Real,
returning a Vector of Reals, not converting anything on the way.
Maybe the word "Real" still sounds generic, but the instance
types aren't.

Maybe rethink the solution. I think it could be made adequately
flexible, by, for example, considering Position as a vector of discrete
numbers in city block space and Direction having one of four possible
values only, in that city block space. Then, devise the operations
needed. Go back to Position and Direction in a more Euclidean
space, allocating a good choice of digits and ranges to each
of the types.

In your solution, "new Real" is creating a new and different type.
This is a good choice when representing things that really are different
and should be kept apart easily, with help from the compiler.