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 Path: border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newspeer1.nac.net!newsfeed.xs4all.nl!newsfeed4a.news.xs4all.nl!xs4all!news.stack.nl!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Your wish list for Ada 202X Date: Sun, 13 Apr 2014 23:07:21 +0200 Organization: cbb software GmbH Message-ID: <1kwpgk4mrnzey.18388dob823vp$.dlg@40tude.net> References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com> <8bhozh836pyt$.1qctlysud0s2q$.dlg@40tude.net> <1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net> <1aa804jg9qq4o$.wdiq33yo621l.dlg@40tude.net> <1w6eh0aiksmdh$.1h16p7y0b8c6h.dlg@40tude.net> <17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net> <1wjmcbk375lzk.6o7dpqcp3va3.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: AuYlnUSfTZrfhAkRjyySpQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 X-Original-Bytes: 7077 Xref: number.nntp.dca.giganews.com comp.lang.ada:185730 Date: 2014-04-13T23:07:21+02:00 List-Id: On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote: > On 14-04-12 11:20 , Dmitry A. Kazakov wrote: >> I don't deny >> existence of the problem. I am against the solution, which is inherently >> unsafe and constraining (precludes by-copy semantics). > > But class-wide operations which contain dispatching calls also preclude > by-copy semantics, don't they? Not at all. There is no problem for a class-wide operation to act on by-copy types. A by-copy class-wide object is a tuple (tag, type-specific value). Upon dispatch the value is passed copy-in/copy-out to the type specific operation. > A class-wide operation, in my view, is just like a primitive operation > except that (1) (re-)dispatching is implicit and automatic for all calls > to primitive operations of the parameter object (because the parameter > is a class-wide type) and (2) the operation cannot be overridden. There is no re-dispatching in a class-wide operation. It is defined on class-wide objects, so it simply neither dispatch nor re-dispatch. > (This is why I don't understand your and Randy's abhorrence of > re-dispatching -- to me, there is no basic difference between > dispatching calls in class-wide operations, and re-dispatching calls in > primitive operations.) The difference is in types involved. A body of a primitive operation is defined on a particular specific type. A re-dispatch within the body breaks this type contract by calling an operation defined on *another* type. This is an untyped behavior. >> The concept should somehow play together with the notion of polymorphic >> operation defined on the class (set of types). Between these two ends: >> independent bodies of a primitive operation and single body of a class-wide >> operation, there lies a whole spectrum of unexplored possibilities. > > I feel that my use of re-dispatching gives me something like that. And I > don't see the problems in re-dispatching that you and Randy worry about. Untyped programming style has known problems. The point is not that an improperly typed program could not expose correct behavior. Of course it can, "it worked to me" is never an argument. One could design a working program directly in machine code. That does not imply that this would be a good idea. >> Then I try to maintain the "no >> abstraction inversion" rule, i.e. never call a "higher-level" operation >> from a "lower-level" one. > > Yes, same here. But re-dispatch would be exactly this kind of inversion. Remember, no higher-level operation is primitive, since I make all higher-level operations class-wide or else self-contained. >> And, I am not a language >> designer anyway. I am a programmer. As a programmer, from my experience >> with Ada, I tell the language designers that they got it all wrong since >> Ada 2005. I don't want yet another dynamically typed or functional >> language. I need a language for software engineering. More static checks, >> more means to make static checks possible. The whole language should >> revolute around helping restructuring my programs in order to support >> static checks. No Constraint_Error to me, please! > > That's a good goal, but I don't think it should be the only goal for Ada. > > Ada's problem and challenge is that it very ambitiously aims to combine > high-level, expressive, and therefore somewhat dynamic language features > with predictable, efficient execution as required for critical embedded > systems. It depends on your understanding of dynamic features. To me it is all OK to have dynamic features (AKA generic programming) under certain conditions. One is that the language remains typed. Ada 95 solved that by introducing a separate type for class-wide objects. Another is that generalized contracts remain statically checked. Again, it is partially so, because Ada 95 guaranteed that dispatch never fail, an operation is either inherited or else requires overriding. There is no gaps in the dispatching table (except for missing MD). But Ada 83 missed that goal when introduced Constraint_Error for discriminated types, array bounds, overflows without means to check exception contracts statically. Ada 2005/2012 broke things even further by adding dynamic constraints, predicates etc. A related requirement is that whatever categories the language introduces they must be spelt as objects, types, operations. The language must be well-structured. Ada 85/95 was, though it had no so much typed things, like ranges and attributes. Ada 2005/2012 ruined much of that. > I think that it will be more and more difficult to extend and evolve Ada > in both directions (high-level, expressive, dynamic; vs. low-level, > predictable, static) without in practice dividing the language into two: > a "high-Ada" and a "low-Ada", with some compilers targeting the high and > others the low. I don't believe in this separation. To me dynamic vs. static is not high vs. low. In first place, there is no fully dynamic system. For any given system observed as dynamic, you can always lump together involved objects, call the result a type and things become static again. So, the requirement is that you can have your dynamic things as much you want, but you MUST introduce an explicit named type for the resulting set of objects. Just as Ada 95 did with T'Class. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de