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,ab1d177a5a26577d X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder.news-service.com!feeder.news-service.com!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: What's wrong with C++? 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: <1ee1a434-4048-48f6-9f5e-d8126bebb808@r19g2000prm.googlegroups.com> <17coueqbf1p27.1g0wj3010saxe$.dlg@40tude.net> Date: Thu, 17 Feb 2011 19:46:19 +0100 Message-ID: <5cys53fdeh64.1s8slmn2cu4o4.dlg@40tude.net> NNTP-Posting-Date: 17 Feb 2011 19:46:15 CET NNTP-Posting-Host: be88000e.newsspool4.arcor-online.net X-Trace: DXC=LjBT0k^JRbmJ00P1S40fZg4IUK On Thu, 17 Feb 2011 12:27:11 -0500, Peter C. Chapin wrote: > On Thu, 17 Feb 2011, Dmitry A. Kazakov wrote: > >> The second note is that if types are not the things from the problem space >> (of which the compiler knows little or nothing), then what kind of stuff >> is there in their place? I presume that nothing. > > You can still define the types you need. Inference just means that you > typically don't have to bother with explicit declarations: create the > objects you need (of the types you need) and let the compiler work out the > details. How the compiler may know that 1.7 is magnetic flux? I don't mean if the compiler derive type constraints: Text : String := "abcd"; That is OK to me. >> Now the main objection is computability and decidability. Only "simple" >> things can be inferred. The compiler cannot solve problems beyond >> Turing-completeness... > > It sounds like you are taking "type inference" to mean that the compiler > figures out pre-conditions, post-conditions, etc. I'm just talking about the > compiler recovering type information based on how entities are used. I doubt this were possible in a rich type system where types are consistently cloned. E.g. in Ada: type My_Integer is new Integer; The properties of both types are same. The above is a typical case of reuse. It seems that reuse is incompatible with inference. There is nothing that tells us that two things are indeed same or not. Maybe the same would be inferred from both, maybe not, how do I know? BTW, inference is incompatible with information hiding and modularity. In order to infer you have to lay everything open, not a good software engineering practice. Even if you say that inferring were optional. Let some part of the system rely on that "optional" inference. That automatically makes it mandatory. What happens if in the process of maintenance inferring stop working because of small incremental changes? > The algorithms for doing this are well understood and they are decidable. Maybe, like pattern matching is, decidable but incomprehensive. It is impossible for the reader to guess the language matched by given pattern. The program shall be understandably by small incremental efforts on the reader side. Non-trivial inference requires qualitative jumps, either you can infer what the compiler does or not. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de