Re: Operation can be dispatching in only one type

[Adam Beneschan <adam@irvine.com>]

On Nov 18, 1:46 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
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:
>
>    Document'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
>           (  Doc       : in out Document;
>              From      : in Text_Region;
>              Clipboard : in out Document
>           );
> procedure Paste
>           (  Clipboard : in Document;
>              Doc       : in out Document;
>              To        : in Marker
>           );

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 from
> Plain_Text_Region and Plain_Marker:
>
>    Plain_Text <-- ASCII_Text
>    Plain_Text_Region <-- ASCII_Region
>    Plain_Marker <-- ASCII_Marker
>
> Now, my concern is what happens with Move_To called on
>
>    ASCII_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 implementations
> 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