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-29 19:44:02 PST Path: supernews.google.com!sn-xit-03!supernews.com!nntp.cs.ubc.ca!newsflash.concordia.ca!sunqbc.risq.qc.ca!howland.erols.net!newsfeed.cwix.com!newscon06.news.prodigy.com!prodigy.com!newscon07!newscon07!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><4mzw6.414$OQ6.73321643@newssvr16.news.prodigy.com> 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: NNTP-Posting-Host: 65.65.209.165 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr16.news.prodigy.com 985923702 6207069 65.65.209.165 (Thu, 29 Mar 2001 22:41:42 EST) NNTP-Posting-Date: Thu, 29 Mar 2001 22:41:42 EST Date: Fri, 30 Mar 2001 03:41:42 GMT Xref: supernews.google.com comp.lang.ada:6225 Date: 2001-03-30T03:41:42+00:00 List-Id: "Robert A Duff" wrote in message news:wccofuk87gj.fsf@world.std.com... : "Ken Garlington" writes: : : > "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. : : No, my proposal is that the form of a literal does not help determine : its type. That applies to all kinds of literals. OK, that's at least internally consistent. However, the number of ambiguities now is significantly expanded. For example: J : constant := 1; -- legitimate named number, or did I mean to type J : constant Character := 1; Even better: J: constant String := a; -- is this a literal "a", or a reference to something that I forgot to import? Both are possible... I'm not sure I want a language that has a design goal of catching faults to be loosened in this regard. (I'm not sure I want it to be *tightened* either in this regard, because I am still human, after all. :) : As I said above, *after* overload resolution has determined the type of : a literal, we can apply rules that ensure the form of the literal is : appropriate for that type. As you suggest, it's probably not a good : idea for: : : "12" : : (with the quotes) to be allowed as an integer. I'm more worried about the _reverse_ case, where 12 is allowed as either a string or an integer. However, why CAN'T "12" be an integer? : I would eliminate the syntactic distinction between character literals : and string literals -- just use double quotes for both. Then the : compiler has to determine whether "A" is a character or string from : context. However, this says that the form of the literal can be used to distinguish between numerics and text. Why make a form-based distinction here, but not within different forms of numerics? :: By the way, the "ulterior motive" in my ideas about literals is that : what I *really* want is user-defined literals. I think the programmer : should be able to say "this type here has literals", and define which : forms are legal for that type, and what they mean. But in order to : avoid chaos, we can't have the form of the literal affecting overload : resolution. I'd have to understand the proposal better, but I don't see why abandoning form is a good idea here. Assume a type type X is (1, 2, 12.7); function "/" (A, B: X) return X; Q: X := 1/12.7; how does form-assisted resolution hurt you? : > And, very importantly, I'm *not* talking about Integer and Float here. I'm : > talking about integer, floating point, and fixed point *literals*. : : I was trying to explain why the "interpretation" of a literal is : different from an implicit type conversion from (say) Integer to Float. : I wouldn't want to allow the implicit type conversion, because it : violates the type system. But literals are different -- a literal, in : and of itself, is not of any particular type. You've contradicted this statement above, by distinguishing between numerics and text. : So you're not really : doing an "implicit conversion" in the usual sense (even though the RM : describes it that way). : : > : 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."). : : It's fine with me if 1 can't be a string, because it has no quotes (my : quoting conventions in English are confusing the issue here!). But I : want that to be a post-resolution legality rule. I don't want the lack : of quotes to help *determine* its type. This says that you'd be willing to make quotes optional for text? Or not? : > : 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? : : I really did mean "any type". : : > X : constant String := 1_000; : > : > Is the underscore retained? : : Probably the right rule is that string literals must have quotes, so the : above is illegal. Back to form of the literal contributing to its interpretation (*sigh*) : Do you understand the rather subtle distinction : between letting the literal's form determine its type, versus making : certain forms illegal after having determined the type (clearly String, : in the above case)? If it's clearly String, why would 1_000 be an illegal string? If you can explain that, then I might understand the distinction... : > : 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), ... : : The whole trivial argument is an awful lot of fun, though! : : >...but that it's : > an *inconsistent* position,. After all, we could just as easily say that Ada : > should accept : > : > X : constant Character := 0; : : I would require: : : X : constant Character := "0"; -- note double quotes : : and also allow: : : X : constant String := "0"; : : because the context unambiguously determines the type of the literal in : each case. But I would say just plain 0 without quotes would be a : malformed literal if it turns out to be a character or string literal. I understand that you see it as a "malformed literal"... but WHY is it a malformed literal, any more than X : constant Float := 1; would NOT be a malformed literal under your proposal? Isn't the desired result "obvious" in each case? I see BOTH of these as malformed literals, based on the commonly accepted conventions for quoted text and floating-point values. : I don't see any inconsistency. : : > 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 don't think the dictionary definition you quoted is what Ada means by : floating point types. In Ada, floating point is referring to an : internal representation, and the behavior of the operators -- not to the : display on the screen. OK... now, WHY do you believe this? : > : 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. : : Yes, and I do. I would like to call those "ambiguous and therefore : illegal". OK, but then note that the following will (almost) always be illegal: X : constant Float := 1/2; X: constant Integer := 1/2; X: constant Float := 1.0/2.0; X: constant Integer := 1.0/2.0; because it's ambiguous which "/" operator is intended here (assuming one is visible for both types). Currently, only two are illegal. Do we really want to break existing programs in this manner? : > : 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? :) : : Well, English is like that. A programming language ought to be less : susceptible to misunderstandings. Exactly - it should have even *more* rules about interpretation, not less. English often ignores form, expecting things to be resolved by context. : > : 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? : : Too hard to describe precisely in the RM. To hard to implement in : general. Not worth the trouble. : : The only reason I wrote "one half" is because it's a notation for : describing a number that is *not* allowed in Ada or any other : programming language I know -- hoping you would guess this is just an : English-language description of a particular number. -- uncompiled: errors may abound function To_Float (Fraction_Description : in String) return Float is begin if Fraction_Description = "one half" then return 0.5; else ... end To_Float; X: = constant Float := To_Float("one half"); All you'd have to do is agree on common descriptions and have at it! : > : > : 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. : : OK. So that wasn't quite fair of me. Nonetheless, Ada floating point : is all about the internal representation, despite what your dictionary : says. Actually, multiple dictionaries (see FOLDOC, for example). It *can* refer to an internal representation, but it's not limited to that. Any evidence to the contrary? : > : 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. : : OK, I see what you mean. I didn't intend to allow that. : : - Bob