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: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Languages don't matter. A mathematical refutation Date: Thu, 9 Apr 2015 16:35:50 +0200 Organization: cbb software GmbH Message-ID: References: <87oan56rpn.fsf@jester.gateway.sonic.net> <877fts7fvm.fsf@jester.gateway.sonic.net> <87twwv66pk.fsf@jester.gateway.sonic.net> <32ecaopodr1g.1xqh7ssdpa2ud.dlg@40tude.net> <87pp7j62ta.fsf@jester.gateway.sonic.net> <87pp7hb2xo.fsf@jester.gateway.sonic.net> <5rxvgyes5xg8.1mqq86gacbsb1.dlg@40tude.net> <87lhi5ayuv.fsf@jester.gateway.sonic.net> <87oan0aote.fsf@jester.gateway.sonic.net> <878ue3ff6y.fsf@jester.gateway.sonic.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: w2sqUGEBZqsVBYNL7Ky3Kg.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 Xref: news.eternal-september.org comp.lang.ada:25490 Date: 2015-04-09T16:35:50+02:00 List-Id: On Thu, 09 Apr 2015 15:14:59 +0200, G.B. wrote: > Now, WRT storage management, assume a bounded container. > The implementation may pre-allocate the maximum number of > objects.(*) Given that, why should it not be possible at all, > in no case, to guarantee a known complexity of storage > management? A bounded vector, say, could specify its > storage management needs, on condition that ... Much like > a hash table package would state that > > "As long as the number of slots is as least N/M, > finding an object will take no more than f(M, N, g(Hash))." Which is elementary incomputable, as it contains the future tense and thus cannot be a part of any contract. >> GC is non-functional and unrelated to the program behavior, which is >> another way to explain why GC is neither low nor high level. It is >> non-existent. > > Like everything that actually handles program data, GC does > influence the program's behavior, e.g. by taking time. That is not the program behavior. The behavior is only things related to the program logic = functional things. Any other things happening upon execution of the program are abstracted away, which is the only way to define 'behavior' without dragging the whole Universe into the picture. > Hence, one may influence GC in server JVMs, for example. Yes, and this is why GC is a bad idea, since its potentially breaks the abstraction and causes unpredicted behavior = *use* of GC is a [potential] bug. > But that's the point. Suppose there is an abstract description > of GC behavior, in terms of parameters. Will the description > be sufficiently detailed for guiding the design of an algorithm? Sure. But that is beside the point. You can design GC and you can do it in a fully contractual manner under SPARK with all bells and whistles. But that would not change anything for the application program which would try to use GC. These are two unrelated things. A correctly behaving GC is still a bug. Compare it with goto. There is no doubt that jumps and labels behave correctly... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de