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: a07f3367d7,dbbbb21ed7f581b X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!t11g2000prh.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Operation can be dispatching in only one type Date: Wed, 18 Nov 2009 08:39:14 -0800 (PST) Organization: http://groups.google.com Message-ID: References: <025105f2-5571-400e-a66f-ef1c3dc9ef32@g27g2000yqn.googlegroups.com> <94e76749-c49c-45aa-b7dc-386da0d71c66@e4g2000prn.googlegroups.com> <1u0im1tdws15u.1n9v9rz7bu4t4$.dlg@40tude.net> <39kf90ha60px$.d7746cf5cx6h.dlg@40tude.net> <691d6892-bc5e-4d81-8025-c36556bf2593@13g2000prl.googlegroups.com> <1h9hilcg5i6il.12edpgu4szw1h.dlg@40tude.net> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1258562354 27382 127.0.0.1 (18 Nov 2009 16:39:14 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 18 Nov 2009 16:39:14 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: t11g2000prh.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618),gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:8145 Date: 2009-11-18T08:39:14-08:00 List-Id: On Nov 18, 1:46=A0am, "Dmitry A. Kazakov" wrote: > > It appears to me that we're talking at cross-purposes. > > No, it is the same problem of MD. It has some special cases like > multi-methods, which are simpler, but it is still MD. The example you > provided is full MD. You have three hierarchies: > > =A0 =A0Document'Class, Text_Region'Class, Marker'Class > > An operation can be primitive in any combinations of types from these > hierarchies. > > Here's an example of the sort of problem I'm thinking > > about: Suppose you want to define an abstract type that > > represents a document, which could be a plain ASCII > > text file, a Word document, a PDF file, etc., that all > > have in common that they consist of sequences of > > "characters" and "other elements of some sort".... > > Of course, Move_Text can't be declared because it is a > > primitive operation of more than one tagged type. > > Actually, none of the functions can be declared, > > either, but I want to focus on the Move_Text procedure. > > You might want to call Move_Text with a > > Word_Documents.Document, Word_Documents.Text_Region, > > and Word_Documents.Marker, or similarly with three > > objects all with types from the PDF_Documents or > > Plaintext_Documents package, but you would never want > > to mix objects from two different packages. > > As an example consider these operations: > > procedure Cut > =A0 =A0 =A0 =A0 =A0 ( =A0Doc =A0 =A0 =A0 : in out Document; > =A0 =A0 =A0 =A0 =A0 =A0 =A0From =A0 =A0 =A0: in Text_Region; > =A0 =A0 =A0 =A0 =A0 =A0 =A0Clipboard : in out Document > =A0 =A0 =A0 =A0 =A0 ); > procedure Paste > =A0 =A0 =A0 =A0 =A0 ( =A0Clipboard : in Document; > =A0 =A0 =A0 =A0 =A0 =A0 =A0Doc =A0 =A0 =A0 : in out Document; > =A0 =A0 =A0 =A0 =A0 =A0 =A0To =A0 =A0 =A0 =A0: in Marker > =A0 =A0 =A0 =A0 =A0 ); Right, I wasn't envisioning this sort of operation that involved two *different* documents of (potentially) two different types. When I started thinking about this idea, I had had some issues with programs I was working on, but it was so long ago that I don't remember what the exact problem was and I can't find it. Whatever it was, it was *not* a case where there would have been any operations involving two different objects of two different child types. > So if you derived ASCII_Text from Plain_Text you would lose Move_Text if > you forgot to derive from Text_Region and Marker? Most likely, I would have written the rules so that if you *do* declare an operation like this of two (or more) different tagged types, and if in some other package you don't derive from all those types, it would be an error at that point. Again, although I can see that someone might want to derive ASCII_Text from Plain_Text, it wasn't something I considered at the time since it wasn't germane to the type of problem I was running into. > Consider again ASCII_Text derived from Plain_Text. Let we also derived fr= om > Plain_Text_Region and Plain_Marker: > > =A0 =A0Plain_Text <-- ASCII_Text > =A0 =A0Plain_Text_Region <-- ASCII_Region > =A0 =A0Plain_Marker <-- ASCII_Marker > > Now, my concern is what happens with Move_To called on > > =A0 =A0ASCII_Text, Text_Region, Plain_Marker > > You say, it is Constraint_Error. The question what is the reason for this= ? > I don't see any. It is for the programmer to decide. > > I you say the language forbids that, I say OK, but then that MUST be done > static. I don't see a practical reason why that would be necessary. And I have a major objection, at least to what I think you're proposing. Suppose someone at some organization declares a package with some abstract types. Another organization is developing a large application. Since this is a large application, it's divided into several parts with one part being given to one team, another part to another team, and so on, working independently. The idea is that as long as each team can develop its part of the application that works according to some "contract", then you should be able to put the pieces together and get the whole thing to work. Suppose that two or three of those teams decide to use this library package and derives child types from those abstract types. This shouldn't be an issue for teams working independently, but your idea would make it an issue, because in order for the program to compile, you would require that somebody write useless versions of the inherited operations for every possible combination of derived types, even when the derived types come from two different teams working independently. Sounds like a needless burden to me. > Anyway your proposal would impose some draconian limitations on the > packages structure. E.g. it would be impossible to provide implementation= s > and different types of Marker in separate packages. Or consider a generic > implementing a Marker for the given document type. Would that work? 1) Keep in mind that I wasn't trying to solve the whole world, just one subset of the problem. The way I envisioned it would, I think, have been fairly simple to generate code for and wouldn't be a huge implementation burden, nor would it have imposed a huge burden on programmers. (I could be wrong, since there are some cases I didn't think about, particularly involving tag-indeterminate function calls.) I realize that my proposal wasn't going to solve everything, but my feeling is that if you can solve a subset of a problem simply, and solving the entire problem would be orders of magnitude more complex, then the fact that there will still be unsolved issues isn't a valid reason not to solve the narrower problem. (That would be called "letting the perfect be the enemy of the good enough". And even with the limitations you think are draconian, I think it would have been good enough for the types of problems I was encountering.) Unless we envision that the larger problem *will* be addressed at some point and the solution to the smaller problem might interfere with the larger solution. But at the time, I didn't see any reason to believe that the general "multiple dispatch" case will ever be addressed. Maybe it still won't. 2) I didn't finish thinking everything through before I abandoned the idea, so I didn't consider things like generics. Also, it's possible that there might have been a way to address some of your objections without significantly adding to the implementation burden. > What I find totally inappropriate for a language like Ada is: > > 3. Dynamic constraint with run-time checks dropping arbitrary exceptions. > > I think we should have learnt something from the "accessibility checks > disaster". OK, I don't understand this. First, I don't understand what about accessibility checks was a disaster; and second, I don't see what's wrong with runtime checks in cases where it's too hard for a compiler to figure out at compile time whether something will go wrong. Is this another case of letting the perfect be the enemy of the good enough? -- Adam