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,21960280f1d61e84 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: How come Ada isn't more popular? 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> <96swuj6qxb$.1k74rt53lh46v.dlg@40tude.net> <1pli2ou515l1z$.jfgoxqdhukav.dlg@40tude.net> From: Markus E Leypold Organization: N/A Date: Mon, 05 Feb 2007 14:53:31 +0100 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:Ihwq6VwBgpOGPtCb9c6xaqj6fQo= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.74.38.71 X-Trace: news.arcor-ip.de 1170683309 88.74.38.71 (5 Feb 2007 14:48:29 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news2.google.com!news1.google.com!news.germany.com!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:9000 Date: 2007-02-05T14:53:31+01:00 List-Id: "Dmitry A. Kazakov" writes: > On Sun, 04 Feb 2007 23:33:40 +0100, Markus E Leypold wrote: > >> "Dmitry A. Kazakov" writes: >> >>> They don't share subtrees they share memory (implementation), which is >>> casual to the program semantics. >> >> They share representation in the underlying system / VM / whatever you >> call it. > > Whatever. They are not shared in the sense of aliasing, when you have more > than one name for semantically same thing. 1+1 and 3-1 "share" 2. And this > is irrelevant to where 2 might be allocated or how it were encoded. > >>>>> When a subtree C of a tree A changes, should it ("it" is an >>>>> identity (:-)) in the tree B be changed as well? >>>> >>>> Change? There is no "change" in a functional world, only the >>>> production of new values (i.e. new elements from a specific set, in >>>> your case the set of all trees). >>> >>> (New values? What is the difference between new and old values? Do values >>> carry RFID chips with timestamps? (:-)) >> >> Don't play dumb. There is certainly an order between values occuring in >> a (functional) program. If let x = f y, I suggest that the parlance "x occurs after y" in the sense of "order in which values are produced during evaluation" is certainly legal. > > Values "occur"? [ You cannot fix the sentence above, it is semantically > broken. ] You're playing dumb. Can't help you there. >>> Consider a mapping between nodes of two trees which has to be >>> preserved. Now a function of the first tree is evaluated, what >>> happens with the function of the second tree? >> >>> g >>> A ------> B >>> | | >>> f| | id = nothing happens >>> | | >>> V g V >>> f(A) ------> B (broken invariant) >> >> The function of the second tree? What are you talking about? Let me >> repeat: In pure functional languages nothing "changes". > > Consider A = tree, B = its maximal path. When f(A) "occur," [a node is > removed] what happens with B? 'occur' -- your way to read what I said is certainly semantically broken. > Answer: nothing happens, the program is broken. The programmer has to > manually evaluate Max_Path(f(A)). "Maximal path of" is non-functional. LOL. > >> It makes a >> difference if you pass an access to a variable instead of passing the >> variable as an in/out parameter and there is a difference if you >> pass it as an in parameter. > > It does because access T and T are different types! T is not passed, access > T is passed (by reference or by value). > > You could save much time if you just said that you wanted referential > objects (pointers). Period. > > Now my question again, what prevents you from collecting objects accessed > via controlled referential objects? I do not even know any more what you're talking about. You introduced the "references don't matter, its a question of implementation not semantics". Since you also fail to understand how representation sharing is implemented in (most functional languages) you are bound to fail to understand how that makes GC a necessity in FP. That AFAIR was my last train of clear thought in this sub-thread. What that has to do with "controlled referential objects" I don't know, since I certainly didn't talk about them. I now have to go to my brain engineer and let him overhaul some areas of my brain. Talking to to you has, sometimes, a rather destructive effect. Regards -- Markus