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/10 Message-ID: <3374C19F.15FE@sprintmail.com> X-Deja-AN: 240709678 References: <3.0.32.19970423164855.00746db8@mail.4dcomm.com> <5kl9qc$g4d@bcrkh13.bnr.ca> <5kmek2$9re@bcrkh13.bnr.ca> <33727FA5.5C7A@sprintmail.com> Organization: Sprint Internet Passport Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-05-10T00:00:00+00:00 List-Id: I (John Volan) wrote: [*] > > But in this case, I think it would have been politically > savvy to have included something like these attributes, as an answer to > the challenge from C++'s operators. Robert Dewar replied: [*] > > Bad reason! It is almost always a mistake in languages to make compromises > in the design on the grounds that users of language X won't be happy unless > you do. John Volan replies: I will grant you that a language feature cannot be justified _solely_ on political grounds, it has to have enough utility in its own right to outweigh the cost of the added complexity. In this case, however, I believe T'Increment and so forth _would_ have had merit in their own right, irrespective of any analogy they might bear to C++ side-effect operators. As I pointed out, they'd help avoid unnecessary and error-prone repetition of variable names in certain common cases of arithmetic statement, and I believe they'd thereby enhance readability. > Every time I have seen this done I think it is a mistake. Three > examples: [snip good examples of bad language compromises] In each of these cases, a general design principle in language X was compromised to introduce a specific exceptional case, with the only justification being that it was politically necessary to make that special case resemble language Y. But I don't see how any of these are an analogy to T'Increment, etc. How would these be special exceptional cases of attributes? I don't see how they'd "compromise" any of Ada's design principles at all. Now, if I had suggested that these be _functions_ that caused side effects but also returned values or (shudder, shudder) returned "references" to variables, then that truly would have "compromised" Ada's design. Likewise if I had suggested, as others have, that we introduce new side-effect delimiters, e.g. "+:=", "-:=", "*:=" etc. But I suggested nothing of the sort. In fact, these attribute procedures would be no different in kind from any other attribute subprogram already present in Ada95. Consider T'Min and T'Max. Why were they added, when their functionality could easily have been supplied with a generic? In fact, it could have been just another generic child of package Ada. Why aren't T'Ceiling, T'Floor, and the like just more functions in Ada.Numerics.Generic_Elementary_Functions? It can't be because they are somehow "intrinsic", because of course intrinsicness can be supplied by a pragma. No, the reason they're all attributes rather than generics is because they are extremely convenient to have at the tip of your fingers. (I assume that was also the motivation for GNAT's non-standard attributes, e.g. X'Img). The reason for not having included T'Increment etc. could only have been either (1) nobody brought up the issue, or (2) well, it was getting late, and heck we had to draw the line _somewhere_. If so, then fair enough. > Features should go in a language because they make sense in terms of the > syntactic and semantic framework of the language, not because of some > perceived political value. That is especially true of tiny syntactic > gizmos. I agree, but having said all that, you can't _entirely_ ignore politics when designing a language, not it today's climate. And in fact, the design of Ada95 certainly did not (_could_ not) ignore politics. Case in point: tagged types. A _huge_ new "gizmo", adding a whole new layer of complexity to the language. It has been argued several times (and most recently in an article in the March/April 1997 Ada Letters) that tagged type inheritance -- in fact, derived type inheritance in general -- compromises one of the original design principles of Ada: locality of declaration. If a package declares a derived type, you cannot simply look at that package and know what record components and primitive subprograms are defined for that type. You also have to hunt down the package that declares the base type, and look at its components and primitives. If that base type was derived from something else, you have to hunt down _that_ package too, and so on. And if you do classwide programming and get dynamic dispatching, then it's no longer true that you can just look at a subprogram call and know exactly what code is getting invoked. All of these things, if abused, can be detrimental to the goals of software engineering and real-time embedded programming. So why do we have inheritance in Ada95? Because, quite simply, it was perceived by many that Ada9X would be doomed to utter extinction if it did not become a fully object-oriented language. Large constituencies in the computer industry would simply reject it out of hand. (_I_ would have rejected it, and if you know me, that's saying a lot.) Now, at least, Ada95 stands a fighting chance. Isn't it obvious that the decision to add type extension and OO-style inheritance was at least _partly_ political? [*] P.S. Robert, your unconventional quoting style forced me to tease out and re-attribute my own words. Doesn't your newsreader/email program support good old standard ">" quotations? You yourself have argued the benefits of adhering to widely-established conventions, why make an exception here? (Although I will admit, it does allow me to tell at a glance that you are the author of a given post, which I suppose is a nice convenience... :-) ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------