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 Path: g2news2.google.com!postnews.google.com!y19g2000yqy.googlegroups.com!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.eiffel,comp.lang.ada Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? Date: Tue, 21 Jul 2009 00:54:29 -0700 (PDT) Organization: http://groups.google.com Message-ID: <30db0781-f919-4bab-acc0-b7034526ed83@y19g2000yqy.googlegroups.com> References: NNTP-Posting-Host: 88.170.86.208 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1248162870 6159 127.0.0.1 (21 Jul 2009 07:54:30 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 21 Jul 2009 07:54:30 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: y19g2000yqy.googlegroups.com; posting-host=88.170.86.208; posting-account=pcLQNgkAAAD9TrXkhkIgiY6-MDtJjIlC User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.11) Gecko/2009061208 Iceweasel/3.0.9 (Debian-3.0.9-1),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.eiffel:346 comp.lang.ada:7198 Date: 2009-07-21T00:54:29-07:00 List-Id: On Jul 21, 3:33=A0am, Cesar Rabak wrote: > 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. =A0Dimensionally 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. =A0In engineering, > > there are very few pure numbers and quite a lot of dimensioned > > numbers. =A0As 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? No, I would personally use Ada and make the number-crunching code into generic units. The user would then provide their application-defined floating-point type as a generic parameter to instantiate the code. > > 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. =A0The 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. =A0 > > More or less. It has all the operations of the derived type, uses the > same representation on the machine. =A0The incompatibility is syntactic n= o > in its essence. > > For example: which type is the operation X^2 + Y^2, or Magnitude * > cos(Theta)? Simple. In Ada, these expressions are illegal. The user must explicitly convert some of the values to a compatible type before being allowed to mix objects of different types, e.g. X : Horizontal_Coordinate :=3D ...; Y : Vertical_Coordinate :=3D ... R : Magnitude :=3D Magnitude (X)**2 + Magnitude (Y)**2; X :=3D Horizontal_Coordinate (R) * Magnitude (cos (Theta)); You may say is it not "ergonomic" but, as an engineer, I see this as "saying what you mean". The best approach, of course, is to make the above operations into application-specific operators, e.g. function Magnitude_Of (X : Horizontal_Coordinate; Y : Vertical_Coordinate) return Magnitude; > 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? No, unfortunately. In Ada, Length squared is a Length. There are however libraries like [1] that allow full dimensioned computations. They use compile-time checks where possible and run-time checks where necessary. [1] http://www.dmitry-kazakov.de/ada/units.htm > > 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. No. The incompatibility between types is checked at compile time and does not depend on values. Indeed, it still works if all types are declared as "new Float" with no range restriction. > > [...] > >>> 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 for= m > >> 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. =A0If I understand your argument correctly, yo= u > > 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 :=3D 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)? The interfaces for reading from the outside already exist and they all use typed input-output routines which check for range constraints (if applicable) at run time. This makes is simply impossible to create untyped values, or values of type universal_real, from outside the program source. One example with streams: type Radians is new Float; F : Ada.Streams.Stream_IO.File_Type; begin Ada.Streams.Stream_IO.Open (File =3D> F, Mode =3D> Ada.Streams.Stream_IO.In_File, Name =3D> "foo.dat"); declare S : constant Ada.Streams.Stream_IO.Stream_Access :=3D Ada.Streams.Stream_IO.Stream (F); R : Radians; begin Radians'Read (Stream =3D> S, Item =3D> R); end; end; (note : I wrote the above in an extra-verbose style to make context unnecessary). -- Ludovic Brenta.