MI is sloppy (was: Construction initialization problem)

MI is sloppy (was: Construction initialization problem)

[Dmitry A. Kazakov]

On Fri, 5 Dec 2008 19:42:40 -0600, Randy Brukardt wrote:

> A waste of effort. I don't believe in multiple inheritance (in any form); it 
> seems to me to be an excuse for sloppy design.

It is like saying that a record with two components is a sloppy design.
Either inheritance is a rubbish concept or else it is multiple.

My pet example of MI is:

   type In_File is ...;
   procedure Get (File : in out Input_File; Item : out Data);

   type Out_File is ...;
   procedure Put (File : in out Output_File; Item : Data);

   type Inout_File is .. ?

Is it sloppy?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: MI is sloppy (was: Construction initialization problem)

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

>    type In_File is ...;
>    procedure Get (File : in out Input_File; Item : out Data);
> 
>    type Out_File is ...;
>    procedure Put (File : in out Output_File; Item : Data);
> 
>    type Inout_File is .. ?

OK, I can use an object of type Inout_File both as In_File or
as Out_File.  OTOH, I'm unsure about the notion of Inout_File.

Inout_File, despite being established in OSs, makes me think of
a new model water tap that at the same time acts as a drain.
I'd rather not approach this thing tired, with a razor in my hand...

Similarly, is it proper design to make a two-way street appear to
have only one polymorphic lane, i.e. think of streets as objects of
a single MI type? I wouldn't want to drive there unless a big, proven
apparatus of typing machinery, calling protocol, etc. makes sure
that my car won't be driving along the wrong view of the street.
I'm not sure but this seems like overhead to me. (Yes, I know there
are cabins and speed trains and normal trains being directed this
way. Without MI AFAIK, so I wonder how rail-bound traffic control
could profit from MI. Will there have to be additional contracts
for MI type that establish a proper order of object use?)

Can't we just make Inout_File some composition and hide the details
completely, behind a suitable collection of primitive operations?
The type would be private, opaque, and nothing else.

Re: MI is sloppy (was: Construction initialization problem)

[Martin Krischik]

Am 06.12.2008, 18:16 Uhr, schrieb Georg Bauhaus  
<see.reply.to@maps.futureapps.de>:

> Inout_File, despite being established in OSs, makes me think of
> a new model water tap that at the same time acts as a drain.
> I'd rather not approach this thing tired, with a razor in my hand...

Datebases? You can read an write to a database.

 From the other examples you habe given I think that you thought to much of  
stream orientated files - which indeed is not very well suited for  
simultanious In/Out use.

However the is no reason why record based files should not use  
simultanious In/Out.

Martin

-- 
Martin Krischik

Re: MI is sloppy (was: Construction initialization problem)

[Maciej Sobczak]

On 6 Gru, 22:16, "Martin Krischik" <krisc...@users.sourceforge.net>
wrote:

>  From the other examples you habe given I think that you thought to much of  
> stream orientated files - which indeed is not very well suited for  
> simultanious In/Out use.

What's wrong with sockets? They are duplex streams.
You might probably implement them as two separate simplex streams, but
then the concept of *closing* gets unnecessarily complicated.
The analogy with two-way street is also wrong - an optical fiber would
be better, because it is not vulnerable to head-on collisions.

As for the MI, I agree with Dmitry - inheritance should be multiple,
otherwise it is just a special case of something that is fundamentally
more general.
Actually, interfaces are a sloppy escape from real MI. :-)

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: MI is sloppy

[Dmitry A. Kazakov]

On Sat, 06 Dec 2008 18:16:37 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
> 
>>    type In_File is ...;
>>    procedure Get (File : in out Input_File; Item : out Data);
>> 
>>    type Out_File is ...;
>>    procedure Put (File : in out Output_File; Item : Data);
>> 
>>    type Inout_File is .. ?
> 
> OK, I can use an object of type Inout_File both as In_File or
> as Out_File.  OTOH, I'm unsure about the notion of Inout_File.

Look at Ada's standard subtypes called "modes." Each Ada type (except
anonymous access) has all of them: "in", "out", "inout", and "constant"
which is merely another name for "in".

> Similarly, is it proper design to make a two-way street appear to
> have only one polymorphic lane, i.e. think of streets as objects of
> a single MI type? I wouldn't want to drive there unless a big, proven
> apparatus of typing machinery, calling protocol, etc. makes sure
> that my car won't be driving along the wrong view of the street.
> I'm not sure but this seems like overhead to me. (Yes, I know there
> are cabins and speed trains and normal trains being directed this
> way. Without MI AFAIK, so I wonder how rail-bound traffic control
> could profit from MI. Will there have to be additional contracts
> for MI type that establish a proper order of object use?)

OK, make the following experiment. 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! 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.
 
> 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. But if you wanted to argue for MI of interfaces (Ada 2005) with an
aggregation behind the scenes, then that obviously would not work. The
diamond diagram is a counterexample:

   type Abstract_File is ...;
   procedure Name (File : Abstract_File) return String;

   type In_File is new Abstract_File ...;
   procedure Get (File : in out Input_File; Item : out Data);
 
   type Out_File is new Abstract_File ...;
   procedure Put (File : in out Output_File; Item : Data);

   type Inout_File is .. ?

No way.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: MI is sloppy

[Georg Bauhaus]

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

Re: MI is sloppy

[Dmitry A. Kazakov]

On Sun, 07 Dec 2008 16:38:46 +0100, Georg Bauhaus wrote:

> 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... ;->

You forgot to turn around!

>> 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.

No it does. As an example consider the languages with large libraries.
Whatever rubbish they might be, they beat Ada by margin, because of reuse
the library code.

> 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.

As any type deviation would. There is no such thing as LSP-subtype. Forget
it. There is no way to preserve all properties of a type while changing
anything there. Be it a constraint, an extension, inheritance or whatever.

> 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?)

Types are not combined and inheritance is not a combination. It is a
contract which can be implemented by a combination, or by something else.
 
> 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?

It is a question about the semantics. As such it is illegal. The language
and its type system don't know the semantics. It is up to you to use the
type algebra in order to implement the semantics you have in mind. MI is
merely an algebraic operation on types. No more, no less. It is wrong even
to imagine asking questions about whether, say, addition is appropriate. It
has no sense without saying what are you going to add to what. MI is in
exactly the same position.

> 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?

Concurrency primitives are non-composable, so your question is illegal with
regard to any algebraic operation on types, not only MI.

Example: array of objects. Do they lock all, individually, by groups when
you access the elements of the array?
 
> 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?

Yes. The compiler has right to do it for certain types.

> Can T's author
> provide for in views and out views, again adding nodes
> to the inheritance graph?

Nice to have.

> 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 looks like an ad-hoc supertype. It is not a replacement to subtypes,
which are more structured, controllable and provide better performance. Yes
ad-hoc supertypes are sometimes useful. See below.
 
> 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)

Yes, I proposed something like this. It is a unified model of type
derivation. When you define a new type related to an old one, you can say
that it imports operations (=inherit) and/or export operations. Relatively
to the given operation it is a subtype when it imports or a supertype when
it exports, or both (an equivalent type).

> 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.

Note that it is no matter how you get the diamond top-down or bottom-up.
The order of derivation is unimportant. Important is the relation sub- or
supertype = import or export.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: MI is sloppy (was: Construction initialization problem)

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:d0goewygto13.10nsyzpabm3vn.dlg@40tude.net...
> On Fri, 5 Dec 2008 19:42:40 -0600, Randy Brukardt wrote:
>
>> A waste of effort. I don't believe in multiple inheritance (in any form); 
>> it
>> seems to me to be an excuse for sloppy design.
>
> It is like saying that a record with two components is a sloppy design.
> Either inheritance is a rubbish concept or else it is multiple.
>
> My pet example of MI is:
>
>   type In_File is ...;
>   procedure Get (File : in out Input_File; Item : out Data);
>
>   type Out_File is ...;
>   procedure Put (File : in out Output_File; Item : Data);
>
>   type Inout_File is .. ?
>
> Is it sloppy?

I tend to think so. These are insufficiently different to be types; there 
should only be one type and different subtypes. Subtypes imply runtime 
checks, but with good contracts most such errors can still be detected by 
tools. And you don't have the goofy restrictions that come with trying to 
make things separate types that aren't logically separate.

This is very much like the attempt to statically check accessibility 
(lifetime) of objects. It doesn't work, at least not in general. And we have 
much better technology in terms of detecting errors without goofy 
restrictions than we did when these rules were defined, so why not use 
them??

                               Randy.

Re: MI is sloppy

[Dmitry A. Kazakov]

On Wed, 10 Dec 2008 18:40:46 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:d0goewygto13.10nsyzpabm3vn.dlg@40tude.net...
>> On Fri, 5 Dec 2008 19:42:40 -0600, Randy Brukardt wrote:
>>
>>> A waste of effort. I don't believe in multiple inheritance (in any form); 
>>> it seems to me to be an excuse for sloppy design.
>>
>> It is like saying that a record with two components is a sloppy design.
>> Either inheritance is a rubbish concept or else it is multiple.
>>
>> My pet example of MI is:
>>
>>   type In_File is ...;
>>   procedure Get (File : in out Input_File; Item : out Data);
>>
>>   type Out_File is ...;
>>   procedure Put (File : in out Output_File; Item : Data);
>>
>>   type Inout_File is .. ?
>>
>> Is it sloppy?
> 
> I tend to think so. These are insufficiently different to be types; there 
> should only be one type and different subtypes. Subtypes imply runtime 
> checks, but with good contracts most such errors can still be detected by 
> tools. And you don't have the goofy restrictions that come with trying to 
> make things separate types that aren't logically separate.

Huh, I don't see any difference. Semantically

   type Inout_File is ...
   procedure Get (File : in out Inout_File; Item : out Data);
   procedure Put (File : in out Inout_File; Item : Data);

   subtype In_File is ...;
   procedure Get (File : in out Input_File; Item : out Data) is abstract;

   subtype Out_File is ...;
   procedure Put (File : in out Output_File; Item : Data) is abstract;

Whatever way you go, incrementally adding operations or else incrementally
removing them.

But the second is certainly worse because it is statically uncheckable, it
is a "God-class," it is potentially inefficient when only input is used,
etc. (It is not the way programs are designed, if we could pick a ready
program from the pool of all possible programs. (:-))

> This is very much like the attempt to statically check accessibility 
> (lifetime) of objects. It doesn't work, at least not in general. And we have 
> much better technology in terms of detecting errors without goofy 
> restrictions than we did when these rules were defined, so why not use 
> them??

I just do not believe that. IF there is a tool capable to read my mind and
understand the program semantics and the reasonably warn me, THEN, please,
build it into the compiler and make those warnings errors. If there is
something (badly wrong) with that, then I don't need neither this tool nor
its features in the compiler.

Tools is cancer of compilers.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: MI is sloppy

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1g29uf1ygl1wc$.1x184o2bk9m0k$.dlg@40tude.net...
> On Wed, 10 Dec 2008 18:40:46 -0600, Randy Brukardt wrote:
...
>> I tend to think so. These are insufficiently different to be types; there
>> should only be one type and different subtypes. Subtypes imply runtime
>> checks, but with good contracts most such errors can still be detected by
>> tools. And you don't have the goofy restrictions that come with trying to
>> make things separate types that aren't logically separate.
>
> Huh, I don't see any difference. Semantically
>
>   type Inout_File is ...
>   procedure Get (File : in out Inout_File; Item : out Data);
>   procedure Put (File : in out Inout_File; Item : Data);
>
>   subtype In_File is ...;
>   procedure Get (File : in out Input_File; Item : out Data) is abstract;
>
>   subtype Out_File is ...;
>   procedure Put (File : in out Output_File; Item : Data) is abstract;
>
> Whatever way you go, incrementally adding operations or else incrementally
> removing them.

No, that's not what I meant. I meant something like:

type File is ...
subtype Inout_File is ...
subtype In_File is ...
subtype Out_File is ...
procedure Get (A_File : in out File; Item : out Data)
with precondition A_File not in In_File;
procedure Put (A_File : in out File; Item : Data)
with precondition A_File not in Out_File;

> But the second is certainly worse because it is statically uncheckable,

Yes, that's the idea in general. I think that static analysis could detect 
95% of the errors, and the rest of course would be detected by exceptions. 
(And with good exception contracts, those too could be made errors if 
desired.)

>.. it is a "God-class,"

Pretty much everything real ends up that way anyhow. Is there really any 
need to extend a good container class? Most of the counter-examples are 
acedemic cases that rarely occur in practice. (Yes, inheritance works great 
for windowing GUIs. And hardly anything else. So maybe it is the GUI that is 
the unusual and oddly designed case??)

> it is potentially inefficient when only input is used,
> etc. (It is not the way programs are designed, if we could pick a ready
> program from the pool of all possible programs. (:-))

Link-time compilation (a basic part of the overall design of Janus/Ada, just 
not practical until very recently) would eliminate most of the 
inefficiencies, just as it has the potential to eliminate most of the 
inefficiencies of generic code sharing and defaulted parameters. But it 
wouldn't put static roadblocks into your way or magic inheritance where you 
need fancy tools just to figure out what operations are available for a 
type. (That's surely the case with Claw.)

As far as not being the way that programs are designed, well, the way that 
they have been designed hasn't worked out that well, so differences 
shouldn't be that harmful.

>> This is very much like the attempt to statically check accessibility
>> (lifetime) of objects. It doesn't work, at least not in general. And we 
>> have
>> much better technology in terms of detecting errors without goofy
>> restrictions than we did when these rules were defined, so why not use
>> them??
>
> I just do not believe that. IF there is a tool capable to read my mind and
> understand the program semantics and the reasonably warn me, THEN, please,
> build it into the compiler and make those warnings errors. If there is
> something (badly wrong) with that, then I don't need neither this tool nor
> its features in the compiler.

No, actually I agree with you here - the tool should be part of the 
compiler. But I don't think it can be part of the *language definition*; it 
doesn't make sense to say that a compiler needs to be smart enough to 
optimizations across units, nor force it to be dumber than that if it *can* 
make such optimizations. That sort of language definition only works if 
there is exactly one compiler.

In any case, I think we need to see such static analysis working in 
compilers before trying to mandate it. And there isn't any such at the 
moment. If anyone has a half-a-million dollars that they'd like to spend on 
Ada, I surely would like to try... :-)

                                               Randy.

Re: MI is sloppy

[Georg Bauhaus]

Randy Brukardt wrote:

> In any case, I think we need to see such static analysis working in 
> compilers before trying to mandate it. And there isn't any such at the 
> moment. If anyone has a half-a-million dollars that they'd like to spend on 
> Ada, I surely would like to try... :-)

A sum much smaller than the excess charges billed
for delayed delivery of modern airliners...  Well.

Re: MI is sloppy

[Dmitry A. Kazakov]

On Thu, 11 Dec 2008 15:44:30 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1g29uf1ygl1wc$.1x184o2bk9m0k$.dlg@40tude.net...
>> On Wed, 10 Dec 2008 18:40:46 -0600, Randy Brukardt wrote:
> ...
>>> I tend to think so. These are insufficiently different to be types; there
>>> should only be one type and different subtypes. Subtypes imply runtime
>>> checks, but with good contracts most such errors can still be detected by
>>> tools. And you don't have the goofy restrictions that come with trying to
>>> make things separate types that aren't logically separate.
>>
>> Huh, I don't see any difference. Semantically
>>
>>   type Inout_File is ...
>>   procedure Get (File : in out Inout_File; Item : out Data);
>>   procedure Put (File : in out Inout_File; Item : Data);
>>
>>   subtype In_File is ...;
>>   procedure Get (File : in out Input_File; Item : out Data) is abstract;
>>
>>   subtype Out_File is ...;
>>   procedure Put (File : in out Output_File; Item : Data) is abstract;
>>
>> Whatever way you go, incrementally adding operations or else incrementally
>> removing them.
> 
> No, that's not what I meant. I meant something like:
> 
> type File is ...
> subtype Inout_File is ...
> subtype In_File is ...
> subtype Out_File is ...
> procedure Get (A_File : in out File; Item : out Data)
> with precondition A_File not in In_File;
> procedure Put (A_File : in out File; Item : Data)
> with precondition A_File not in Out_File;

To me it is exactly same. The precondition not to be in a subtype is
equivalent to disallowing the operations specific to that subtype. Unless
precondition is treated as a constraint check with Constraint_Error
propagated. In the latter case Get is merely an overriding by the body

begin
   raise Constraint_Error;
end;

Not very exciting to me.

>>.. it is a "God-class,"
> 
> Pretty much everything real ends up that way anyhow. Is there really any 
> need to extend a good container class? Most of the counter-examples are 
> acedemic cases that rarely occur in practice. (Yes, inheritance works great 
> for windowing GUIs. And hardly anything else. So maybe it is the GUI that is 
> the unusual and oddly designed case??)

That is because that "else" is not built upon inheritance. Tasks aren't
tagged. End of story.

I honestly believe that inheritance must be given a chance. After all,
there is no any other candidate. Well, there is generics. But you cannot
extend/cut/attune anything with generics anyway.

>> it is potentially inefficient when only input is used,
>> etc. (It is not the way programs are designed, if we could pick a ready
>> program from the pool of all possible programs. (:-))
> 
> Link-time compilation (a basic part of the overall design of Janus/Ada, just 
> not practical until very recently) would eliminate most of the 
> inefficiencies, just as it has the potential to eliminate most of the 
> inefficiencies of generic code sharing and defaulted parameters. But it 
> wouldn't put static roadblocks into your way or magic inheritance where you 
> need fancy tools just to figure out what operations are available for a 
> type. (That's surely the case with Claw.)

I agree that finding the primitive operations of a type is a problem.

> In any case, I think we need to see such static analysis working in 
> compilers before trying to mandate it. And there isn't any such at the 
> moment. If anyone has a half-a-million dollars that they'd like to spend on 
> Ada, I surely would like to try... :-)

But that can be the niche where Ada could survive. Going more and more
dynamic will eventually kill Ada. There is Phyton and other fancy
dynamically typed languages. The niche write-once-debug-forever is densely
inhabited already...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: MI is sloppy

[Dmitry A. Kazakov]

On Fri, 12 Dec 2008 00:17:25 +0100, Georg Bauhaus wrote:

> Randy Brukardt wrote:
> 
>> In any case, I think we need to see such static analysis working in 
>> compilers before trying to mandate it. And there isn't any such at the 
>> moment. If anyone has a half-a-million dollars that they'd like to spend on 
>> Ada, I surely would like to try... :-)
> 
> A sum much smaller than the excess charges billed
> for delayed delivery of modern airliners...  Well.

A language project is certainly for a big university. Industry always does
everything wrong... Unfortunately universities have little interest in Ada.
The governments are ready to spend trillions on lousy banks, whatever...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: MI is sloppy

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:
> On Thu, 11 Dec 2008 15:44:30 -0600, Randy Brukardt wrote:

>>> Whatever way you go, incrementally adding operations or else incrementally
>>> removing them.
>> No, that's not what I meant. I meant something like:
>>
>> type File is ...
>> subtype Inout_File is ...
>> subtype In_File is ...
>> subtype Out_File is ...
>> procedure Get (A_File : in out File; Item : out Data)
>> with precondition A_File not in In_File;
>> procedure Put (A_File : in out File; Item : Data)
>> with precondition A_File not in Out_File;
> 
> To me it is exactly same. The precondition not to be in a subtype is
> equivalent to disallowing the operations specific to that subtype. Unless
> precondition is treated as a constraint check with Constraint_Error
> propagated. In the latter case Get is merely an overriding by the body
> 
> begin
>    raise Constraint_Error;
> end;
> 
> Not very exciting to me.

If you have an ambitious compiler, it might reach out,
at compile time, for objects whose behavior is then known
to be constrained by membership in a then known specific
subtype.

Re: MI is sloppy

[Dmitry A. Kazakov]

On Fri, 12 Dec 2008 11:50:43 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:

>> To me it is exactly same. The precondition not to be in a subtype is
>> equivalent to disallowing the operations specific to that subtype. Unless
>> precondition is treated as a constraint check with Constraint_Error
>> propagated. In the latter case Get is merely an overriding by the body
>> 
>> begin
>>    raise Constraint_Error;
>> end;
>> 
>> Not very exciting to me.
> 
> If you have an ambitious compiler, it might reach out,
> at compile time, for objects whose behavior is then known
> to be constrained by membership in a then known specific
> subtype.

... and then inline raising Constraint_Error. Great!

Constraint_Error propagation is the contracted behavior. You have signed
that contract, enjoy it.

Ambitious is not to be always forced to such contracts...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: MI is sloppy

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:

>> If you have an ambitious compiler, it might reach out,
>> at compile time, for objects whose behavior is then known
>> to be constrained by membership in a then known specific
>> subtype.
> 
> ... and then inline raising Constraint_Error. Great!
> 
> Constraint_Error propagation is the contracted behavior. You have signed
> that contract, enjoy it.

But the compiler informs you that Constraint_Error will
be raised if your program is such that it will be raised.
Anything wrong with correcting the program?

Deriving another type, even if not sufficiently different
from the original to warrant a type, is another formal
way to trigger the same effect on the programmer, at compile
time: "There is something odd about your program".


If we wanted more of the minor differences covered
by type hierarchies, we might end up with a Qi type
system... For Ada?

Re: MI is sloppy

[Dmitry A. Kazakov]

On Fri, 12 Dec 2008 13:15:35 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
> 
>>> If you have an ambitious compiler, it might reach out,
>>> at compile time, for objects whose behavior is then known
>>> to be constrained by membership in a then known specific
>>> subtype.
>> 
>> ... and then inline raising Constraint_Error. Great!
>> 
>> Constraint_Error propagation is the contracted behavior. You have signed
>> that contract, enjoy it.
> 
> But the compiler informs you that Constraint_Error will
> be raised if your program is such that it will be raised.
> Anything wrong with correcting the program?

How? The program is already correct it does what you asked it to do.

> Deriving another type, even if not sufficiently different
> from the original to warrant a type, is another formal
> way to trigger the same effect on the programmer, at compile
> time: "There is something odd about your program".

No, the effect is fundamentally different. The effect is that the program
becomes illegal, it may not run.

> If we wanted more of the minor differences covered
> by type hierarchies, we might end up with a Qi type
> system... For Ada?

1. Qt is not a programming language.

2. There is no minor differences in terms of correctness. An incorrect
program is incorrect.

There is no *any* way to predict the effect of incorrectness. The system is
not only instable, it is simply unknown. It does not obey the logic of
(some) physical systems, where you can A) measure the change, B) measure
the effects. There is no metric, no distance, no way to measure things, it
is just non-continuous etc. "minor differences" is meaningless.

Last but not least, how are you going to make differences visible to the
program reader? By writing comments explaining when and how
Constraint_Error, other exceptions, and program crashes would happen?
What's wrong with using C for that?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: MI is sloppy

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:

>>> Constraint_Error propagation is the contracted behavior. You have signed
>>> that contract, enjoy it.
>> But the compiler informs you that Constraint_Error will
>> be raised if your program is such that it will be raised.
>> Anything wrong with correcting the program?
> 
> How? The program is already correct it does what you asked it to do.

I had understood that the subprogram in question
was *formally* receiving any file, and in addition
was constrained to only accept a file object that
falls into the correct subset of the File type.
This kind of constraint might be interpreted to be a run-time
thing, but could be made a compile-time check where possible.

What's a correct program?
If the program passes an object outside the set,
it is not correct, taking "correct" to mean the program
operates as intended by the programmer - stopping at type
correctness seems comparatively lame (unless you have a
type system such as that of Qi, see below).


>> If we wanted more of the minor differences covered
>> by type hierarchies, we might end up with a Qi type
>> system... For Ada?
> 
> 1. Qt is not a programming language.

Qi, 'Q' & Character'Val(151), is a programming
language that includes the most powerful type system
of all type systems ever to be invented (in terms of
Turing equivalence).

http://www.lambdassociates.org/


> 2. There is no minor differences in terms of correctness. An incorrect
> program is incorrect.
> 
> There is no *any* way to predict the effect of incorrectness. The system is
> not only instable, it is simply unknown. It does not obey the logic of
> (some) physical systems, where you can A) measure the change, B) measure
> the effects. There is no metric, no distance, no way to measure things, it
> is just non-continuous etc. "minor differences" is meaningless.
> 
> Last but not least, how are you going to make differences visible to the
> program reader? By writing comments explaining when and how
> Constraint_Error, other exceptions, and program crashes would happen?

Minor differences can be formally specified by writing
additional constraints that may not be impressive
enough to justify yet another type.  As you know,
it is not possible (according to different sources)
to express any significant amount of differentiation
employing just a type system *unless* the type system
is so powerful that you are expected and willing to
wait an indeterminate amount of time until your compiler's
type checking parts start commenting on your program, if ever.

Re: MI is sloppy

[Dmitry A. Kazakov]

On Fri, 12 Dec 2008 15:29:46 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
> 
>>>> Constraint_Error propagation is the contracted behavior. You have signed
>>>> that contract, enjoy it.
>>> But the compiler informs you that Constraint_Error will
>>> be raised if your program is such that it will be raised.
>>> Anything wrong with correcting the program?
>> 
>> How? The program is already correct it does what you asked it to do.
> 
> I had understood that the subprogram in question
> was *formally* receiving any file, and in addition
> was constrained to only accept a file object that
> falls into the correct subset of the File type.
> This kind of constraint might be interpreted to be a run-time
> thing, but could be made a compile-time check where possible.

Again, how? What are you going to check?

> What's a correct program?
> If the program passes an object outside the set,
> it is not correct, taking "correct" to mean the program
> operates as intended by the programmer

So can you tell from reading the code, what was intended by the programmer
when the object is outside?

> - stopping at type
> correctness seems comparatively lame (unless you have a
> type system such as that of Qi, see below).

It is not lame. The behavior of values = type. So long you deal with
first-order values, types is where you are. When types become themselves
values for type types..., but you are not that far with mere in/out files.

>>> If we wanted more of the minor differences covered
>>> by type hierarchies, we might end up with a Qi type
>>> system... For Ada?
>> 
>> 1. Qt is not a programming language.
> 
> Qi, 'Q' & Character'Val(151), is a programming
> language that includes the most powerful type system
> of all type systems ever to be invented (in terms of
> Turing equivalence).
> 
> http://www.lambdassociates.org/

Ah, Qi, sorry. What about unlambda?

http://www.madore.org/~david/programs/unlambda

(:-))

>> 2. There is no minor differences in terms of correctness. An incorrect
>> program is incorrect.
>> 
>> There is no *any* way to predict the effect of incorrectness. The system is
>> not only instable, it is simply unknown. It does not obey the logic of
>> (some) physical systems, where you can A) measure the change, B) measure
>> the effects. There is no metric, no distance, no way to measure things, it
>> is just non-continuous etc. "minor differences" is meaningless.
>> 
>> Last but not least, how are you going to make differences visible to the
>> program reader? By writing comments explaining when and how
>> Constraint_Error, other exceptions, and program crashes would happen?
> 
> Minor differences can be formally specified by writing
> additional constraints that may not be impressive
> enough to justify yet another type.

According to this to be not 0 is a minor difference, just one value after
all... Does absence of fractional values justify the type Integer? Every
seasoned C programmer knows that the only thing that is really needed is
void *. Everything else is just minor differences...

> As you know,
> it is not possible (according to different sources)
> to express any significant amount of differentiation
> employing just a type system *unless* the type system
> is so powerful that you are expected and willing to
> wait an indeterminate amount of time until your compiler's
> type checking parts start commenting on your program, if ever.

This is absolutely true, but it does not mean that you should avoid
differentiation everywhere. In the case in/out files you can differentiate.
It is decidable. So why shouldn't we?

Constrained types appear not because the change is "minor." They do when we
wanted to have polymorphic objects, because the constraint might be
unknown. But note that polymorphic value is of yet another type. So you can
have both type safety where possible and flexibility elsewhere.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: MI is sloppy

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:43lprrmyik2q.1esp72deqcw6o.dlg@40tude.net...
> On Fri, 12 Dec 2008 13:15:35 +0100, Georg Bauhaus wrote:
>
>> Dmitry A. Kazakov schrieb:
>>
>>>> If you have an ambitious compiler, it might reach out,
>>>> at compile time, for objects whose behavior is then known
>>>> to be constrained by membership in a then known specific
>>>> subtype.
>>>
>>> ... and then inline raising Constraint_Error. Great!

For some reason, I didn't get the other messages to this thread.

But that's not what I'm suggesting. First of all, this is a contract 
failure; it has it's own dedicated exception (maybe Assertion_Error). In 
addition, I think compilers should be allowed to reject any program in which 
that it can be determined statically that the contract exception will 
unconditionally be raised. What a programming language can't do is mandate 
the cases in which that detection will occur. That will depend on the tools 
you use; a really good tool should be able to detect just about everything 
statically. (In addition, you could use an exception contract to force this, 
or the program would also be illegal.)

...
>> Deriving another type, even if not sufficiently different
>> from the original to warrant a type, is another formal
>> way to trigger the same effect on the programmer, at compile
>> time: "There is something odd about your program".
>
> No, the effect is fundamentally different. The effect is that the program
> becomes illegal, it may not run.

That's exactly what is possible with the contracts that I'm suggesting. But 
it cannot be mandated; we have to leave to the tools vendors to describe 
what is possible to detect statically (after giving them the framework).

...
>> If we wanted more of the minor differences covered
>> by type hierarchies, we might end up with a Qi type
>> system... For Ada?
>
> 1. Qt is not a programming language.
>
> 2. There is no minor differences in terms of correctness. An incorrect
> program is incorrect.

You are definitely wrong about this, at least in a finite world. The cost to 
fix some technically incorrect programs (in manpower, performance, 
useability, etc.) is greater than the cost of the error occurring. Such 
programs might be technically incorrect, but they're practically correct. 
This the reason that we tolerate erroneousness in the language definition. 
And it's the reason that we use exception handlers.

> There is no *any* way to predict the effect of incorrectness.

That is surely not true. An Ada bounded error occurs in a program that is 
incorrect, but the effect of that incorrectness is strictly bounded.

                                Randy.

Re: MI is sloppy

[Dmitry A. Kazakov]

On Fri, 12 Dec 2008 18:08:12 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:43lprrmyik2q.1esp72deqcw6o.dlg@40tude.net...
>> On Fri, 12 Dec 2008 13:15:35 +0100, Georg Bauhaus wrote:
>>
>>> Dmitry A. Kazakov schrieb:
>>>
>>>>> If you have an ambitious compiler, it might reach out,
>>>>> at compile time, for objects whose behavior is then known
>>>>> to be constrained by membership in a then known specific
>>>>> subtype.
>>>>
>>>> ... and then inline raising Constraint_Error. Great!
> 
> For some reason, I didn't get the other messages to this thread.
> 
> But that's not what I'm suggesting. First of all, this is a contract 
> failure; it has it's own dedicated exception (maybe Assertion_Error).

Does it change anything?

> In 
> addition, I think compilers should be allowed to reject any program in which 
> that it can be determined statically that the contract exception will 
> unconditionally be raised.

If exceptions where *statically* contracted I would accept assertions (not
preconditions) raising them.

> What a programming language can't do is mandate 
> the cases in which that detection will occur.

Why? That looks simple:

procedure Foo raise Constraint_Error and not Assertion_Error;

declare
   raises not (Constraint_Error or Assertion_Error);
begin
   if False then
      Foo;
   end if;
end;  -- Compile error, the block may propagate
      -- Constraint_Error, because Foo can

The estimation is conservative, it ignores that Foo would eventually never
called.

> That will depend on the tools 
> you use; a really good tool should be able to detect just about everything 
> statically. (In addition, you could use an exception contract to force this, 
> or the program would also be illegal.)

Not an addition (to having nothing), but how things should work, IMO.

>>> Deriving another type, even if not sufficiently different
>>> from the original to warrant a type, is another formal
>>> way to trigger the same effect on the programmer, at compile
>>> time: "There is something odd about your program".
>>
>> No, the effect is fundamentally different. The effect is that the program
>> becomes illegal, it may not run.
> 
> That's exactly what is possible with the contracts that I'm suggesting. But 
> it cannot be mandated; we have to leave to the tools vendors to describe 
> what is possible to detect statically (after giving them the framework).

Leaving legality to vendor tools? Shudder...

>> 2. There is no minor differences in terms of correctness. An incorrect
>> program is incorrect.
> 
> You are definitely wrong about this, at least in a finite world. The cost to 
> fix some technically incorrect programs (in manpower, performance, 
> useability, etc.) is greater than the cost of the error occurring. Such 
> programs might be technically incorrect, but they're practically correct. 
> This the reason that we tolerate erroneousness in the language definition. 
> And it's the reason that we use exception handlers.

It is an empiric estimation which nobody can tell how close to reality it
is. You can declare any program correct if it will never be started. In
order to make such estimations any scientific, you have to enumerate all
program states, attach a cost of failure to each one and the probability
that the program traverses the state. Basically, what certification process
does. Now, because this is technically (and economically) impossible, you
usually estimate the program behaviour, based on the assumption that it was
implemented more or less correctly. Now the vicious circle is closed.

This is a psychotherapy, no more. I don't argue that it does not work. It
does. This is why you mailer cannot see all messages in this group... (:-))

>> There is no *any* way to predict the effect of incorrectness.
> 
> That is surely not true. An Ada bounded error occurs in a program that is 
> incorrect, but the effect of that incorrectness is strictly bounded.

No. Bounded error defines the effect for the program execution. It does not
define the semantics of. If I wrote I := I + 2 instead of I := I + 1, that
would not be an error at all. Yet the program would be incorrect and nobody
could tell anything about the effect without knowing what the program does
and where it is deployed.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de