Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Cesar Rabak <csrabak@yahoo.com.br>]

Colin Paul Gloster escreveu:
> On Mon, 20 Jul 2009, Cesar Rabak wrote:
[snipped]

> 
> I doubt that you or I shall convince me or you but... if you want to
> complain that I misuse the word "type", then fine. 

I don't think you do on purpose, it is the nature of the crosspost to 
have certain concepts blurred by the naming conventions of each technology.

> If you want to
> claim that an angle in radians is the same thing as a length, then you
> are mistaken. 

I did not say that, and your example also is not an implementation of that.

> You can measure an angle with a protractor. You can not
> measure a length with a protractor. You can measure a length with a
> ruler. You can not measure an angle with a ruler (without some
> additional hassle). A rotation is not a translation, despite both
> being transformations.
> 
> If you believe that a real number of an angle in radians is the same
> as a length, then do you believe that a real number of an angle
> gradients is the same as a real number of an angle in degrees? 200.0
> (a measurement in gradients of an angle) is not equal to pi (a
> measurement in radians of the same angle) which is not equal to 180.0
> (a measurement in degrees of the same angle). The angle is the same
> and the numbers are not so casually interchangable.
> 

Worse than that: radians are always pure numbers because the way they 
are defined they are relations between two lengths (which for correct 
results have to be in the same unit ;-).

If you want to discuss about new types around above arguments, you'll 
agree that a new type Length would need to accept several _units_ of 
measurement and keep an internal representation which is opaque for 
this, but able to respond to requests of its 'size' in whichever units 
the system have been devised to support.  Also some operations would 
create no units at all (division would give pure numbers [except if both 
operands explicitly require different units, to allow unit conversions], 
multiplication would give Area, etc.).

> A NASA probe was lost when all units were treated as equivalent
> numbers.

Yes and no line of Ada code could save the poor engineers that made that 
mistake (I bet B. Meyer would say Eiffel would :-)

> 
> |-------------------------------------------------------------------------------|
> |"[..]                                                                          |
> |                                                                               |
> |As for normalization, IMNHO it has to be done in the constructor of the        |
> |class/object, and not as an (external) wrapper."                               |
> |-------------------------------------------------------------------------------|
> 
> I did not necessarily prohibit that. The wrapper could be called by
> the constructor. The wrapper is external to the floating point Ada
> type Radians or Magnitude or X_Coordinate or Y_Coordinate, which
> itself could be restricted to the internals of a client's class, much
> as a C++ std::string might use a char* internally.

Notice that all this would be unnecessary if the language's needs did 
not entered into the problem: once an internal representation for the 
type Point had been chosen, the constructors would accept the values and 
do the conversion, which in case of the <rho, theta> representation 
would be done as part of the constructor job.

> 
> If normalization is required, it might not be ideal to keep it in the
> constructor because a variable could be constructed whose value is
> changed later, for example
> --Call a constructor for Radius but do not give it a value yet.
> [..]
>   for some_iterations loop
>     Radius := Get_Current_Radius;
>     --Do stuff.
>   end loop;

The example must be too contrived and I have not code Ada for years to 
understand it, but again it seems to be more an Ada technology related 
issue than a fundamental aspect.

> 
> |-------------------------------------------------------------------------------|
> |"> With the type Radians as I had typed it,                                    |
> |> Theta := 7.0;                                                                |
> |> would not result in a runtime exception. It would be rejected by a           |
> |> compiler.                                                                    |
> |                                                                               |
> |Because we are dealing with examples with literals, let the value come from an |
> |input...                                                                       |
> |                                                                               |
> |[..]"                                                                          |
> |-------------------------------------------------------------------------------|
> 
> Literals are not restricted to input, but yes, a runtime exception
> would occur with input if some other precaution is not taken.

Ludovic has shown all else would be required to attain a safer 
implementation.  As soon one starts to code for real the number of lines 
of code grow exponentially ;-)

Regards,

--
Cesar Rabak