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,131f06967722ab4b X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada 2005? Date: Fri, 24 Dec 2004 10:41:48 +0100 Organization: cbb software GmbH Message-ID: <1j02qdx8hrd7o.1d5se652uerrr$.dlg@40tude.net> References: <1103344064.372396.51420@c13g2000cwb.googlegroups.com> <1n1v6175zrtcc.2g6ewdvu7ei5$.dlg@40tude.net> <1103568585.285484.237450@c13g2000cwb.googlegroups.com> <20xbhf8rjd33.t7dojmf0ky12.dlg@40tude.net> <1nl7gq6tozeyw.146x7at50m0lr.dlg@40tude.net> <1vj2pp9437gal.1b1lyqe3o973k$.dlg@40tude.net> <1ttqv5msigzua$.12l6jurw2zmd6$.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: individual.net +EerwXHSt/h/qF1Et4klDQ4wFyj0khUuI4UsXrzczJ2wR+Zho= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:7203 Date: 2004-12-24T10:41:48+01:00 List-Id: On 23 Dec 2004 13:09:34 -0500, jayessay wrote: > "Dmitry A. Kazakov" writes: > >> On 22 Dec 2004 13:02:26 -0500, jayessay wrote: >> >>> "Dmitry A. Kazakov" writes: >>> >>>>>> I doubt that CLOS seriously approaches the problem. >>>>> >>>>> That's an odd statement, and it is just uninformed opinion which >>>>> happens to be factually incorrect. >>>> >>>> Maybe >>> >>> There is no "maybe" about it. You clearly have not studied this and >>> therefore any comment you make on it is indeed uninformed opinion. >>> >>>> , but the very first page introduces "no-applicable-method". It is a >>>> non-starter for me. In my view the goal of safe MD design is to make >>>> dispatch failures impossible (checked at compile time). >>> >>> For true MD, that requires solving the halting problem in any Turing >>> complete setting. >> >> What about any proof? > > One Hint: I/O. There are many others. You should define MD in a way which would not involve the Great Theory of All, otherwise anything would become unsolvable... >> [ Hint: Ada is statically typed, freezing rules do >> not allow dynamic declaration of primitive operations. ] > > Irrelevant to the above point. > > However, these rules really have nothing to do with restricting > "dynamic declarations" (Ada is static and so of course there are no > dynamic declarations at all). This is wrong. Not all dynamic declarations are of primitive operations. Ada is a statically *typed* language. > The rules are about where the > representation of the entity is frozen and can no longer be added to > even statically. One consequence of these rules is that they remove a > lot of the potential good from the separation of name space and class > constructs. I do not know what you mean here... >>> Good luck on your hopeless quest. OTOH, if you >>> restrict things enough, what you are talking about is simply >>> overloading. Ada already has that. >> >> There is no way to restrict dynamic dispatch to make overloading of it. >> Care to elaborate? > > "things" /= DD Are we talking about DD or "things"? >>>> BTW, I am deeply unsatisfied with Ada's "MD" raising run-time >>>> exceptions. It is tolerable because there was no better way, and >>>> only as an intermediate state to be replaced by a "right" MD in the >>>> future. >>> >>> First, raising runtime exceptions is not only reasonable, it is the >>> only thing possible in non trivial situations. >> >> Again, the goal of proper design is to have no such situations. > > Then you should not have dynamic dispatch at all. Where that follows from? >> Dispatch tables are finite in presence of finite number of types and >> finite number of actual parameters. It is quite trivial to check >> that all cells in each table are defined. > > That's completely irrelevant to the problem. The issue is whether any > given actual call will find a match in the table. The tables are > trivial, it is the flow analysis that is (in the general case) > impossible. We have different general cases. Ada is not a dynamically typed language. The reason for that was: not to have your "general case". Back to Ada's case, it is trivial to find a match. Moreover it requires bounded time. Otherwise, I guess polymorphic calls would never be adopted in Ada. The problems with implementation of MD in Ada lie elsewhere. >>> Second, Ada has no MD. That is a fact. >> >> MD = "more to have than one dispatching parameter". >> >> So clearly, Ada has MD. > > Ah, so you define it away. MD = "Multiple Dispatch" in the orignal > context of this thread which is /= more than one dispatching > parameter. This should be obvious. Ada does not have MD, to argue > otherwise just makes you look silly. Care to give another definition of MD? >> To have any meta language is a wrong idea anyway. > > MOP is not a meta language, it is a meta _protocol_ for object models. > The only extent example (that I am aware of) is CLOS, but there could > be others. > > OTOH, I'm not sure why a "meta language" is somehow an intrinsically > "wrong idea". Because it is difficult to talk two languages for a person who is not "above average" or else does not suffer from split personality... >>> I've seen situations where this claim is completely at odds with >>> reality. Hence, your position would remove expressivity and force >>> programmers into pounding square pegs into round holes. >> >> Yes, this is exactly Ada's way (tm). Moreover, both pegs and the plate are >> made of hard steel. So the programmer will spend a lot of time pounding on. >> This has an important educational effect. Maybe next time [s]he will think >> first. > > I don't think this is "Ada's way". I sure hope it isn't because it is > the dumbest thing anyone could advocate. The "education" any > intelligent person would get from this would be, "this language is an > extremely poor means for expressing elegant correct solutions." An *intelligent* person would notice difference in shapes. The level of intelligence is inversely proportional to the time spent on pounding... >>> What you call "playing with fire", is simply another tool, with a well >>> defined and specified protocol. Can it be abused? Yes. Does it >>> require someone above average to use it properly? Most likely. Can >>> it be exactly the right thing for an elegant solution to a thorny >>> problem? Yes. >> >> Bottom line: >> *rejected* > > Bottom line: You will not be able to solve a large class of (non > trivial) problems as they will require far too much work to find a > means to express their solution. Which quote "would require someone above average to use it properly". How much above? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de