Re: MI is sloppy

[Georg Bauhaus <see.reply.to@maps.futureapps.de>]

Dmitry A. Kazakov wrote:

>  Go outside and look at the left side of
> the roadway. Cross it to the right side and then turn around 180 degrees.
> Study it. Can you note any difference? There is no one!

Yes, there is a difference, the cars now have transparent glass
above the bumber where they had colorfol arrangements of mostly
red before... ;->

> A big advantage,
> you know. You don't need another car, another driving license etc in order
> to be able to drive back home. In SW we call it reuse. MI is nothing but
> reuse.

Reuse isn't enough justification, I think.  Even leaving out issues
with -> LOOK RIGHT -> written on some roads in some countries.
(IOW, the assumptions that a road being a road here it must
be a same-use road there, too, may be misleading.)


>> Can't we just make Inout_File some composition and hide the details
>> completely, behind a suitable collection of primitive operations?
> 
> A hidden composition does not exist for observers <=> it does not exist at
> all.

Exactly. More on its faint existence below.

> The
> diamond diagram is a counterexample:
> [...]
>    type Inout_File is .. ?
> 
> No way.

Here is one.
I'm not speaking in favor single parenthood  but against an
attempt to inflate the existing type system as is, I guess.
Maybe to the contrary.  Assume

  type Animal =
    ({+Fish, +Bird, +Snail, +Quadruped, +Insect, ...} =: V,
     {Move, Eat, Multiply, ...} =: Op );

(Sorry if this seems improper biological classification.
A type Animal =
     ({+Bones, +Skin, +Veins, +Intestines, ...} =: V,
      {Move, Eat, Multiply, ...} =: Op))
or otherwise more fine grained will be less handy for
my purpose.)
The + designates the bit patterns that represent
the respective animals in the program's state space.


Then I use specialization,

  type Dog is new Animal ...;

as if I had written

  type Dog =
    ({+Quadruped | ...} =: V,
     {Move, Eat, Multiply, ...} =: Op);

(Leaving out the overridings for the moment.)  So Dog's value
set will actually be a proper subset of the value set of
Animal, with a suitable restriction. Employing MI, I could have

   type Dog_Fish =
     ({+Quadruped, +Fish | ...} =: V,
     {Move, Eat, Multiply, ...} =: Op);

The key issue here is not that this is the wrong choice of
parent types. The issue is that it is a wrong choice of parent
types *because* Quadrupeds and Fish can have different habits,
they can have contradictory operations; maybe some bits of
tissue will cause compatibility problems, too.  A Fish will
suffocate where a Dog Moves, a Dog will drown where Fish Eats.
(Not implying that contradiction is a necessity of MI.
A freaky Asian restaurant will offer a dog and fish
for dinner, no problem.)

So, Dog_Fish may not be a proper combination of two types. Is
Inout_File a proper combination of types? (Is it like Cat_Fish?)

As Martin Krischik observes, an In_File could be a stream.  An
Out_File could be a stream, too. They just flow in opposite
directions.  Which problems can we expect to occur with
Inout_File and how are they solved in the type system using MI?
Are the problems relative to the combination, or are they
relative to the observer/user/programmer's intentions?
IOW, is this specific example actually a good example of MI or
is it just an example of something (Inout_File) that we only
think we know to be multiply polymorphic?

The database illustrates what I mean by a solution necessary
for Inout_File to be practical: Behind the scenes, there are
locks.  Actually, there is transaction control. So there is
more than just inheriting the operations of In_File and
Out_File.  Preliminary conclusion: "in" and "out" need more
mechanism than simple (or simplistic?) MI can offer.  Can the
necessary mechanism be built into MI?  With the programmer
controlling the MI hooks, maybe?

Taking MI to the level of Ada's in mode and out mode as mentioned
by Dmitry, what MI mechanism is practical enough so that we could
define

  type T is new A and B and in and out;

Or partially in and partially out?  How does T adapt to the
desired parameter modes of new subprograms?  Can T's author
provide for in views and out views, again adding nodes
to the inheritance graph?


My current favorite among type fantasies is to root out all
inheritance of data and implementations (not Ada, I guess).
Then as expected,

(a) establish a named type T that has the same interface as one
    or more other types: T := (_, Op(T1) or Op(T2) ...)

(b) allow definition of primitive operations of this T:
    Op(T) := Op(T1 x T2 ...)

This  "inheritance", to stress the
difference, is a collection of tags, at best.
(It is not necessarily MD, I think, rather a "multitag" mapped
to the set of primitives of T.)

For Inout_File, then, you have only interface requirements.
An concrete type will *require* an implementation of a
properly crafted set of operations of type Inout_File = (_,
Op(In_File) or Op(Out_File)).  Properly crafted means that
the programmer takes care of issues that do never occur
with In_File or Out_File alone.  The issue emerging in the
product type will likely affect the way that Read or Write
can be performed. Duplexing, say. So these operations would
have to be overridden anyway. You'd effectively be writing
for a new type.

In order to switch from one interface to another, view
conversion might be nice, but defining conversion functions
would be more powerful:

(c) allow defining projection functions from T -> Ti
    (nothing new here)


So for Inout_Files, a duplexed, transactional, intermittend
mode of reading and writing can act as if it were a simple
streaming operation. But it seems unlikely that the added
machinery is always what the client wants: reusing Inout_File
may be prohibitively slow. Therefore, so a conversion function
could lock the Inout_File object, delegate to an Out_File
object (which is quicker) and be back in business.


-- 
Georg Bauhaus
Y A Time Drain  http://www.9toX.de