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

On 20 juil, 11:57, Jean-Pierre Rosen <ro...@adalog.fr> wrote:
> 1) More than complex, Ada is feature-rich,
And its feature are logically or mathematically justified, that's what
make them easy to understand when needed. Trying to use some of its
features when they are not needed, is perhaps more difficult. That's
another good reason for the “ Pascal subset ” approach. This will also
imply that a too much lecture oriented course may not be well suited.
In some way, perhaps the traditional university approach is not well
suited (not all time).

On 20 Jul., 11:57, Jean-Pierre Rosen <ro...@adalog.fr> wrote:
> Andrea Taverna a écrit :
> [...]> * * - Ada is best suited for large teams and/or critical software, thus
> > it may be overkill for my work, OTH it could have anything I might
> > happen to need.
> > What holds me from jumping onto Ada is the potential complexity
>
> As a long time teacher of Ada, let me elaborate on this particular issue.
>
> 1) More than complex, Ada is feature-rich, with some properties that do
> not exist in most other languages (user defined elementary types,
> discriminants, stack-allocated dynamic structures ...). Of course,
> you'll have to learn about these features - if you want to use them.
>
> 2) Ada is extremely consistent. You'll have to learn the basic
> principles, but once you've got them, you'll discover that all the
> features follow the same logic. Therefore, the first step might be
> higher than for other languages, but then everything appears logical and
> easy to grasp.
>
> 3) Ada is simple to use, because difficulty of implementation has never
> been an excuse for forbidding something that the user would expect to
> work. However, that makes the language complex to compile, and part of
> the alledged complexity of Ada refers to complexity of implementation,

That is exactly the area where Ada left the path of Pascal. Pascal
was designed to be easy to implement. Nicklaus Wirth had good
reasons to keep the implementation simple. He once said (IIRC):

What can be parsed easily by a compiler can also be
parsed easily by a human and this can be an asset.

He probably did not use exactly this words, but they hopefully
describe his intentions.

Many languages try to make the job of writing a program easier
and at the same time make the job of reading programs is
harder. All this wonderful "do what I mean" concepts used by
many languages fail in some cases.

IMHO complex compilation processes are an indication
of hard-to-understand concepts or hard-to-read constructs.
As such a complex compilation process only seemingly
(and not really) makes programming easier.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

tm a écrit :
> That is exactly the area where Ada left the path of Pascal. Pascal
> was designed to be easy to implement. Nicklaus Wirth had good
> reasons to keep the implementation simple. He once said (IIRC):
>
> What can be parsed easily by a compiler can also be
> parsed easily by a human and this can be an asset.
Parsing is not the difficult part of an Ada compiler.
> [...]

> Many languages try to make the job of writing a program easier
> and at the same time make the job of reading programs is
> harder. All this wonderful "do what I mean" concepts used by
> many languages fail in some cases.
True, but this does not apply to Ada. Ada was designed with requirements
that explicitely required ease of reading over ease of writing.

> IMHO complex compilation processes are an indication
> of hard-to-understand concepts or hard-to-read constructs.
> As such a complex compilation process only seemingly
> (and not really) makes programming easier.
>
Not at all. Let me take an example to show you what I meant. If you have
a record (in Pascal) or struct (in C), you are not allowed to compare
them directly. Why? because records may contain gaps that shouldn't be
compared, and skipping the gaps was deemed too much work for the
compiler. In Ada, there is no problem writing:
if Rec1 = Rec2 then ....

would you argue that it is /less/readable than writing:
if Rec1.F1 = Rec2.F1 and Rec1.F2 = Rec2.F2 and Rec1.F2 = Rec2.F3...


--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

tm schrieb:

> That is exactly the area where Ada left the path of Pascal. Pascal
> was designed to be easy to implement. Nicklaus Wirth had good
> reasons to keep the implementation simple. He once said (IIRC):
>
> What can be parsed easily by a compiler can also be
> parsed easily by a human and this can be an asset.
>
> He probably did not use exactly this words, but they hopefully
> describe his intentions.

A human who has parsed some part of a program is far away from having
understood the part of the program: Many concepts expressed "easily"
in "simple" languages hide the fact that a complex combination
of simple things needs to be studied (and made "conventional"
or idiomatic) in order to arrive at an understanding of what
is really going on, and what is intended, due to the combination.
Sometimes these lengthy combinations of "simply" expressed things
are equivalent to a simple builtin of less "simple" languages.

tm <thomas.mertes@gmx.at> writes:

> On 20 Jul., 11:57, Jean-Pierre Rosen <ro...@adalog.fr> wrote:
>> Andrea Taverna a écrit :
>> [...]> Â* Â* - Ada is best suited for large teams and/or critical software, thus
>> > it may be overkill for my work, OTH it could have anything I might
>> > happen to need.
>> > What holds me from jumping onto Ada is the potential complexity
>>
>> As a long time teacher of Ada, let me elaborate on this particular issue.
>>
>> 1) More than complex, Ada is feature-rich, with some properties that do
>> not exist in most other languages (user defined elementary types,
>> discriminants, stack-allocated dynamic structures ...). Of course,
>> you'll have to learn about these features - if you want to use them.
>>
>> 2) Ada is extremely consistent. You'll have to learn the basic
>> principles, but once you've got them, you'll discover that all the
>> features follow the same logic. Therefore, the first step might be
>> higher than for other languages, but then everything appears logical and
>> easy to grasp.
>>
>> 3) Ada is simple to use, because difficulty of implementation has never
>> been an excuse for forbidding something that the user would expect to
>> work. However, that makes the language complex to compile, and part of
>> the alledged complexity of Ada refers to complexity of implementation,
>
> That is exactly the area where Ada left the path of Pascal. Pascal
> was designed to be easy to implement. Nicklaus Wirth had good
> reasons to keep the implementation simple. He once said (IIRC):
>
> What can be parsed easily by a compiler can also be
> parsed easily by a human and this can be an asset.

That is a fine notion.

> He probably did not use exactly this words, but they hopefully
> describe his intentions.
>
> Many languages try to make the job of writing a program easier
> and at the same time make the job of reading programs is
> harder. All this wonderful "do what I mean" concepts used by
> many languages fail in some cases.

Does Ada have any of these though? I don't know the language well,
but I have never heard that accusation levelled at it (yes, I know you
are not doing so, but it was Ada that prompted your thoughts on this).

> IMHO complex compilation processes are an indication
> of hard-to-understand concepts or hard-to-read constructs.
> As such a complex compilation process only seemingly
> (and not really) makes programming easier.

I don't agree with that at all. There must be a germ of truth in it
(a hard to implement notion must be somewhat harder to understand than
an easy to implement one) but presumably you are arguing for the
reverse: that keeping the implementation simple ultimately helps the
programmer.

I'd cite higher-order functions and rendezvous as counter examples.
There are easier to implement alternatives to both but neither is
hard to read not particularly hard to understand. Even if we grant
that they are hard to understand, the benefit to programmers is
significant. In my view, certainly worth the effort needed to
understand them.

--
Ben.

Nicholas Paul Collin Gloucester <Colin_Paul_Gloster@ACM.org> writes:

> On 2009-07-18, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
> |-----------------------------------------------------------------------------|
> |"Andrea Taverna <a.tavs.NOSPAM@libero.it.invalid> writes: |
> |<snip> |
> |> In the past I used C, but now I have decided to change language. |
> |> I'm looking for a "better" one. |
> |> |
> |> Here follow the features it should have, ranked approximately by relevance:|
> |> |
> |> 0) open-source support and an alive community |
> |> 1) directly compiled to efficient code |
> |> 2) statically typed and object-oriented, better if multi-paradigm |
> |> 3) general-purpose libraries (possibly standardized, either by |
> |> standard or de facto), including containers and some math |
> |> abstractions. |
> |> 4) garbage collected. As an alternative, provide memory management |
> |> policies via libraries (e.g. memory pools and such) |
> |> 5) optional run-time checks and some kind of control over compilation |
> |> and low-level issues |
> |> 6) "relatively simple and consistent" |
> |> |
> |> So I have considered these alternatives: FreePascal, Eiffel, Ada and |
> |> Modula-3. |
> | |
> |Other people have been adding to your list but Objective Caml is still |
> |missing. It ticks all you boxes." |
> |-----------------------------------------------------------------------------|
>
> Why Objective Caml instead of JoCaml; G'Caml; Chamau; BIGLOO; HimML;
> CeML; or Gaml?

No reason at all if these all meet the OP's needs. I don't know them
so I could not reasonably suggest them. OCaml is the only ML-like
language I know that is object oriented as asked for. A quick look at
some of your list suggests that not all of them are.

--
Ben.

Nicholas Paul Collin Gloucester escreveu:
[snipped]

>
> I give an example showing that Ada is better than Eiffel (and Modula-3
> and many versions of Pascal) in this regard, based on an example by
> Bertrand Meyer in the second edition of the book "Object-oriented
> software construction". In that book, Dr. Meyer claimed that Ada's
> overloading is inferior to Eiffel's overloading. He called Ada's
> overloading syntactic overloading. He called Eiffel's overloading
> semantic overloading. I believe that he was being sincere, but he was
> definitely mistaken. He claimed that it would not be possible to
> sensibly discriminate between overloaded subprograms for a point if
> the real-number parameters could be in any of Cartesian notation and
> polar notation.
>
> 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. BTW, why
the need of two subtypes for coordinates?

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


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

--
Cesar Rabak

PS.: for some reason could not set the Followup-To so I trimmed to the
pertaining language NGs.

On 20 juil, 20:33, Cesar Rabak <csra...@yahoo.com.br> wrote:
> Here you create two "subtypes" which are only nicknames for Float in
> order to help the Ada compiler to discriminate the signature. BTW, why
> the need of two subtypes for coordinates?
Not “ subtype ” but “ type ”, which is not the same. Ada has both, and
both are differents.

A type does not only designate a range of allowed values, it also
designate a source, which in turn, associate design property to it
(this can be asserted relying on type matching rules).

If you want to be sure what a function recieve only come from a
defined set of functions, then you define a type, some functions
returning value of this types, or procedure modifying this type. Two
types may seem similar at a quick sight, but types are not only used
to define ranges.

Types allow to define the valid flow of some objects or values, it
allows to make assertions about where it come from and where it can go
(thus, what was done with on/with it). This as to deal with the
overall design, the whole usage of a library, and not only with the
set of value allowed for a given type.

This is not a kind of nickname, this is a difference written in the
stone

Cesar Rabak schrieb:

>> 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. BTW, why
> the need of two subtypes for coordinates?

Horizontal_Coordinate and Vertical_Coordinate are specifically
*not* nicknames, not even informally.
Two new types derived from the same ancestor are definitely
*not* only nicknames for Float. I see you are trying to
come up with an argument about the same literals providing
values for objects of entirely different types, and that's
certainly formally true and a nice try. But if you defer to
the programmers, I will, too, and suggest

X := Vertical_Coordinate'(1.1);

so as to say what they mean. Et voila,

21. X := Vertical_Coordinate'(1.1);
|
>>> expected type "Horizontal_Coordinate" defined at line 2
>>> found type "Vertical_Coordinate" defined at line 3


I'm sure Gloucester will speak for himself, but it's tempting
to step in.

(Nitpick: he is introducing two new distinct types,
not subtypes as an Ada subtype is a type with a constraint
as in subset of values that are in the type).

Every one of the tricks you play below in your example
assigns values of literals of anonymous predefined type
'universal_real' to objects of distinct types. There
is certainly an issue with literals not being silver
bullets. Yes, some programmers do not define typed
constants of important values. Yes, they are not even
using C's untyped #define, they just sprinkle literals.


> Careful reading of this line of code shows the 'protection' against
> mistakes occurs only after the 'subtype' has been initialized, 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...

Well, there is no way to write full application programs in
type systems(*). But what's your point? If we add rigor to your
argument then we might just as well have but one type and make
the compilers even happier with that universal type...


(*) except Qi's, I should think.

--
Georg Bauhaus

Hibou57 (Yannick Duchêne) escreveu:
> On 20 juil, 20:33, Cesar Rabak <csra...@yahoo.com.br> wrote:
>> Here you create two "subtypes" which are only nicknames for Float in
>> order to help the Ada compiler to discriminate the signature. BTW, why
>> the need of two subtypes for coordinates?
> Not “ subtype ” but “ type ”, which is not the same. Ada has both, and
> both are differents.

They are *considered* different in Ada technology, I respect that, but
from a OO point of view, they are not: a new type would define a new set
of operations on it.

>
> A type does not only designate a range of allowed values, it also
> designate a source, which in turn, associate design property to it
> (this can be asserted relying on type matching rules).

In Ada language, defined as such.

>
> If you want to be sure what a function recieve only come from a
> defined set of functions, then you define a type, some functions
> returning value of this types, or procedure modifying this type. Two
> types may seem similar at a quick sight, but types are not only used
> to define ranges.

Which is syntatic sugar for allowing signatures and allowing for
internal consistency in the program *after* the variables have been
initialized from a primitive type.

>
> Types allow to define the valid flow of some objects or values, it
> allows to make assertions about where it come from and where it can go
> (thus, what was done with on/with it). This as to deal with the
> overall design, the whole usage of a library, and not only with the
> set of value allowed for a given type.

After have been initialized by primitive types (as your own example shows).

>
> This is not a kind of nickname, this is a difference written in the
> stone

From a practical matter it is only a nickname, see my example you snipped.

tm wrote:
> That is exactly the area where Ada left the path of Pascal. Pascal
> was designed to be easy to implement. Nicklaus Wirth had good
> reasons to keep the implementation simple. He once said (IIRC):
>
> What can be parsed easily by a compiler can also be
> parsed easily by a human and this can be an asset.

The converse, however, is not necessarily true: that which cannot be
parsed easily by a compiler sometimes still can be parsed easily by a human.

This will remain so until strong AI is developed.

Georg Bauhaus escreveu:
> Cesar Rabak schrieb:
>
>>> 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. BTW, why
>> the need of two subtypes for coordinates?
>
> Horizontal_Coordinate and Vertical_Coordinate are specifically
> *not* nicknames, not even informally.
> Two new types derived from the same ancestor are definitely
> *not* only nicknames for Float. I see you are trying to
> come up with an argument about the same literals providing
> values for objects of entirely different types, and that's
> certainly formally true and a nice try.

Yes, formally it is my gripe. Remember this is not a thread is running
in Ada NG only, so recursing to Ada _terminology_ does not add to
discourse here.

> But if you defer to
> the programmers, I will, too, and suggest
>
> X := Vertical_Coordinate'(1.1);
>
> so as to say what they mean. Et voila,
>
> 21. X := Vertical_Coordinate'(1.1);
> |
> >>> expected type "Horizontal_Coordinate" defined at line 2
> >>> found type "Vertical_Coordinate" defined at line 3

Still, a pretense feeling of safety as the programmer had to work very
hard to allow the compiler find the 'error'.

>
>
> I'm sure Gloucester will speak for himself, but it's tempting
> to step in.
>
> (Nitpick: he is introducing two new distinct types,
> not subtypes as an Ada subtype is a type with a constraint
> as in subset of values that are in the type).

I comment this on other post.

>
> Every one of the tricks you play below in your example
> assigns values of literals of anonymous predefined type
> 'universal_real' to objects of distinct types. There
> is certainly an issue with literals not being silver
> bullets. Yes, some programmers do not define typed
> constants of important values. Yes, they are not even
> using C's untyped #define, they just sprinkle literals.

I'm not playing tricks, just showing something may appear unnoticed if
not debated. Although the example has been on literals, I've noticed
the bulk of problems happen when data is read from the outside of the
program (file reading, GUI fields, etc.).

>
>
>> Careful reading of this line of code shows the 'protection' against
>> mistakes occurs only after the 'subtype' has been initialized, 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...
>
> Well, there is no way to write full application programs in
> type systems(*). But what's your point? If we add rigor to your
> argument then we might just as well have but one type and make
> the compilers even happier with that universal type...
>
>
> (*) except Qi's, I should think.

I avoided mentioning because this would open even more the discussion,
but the OP could do its own research.

Yes your assertion goes in the Lisp direction, which for numerics could
even be more interesting as numbers are stored in a more accurate way
(if you avoid 'premature optimization' syndrome ;-)

Cesar Rabak wrote:
> Hibou57 (Yannick Duchêne) escreveu:
>> On 20 juil, 20:33, Cesar Rabak <csra...@yahoo.com.br> wrote:
>>> Here you create two "subtypes" which are only nicknames for Float in
>>> order to help the Ada compiler to discriminate the signature. BTW, why
>>> the need of two subtypes for coordinates?
>> Not “ subtype ” but “ type ”, which is not the same. Ada has both, and
>> both are differents.
>
> They are *considered* different in Ada technology, I respect that, but
> from a OO point of view, they are not: a new type would define a new set
> of operations on it.

Could, I'd say. A derived type could (1) define a new set of
operations, or it could (2) just create a different kind of
fruit exhibiting the same behavior (operation-wise),
or (2a) override an operation,
or it could (3) defer (Eiffel) or abstract (Ada) some operations.
Except, perhaps, that Eiffel's elementary types are frozen,
that is, cannot be subclassed at all (last time I checked).

If Ada had an explicit unit system in addition to it's
type properties (the 'First and so on), then I could imagine
a case for requiring (2) to become (2a). Define a new (an own)
floting point type derived from some other floating point
type and make explicit where you expect them to be different,
for example in their units.

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.

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

[...]
> > 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);

?

--
Ludovic Brenta.

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?

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

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?

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

>
> [...]
>>> 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)?