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=0.6 required=5.0 tests=BAYES_00,FROM_WORDY autolearn=no 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 21:04:06 PST Path: supernews.google.com!sn-xit-03!supernews.com!nntp.cs.ubc.ca!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.cwix.com!newscon06.news.prodigy.com!prodigy.com!newsmst01!postmaster.news.prodigy.com!newssvr16.news.prodigy.com.POSTED!not-for-mail From: "Ken Garlington" Newsgroups: comp.lang.ada 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> Subject: Re: Static typing (Was Re: Better support for garbage collection) Organization: ex-FlashNet, now Prodigy X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: <4mzw6.414$OQ6.73321643@newssvr16.news.prodigy.com> NNTP-Posting-Host: 65.65.211.168 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr16.news.prodigy.com 985842176 6207069 65.65.211.168 (Thu, 29 Mar 2001 00:02:56 EST) NNTP-Posting-Date: Thu, 29 Mar 2001 00:02:56 EST Date: Thu, 29 Mar 2001 05:02:56 GMT Xref: supernews.google.com comp.lang.ada:6184 Date: 2001-03-29T05:02:56+00:00 List-Id: "Robert A Duff" wrote in message news:wccvgotscxo.fsf@world.std.com... : 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. However, form would still be used to distinguish between numerics, characters, and strings even if your proposal is adopted. Why is it harmful in one context, but not another? : > : >... 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. And, very importantly, I'm *not* talking about Integer and Float here. I'm talking about integer, floating point, and fixed point *literals*. : 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), Right! To continue the thought - it *couldn't* be a string, a character, etc... (where Ada includes "floating point" and "fixed point" value in the "etc."). : 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. I think you either meant (a) any *numeric* type, in which case you're inconsistent, or (b) *any type*, which is now an internally consistent position, but brings about some new problems. For example, how should the following be interpreted? X : constant String := 1_000; Is the underscore retained? : > : 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. My point is not that it's a trivial position (although it is), but that it's an *inconsistent* position,. After all, we could just as easily say that Ada should accept X : constant Character := 0; where the tick marks would be equally unnecessary. This would be much more like a Do What I Mean compiler, which would annoy me no end. : 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). As noted earlier, not according to the dictionary definition of "floating-point". : 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). Not according to the dictionary definition of "integer". : 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. Then, to be consistent, you have to object to these as well: procedure Mumble("0"); procedure Mumble('0'); procedure Mumble("0.000"); and so forth. : By the way, when I said "one half", I meant it as an English description : of a number. In order to deduce this, I would have had to look at the form of the expression, now wouldn't I? :) : 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. But "one half" is an equally valid way of describing 0.5, 1/2, 1.0/2.0, etc. using the informal notation you appear to have adopted... if not, why not? : > : 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. I never used the word internal in the sentence above. : 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. Oops! Now *you're* dealing in internal representations. Floating-point numbers aren't an approximation of anything, according to Merriam-Webster. It's a mathematical notation (a representation, in the dictionary's words) for a real number. Any precision can be represented. : 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? Example: I write 4, meaning the integer value 4. You convert it to '4', since that's the context in which I appeared to use it. You've added information (4 can be a character) that I didn't intend.