RE: Suggestion for Ada 200x - Interface inheritance

RE: Suggestion for Ada 200x - Interface inheritance

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Pascal Obry [mailto:p.obry@wanadoo.fr]
...
| 
| > My idea was to introduce "<=" for out parameters and "<=>" 
| for in out.
| > 
| > Example:
| > Create (File   <=> My_File,
| >         Mode    => In_File,
| >         Name    => "My_File",
| >         Status <=  Status);
| > Pretty clear, isn't it? :-) And could also apply to declaration!
| 
| And this was part of the green language. I think it was := 
| :=: =: for "in" "in
| out" and "out" mode.

I didn't know, but i really prefer "arrows".
It's much more clear, almost as a sequence diagram within the code! :-)

-- 
Lionel Draghi 

Re: Suggestion for Ada 200x - Interface inheritance

[Preben Randhol]

Lionel.DRAGHI@fr.thalesgroup.com wrote:
> 
> I didn't know, but i really prefer "arrows".

Please take another look at the language.
In Ada what does <= currently mean? And what does => mean?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Suggestion for Ada 200x - Interface inheritance

[Vinzent Hoefler]

Lionel.DRAGHI@fr.thalesgroup.com wrote:

>I didn't know, but i really prefer "arrows".

So what about '<-', '<->' and '->' then? If I am right, these are
still free. Perhaps a little C'ish, especially the last. ;-)


Vinzent.

RE: Suggestion for Ada 200x - Interface inheritance

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Vinzent Hoefler [mailto:ada.rocks@jlfencey.com]
...
| 
| So what about '<-', '<->' and '->' then? If I am right, these are
| still free. Perhaps a little C'ish, especially the last. ;-)
| 
Wonderful, let's go for it! :-)

RE: Suggestion for Ada 200x - Interface inheritance

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Bill Findlay [mailto:yaldnifw@blueyonder.co.uk]
...
| > 
| > Example:
| > Create (File <=> My_File,
| >       Mode    => In_File,
| >       Name    => "My_File",
| >       Status <=  Status);
| > Pretty clear, isn't it? :-) And could also apply to declaration!
| 
| I hope Status is not of Boolean type! 8-)

No, it isn't. I had called it Is_Created.

Re: Suggestion for Ada 200x - Interface inheritance

[Vinzent Hoefler]

Lionel.DRAGHI@fr.thalesgroup.com wrote:

>| -----Message d'origine-----
>| De: Bill Findlay [mailto:yaldnifw@blueyonder.co.uk]
>...
>| > 
>| > Example:
>| > Create (File <=> My_File,
>| >       Mode    => In_File,
>| >       Name    => "My_File",
>| >       Status <=  Status);
>| > Pretty clear, isn't it? :-) And could also apply to declaration!
>| 
>| I hope Status is not of Boolean type! 8-)
>
>No, it isn't. I had called it Is_Created.

Well, "<=" is a comparison that would create a result of type Boolean.
Fortunately you just can't compare Booleans that way. ;-)


Vinzent.

Re: Suggestion for Ada 200x - Interface inheritance

[Bill Findlay]

On 3/6/03 18:46, in article bbin04$9onrq$1@ID-175126.news.dfncis.de,
"Vinzent Hoefler" <ada.rocks@jlfencey.com> wrote:

> Lionel.DRAGHI@fr.thalesgroup.com wrote:
> 
>> | -----Message d'origine-----
>> | De: Bill Findlay [mailto:yaldnifw@blueyonder.co.uk]
>> ...
>> | > 
>> | > Example:
>> | > Create (File <=> My_File,
>> | >       Mode    => In_File,
>> | >       Name    => "My_File",
>> | >       Status <=  Status);
>> | > Pretty clear, isn't it? :-) And could also apply to declaration!
>> | 
>> | I hope Status is not of Boolean type! 8-)
>> 
>> No, it isn't. I had called it Is_Created.
> 
> Well, "<=" is a comparison that would create a result of type Boolean.
> Fortunately you just can't compare Booleans that way. ;-)

Sorry? Am I missing a joke?

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: Suggestion for Ada 200x - Interface inheritance

[Vinzent Hoefler]

Bill Findlay wrote:

>On 3/6/03 18:46, in article bbin04$9onrq$1@ID-175126.news.dfncis.de,
>"Vinzent Hoefler" <ada.rocks@jlfencey.com> wrote:
>
>> Lionel.DRAGHI@fr.thalesgroup.com wrote:
>> 
>>> | -----Message d'origine-----
>>> | De: Bill Findlay [mailto:yaldnifw@blueyonder.co.uk]
>>> ...
>>> | > 
>>> | > Example:
>>> | > Create (File <=> My_File,
>>> | >       Mode    => In_File,
>>> | >       Name    => "My_File",
>>> | >       Status <=  Status);
>>> | > Pretty clear, isn't it? :-) And could also apply to declaration!
>>> | 
>>> | I hope Status is not of Boolean type! 8-)
>>> 
>>> No, it isn't. I had called it Is_Created.
>> 
>> Well, "<=" is a comparison that would create a result of type Boolean.
>> Fortunately you just can't compare Booleans that way. ;-)
>
>Sorry? Am I missing a joke?

Maybe?

What would you expect from a call like this:

|procedure Create_Conditional (Do_It : Boolean);
| ...
|Create_Conditional (3 <= 5);

If I didn't miss anything, this should be legal Ada.


Vinzent.

Re: Suggestion for Ada 200x - Interface inheritance

[Vinzent Hoefler]

Bill Findlay wrote:

>On 3/6/03 18:46, in article bbin04$9onrq$1@ID-175126.news.dfncis.de,
>"Vinzent Hoefler" <ada.rocks@jlfencey.com> wrote:
>
>> Well, "<=" is a comparison that would create a result of type Boolean.
>> Fortunately you just can't compare Booleans that way. ;-)
>
>Sorry? Am I missing a joke?

Uhoh. Got it, yes. I should go home now (get some sleep and hope, my
cancel was fast enough...), it's too late already.

Of course you can do that because Boolean is basically an enumeration
type which is ordered.


Vinzent.

RE: Suggestion for Ada 200x - Interface inheritance

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Steve [mailto:nospam_steved94@attbi.com]
...
| What do you think of the idea of also optionally giving the 
| mode of the
| parameter, which if present must match the function or procedure
| declaration.  That is, extending the above example:
| 
|   result := Add( in left => 2, in right => 3 );
| 
| Why?  Readability.  When reading code it is sometimes unclear from the
| caller whether or not a procedure modifies its parameters. 
 
Yes, and i often need to "navigate" up to the operation declaration to see
parameter's mode.

My idea was to introduce "<=" for out parameters and "<=>" for in out.

Example:
Create (File   <=> My_File,
        Mode    => In_File,
        Name    => "My_File",
        Status <=  Status);
Pretty clear, isn't it? :-) And could also apply to declaration!

Anyway, some ada-mode colouring parameters according to their mode would do
the job just fine for me.

-- 
Lionel Draghi

Re: Suggestion for Ada 200x - Interface inheritance

[Pascal Obry]

Lionel.DRAGHI@fr.thalesgroup.com writes:

> My idea was to introduce "<=" for out parameters and "<=>" for in out.
> 
> Example:
> Create (File   <=> My_File,
>         Mode    => In_File,
>         Name    => "My_File",
>         Status <=  Status);
> Pretty clear, isn't it? :-) And could also apply to declaration!

And this was part of the green language. I think it was := :=: =: for "in" "in
out" and "out" mode.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Suggestion for Ada 200x - Interface inheritance

[Bill Findlay]

On 2/6/03 16:57, in article
mailman.12.1054569301.12990.comp.lang.ada@ada.eu.org,
"Lionel.DRAGHI@fr.thalesgroup.com" <Lionel.DRAGHI@fr.thalesgroup.com> wrote:

> 
> My idea was to introduce "<=" for out parameters and "<=>" for in out.
> 
> Example:
> Create (File <=> My_File,
>       Mode    => In_File,
>       Name    => "My_File",
>       Status <=  Status);
> Pretty clear, isn't it? :-) And could also apply to declaration!

I hope Status is not of Boolean type! 8-)

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Suggestion for Ada 200x - Interface inheritance

[Steve]

Java and C# use the concept of interface inheritance.  What do you think of
adding this feature to Ada?

A tagged type containing only abstract methods (functions and procedures)
would be considered to be an interface.  Any tagged type may be dervied from
at most one tagged type containing data elements and any number of
interfaces.

That is, you may define an interface:

  type interface_example is abstract tagged null record;

  function in_order( obj : interface_example ) return boolean;

  procedure swap( obj1, obj2 : in out interface_example );

  type data_value is tagged
    record
      field1 : Natural;
      field2 : Natural;
    end record;

  type sorted_data is new data_value, interface_example with
    record
      is_valid : Boolean;
    end record;

The objective is to add interfaces to existing objects such that they may be
used by common routines, in the same way as Java.  In fact this might make
it easier to interface with Java.

Steve
(The Duck)

Re: Suggestion for Ada 200x - Interface inheritance

[Robert A Duff]

"Steve" <nospam_steved94@attbi.com> writes:

> Java and C# use the concept of interface inheritance.  What do you think of
> adding this feature to Ada?

I think it's a good idea.  There is an AI on this, and I think the ARG
is considering it one of the most urgent ones.  Look up the AI, and see
what you think.

- Bob

Re: Suggestion for Ada 200x - Interface inheritance

[Brian Gaffney]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wcc3cj5i2cd.fsf@shell01.TheWorld.com>...
> "Steve" <nospam_steved94@attbi.com> writes:
> 
> > Java and C# use the concept of interface inheritance.  What do you think of
> > adding this feature to Ada?
> 
> I think it's a good idea.  There is an AI on this, and I think the ARG
> is considering it one of the most urgent ones.  Look up the AI, and see
> what you think.
> 
> - Bob

(http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00251.TXT?rev=1.12)

I looked briefly at this AI (though I haven't read it in detail -- so
I might have missed something), and there's one thing about it that I
don't understand:  If Ada'0Y is to add the concept of Interfaces, why
would it be added as an Interface _type_?  I can understand Java and
C# using a Class-based approach, but since Ada splits up the concepts
of a 'Class' wouldn't it be more the Ada-Way to use a concept related
to packages?  For example an "abstract package" which must have a body
provided at the 'instantiation' site.

I don't think this example would work, but something like:

   generic
      type Data is private;
   abstract package This_Interface is ...
or
   abstract package This_Interface (type Data is private) is ...

along with

   ...
      type Mine is ...
      package My_Interface is new This_Interface(Mine);
      package body My_Interface is ...
   ...

I don't like this since My_Interface would be a different scope than
that containing Data, but perhaps a way could be devised to annotate
the type definition:

   type Mine is ... with This_Interface(Mine) ...
or 
   type Mine is ...
   for Data'interface use This_Interface(Mine), That_Interface(Mine),
...;"

The bodies for subroutines, etc. defined in the Interfaces would then
be required to follow (within the freezing rules?).

This would give the advantage of allowing it for all types, not just
tagged types.

                     --Brian

Re: Suggestion for Ada 200x - Interface inheritance

[Craig Carey]

On 23 May 2003 21:02:26 -0400, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:

>"Steve" <nospam_steved94@attbi.com> writes:
>
>> Java and C# use the concept of interface inheritance.  What do you think of
>> adding this feature to Ada?
>
>I think it's a good idea.  There is an AI on this, and I think the ARG
>is considering it one of the most urgent ones.  Look up the AI, and see
>what you think.
>

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00251.TXT

The AI contains this comment:

: ****************************************************************
:
: From: Randy Brukardt
: Sent: Monday, December 04, 2000 10:31 PM
...
: I note that the proposal never seems to state that abstract interface
: types must not define any components. Certainly, the implementation
: model and the entire discussion seem to assume that is the case. (An
: "normal" abstract type can have components defined, they'll be part of
: any extension; but I don't think we want that here.)
:
: ****************************************************************


There seems to be inherent safety in avoiding O.O. and using subrecords.

So... Mulitple Inheritance is doing something like making the parent
record be subrecords of the new derived type.

If the aim is flatten out subrecords so that fields names can conflict
and fields can be accidentally not correctly set to a value, then 
the flattening could be made explicit with a way to rename Ada types.

Here is an example showing variable X holding 4 integers. Due to the
renaming of types, the 1st Integer is identified with the name
   X.A
instead of:
   X.R1.A

A sample extension of Ada:
------------------------------------------------------------------------
type T1 is
   tagged record
      A, B : Integer;
   end record;

type T2 is
   tagged record
      B, C : Integer;
   end record;

type Mixin is
   tagged record
      R1 : <> renames T1;     --  Flatten T1's fields into Mixin record
      R2 : T2;
   end record;

type Mixin renames Mixin.T2;  --  Flatten T2's fields into Mixin record

X  : Mixin := Mixin'(A => 1, R1.B => 2, R2.B => 3, C => 4);

------------------------------------------------------------------------

I regard the idea of X'Class as a way to make it easy to unintentionally
leave fields not-assigned-to. It would be harder to make that mistake
when there are subrecords. The "MI" gain of shifting fields of a
subrecord into the surrounding containing record must be quite slight
if renaming has made it look like that has occurred when it actually
hadn't.


Craig Carey
   http://www.ijs.co.nz/ada_95.htm

Re: Suggestion for Ada 200x - Interface inheritance

[Wojtek Narczynski]

"Steve" <nospam_steved94@attbi.com> wrote in message news:<0Pxza.699607$OV.652508@rwcrnsc54>...
> Java and C# use the concept of interface inheritance.  What do you think of
> adding this feature to Ada?
> 
> A tagged type containing only abstract methods (functions and procedures)
> would be considered to be an interface.  Any tagged type may be dervied from
> at most one tagged type containing data elements and any number of
> interfaces.
> 
> That is, you may define an interface:
> 
>   type interface_example is abstract tagged null record;
> 
>   function in_order( obj : interface_example ) return boolean;
> 
>   procedure swap( obj1, obj2 : in out interface_example );
> 
>   type data_value is tagged
>     record
>       field1 : Natural;
>       field2 : Natural;
>     end record;
> 
>   type sorted_data is new data_value, interface_example with
>     record
>       is_valid : Boolean;
>     end record;
> 
> The objective is to add interfaces to existing objects such that they may be
> used by common routines, in the same way as Java.  In fact this might make
> it easier to interface with Java.
> 
> Steve
> (The Duck)

I find your syntax cleaner than the AI proposal:

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00251.TXT?rev=1.12

This AI has a funny title: "Abstract Interfaces to provide Multiple
Inheritance". Two misconceptions: 1. Interfaces cannot be concrete, 2.
Interfaces do not provide multiple inheritance. They are just a
different solution to to the problem.

The AI proposes a new keyword 'interface' which, seems to have no
purpose in existence of 'abstract tagged null record'. The new keyword
approach also makes it impossible to reuse existing code that declares
abstract tagged null records in place of interfaces. Or maybe could
the new keyword 'interface' be used interchangably with the (lenthy)
'abstract tagged null record' clause?

There is also this weirdness of 'abstract interface' at the begining,
but I think the word 'abstract' has been dropped in later stages.

The 'type T3 is new T1 and T2 and T3 with null record;' looks is weird
as well. A simple comma like in your example is more readable.

But I'll welcome whatever comes out, because the inability to create
heterogenous collections just plain sucks.

By the way, is there an AI for the second thing Ada could learn from
Java, that is 'throws' clause?

Regards,
Wojtek

Re: Suggestion for Ada 200x - Interface inheritance

[Georg Bauhaus]

Wojtek Narczynski <wojtek@power.com.pl> wrote:
: 
: This AI has a funny title: "Abstract Interfaces to provide Multiple
: Inheritance". Two misconceptions: 1. Interfaces cannot be concrete,

Well, Java interfaces cannot in a sense be concrete, but there
is more to the term "interface", which is a venerable, general purpose
term dating from before the days of Java speak.  Ada is a general purpose
programming language...

Georg

Re: Suggestion for Ada 200x - Interface inheritance

[Wojtek Narczynski]

Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> wrote in message news:<baobi7$pro$1@a1-hrz.uni-duisburg.de>...
> Wojtek Narczynski <wojtek@power.com.pl> wrote:
> : 
> : This AI has a funny title: "Abstract Interfaces to provide Multiple
> : Inheritance". Two misconceptions: 1. Interfaces cannot be concrete,
> 
> Well, Java interfaces cannot in a sense be concrete, but there
> is more to the term "interface", which is a venerable, general purpose
> term dating from before the days of Java speak.  Ada is a general purpose
> programming language...

I get your point, but still I pefer talking about "interfaces" instead
of "abstract interfaces", unless one defines what a "concrete
interface" is, on the Ada ground.

Objective-C has 'protocols' by the way, they are said to be ancestors
of java interfaces.

Regards,
Wojtek

Re: Suggestion for Ada 200x - Interface inheritance

[Robert A Duff]

wojtek@power.com.pl (Wojtek Narczynski) writes:

> This AI has a funny title: "Abstract Interfaces to provide Multiple
> Inheritance". Two misconceptions: 1. Interfaces cannot be concrete, 2.
> Interfaces do not provide multiple inheritance. They are just a
> different solution to to the problem.

More than one interface can be inherited.  That sounds like "multiple
inheritance" to me.  Java interface inheritance is just like C++ muliple
inheritance, with the restriction that you can't inherit record
components and procedure bodies.

> But I'll welcome whatever comes out, because the inability to create
> heterogenous collections just plain sucks.

What do you mean by that?  You can pass class-wide types to generic
collection packages, and that's heterogeneous.  I guess you mean you
can't do what interface'Class allows...

> By the way, is there an AI for the second thing Ada could learn from
> Java, that is 'throws' clause?

I think there's one about pre- and post-conditions, which is somewhat
related.

By the way, the ARG is not listening to your comments posted *here*.

- Bob

Re: Suggestion for Ada 200x - Interface inheritance

[Wojtek Narczynski]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccznlcm226.fsf@shell01.TheWorld.com>...

> More than one interface can be inherited.  That sounds like "multiple
> inheritance" to me.  Java interface inheritance is just like C++ muliple
> inheritance, with the restriction that you can't inherit record
> components and procedure bodies.

Usually you implement the interface. This likely comes from the
Objective-C ground, where you have 'protocols' (different name, same
role, said to be inspiration for Java interfaces). It's pretty natural
that you implement a protocol, not inherit a protocol. In the same
sense an interface/protocol can implement another interface/protocol.

The question boils down to wether an interface is an ancestor of the
type which implements (/inherits?) it. I think it is not, and thus
prefer to talk about implementing the interface not inheriting it. For
examle the USB interface is not an ancestor of my PC.

> > But I'll welcome whatever comes out, because the inability to create
> > heterogenous collections just plain sucks.
> 
> What do you mean by that?  You can pass class-wide types to generic
> collection packages, and that's heterogeneous.  I guess you mean you
> can't do what interface'Class allows...

I meant the situation where I needed to store objects from two
libraries I could not put a common ancestor above. But I admit it is
not the usual case.

> > By the way, is there an AI for the second thing Ada could learn from
> > Java, that is 'throws' clause?
> 
> I think there's one about pre- and post-conditions, which is somewhat
> related.

Yeah. Pre- and post-conditions are easier, I guess, because they can't
break current code, while the introduction of 'throws' ('raises'?),
without some trick, would.

Regards,
Wojtek

Re: Suggestion for Ada 200x - Interface inheritance

[Jeffrey Carter]

Wojtek Narczynski wrote:
> 
> Yeah. Pre- and post-conditions are easier, I guess, because they can't
> break current code, while the introduction of 'throws' ('raises'?),
> without some trick, would.

I would think we'd overload "raise" if this were introduced. Something like

procedure Approach_Woman (Num_Beers_Drunk : in Natural)
raise Your_Fly_Is_Open;

perhaps? :)

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail

Re: Suggestion for Ada 200x - Interface inheritance

[Wesley Groleau]

>> Yeah. Pre- and post-conditions are easier, I guess, because they can't
>> break current code, while the introduction of 'throws' ('raises'?),
>> without some trick, would.

Indeed.  I was asked to fix an out of bounds exception
in Java once.  Chased an empty string down through several
layers of the call stack till I found that the class
that was supposed to get the string out of a database caught
file not found by creating an empty database, and handled
no such key in the database by returning an empty string.
For reasons which would take up unnecessary bandwidth,
the right thing to do was throw an exception instead of
pretending everything is OK for a later crash.  But that
meant adding a throws clause to each of hundreds of
files.

Re: Suggestion for Ada 200x - Interface inheritance

[Hyman Rosen]

Wesley Groleau wrote:
 > But that meant adding a throws clause to each of hundreds of files.

'Throws' clauses are a really bad idea, the more so because it seems
so right on first appraisal. C++ got lucky that because of legacy
code requirements, no clause at all means that any exception may be
thrown, and so once the idea was known to be bad, no one had to use
it.

Re: Suggestion for Ada 200x - Interface inheritance

[Wojtek Narczynski]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<719Aa.14547$fT5.3595@nwrdny01.gnilink.net>...
> Wesley Groleau wrote:
>  > But that meant adding a throws clause to each of hundreds of files.
> 
> 'Throws' clauses are a really bad idea, the more so because it seems
> so right on first appraisal.

Why? Because it is a lot of typing?

Regards,
Wojtek

Re: Suggestion for Ada 200x - Interface inheritance

[Hyman Rosen]

Wojtek Narczynski wrote:
> Why? Because it is a lot of typing?

Because, as Wes demonstrated with a real life example,
'throws' clauses force the entanglement of classes that
couldn't care less about the exceptions which are passing
through them. Not the least of problems this causes is the
implied coupling of classes that are in fact completely
disjoint.

Re: Suggestion for Ada 200x - Interface inheritance

[Wojtek Narczynski]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<PIqAa.18136$fT5.13411@nwrdny01.gnilink.net>...
> Wojtek Narczynski wrote:
> > Why? Because it is a lot of typing?
> 
> Because, as Wes demonstrated with a real life example,
> 'throws' clauses force the entanglement of classes that
> couldn't care less about the exceptions which are passing
> through them. Not the least of problems this causes is the
> implied coupling of classes that are in fact completely
> disjoint.

But the situation where you cannot rely on the compiler to check
wether you did not forget to put an exception handler in isn't good
either.

Maybe there is some middle ground, like declaring on package level
which exceptions should be allowed to go through, and package level
exception handlers?

Regards,
Wojtek

Re: Suggestion for Ada 200x - Interface inheritance

[Wesley Groleau]

> But the situation where you cannot rely on the compiler to check
> wether you did not forget to put an exception handler in isn't good
> either.

Well, there are tools for analyzing for that.
One of them is called "peer review"  But some
are less creative and MUCH faster.

Too much dependence on "when others =>"
contributes to a problem, though.

Re: Suggestion for Ada 200x - Interface inheritance

[Hyman Rosen]

Wojtek Narczynski wrote:
> But the situation where you cannot rely on the compiler to check
> wether you did not forget to put an exception handler in isn't good
> either.

Yes it is.

Re: Suggestion for Ada 200x - Interface inheritance

[Wojtek Narczynski]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1054062833.558791@master.nyc.kbcfp.com>...
> Wojtek Narczynski wrote:
> > But the situation where you cannot rely on the compiler to check
> > wether you did not forget to put an exception handler in isn't good
> > either.
> 
> Yes it is.

So it's good to have the compiler check types and ranges, but it's not
good to check exception propagation patterns. All clear, thank you.

Re: Suggestion for Ada 200x - Interface inheritance

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 981 bytes --]


"Wojtek Narczynski" <wojtek@power.com.pl> a �crit dans le message de news:5ad0dd8a.0305280507.57bd5a16@posting.google.com...
> Hyman Rosen <hyrosen@mail.com> wrote in message news:<1054062833.558791@master.nyc.kbcfp.com>...
> > Wojtek Narczynski wrote:
> > > But the situation where you cannot rely on the compiler to check
> > > wether you did not forget to put an exception handler in isn't good
> > > either.
> >
> > Yes it is.
>
> So it's good to have the compiler check types and ranges, but it's not
> good to check exception propagation patterns. All clear, thank you.
Exceptions are for unexpected events. As the saying goes:

"Once you've taken care of the unexpected, consider the unexpected unexpected".

The nice things with exceptions as they are is that they allow you to deal with
the unexpected unexpected.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Suggestion for Ada 200x - Interface inheritance

[Hyman Rosen]

Wojtek Narczynski wrote:
> So it's good to have the compiler check types and ranges, but it's not
> good to check exception propagation patterns. All clear, thank you.

You're welcome. The difference, of course, is that it's an error to
mix types incorrectly, or to wander out of range, but it's not an
error to ignore an exception. That's exactly what exceptions are for,
to be ignored by code that wants to ignore them, until they reach an
interested handler. Explicit expressions of disinterest are wrong,
because the universe of things in which to be disintersted in is ever
expanding.

Re: Suggestion for Ada 200x - Interface inheritance

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> Wesley Groleau wrote:
>  > But that meant adding a throws clause to each of hundreds of files.
> 
> 'Throws' clauses are a really bad idea, the more so because it seems
> so right on first appraisal.

Throws clauses are a bad idea in Java, because they require scattering a
whole lot of useless exception handlers all over the place.  Or else a
whole lot of useless throws clauses.  But I don't think they're a
fundamentally bad idea; I think it would be possible to design a
language without those problems.

One thing Java got right is that there are two kinds of exceptions:
For one kind, you want to declare "this procedure can raise X",
and force callers to either handle it or declare that they throw it.
For the other kind, you don't want to declare anything.

One thing Java got wrong is the some of the exceptions are in the wrong
category.  For example, all the streams operations can throw I/O
exceptions, even though streams are not necessarily tied to I/O.
If an open-file operation is designed to raise a file-not-found
exception, then I think it's reasonable to require the caller to handle
it (or reraise it).  But a read-from-stream operation should not require
any extra mumbo-jumbo at the call site; it might not even be reading
from a file.

I also think you should let the programmer decide which exceptions are
in which category.  For example, an out-of-memory exception
(Storage_Error, in Ada) should, by default, not require any
declarations, since pretty-much anything can raise it.
But in an embedded system, you might want the compiler to prove that
out-of-memory can't happen.  I envision a compiler that calculates (at
link time) a worst-case stack size for every procedure (including called
procedures).  The programmer could say, "on entry to this procedure,
make sure there's enough stack space".  If the procedure is recursive,
or declares something like:

    X: String(1..N);

where N is not known, the "worst case" would be "the size of the whole
address space".  But if you don't do those things, the "worst case"
could be reasonable, and the compiler could prove at compile time (link
time, really) that certain regions of code (perhaps the whole program)
do not run out of stack space.

Consider also something like a generic iterator:

    generic
        with procedure Action(X: Element);
    procedure Set_Iterate(S: Set);
    -- Calls Action once for each element of the Set.

Presumably Set_Iterate can raise whatever exceptions are raised by the
actual procedure passed to Action.  But you don't want to say
Set_Iterate raises "any exception".  You want to say, "Set_Iterate
raises whatever exceptions are raised by Action".  That's not known at
compile time of the generic, but it could be known at compile time of
the instantiations.

So for "throws clauses" to work well, we need some sort of pass-through
concept -- "this throws what that throws".  This would allow abstraction
layers that simply pass exceptions through to avoid saying "throws
anything" and the subsequent clutter in clients.

Another point is that most exceptions are really preconditions.  See
Eiffel, and design-by-contract.  You want to declare not only that this
procedure raises Queue_Empty_Error, but also under what conditions that
exception is raised (e.g. if Is_Empty is True), and that
Queue_Empty_Error gets raised before modifying the queue.

And if you have pre- and postconditions, I think you want to attach
postconditions to exceptional situations.  You want a way to express,
"If this procedure returns normally, then such-and-such is true.  If it
raises File_Not_Found, then so-and-so is true.  And if it raises
Storage_Error, all bets are off (i.e., any data touched by this
procedure might have been damaged, so don't touch it)."

And finally, you want user-settable defaults.  Like, "All procedures in
this package, and all of its descendants, behave such-and-such a way in
the presence of so-and-so exception."

- Bob

Re: Suggestion for Ada 200x - Interface inheritance

[Hyman Rosen]

Robert A Duff wrote:
 > I think it would be possible to design a
> language without those problems.

Maybe. I'll believe it when I see it, though. I think that
there is a fundamental incoherency here - exceptions are
designed to be a "long-distance" method of error handling;
you throw where the error is noticed, and the closest
interested handler gets invoked. This style means that the
code in between explicitly does not want to know about the
exception, because if it did, then it would have a handler.
So forcing the code to declaim all the things in which it
is not interested is counterproductive and useless. And as
you point out, the problem is even more basic when it comes
to generics.

Which reminds me that I'll bet this will be another phonied
up aspect of generics in Java. Odds are you won't be able to
specify the generic parameter in a throws clause.

Re: Suggestion for Ada 200x - Interface inheritance

[Dmitry A. Kazakov]

Robert A Duff wrote:

> Hyman Rosen <hyrosen@mail.com> writes:
> 
>> Wesley Groleau wrote:
>>  > But that meant adding a throws clause to each of hundreds of files.
>> 
>> 'Throws' clauses are a really bad idea, the more so because it seems
>> so right on first appraisal.
> 
> Throws clauses are a bad idea in Java, because they require scattering a
> whole lot of useless exception handlers all over the place.  Or else a
> whole lot of useless throws clauses.  But I don't think they're a
> fundamentally bad idea; I think it would be possible to design a
> language without those problems.
> 
> One thing Java got right is that there are two kinds of exceptions:
> For one kind, you want to declare "this procedure can raise X",
> and force callers to either handle it or declare that they throw it.
> For the other kind, you don't want to declare anything.

I do not think it is a good idea. The set of exceptions is countable for any 
given program, I hope. (:-)) I would like to declare: f potentially raises 
what A, B, C may raise and also the exceptions W and V, but not the 
exceptions X, Y, Z.

> One thing Java got wrong is the some of the exceptions are in the wrong
> category.  For example, all the streams operations can throw I/O
> exceptions, even though streams are not necessarily tied to I/O.
> If an open-file operation is designed to raise a file-not-found
> exception, then I think it's reasonable to require the caller to handle
> it (or reraise it).  But a read-from-stream operation should not require
> any extra mumbo-jumbo at the call site; it might not even be reading
> from a file.
> 
> I also think you should let the programmer decide which exceptions are
> in which category.  For example, an out-of-memory exception
> (Storage_Error, in Ada) should, by default, not require any
> declarations, since pretty-much anything can raise it.
> But in an embedded system, you might want the compiler to prove that
> out-of-memory can't happen.  I envision a compiler that calculates (at
> link time) a worst-case stack size for every procedure (including called
> procedures).  The programmer could say, "on entry to this procedure,
> make sure there's enough stack space".  If the procedure is recursive,
> or declares something like:
> 
>     X: String(1..N);
> 
> where N is not known, the "worst case" would be "the size of the whole
> address space".  But if you don't do those things, the "worst case"
> could be reasonable, and the compiler could prove at compile time (link
> time, really) that certain regions of code (perhaps the whole program)
> do not run out of stack space.
> 
> Consider also something like a generic iterator:
> 
>     generic
>         with procedure Action(X: Element);
>     procedure Set_Iterate(S: Set);
>     -- Calls Action once for each element of the Set.
> 
> Presumably Set_Iterate can raise whatever exceptions are raised by the
> actual procedure passed to Action.  But you don't want to say
> Set_Iterate raises "any exception".  You want to say, "Set_Iterate
> raises whatever exceptions are raised by Action".  That's not known at
> compile time of the generic, but it could be known at compile time of
> the instantiations.
> 
> So for "throws clauses" to work well, we need some sort of pass-through
> concept -- "this throws what that throws".  This would allow abstraction
> layers that simply pass exceptions through to avoid saying "throws
> anything" and the subsequent clutter in clients.

This is a simple inheritance model. A derivant inherits the contract which 
includes "throws clauses". It may strengthen it by saying "I will not throw 
X". Then the implementation of derivant has to catch X.

> Another point is that most exceptions are really preconditions.

Of course.

> See
> Eiffel, and design-by-contract.  You want to declare not only that this
> procedure raises Queue_Empty_Error, but also under what conditions that
> exception is raised (e.g. if Is_Empty is True), and that
> Queue_Empty_Error gets raised before modifying the queue.
> 
> And if you have pre- and postconditions, I think you want to attach
> postconditions to exceptional situations.  You want a way to express,
> "If this procedure returns normally, then such-and-such is true.  If it
> raises File_Not_Found, then so-and-so is true.  And if it raises
> Storage_Error, all bets are off (i.e., any data touched by this
> procedure might have been damaged, so don't touch it)."

Semantics of exceptions as a part of the contract, I like it. Of course, 
"throw clauses" has to be inherited with pre- and postconditions upon 
exceptions. Then a derivant may tune those. If it promises not to raise an 
exception then it is same as to say that the precondition of the exception 
is False.

> And finally, you want user-settable defaults.  Like, "All procedures in
> this package, and all of its descendants, behave such-and-such a way in
> the presence of so-and-so exception."

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Suggestion for Ada 200x - Interface inheritance

[Wojtek Narczynski]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccd6i2yb1s.fsf@shell01.TheWorld.com>...

> I also think you should let the programmer decide which exceptions are
> in which category.  For example, an out-of-memory exception
> (Storage_Error, in Ada) should, by default, not require any
> declarations, since pretty-much anything can raise it.

Just to clarify. In Java 'out of memory' is an Error, not Exception.
You never need to declare it in throws clause, and you very rarely
throw it by yourself, only when you are are doing malloc() by
yourself.

> Another point is that most exceptions are really preconditions. 

Yes! For example the Java IllegalArgument exception, you don't need to
declare it, but practically most methods should throw it.
Preconditions would do the job much better.

> And finally, you want user-settable defaults. Like, "All procedures in
> this package, and all of its descendants, behave such-and-such a way in
> the presence of so-and-so exception."

Yeah, I would want this.

Regards,
Wojtek

Re: Suggestion for Ada 200x - Interface inheritance

[Wojtek Narczynski]

Wesley Groleau <wesgroleau@despammed.com> wrote in message news:<iYWdna3UTaIzkkyjXTWcoA@gbronline.com>...

> But that meant adding a throws clause to each of hundreds of
> files.

People tend to heavily abuse 'throw new XxxxException' instead of
'throw new Error'. The difference is that Excetions are supposed to be
handled gracefully while Errors should cause the JVM to die. So when
you know that you cannot go on, you just throw an Error. In library
code you'll often throw exceptions, but in application code you'll
often catch an exception just to throw an error.

Regards,
Wojtek

Re: Suggestion for Ada 200x - Interface inheritance

[Steve]

Thanks.  I looked at AI-251.  It looks like it is covered..

Here's another one:
  Ada currently permits giving the names of operands to functions and
procedures from the caller:

Example:
  function Add( left, right : Natural ) return Natural;

  May be called using:

  result := Add( left => 2, right => 3 );

Use of the names is optional, but if they are present they must match.

What do you think of the idea of also optionally giving the mode of the
parameter, which if present must match the function or procedure
declaration.  That is, extending the above example:

  result := Add( in left => 2, in right => 3 );

Why?  Readability.  When reading code it is sometimes unclear from the
caller whether or not a procedure modifies its parameters.  Adding this
feature would permit specifying this explicitly.  I realize I haven't chosen
the best example since functions only permit "in" parameters, but you
probably get the idea.

It really enhances readability with certain procedure calls such as:

Copy( out buf_1 => a, in buf_2 => b );

Of course bettern naming conventions would help readability in this example.

I could even imagine a pragma that requiring such qualification to enforce
coding conventions.

Steve
(The Duck)

"Wojtek Narczynski" <wojtek@power.com.pl> wrote in message
news:5ad0dd8a.0305240435.337d9373@posting.google.com...
> "Steve" <nospam_steved94@attbi.com> wrote in message
news:<0Pxza.699607$OV.652508@rwcrnsc54>...
[snip]
>
> I find your syntax cleaner than the AI proposal:
>
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00251.TXT?rev=1.12
>
> This AI has a funny title: "Abstract Interfaces to provide Multiple
> Inheritance". Two misconceptions: 1. Interfaces cannot be concrete, 2.
> Interfaces do not provide multiple inheritance. They are just a
> different solution to to the problem.
[snip]
>
> Regards,
> Wojtek

Re: Suggestion for Ada 200x - Interface inheritance

[Simon Wright]

"Steve" <nospam_steved94@attbi.com> writes:

> It really enhances readability with certain procedure calls such as:
> 
> Copy( out buf_1 => a, in buf_2 => b );
> 
> Of course better naming conventions would help readability in this
> example.

Indeed.

  Copy (From => A, To => B);

in this simple example.

I find people don't always think of the subprograms they're providing
from the point of view of the people who are going to use them.

Re: Suggestion for Ada 200x - Interface inheritance

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]


"Steve" <nospam_steved94@attbi.com> a �crit dans le message de news:m3Vza.963555$3D1.566040@sccrnsc01...
> What do you think of the idea of also optionally giving the mode of the
> parameter, which if present must match the function or procedure
> declaration.  That is, extending the above example:
>
>   result := Add( in left => 2, in right => 3 );
>
Sigh... In the green language proposal, associations between formal and actual used ":=" for in parameters,
"=:" for out parameters, and ":=:" for in out parameters.

It was later dropped, I don't remember why, but presumably because it was felt that the gain was not worth
the extra complexity.

So this idea, although it has some merit, is not really new...

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Suggestion for Ada 200x - Interface inheritance

[Preben Randhol]

Jean-Pierre Rosen wrote:

> Sigh... In the green language proposal, associations between formal
> and actual used ":=" for in parameters, "=:" for out parameters, and
> ":=:" for in out parameters.
> 
> It was later dropped, I don't remember why, but presumably because it
> was felt that the gain was not worth the extra complexity.

I don't know why it was dropped, but I would say why I would drop it it
would be that it has very low readability. := and =: are too similar and
an error can easily be overlooked IMHO. At least I know *I* could easily
do that mistake.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Suggestion for Ada 200x - Interface inheritance

[Pascal Obry]

Preben Randhol <randhol+abuse@pvv.org> writes:

> I don't know why it was dropped, but I would say why I would drop it it
> would be that it has very low readability. := and =: are too similar and
> an error can easily be overlooked IMHO. At least I know *I* could easily
> do that mistake.

But that's not a big problem since the compiler would detect such errors.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Suggestion for Ada 200x - Interface inheritance

[Preben Randhol]

Pascal Obry wrote:
> 
> But that's not a big problem since the compiler would detect such errors.

Sure, but it would afwully annoying to all the time get the : at the
right side of the =. But my main point it doesn't give much information
to the *eye* that reads the code.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Suggestion for Ada 200x - Interface inheritance

[Craig Carey]

On Mon, 26 May 2003 09:54:07 +0200, "Jean-Pierre Rosen" <rosen@adalog.fr> wrote:
>"Steve" <nospam_steved94@attbi.com> a �crit dans le message de news:m3Vza.963555$3D1.566040@sccrnsc01...
>> What do you think of the idea of also optionally giving the mode of the
>> parameter, which if present must match the function or procedure
>> declaration.  That is, extending the above example:
>>
>>   result := Add( in left => 2, in right => 3 );
>>
>Sigh... In the green language proposal, associations between formal and actual used ":="
> for in parameters, >"=:" for out parameters, and ":=:" for in out parameters.
>
>It was later dropped,

How interesting.

Instead of "=:", ":=:", ":=", these may be used:
   "/" [constant 'in' mode parameter for the procedure or generic],
   "|" [in out], and
   "\" [out].

Two examples of calling a procedure:

   Text_IO.Get_Line (/File, \Item, \Last);

   Text_IO.Get_Line (/File, \Item => Item, \Last => Last);



Craig Carey
   http://www.ijs.co.nz/ada_95.htm

Re: Suggestion for Ada 200x - Interface inheritance

[Preben Randhol]

Craig Carey wrote:
>    "/" [constant 'in' mode parameter for the procedure or generic],
>    "|" [in out], and
>    "\" [out].
> 
> Two examples of calling a procedure:
> 
>    Text_IO.Get_Line (/File, \Item, \Last);
> 
>    Text_IO.Get_Line (/File, \Item => Item, \Last => Last);

IMHO awful. We are saying Ada is more readable because it uses less
whitespaces so why should we now start adding more whitespaces which
makes the code less readable?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: Suggestion for Ada 200x - Interface inheritance

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 767 bytes --]


"Wojtek Narczynski" <wojtek@power.com.pl> a �crit dans le message de news:5ad0dd8a.0305240435.337d9373@posting.google.com...
> "Steve" <nospam_steved94@attbi.com> wrote in message news:<0Pxza.699607$OV.652508@rwcrnsc54>...
> But I'll welcome whatever comes out, because the inability to create
> heterogenous collections just plain sucks.
>
"Inability" is an overstatement. Of course, you can create heterogenous collections in Ada, it just requires you
to follow a certain design pattern.
See my last year's Ada-Europe paper for how to do that (available at http://www.adalog.fr/publicat/ada-interfaces.pdf)

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Suggestion for Ada 200x - Interface inheritance

[Wojtek Narczynski]

"Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message news:<8khsab.h94.ln@skymaster>...

> "Inability" is an overstatement.

Yeah, I overstated it...

> See my last year's Ada-Europe paper for how to do that 
> (available at http://www.adalog.fr/publicat/ada-interfaces.pdf)

It seems to me that the idea that 'abstract tagged null record' is
'interface enough' already pops-up every now and then.

It is a valid point that you can simulate interfaces with inner
classes / record components. But you can also write object oriented
code in raw C (see GNOME), it's rather the decision which constructs
to make first class citizens of a given language.

Your paper also shows that interfaces should not be hard to implement
in compilers. Right?


Thank you,
Wojtek