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: Wed, 22 Dec 2004 20:10:24 +0100 Organization: cbb software GmbH Message-ID: 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 JXgtcxDxdN/JzvszvHRdIAVb2P/AisyFz94gF+MBT3A8MyDuM= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:7181 Date: 2004-12-22T20:10:24+01:00 List-Id: 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? [ Hint: Ada is statically typed, freezing rules do not allow dynamic declaration of primitive operations. ] > 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? >> 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. 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. > Second, Ada has no MD. That is a fact. MD = "more to have than one dispatching parameter". So clearly, Ada has MD. > I make the prediction that it > will never have an MD. Not because it is not possible to get "right" > (a context sensitive notion if there ever was one), but because the > language simply does not have the proper machinery to support it. You > basically require a MOP and that will never be added to Ada for many > reasons, not the least of which is that it would simply be "too hard". I do not see any relation. To have any meta language is a wrong idea anyway. Either generics or parameter pattern matching, anything like that just indicates language infancy. [Many Ada people disagree with me] >>> If you really would like to >>> understand the issues you should read the hyperspec sections noted >>> above as a start. This will give you a programmer's (user's) view of >>> things albeit from a language specification angle. >>> >>> More information as to the what, hows, and wherefores can be found in >>> (1) and further insight and rationale is detailed in the MOP (2). >>> >>> It's worth noting that CLOS method combination is actually >>> programmable. There are several versions supplied as part of the >>> specification (including the 'standard method combination'), but the >>> protocol and semantics of how to define others is also defined and >>> specified. >> >> I don't think it is a good idea. I believe that there must be one right >> way. > > There is no such thing as "one right way" in any non trivial problem > solving context. It has long been known in problem solving (not just > computation) that multiple ways of attacking a problem, and shifting > among those ways, tends to yield the the better solutions. Non-trivial problem is one for which a particular person knows no solution. Once solved it becomes trivial. > I thought Ada folks understood this (Ada being a multiparadigm > language). The position you state looks much more like a Pythonista, > where the above is not just a mantra but the central dogmatism. If > you like the idea of "the one right way" for any > computational/software issue, Python is definitely the place to be. > Not that they're "right", but they believe they are. I cannot speak for Ada folks... >> Though, there might be some variations, in the case of commutative >> methods for example. But they should be "projections" of the main >> schemata. > > 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. > This is > _always_ a bad thing, though it is something that most language models > do impose. > >> I really, wouldn't allow programmers to play with fire. > > 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* > Being a denizen of cla I realize you are probably a B&D software > development proponent, and I suppose in certain contexts (mediocre > programmers, large beauracracies) your sentiment here makes sense. > But in general it is a bad idea which at best tends to produce what I > like to term "superior mediocrity" (which, to be fair, often wins big > in the "marketplace"). You have to understand a very simple thing. You cannot get excellent programmers for each project. They are precious goods. They make errors too. specially if the language requires permanent attention and high concentration to each typed character. So you cannot rely on excellence in mass production. You should do on technology. And technology is the language. Superior mediocrity? Yes, sure. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de