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,FREEMAIL_FROM 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!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!feeder.news-service.com!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!news.stack.nl!aioe.org!not-for-mail From: Cesar Rabak Newsgroups: comp.lang.eiffel,comp.lang.ada Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? Date: Mon, 20 Jul 2009 17:14:29 -0300 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: CypMocAmQgU7ZoH9HGMqRg.user.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org X-Antivirus-Status: Clean X-Notice: Filtered by postfilter v. 0.7.9 X-Antivirus: avast! (VPS 090513-0, 13/05/2009), Outbound message Cancel-Lock: sha1:XWc5yamrM+g6cBstpkQ+wQK8zVc= User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) Xref: g2news2.google.com comp.lang.eiffel:341 comp.lang.ada:7192 Date: 2009-07-20T17:14:29-03:00 List-Id: Nicholas Paul Collin Gloucester escreveu: > On 2009-07-20, Cesar Rabak 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.