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!feeder.news-service.com!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 22:33:59 -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:mJEsHK+KWVSIRrZlKNjimI1OsoM= User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) Xref: g2news2.google.com comp.lang.eiffel:344 comp.lang.ada:7196 Date: 2009-07-20T22:33:59-03:00 List-Id: 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: 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. 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)?