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

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

On Jul 21, 3:33 am, Cesar Rabak <csra...@yahoo.com.br> wrote:
> Ludovic Brenta escreveu:
>
>
>
> > Cesar Rabak wrote on comp.lang.eiffel, comp.lang.ada:
> >> Nicholas Paul Collin Gloucester escreveu:
> > [...]
> >>> 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.
>
> > Ada is not a language for mathematicians (mathematicians would rather
> > use e.g. Octave), it is a language for engineers.  In engineering,
> > there are very few pure numbers and quite a lot of dimensioned
> > numbers.  As an engineer, I certainly view angles, frequencies and
> > dimensionless constants (e.g. correction factors) as all having
> > different dimensions.
>
> Nice you bring this, Ludovic! However, remember the OP question:
> <quote>
> I'm a CS student and I often need to write number-crunching code dealing
> with combinatorial optimization problems.
> What I do usually is implementing ad-hoc algorithms and testing their
> performance against other previously-known solutions, including general
> solvers.
> </quote>
>
> So your suggestion is to steer from Ada?

No, I would personally use Ada and make the number-crunching code into
generic units.  The user would then provide their application-defined
floating-point type as a generic parameter to instantiate the code.

> > I would have declared the types for angles thus:
> > type Radians is new Float; -- no range restriction
>
> > You focused too much, IMHO, on the range restriction which is not the
> > important part.  The important part is that, in Ada, this declares a
> > new *type* (not a "subtype" or "nickname for Float"), which is
> > *incompatible* with Float or any other type.  
>
> More or less. It has all the operations of the derived type, uses the
> same representation on the machine.  The incompatibility is syntactic no
> in its essence.
>
> For example: which type is the operation X^2 + Y^2, or Magnitude *
> cos(Theta)?

Simple.  In Ada, these expressions are illegal.  The user must
explicitly convert some of the values to a compatible type before
being allowed to mix objects of different types, e.g.

X : Horizontal_Coordinate := ...;
Y : Vertical_Coordinate := ...
R : Magnitude := Magnitude (X)**2 + Magnitude (Y)**2;
X := Horizontal_Coordinate (R) * Magnitude (cos (Theta));

You may say is it not "ergonomic" but, as an engineer, I see this as
"saying what you mean".  The best approach, of course, is to make the
above operations into application-specific operators, e.g.

function Magnitude_Of (X : Horizontal_Coordinate; Y :
Vertical_Coordinate)
  return Magnitude;

> Does the subtyping in Ada complain if one makes an operation on two
> variables of type Length (here defined as 'type Length is new Float;')
> that there is not a compatible Length squared defined?

No, unfortunately.  In Ada, Length squared is a Length.  There are
however libraries like [1] that allow full dimensioned computations.
They use compile-time checks where possible and run-time checks where
necessary.

[1] http://www.dmitry-kazakov.de/ada/units.htm

> > This incompatibility has
> > two benefits: early detection of some errors (except, of course, those
> > involving literals of type universal_real) and documentation, to the
> > human reader, of what objects of the type represent in the real world.
>
> I agree this allows for some error protection, but as I showed already
> this only happens *after* the variable has been initialized with a value
> which for non trivial programs have to come from outside world.

No.  The incompatibility between types is checked at compile time and
does not depend on values.  Indeed, it still works if all types are
declared as "new Float" with no range restriction.

> > [...]
> >>> 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.
>
> > In Ada, floating-point literals (which were the crux of your argument)
> > belong to the type universal_real which allows implicit conversion to
> > any floating-point type.  If I understand your argument correctly, you
> > are suggesting that universal_real (and universal_integer) should
> > disappear and that the language should force the programmer to qualify
> > every literal, i.e.:
>
> > X : Radians := Radians'(3.0);
>
> Why? Doesn't it make sense for you?
>
> How would Ada gurus suggest the interfaces for reading data from outside
> the program (GUI, command line parameters, fields in files, etc.) be
> coded (in order to make full use of Ada features)?

The interfaces for reading from the outside already exist and they all
use typed input-output routines which check for range constraints (if
applicable) at run time. This makes is simply impossible to create
untyped values, or values of type universal_real, from outside the
program source. One example with streams:

   type Radians is new Float;
   F : Ada.Streams.Stream_IO.File_Type;
begin
   Ada.Streams.Stream_IO.Open (File => F,
                               Mode => Ada.Streams.Stream_IO.In_File,
                               Name => "foo.dat");
   declare
      S : constant Ada.Streams.Stream_IO.Stream_Access :=
        Ada.Streams.Stream_IO.Stream (F);
      R : Radians;
   begin
      Radians'Read (Stream => S, Item => R);
   end;
end;

(note : I wrote the above in an extra-verbose style to make context
unnecessary).

--
Ludovic Brenta.