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: a07f3367d7,dbbbb21ed7f581b X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder.news-service.com!news.astraweb.com!border5.a.newsrouter.astraweb.com!news-out2.kabelfoon.nl!newsfeed.kabelfoon.nl!bandi.nntp.kabelfoon.nl!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: Operation can be dispatching in only one type 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: <025105f2-5571-400e-a66f-ef1c3dc9ef32@g27g2000yqn.googlegroups.com> <94e76749-c49c-45aa-b7dc-386da0d71c66@e4g2000prn.googlegroups.com> Date: Mon, 16 Nov 2009 21:28:00 +0100 Message-ID: <1u0im1tdws15u.1n9v9rz7bu4t4$.dlg@40tude.net> NNTP-Posting-Date: 16 Nov 2009 21:28:00 CET NNTP-Posting-Host: 9c77f6af.newsspool4.arcor-online.net X-Trace: DXC=AGo\4J;BDR7T2Rfi6COgUkn_?_Y?EWfAa7IF8Y2N^AJC7IhIG< X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:8116 Date: 2009-11-16T21:28:00+01:00 List-Id: On Mon, 16 Nov 2009 09:43:06 -0800 (PST), Adam Beneschan wrote: > By the way, for a while I was considering requesting a language change > to allow this sort of restricted multiple dispatch, in cases where a > primitive operation of two types could be declared and inherited for > two derived types that are derived in the same package, and when > dispatching, the program would check to make sure the two actual types > really were declared in the same package. This would avoid having to > deal with M x N combinations of types---something that I think is an > issue with MI---since it only deals with pairs (or triplets, etc.) of > types that are defined to "go together". But you still have these combinations independently on where you derive. You allow the "diagonal" of the full dispatching table. I.e. the combinations: A1, B1, A2, B2, A3, B3 But other combinations are still there, because they can be spelt. It is just so that they raise Constraint_Error. This "diagonal" behavior is what we already have for multi-methods (a form of MD with only one hierarchy A=B). I suppose this is one of the motivations of your proposal. But the problem with "diagonal" dispatch is that it is inconsistent with the idea of static typing. I would insist on the design rule that dispatch shall never fail in a legal program. I.e. the compiler shall enforce all possible combinations of types no later than at compile time. Further, it shall not "invent" broken implementations. In "diagonal" dispatch it would do (and does) exactly this, it would override A1, B2 with an implementation raising Constraint_Error. At the same time the case represented by "diagonal" dispatch is very important in other situations, like parallel hierarchies of types. E.g. when we wanted to force a new instance from B'Class for each new instance from A'Class. But again that enforcement shall be static. BTW, it is not multiple dispatch. Technically this is rather single dispatch where the tuple of types (A, B) is considered as root of some class of tuples, in which (A1, B1), (A2, B2) are instances. Presently we have nothing in the language to handle this (except the jack-of-all-trades, generics). It would be interesting to speculate how tuples can be supported in Ada, especially their flattening in the arguments lists, and using tuples as multiple results of a function. > I could try to write a > proposal if there's enough interest, but I think it's too late to get > into the next language revision. I am incredibly interested in MD (and in tuples as well), but I think we should not touch it until we knew how to do it right. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de