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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,3ef3e78eacf6f938 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder.news-service.com!newsfeed.straub-nv.de!feeder.eternal-september.org!eternal-september.org!not-for-mail From: Nicholas Paul Collin Gloucester Newsgroups: comp.lang.eiffel,comp.lang.ada Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? Date: Mon, 20 Jul 2009 19:44:03 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.eternal-september.org U2FsdGVkX19+YCTAy5lAqF7FRHkJzTyQhtvKiB6qNpIW05fvkEGHErStCG4o+schcgUAH0bbmE2KtSYLwwAZZIuLeQErDWDxIzSBlX0pQO8AXZC/E4PPhf+5snNPhUM83utwXLzGrmxMCX94RC1CLTpwaB0m7u0g6mutriSivoA= X-Complaints-To: abuse@eternal-september.org NNTP-Posting-Date: Mon, 20 Jul 2009 19:44:03 +0000 (UTC) X-Auth-Sender: U2FsdGVkX198n9dEnxWu+h1HFMD6VzgaBhuHGZHIzmosgkBSQk5xfHyz/bMceRwXGVZG7+N+B4s= Cancel-Lock: sha1:oo+w0a4cNqt+/SxbC/qAlsmYHnQ= User-Agent: slrn/0.9.9p1 (Linux) Xref: g2news2.google.com comp.lang.eiffel:338 comp.lang.ada:7188 Date: 2009-07-20T19:44:03+00:00 List-Id: On 2009-07-20, Cesar Rabak wrote: |----------------------------------------------------------------------------------| |"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."" | |----------------------------------------------------------------------------------| 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. |----------------------------------------------------------------------------------| |"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. 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. 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? 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. |----------------------------------------------------------------------------------| |"> 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.