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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d1df6bc3799debed X-Google-Attributes: gid103376,public From: "John G. Volan" Subject: Re: Not intended for use in medical, Date: 1997/05/11 Message-ID: <3375EBA0.777A@sprintmail.com> X-Deja-AN: 240877247 References: <3.0.32.19970423164855.00746db8@mail.4dcomm.com> <5kl9qc$g4d@bcrkh13.bnr.ca> <5kmek2$9re@bcrkh13.bnr.ca> <33727FA5.5C7A@sprintmail.com> <3374C19F.15FE@sprintmail.com> Organization: Sprint Internet Passport Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-05-11T00:00:00+00:00 List-Id: Robert Dewar wrote: > > No, I think it is just that they seem to junky, ... I hope this is not just a case of "guilt by association." I seem to recall that those "+:=" operators were proposed during the Ada9X process, and I agree those did seem quite "junky". But I've tried to distinguish T'Increment etc. from those. T'Increment might be _analogous_ to "+:=", but I hope I've made it clear how it would be safer, and more "natural" for Ada. > ...at least in this form. Hmm. What form would make them seem less "junky" to you? > Certainly for instance the notion of "Increment" is inappropriate for > enumeration types. I can't see why. It seems plain to me that to "increment" a variable would mean to assign it the "successor" of its current value, whatever that happens to mean. Since enumeration types have a well-defined meaning for the notion of "successor" and "predecessor", and built-in support for that notion already (T'Succ and T'Pred), there shouldn't be any difficulty there. Perhaps the word "increment" has some different connotation for you (e.g., "Why, John, it just means "add 1" doesn't it? Come now, how can you "add 1" to an enumeration! Don't be so silly...") If the only problem is the label I've affixed to the concept, then perhaps a different one could be found. (Perhaps just overload T'Succ and T'Pred as procedures?) Certainly T'Increase(X, By => ) and T'Decrease(X, By => ) would _not_ be defined for enumeration types, since these would be implemented in terms of "+" and "-", which of course are not part of the abstraction for enumerations. Now, where someone could have difficulty accepting T'Increment and T'Decrement would be for the case of floating and fixed point types, for the same reason that they might have trouble with T'Succ and T'Pred for those types. As you know, Ada83 did not include T'Succ and T'Pred for real types, presumably because there can be no notion of "successor" and "predecessor" for actual mathematical real numbers, because between any two reals there is always an infinity of other reals. But now Ada95 has come up with meanings for T'Succ and T'Pred for floating and fixed point types: for fixed they add/subtract small; for floating they return the machine number immediately above/below; loosely speaking, they return the next representable value greater/lesser than the argument. A mathematical purist would (rightly) scoff at this idea and call it "junky". But a computer programmer should take to this notion readily because...well, let's face it, computers _are_ "junky" in this regard. They have trouble representing infinity. We have to make compromises: floating and fixed-pointe types are only _approximations_ of true mathematical real numbers. They can only represent a finite number of points on the real number line. Well, the notion of being able to get the next "representable" value, given our compromise with infinity, turns out to be an extremely useful one from a practical point of view. Hence, T'Succ and T'Pred for real types. > I personally prefer NOT to see T'Increment and > T'Decrement added, and would not find these sufficiently attractive > additions to be worth the extra complexity. Oh, come now, how much extra "complexity" would it be? How much complexity did T'Min and T'Max add? T'Min is essentially just: function T'Min (Left, Right : T'Base) return T'Base is begin if Left < Right then return Left; else return Right; end if; end T'Min; (well, obviously not literally so, but you know what I mean). And T'Increment would simply be: procedure T'Increment (Arg : in out T'Base) is begin Arg := T'Succ(Arg); end T'Increment; That doesn't seem like a whole lot of complexity to me... > So both of the reasons > you guess are wrong -- it is simply that people do not agree with > you that these would have been worth while additions! I can accept that -- although I'm not sure who you mean by "people". The "people" haven't said much on this subject lately, so I don't know whether they'd agree with me or not. :-) But as for those who had decision-making power during the Ada9X process, if this was presented to them and they rejected it, I'd have to think it was just a matter of taste: Somehow, T'Min and T'Max suited the taste of those with the votes, and somehow T'Increment etc. didn't. (_If_ it ever happened. Did anyone propose standard attribute procedures (or even just standard procedures) as an alternative to the "+:=" proposal during the Ada9X process?) Bottom line, I just can't see any _technical_ distinction between T'Min, T'Max, and T'Increment, etc. > P.S. going back to 'Max and 'Min, I find these tolerable, though unnecessary > additions to Ada 83. If you tell me that your view is that if I have Min > and Max, then I should also have all yoru extra attributes, then I would > prefer to have none of them. Right. All of these attributes can be composed out of elements already present in the language, so in a sense they are "unnecessary". Don't get me wrong, T'Min and T'Max are nice to have. But when I noticed them in the RM, I was puzzled how they managed to slip under the door, given the pressure to keep down the creeping featurism. But I happen to be of the opinion that T'Increment, etc. are a little more than "nice to have" features. As I've already said, I think they're in the category of "not strictly necessary but enhancing readability and error-avoidance," worthy goals in keeping with the design philosophy of Ada. T'Increment, etc. also happen to be analogous to (but much safer than) certain very popular built-in operations at the immediate disposal of C and C++ programmers. They also seem to be analogous to certain perfectly reasonable, safe, and useful operations in other languages, notably COBOL's "ADD 1 TO X". (I think there's something similar in Lisp, but my old Lisp textbook is in a box somewhere...) The absense of analogs to these operations in Ada95 seems to me a challenge to Ada's acceptability (though admittedly a small one) to programmers coming to Ada for the first time from other languages. I don't think in today's climate Ada can afford to live in an ivory tower and eschew _all_ concerns of a "political" or (shudder, shudder) "marketing" nature. ------------------------------------------------------------------------ Internet.Usenet.Put_Signature (Name => "John G. Volan", Home_Email => "johnvolan@sprintmail.com", Slogan => "Ada95: The World's *FIRST* International-Standard OOPL", Disclaimer => "These opinions were never defined, so using them " & "would be erroneous...or is that just nondeterministic now? :-) "); ------------------------------------------------------------------------