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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fd63afa4dc364b7e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-03-28 15:19:47 PST Newsgroups: comp.lang.ada Path: supernews.google.com!sn-xit-02!supernews.com!news.gv.tsc.tdk.com!news.iac.net!news-out.cwix.com!newsfeed.cwix.com!newsfeed.icl.net!colt.net!newspeer.clara.net!news.clara.net!newsfeed.online.be!zur.uu.net!ash.uu.net!world!bobduff From: Robert A Duff Subject: Re: Static typing (Was Re: Better support for garbage collection) Sender: bobduff@world.std.com (Robert A Duff) Message-ID: Date: Wed, 28 Mar 2001 23:15:15 GMT References: <98m938$2iod0$1@ID-25716.news.dfncis.de><98pgs1$32up7$1@ID-25716.news.dfncis.de><98umc6$39coj$1@ID-25716.news.dfncis.de> Organization: The World Public Access UNIX, Brookline, MA X-Newsreader: Gnus v5.3/Emacs 19.34 Xref: supernews.google.com comp.lang.ada:6180 Date: 2001-03-28T23:15:15+00:00 List-Id: "Ken Garlington" writes: > > "Robert A Duff" wrote in message > news:wccr8zl4h0n.fsf@world.std.com... > Note, however, that if these literals were "interpreted" as their "obvious" > floating-point context, and the function I posted earlier were introduced, > you'd have to decide if now (a) the literals were "more obviously" an > integer or (b) that the correct form could not be determined from context. > Either way would seem very awkward to me. Granted, you have that problem now > distinguishing different decimal representations, but I certainly wouldn't > want to make it any worse! Sorry, I've lost track of which function you mean. But certainly (a) is Bad (if I understand what you mean) -- it introduces Beaujolais effects. As to (b), once we have determined the type of a literal (ignoring its form), we can then apply some rules to insist that its form is Good. What I don't like is that the form helps determine the type. > : >... If we are to have implicit casts of integers to > : > floating point values, why not then permit the more general: > : > > : > Y : Float := ferble; > : > > : > where "ferble" is a function that returns an integer (or, for that > matter, > : > any fixed-point) type? > : > : Why not? Because it makes no sense. Converting type Standard.Integer > : to Standard.Float probably makes no sense. > > A conversion (or "interpretation", if you prefer) of a representation that > is numeric, but has an implied decimal point to the right of the last digit, > to a representation that has an explicit decimal point to the right of the > last digit, makes no sense? Then why do you want an Ada compiler to do it > for literals? I see the two as completely different. We shouldn't really be talking about Integer and Float here. We should be talking about, say: type Apple_Count is range 0..1_000; type Length_In_Meters is digits 7; We don't want to implicitly convert a number-of-apples to a length, because it doesn't make sense -- they're measuring different things. This has nothing to do with the fact that one is float and the other integer. We wouldn't want to implicitly convert Apple_Count to Orange_Count (two different integer types), either. Literals, on the other hand, have no particular type. The literal "1" could be of any integer type (in Ada), and which type is determined by context. I say it should be "any type", and still determined by context according to the usual overload resolution rules. > : But implicitly converting > : "1" to (say) Float *does* make sense. I was only talking about > : literals. > > Again, this makes about as much sense as insisting that 1 be implicitly > coverted to character, string... or, for that matter, "one half" to be > converted to some numeric type. After all, if you're going to object to the > "overhead" of adding .0, then why not object to adding quote marks for a > character or a single-word string (in the absence of some object with that > name)... isn't each "obvious in context"? Of course it would be silly of me to make a big stink about having to read an extra ".0" in the code. I think it's silly, but it's obviously not a big deal. What I really object to is the general idea that the *form* of a literal helps determine its type (during overload resolution). For example, suppose we have two procedures: procedure Mumble(X: Integer); procedure Mumble(X: Float); Then in Ada, a call "Mumble(1);" will resolve to the first Mumble. But that's error prone. A reasonable person might accidentally think it refers to the other one (because, after all, the number one is a perfectly reasonable floating-point number). I claim that this call should be ambiguous, and therefore illegal. Likewise, "Mumble(1.0)" could be mistaken to refer to the wrong one (because, after all, 1.0 is an integer number). If you want to require the ".0" in a call to the second one, as an extra hint, I won't complain *too* much. But I object to the ".0" being used to help determine which Mumble we're talking about. By the way, when I said "one half", I meant it as an English description of a number. Not as an Ada string literal. I wanted to distinguish the concept of numbers from the way they are written in Ada, so I could complain about the latter clearly -- apparently it didn't work. ;-) So your point about converting "one half" is missing my point. > : Note that Ada always converts literals to some particular type. > > Sure... some type that is *closest* to the representation *as entered*. If > you don't enter a decimal point, why would you expect it to be converted to > a representation that requires a decimal point (fixed or floating)? I don't understand why you think the form of a literal should have something to do with the internal representation of the thing. If that were the case, we would be writing all numbers in binary, because that's closer to their representation. It seems to me that floating point is a way of approximating the real numbers efficiently, at the expense of some loss of precision. Fixed point is a different way of doing the same thing. So it seems to me that the syntax for literals should reflect the way we naturally write numbers, and not worry too much about the internal representation. > : Note also that I'm not advocating all manner of implicit conversions. > : Certainly no implicit conversions that might lose information. > > What about a conversion that adds *unintended* information? I'm not sure what you mean by that. Certainly if I say "it's about 10 miles from here to my house", you understand just as well as if I had written "... 10.0 miles ...". (In fact, I suppose 10.0 would confuse you into thinking I was being overly precise -- but that's a whole 'nother issue.) Leaving off the ".0" doesn't make you think miles are discrete integer quantities, in English anyway. - Bob