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-Thread: 103376,c406e0c4a6eb74ed X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: ADA Popularity Discussion Request Date: Thu, 9 Sep 2004 11:12:08 +0200 Organization: cbb-software GmbH Message-ID: <7aytmncfkoep.1rju9m4v4xl21.dlg@40tude.net> References: <49dc98cf.0408110556.18ae7df@posting.google.com> <6F2Yc.848$8d1.621@newsread2.news.pas.earthlink.net> <413e2fbd$0$30586$626a14ce@news.free.fr> <9snhizowcwg9.16smaxkxhyu67$.dlg@40tude.net> <1m4nnmjq31u5p.1ufrf06w53qsz.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1JmWF7/3qmUGMlI0BehyhQMDFfEjA7v6O8G01e0Awit5liYeI= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:3531 Date: 2004-09-09T11:12:08+02:00 List-Id: On 08 Sep 2004 19:23:40 -0400, jayessay wrote: > "Dmitry A. Kazakov" writes: > >> On 08 Sep 2004 12:26:54 -0400, jayessay wrote: >> >>> "Dmitry A. Kazakov" writes: >>> >>>> The philosophy behind is that types are random artifacts of the >>>> program, >>> >>> No, this is also incorrect. The real difference is that with dynamic >>> typing _values_ have types _not_ variables. Since _variables_ don't >>> even exist at runtime, your type information is largely gone at >>> runtime in static systems. >> >> I suppose you are talking about polymorphic objects. > > No, I'm not. Simply put variable don't exist at runtime. I'm talking > about every value having its type with it. But that's exactly what a [dynamically] polymorphic object is. Its value (a class-wide value in Ada terms) carries the type tag with it. The type tag determines the specific type. Note that this specific type is not the type of the object. T and T'Class are different types in Ada. Note also that there is still room for static checks here. Toy'Class and Gun'Class are statically different types. So Baby.Take (Gun) will be a compile error. >> 1. That statically typed languages cannot express polymorphism? This is >> plainly wrong. > > This is irrelevant as again, the type information is basically gone. > You have certain limited RTTI abilities, but that is not the same. Should it mean that dynamic polymorphism is not powerful enough for the tasks ...., which ones? Note that nobody says that ADT theory in its present state is complete. So to argue against its concrete implementations in concrete statically typed languages would be rather wasting time. Because everybody will agree that there are [many] problems. So your argument should go beyond that. Namely: no static analysis of types in any its form can be fundamentally useful. Here we go again.... >> 2. That all polymorphic values should be considered of same type ANY? This >> is also wrong. > > No, this is irrelevant. Really? But then if you have different bases like Toy and Gun, you can use this type information to *statically* ensure that no type of guns can be ever given to a child. >> As Unchecked_Conversion does. > > I guess i've forgotten this (never really used it much). So, when > 13.9(5) says an instance of this returns a value whose "representation > is the same as that of the source, ARM then continues to the list of conditions to be satisfied to make the above true. In other cases the result might be quite different. For example when you convert between a general access and pool specific access types. Former are probably fat pointers, latter could be tiny integers, depending on the compiler, of course. > how is that functionally different from a cast? It is a cast. > I realize that can make a differnce at compile time, but > where's the runtime difference? Especially as there's no type at > runtime. How so? Types do exist at run-time. Consider it as if the *unused* type information were optimized out. >> is a part of the language, why the compiler should be prevented from >> checking where it can? > > It's _not_ prevented - it isn't _required_ to! That's silly. Why not to require to check what could be checked? Compare with your beloved tests. You can test, but not required to. Any difference? No one, except that types as a concept have reached the level of formality where they can be integrated into the language to support static analysis. Which only means that the tests related to types and their relationships are performed by the compiler. Pre- and post-conditions is another example of tests which can be partially automated. The rest, TDD etc has not reached that level. It is no more than a mere informal advise of good programming practice. As such it by no means can supersede static analysis. >> Again, having accepted types you cannot argue that to check them earlier is >> worse than to check them later. > > If you think I'm arguing that, you really haven't understood. I'm not > saying checking them "earlier" is somehow bad, I'm saying it is > largely irrelevant in practice with dynamic typing because any type > inconsistency is caught during development anyway! "Any type inconsistency caught anyway" is either too strong to be true or else it just means that there are no interesting types to check for consistency. The latter returns us back to the starting point. Are you using types in your software design? -- Regards, Dmitry Kazakov www.dmitry-kazakov.de