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-Thread: 103376,21960280f1d61e84 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!130.59.10.21.MISMATCH!kanaga.switch.ch!switch.ch!news-fra1.dfn.de!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: How come Ada isn't more popular? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1169636785.504223.139630@j27g2000cwj.googlegroups.com> <45b8361a_5@news.bluewin.ch> <3pejpgfbki.fsf@hod.lan.m-e-leypold.de> <8lwt2zb8ga.fsf@hod.lan.m-e-leypold.de> Date: Sun, 4 Feb 2007 18:55:47 +0100 Message-ID: <96swuj6qxb$.1k74rt53lh46v.dlg@40tude.net> NNTP-Posting-Date: 04 Feb 2007 18:55:47 CET NNTP-Posting-Host: f2e7e621.newsspool1.arcor-online.net X-Trace: DXC=GWMH@V75[MbOKO]LCQ@0g`ic==]BZ:afn4Fo<]lROoRa^YC2XCjHcbi\@e>4hAn26jDNcfSJ;bb[eIRnRBaCd On Sat, 03 Feb 2007 15:51:33 +0100, Markus E Leypold wrote: > "Dmitry A. Kazakov" writes: > >> On Fri, 02 Feb 2007 14:57:17 +0100, Markus E Leypold wrote: > >>> When I talk about all those transitions, I see, that there was no >>> C->Ada transition, at least no mass movement. So we come back to the >>> C->initial question: Why not? >> >> How much popular was C that time? I am asking this question because I > > Really popular, at least in Europe and the US, I think. Pascal was a > real contender on micros in the eighties but it had practically lost > out in the nineties despite there being still a good number of Delphi > shops/people/developers around. > >> learned C after Ada. My personal transition was FORTRAN-IV/PL/1 -> Ada 83. > >> I think so. GNAT was a quite poor compiler for too long. Another important > > GNAT is still annoying the hell out of me in fringe areas of the > language. And the errors are so fundamental, that I begin to think > that it will take a long time to smoke them out. Well, visibility in generics is still a great problem. > Furthermore I believe there is simply no incentive for AdaCore (who as > I understand maintain most of the GNAT code in the GCC repository) to > establish a good or stable baseline in the publicly accessible > repository. Yes, at least a publicly available bug tracking system. I have an impression that the same bugs come and go over and over again. >>>> Why? OO is about encapsulation and polymorphism, these don't need >>>> references everywhere. >>> >>> Yes, but -- you want to keep, say, a list of Shape(s). Those can be >>> Triangle(s), Circle(s) etc, which are all derived from class >>> Shape. How do you store this list? An array of Shape'Class is out of >>> question because of the different allocation requirements for the >>> descendants of Shape(s). >> >> Why should this worry you (and me)? It should Randy and Robert! (:-)) >> >> The language does not require array implementation to be contiguous. Randy >> told once that Janus Ada is practically ready for >> >> type X is array (...) of Y'Ckass; > > OK, then But non contigous representation of arrays will really stress > memory management, fragment the heap (we can't do that on the stack > AFAIS). Maybe, but it is no different from what would happen in any other implementation. Note that there is a sufficiently different case, when all Y'Class are of the same shape. For this I propose Tag discriminants: type X (Shape : Y'Class'Tag.) is array (...) of Y'Ckass (Shape); Here the compiler can allocate X in one chunk of memory. > And what about mapping of C arrays to Ada arrays That were not possible, but it also were no problem. When you apply pragma Convention to an array type, the compiler should tell you that you can't have dynamic bounds and elements. You cannot pass String down to C, but you could try String(1..20). [If there were no Interfaces.C of course.] >>>> What about maintainability and reasoning? >>> >>> What about it? It's easy with value-oriented languages (i.e. languages >>> that just produce new values from old ones in a non-destructive >>> fashion). Functional languages do this therefore reasoning is a well >>> developed art there. But the representations of all those values >>> (trees, lists, ...) (a) rely heavily on representation sharing and (b) >>> use references because of that. They need and use GC. > >> You are mixing by-value vs. by-reference semantics with no-identity vs. >> has-identity. > > No. Values have no "identity". It depends. Polymorphic value has an identity. But I understand what you mean, and that meaning is correct. > "Object identity" smacks heavily of > storage and memory chunks. No. Identity is just a function id:X->I, where I is some set of comparable values. No magic. X'Address or X'Access can serve as an identity function. Or not, if you have relocatable objects, for instance. In general nothing in objects requires X'Address. There are other kinds of identity. For example id:X->T, where T is the type of X. > I fail to see how "identity" comes into the question of > "value-oriented" languages (your term, BTW) and represenation > sharing. GC is about references (to memory) and representation sharing > works with references to parts of another "value" (see lisp > lists). Represnattion sharing needs either reference counting > (inefficient, is also just some kind of instant GC) or GC. The example you mentioned was a tree. Do you want to share subtrees between other trees? When a subtree C of a tree A changes, should it ("it" is an identity (:-)) in the tree B be changed as well? You cannot answer these questions in terms of tree values. For all possible answers there exist corresponding values of A, B, C, C in A, C in B, A/\B etc. It is a semantic problem which has nothing to do with representation, be it immutable-functional or shared. Identity is a way to express this semantics. Value vs. reference is a semantically irrelevant implementation detail. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de