From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 5b1e799cdb,3ef3e78eacf6f938
X-Google-Attributes: gid5b1e799cdb,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news2.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.straub-nv.de!noris.net!news.n-ix.net!newsfeed.freenet.de!multikabel.net!newsfeed20.multikabel.net!eweka.nl!lightspeed.eweka.nl!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?
Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.modula3,comp.programming
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
References: <h3sln0$rhm$2@news.eternal-september.org>
 <h41n4c$pm0$1@news.eternal-september.org>
 <24b1e02c-ef00-4adf-be11-e65277fc095c@j32g2000yqh.googlegroups.com>
Date: Wed, 22 Jul 2009 22:05:24 +0200
Message-ID: <1r7ti9jh08nhj.1qij2ynd4rsds.dlg@40tude.net>
NNTP-Posting-Date: 22 Jul 2009 22:05:23 CEST
NNTP-Posting-Host: daf1c143.newsspool2.arcor-online.net
X-Trace: 
 DXC=i2RPO@Noikd]BlmkiiU@BiA9EHlD;3Ycb4Fo<]lROoRa^YC2XCjHcbiEL]<Q>HnTCdDNcfSJ;bb[eIRnRBaCd<MnoMFBLkMD?lb:8_QkmVgXLa
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.eiffel:395 comp.lang.ada:7279
 comp.lang.modula3:90 comp.programming:11979
Date: 2009-07-22T22:05:23+02:00
List-Id: <comp.lang.ada>

On Wed, 22 Jul 2009 12:29:36 -0700 (PDT), sjw wrote:

> On Jul 20, 1:15�pm, Nicholas Paul Collin Gloucester
> <Colin_Paul_Glos...@ACM.org> wrote:
> 
>> � �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;
>>
>> � �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
>> � �begin
>> � � � null; --Whatever.
>> � �end;
> 
> And what will happen to this distinction with Point (2.0, 2.0);?

The rule is "never use magical constants". This applies both to 3.14 and to
2.0. In any case it should better be:

   (2.0 * Horizontal_Unit, 2.0 * Vertical_Unit)

> You could use named parameter association, but *much* better to use
> proper types --
> 
> type Cartesian_Coordinate is record
>    X : Metres;
>    Y : Metres;
> end record;

That depends on whether the surface isotropic, in GUI it is usually not,
which makes sense in having Horizontal_Coordinate and Vertical_Coordinate
distinct. In older alphanumerical displays the aspect ratio was not 1. It
was important to keep units different for the vertical and horizontal
coordinates. Though Radians let us assume otherwise....
 
> which makes it easy to (for instance) create appropriate functions
> "+", "-", "*", "/".

Yes.

Interestingly, but I have an impression that a well-done Ada program can be
improved, sort of, infinitely. The language is so rich, there are many
semantic layers hard if possible to penetrate at once... I am not ready to
claim whether this is an advantage or disadvantage.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de