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

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

Nicholas Paul Collin Gloucester escreveu:
> On 2009-07-20, Cesar Rabak <csrabak@yahoo.com.br> wrote:
[snipped]
> |>                                                                                 |
> |> This is refuted by the following Ada code...                                    |
> |>                                                                                 |
> |Not it's not, your code only changed the problem appearance but not               |
> |substance:                                                                        |
> |                                                                                  |
> |> procedure Syntactic_Overloading_Example_Based_On_An_Example_By_Bertrand_Meyer is|
> |>    type Horizontal_Coordinate is new Float;                                     |
> |>    type Vertical_Coordinate is new Float;                                       |
> |>    procedure Point(X : Horizontal_Coordinate; Y : Vertical_Coordinate) is       |
> |>    begin                                                                        |
> |>       null; --Whatever.                                                         |
> |>    end;                                                                         |
> |                                                                                  |
> |Here you create two "subtypes" which are only nicknames for Float in              |
> |order to help the Ada compiler to discriminate the signature.""                   |
> |----------------------------------------------------------------------------------|
> 
> As an Ada compiler would detect the difference and Bertrand Meyer was
> unable to realize that the difference can be detected like this and
> used that as his justification for his version of overloading, I
> believe I have disproved the rationale of Dr. Meyer's.
> 
> 
> |----------------------------------------------------------------------------------|
> |" BTW, why                                                                        |
> |the need of two subtypes for coordinates?"                                        |
> |----------------------------------------------------------------------------------|
> 
> They might not be necessary, but they do no harm.
> 
> |----------------------------------------------------------------------------------|
> |">                                                                                |
> |>    type Magnitude is new Float;                                                 |
> |>    type Radians is new Float range -3.14*2.0 .. 3.14*2.0;                       |
> |>    procedure Point(R : Magnitude; Theta : Radians) is                           |
> |                                                                                  |
> |Ditto with two more "subtypes", and for no reason"                                |
> |----------------------------------------------------------------------------------|
> 
> In this case there is a reason for having more types. An angle and a
> length are simply not interchangable, so they should not be
> represented both by Float. The amount of money equal to U.S.$1.00 is
> not equal to the amount of money equal to 1.00 Canadian dollar, but
> they are both written with the number 1.00.
> 

I disagree strongly: an angle in radians is a real number as any other 
there is not any intrinsic difference in its *type* on ordinary 
Mathematics.  Dimensionally they are 'pure numbers' with no unit 
atached, your example on monetary units being fallacious, so non sequitur.


> |----------------------------------------------------------------------------------|
> |"creating a new mess as                                                           |
> |you made a design decision that Radians can only go from -6.28 to +6.28,          |
> |so you leave to the poor programmers that shall use this code the task            |
> |of normalizing the angles before creating points else runtime exceptions?"        |
> |----------------------------------------------------------------------------------|
> 
> If you really want to be able to write values such as 390 degrees; 750
> degrees; 1470 degrees; 1830 degrees; and 2190 degrees as was done in
> Section 3.2 Case Study 3: Errors in the Direct Evaluation of the Sine
> Series of the book William S. Dorn and Daniel D. McCracken, "Numerical
> Methods with Fortran IV Case Studies", then you can do so without
> normalization. 

I was not thinking on this, only on the 'ergonomy' of the solution, 
which I maintain happens due the desire to create 'type' (in Ada 
parlance [but in fact a nickname for Float]) so to allow the compiler to 
make critics in values *after have been initialized* with a primitive type.

My thinking was why one should restrict prematurely a range while it 
still make sense mathematically (1000 radians is a number that can come 
from some rotational routine or from an external data set, for example).

> Of course, to do so I would suggest a Degree type, and
> yes, I would probably had written
> type Degree is new Float range 0.0 .. 360.0;
> or
> type Degree is new Float range -180.0 .. 180.0;
> instead of
> type Degree is new Float;
> as I would not had realized that this would distract you from the
> emphasis that the Magnitude and angular types are very different, even
> though they are both based on floating point types.

They are not different at all both are real numbers, just that. Their 
*interpretation* in the program after they have been used in the Point 
object is different.

> 
> Even if we wanted to allow radians outside of the range I prescribed,
> the restriction -6.28 to +6.28 might still be used internally with
> normalization performed in a wrapper. Do you realize that when you
> write a number with ASCII numerals, it is probably going to be
> represented with something other than ASCII numerals before long?

Yes for your question, and of course I understand we are not discussing 
the design of the whole class/object, as we'd need to agree if magnitude 
can or not be negative, etc.

As for normalization, IMNHO it has to be done in the constructor of the 
class/object, and not as an (external) wrapper.

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

> 
> |----------------------------------------------------------------------------------|
> |">   begin                                                                        |
> |>       null; --Whatever.                                                         |
> |>    end;                                                                         |
> |>                                                                                 |
> |>    X : Horizontal_Coordinate;                                                   |
> |>    Y : Vertical_Coordinate;                                                     |
> |>    R : Magnitude;                                                               |
> |>    Theta : Radians;                                                             |
> |> begin                                                                           |
> |>    X := 1.1;                                                                    |
> |>    Y := 2.2;                                                                    |
> |>    R := 3.3;                                                                    |
> |>    Theta := 0.5;                                                                |
> |>    Point(X, Y);                                                                 |
> |>    Point(R, Theta);                                                             |
> |>                                                                                 |
> |>    --The above is all legal Ada. However, the following mistakes would          |
> |>    --be legal in Eiffel but would be rejected by an Ada compiler...             |
> |>                                                                                 |
> |>    R := X;                                                                      |
> |                                                                                  |
> |Careful reading of this line of code shows the 'protection' against               |
> |mistakes occurs only after the 'subtype' has been initialized,"                   |
> |----------------------------------------------------------------------------------|
> 
> What?
> 
> |----------------------------------------------------------------------------------|
> |" but this:                                                                       |
> |                                                                                  |
> |X := 3.3;  -- for the sake of argument programmer                                 |
> |Y := 0.5;  -- wrote the GUI code backwards                                        |
> |R := 1.1;                                                                         |
> |Theta := 2.2;                                                                     |
> |Point(X, Y);                                                                      |
> |Point(R, Theta);                                                                  |
> |                                                                                  |
> |Happy compiler and code runs, albeit with unexpected results..."                  |
> |----------------------------------------------------------------------------------|
> 
> Nothing is foolproof, but I did prevent some accidents.

Yes, I agree on that and Ada has been a step forward on this direction, 
but as has been written elsewhere in this thread, Ada types do not form 
a 'type system' so it brings moderate safety against errors.