Ada User Journal

Ada User Journal

[Marie-Louise.Kok]

Ada User Journal (Formerly: ADA User)

Editor: Dan Simpson

Ada User Journal is the quarterly journal of Ada (UK).  It aims to 
inform readers of recent developments in the Ada Language, the use 
of Ada and general Ada-related software engineering issues.

The journal contains refereed articles in Ada methodologies, case 
studies, surveys and tutorials on Ada-related topics and also features 
reports of conferences and workshops.

Subscription information: Ada User Journal (ISSN: 0268-652X) is published 
quarterly.  The subscription price for Volume 16, 1995, is NLG 296/$ 
164 postpaid.

If you would like to receive a FREE SAMPLE COPY of the journal, 
please e-mail your full postal mailing address to Marie-Louise.Kok@ios.nl

Ada User Journal

[Bo I. Sanden]

A reference I made in an earlier post (in the thread "Question about the
need for requeue ...") has prompted some email questions about the Ada
User Journal. Its existence seems to be a well guarded secret at least in
the US. 

It is a refereed journal, published by Ada Language UK Ltd. There are 4 
issues per year. They give the following address for mail orders and 
enquiries:

Ada Language UK Ltd.
PO Box 322
York, YO1 3HL
England

For quicker information you might try the Ada UK administrator H. Byard: 
h.byard@bton.ac.uk, Tel +44 1904 412740 Fax +44 1904 42670


---------------------------------------------------------------------
Dr. Bo Sanden					Author of:
Mail Stop 4A4				Software Systems Construction
George Mason University			    with examples in Ada
Fairfax, VA 22030-4444, USA		     Prentice-Hall 1994

        Tutorials on concurrent/real-time software design
                      at WAdaS and TRI-Ada
             http://www.isse.gmu.edu/faculty/bsanden
---------------------------------------------------------------------

Ada 2005?

[conradwt]

Hi, will Ada support keyword class for designing and implementing
classes?  For example, I'm forced to convert the following C++ class in
Ada as follows:

// C++

class A_Device {

public:

A_Device( char*, int, int );

char* Name( void );

int Major( void );

int Minor( void );

protected:

char* name;

int major;

int minor;
};

// Now, if I need to interact with the, this class I can do the
// following:

void main(void) {

A_Device aDevice = new A_Device( "Test", 1, 1 );

cout << aDevice.Name() << endl;
cout << aDevice.Major() << endl;
cout << aDevice.Minor() << endl;

}

// Ada

package Devices is

type Device is tagged private;

type Device_Type is access private;

function Create( Name : String,
Major : Integer,
Minor : Integer ) return Device_Type;

function Name( this : Device_Type ) return String;

function Major( this : Device_Type ) return Integer;

function Minor( this : Device_Type ) return Integer;

private

type Device is tagged

record

name : String(1..20);
major: Integer;
minor: Integer;

end record;

end Devices;

Now, interact with Ada package I would need to do the following:

procedure main

aDevice : Device_Type := Devices.Create( "Test", 1, 1 );

begin

Put_Line( Name( aDevice ) );
Put_Line( Major( aDevice ) );
Put_line( Minor( aDevice ) );

end main;

It seems that I'm trying to mimic the behavior of a OO language in a
procedural language when converting C++ to Ada.  Is this correct?  If
so, why doesn't Ada have OO contructs similar to C++,
Java, Eiffel, and Smalltalk to name a few where one passes a message to
an instance of a class?  Will this be something in Ada 2005 because I
have been able to find a good overview of the language to date?  Well,
I must go and thanks for any comments that you may send me.

-Conrad

Re: Ada 2005?

[Martin Dowie]

conradwt@runbox.com wrote:
> Hi, will Ada support keyword class for designing and implementing
> classes?  For example, I'm forced to convert the following C++ class in
> Ada as follows:

Why are you hung up on having a keyword 'class'? 'Tagged types' in Ada 
do the same thing wrt dynamic dispatching and 'packages' give you 
namespaces/modules.


> // C++
> 
> class A_Device {
> 
> public:
> 
> A_Device( char*, int, int );

"char*" really ought to be a 'const'...


> char* Name( void );
> 
> int Major( void );
> 
> int Minor( void );

These really ought to be marked as 'const' functions...


> protected:
> 
> char* name;
> 
> int major;
> 
> int minor;
> };
> 
> // Now, if I need to interact with the, this class I can do the
> // following:
> 
> void main(void) {
> 
> A_Device aDevice = new A_Device( "Test", 1, 1 );
> 
> cout << aDevice.Name() << endl;
> cout << aDevice.Major() << endl;
> cout << aDevice.Minor() << endl;
> 
> }
> 
> // Ada
> 
> package Devices is
> 
> type Device is tagged private;
> 
> type Device_Type is access private;

You just don't need this access type



> function Create( Name : String,
> Major : Integer,
> Minor : Integer ) return Device_Type;

Just return something of type Device...


> function Name( this : Device_Type ) return String;
> 
> function Major( this : Device_Type ) return Integer;
> 
> function Minor( this : Device_Type ) return Integer;
> 
> private
> 
> type Device is tagged
> 
> record
> 
> name : String(1..20);
> major: Integer;
> minor: Integer;
> 
> end record;
> 
> end Devices;
> 
> Now, interact with Ada package I would need to do the following:
> 
> procedure main
> 
> aDevice : Device_Type := Devices.Create( "Test", 1, 1 );
> 
> begin
> 
> Put_Line( Name( aDevice ) );
> Put_Line( Major( aDevice ) );
> Put_line( Minor( aDevice ) );
> 
> end main;
> 
> It seems that I'm trying to mimic the behavior of a OO language in a
> procedural language when converting C++ to Ada.  Is this correct?  If
> so, why doesn't Ada have OO contructs similar to C++,
> Java, Eiffel, and Smalltalk to name a few where one passes a message to
> an instance of a class?  Will this be something in Ada 2005 because I
> have been able to find a good overview of the language to date?  Well,
> I must go and thanks for any comments that you may send me.

Ada does have OO behaviour - what isn't OO about the behaviour of a 
'tagged type'?

If you're bother that you can't say

"Put_Line (aDevice.Name);"

then wait for Ada200Y which adds this. But it is nothing more than 
playing with syntax - there is no symantic difference to this notation 
that to:

Put_Line (Name (aDevice));

Cheers

-- Martin

Re: Ada 2005?

[christov]

conradwt@runbox.com wrote:
> Hi, will Ada support keyword class for designing and implementing
> classes?  For example, I'm forced to convert the following C++ class
in
> Ada as follows:

No, I do not think that Ada 2005 will support the keyword "class".  Ada
2005 will
add the "interface" keyword however.  (I haven't read up on it yet.)

[non-object-oriented code examples snipped]

Neither of your code examples really show much "object-orientation."
The best that you can say is that both examples show encapulation and
static function binding.  The C++ example is just a syntactic sugar
over what is easily acheivable in plain C.  The Ada example, while you
use tagged types, does not show any methods taking Classwide parameters
and thus use dynamic dispatch.

The syntax difference is just that, a syntax difference.  Looking at
the Ada Issues database it does look like Ada 2005 will support an
Object.Operation(...) style of notation.  It will provide a more
familiar syntax for C++/Java programmers who balk at
Package.Operation(Object,...).

>
> It seems that I'm trying to mimic the behavior of a OO language in a
> procedural language when converting C++ to Ada.  Is this correct?  If
> so, why doesn't Ada have OO contructs similar to C++,
> Java, Eiffel, and Smalltalk to name a few where one passes a message
to
> an instance of a class?  Will this be something in Ada 2005 because I
> have been able to find a good overview of the language to date?
Well,
> I must go and thanks for any comments that you may send me.

Ada95 is at least as object oriented as C++ in that it offers data
encapulation, type heirarchies, dynamic dispatch, abstract types and
methods, etc.  The syntax and procedure for their use are different.
Packages provide the mechanism for encapsulation and specialization in
Ada.  Tagged types and subprograms taking Type'Class arguments
(declared in the same package) provide the method for dynamic dispatch
and type inheiritance.

I also think that many Smalltalk adherants would be dismayed to find
you lumping that language in with C++ and Java.  Smalltalk (and
Objective C) are message passing, dynamically bound OO languages.  C++
is not a message passing language.

If you want a good book on Ada, I recommend  _Programming in Ada95, 2nd
edition_ by John Barnes.  There are also several excellent refferences
on Ada to be found for free from sites like http://www.adapower.com/ or
http://www.adaworld.com/.

Adacore has a short summary of Ada 2005 at
http://www.adacore.com/ada_2005.php.
If you want to go to the source then
http://www.ada-auth.org/arg-minutes.html shows the language design
process in all of its messy glory.  I really don't recommend it for
beginers though.  I try to steer clear myself. :-)

Cheers,
     Chris

Re: Ada 2005?

[Martin Krischik]

conradwt@runbox.com wrote:

> Hi, will Ada support keyword class for designing and implementing
> classes?  For example, I'm forced to convert the following C++ class in
> Ada as follows:
> 
> // C++
> 
> class A_Device {
> 
> public:
> 
> A_Device( char*, int, int );
> 
> char* Name( void );
> 
> int Major( void );
> 
> int Minor( void );
> 
> protected:
> 
> char* name;
> 
> int major;
> 
> int minor;
> };
> 
> // Now, if I need to interact with the, this class I can do the
> // following:
> 
> void main(void) {
> 
> A_Device aDevice = new A_Device( "Test", 1, 1 );
> 
> cout << aDevice.Name() << endl;
> cout << aDevice.Major() << endl;
> cout << aDevice.Minor() << endl;
> 
> }
> 
> // Ada
> 
> package Devices is
> 
> type Device is tagged private;
> 
> type Device_Type is access private;

You do to much pointer work! Ada does not need that much pointer work! Read:

http://en.wikibooks.org/wiki/Programming:Ada:OO#The_class-wide_type

> function Create( Name : String,
> Major : Integer,
> Minor : Integer ) return Device_Type;
> 
> function Name( this : Device_Type ) return String;

You did the equivalent of:

class Device
   {
   static char*
   Name(Device* this);
   }

A "static" class member will not dispatch! You should have done:

function Name( this : in Device) return String;

or

function Name( this : in out Device) return String;

Read:

http://en.wikibooks.org/wiki/Programming:Ada:OO#Primitive_Operations

> 
> function Major( this : Device_Type ) return Integer;
> 
> function Minor( this : Device_Type ) return Integer;
> 
> private
> 
> type Device is tagged
> 
> record
> 
> name : String(1..20);
> major: Integer;
> minor: Integer;
> 
> end record;
> 
> end Devices;
> 
> Now, interact with Ada package I would need to do the following:
> 
> procedure main
> 
> aDevice : Device_Type := Devices.Create( "Test", 1, 1 );
> 
> begin
> 
> Put_Line( Name( aDevice ) );
> Put_Line( Major( aDevice ) );
> Put_line( Minor( aDevice ) );
> end main;
> 
> It seems that I'm trying to mimic the behavior of a OO language in a
> procedural language when converting C++ to Ada.  Is this correct?

No! Ada has OO - but you have not read enough tutorials to know how Ada's OO
works. Keep going and you get there!

> If 
> so, why doesn't Ada have OO contructs similar to C++,
> Java, Eiffel, and Smalltalk to name a few where one passes a message to
> an instance of a class?

Ada does have these features! The difference is that Ada is package
(namespace) centric and not record (struct) centric. In fact a Ada class
need to be defined inside a package (namespace)! 

It is not uncomme to declare a classes like this:

package Parent_Class
is

  type Object is tagged
     record
        .....
     end record;

end Class_Name;

with Parent_Class;

package Child_Class
is

  type Object
  is new  
     Parent_Class.Object
   with  record
        .....
   end record;

end Class_Name;


> Will this be something in Ada 2005 because I 
> have been able to find a good overview of the language to date?

Only interfaces are added to Ada 2005 - everything else is allready there.

With Rergards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada 2005?

[Dmitry A. Kazakov]

On 17 Dec 2004 20:27:44 -0800, conradwt@runbox.com wrote:

> It seems that I'm trying to mimic the behavior of a OO language in a
> procedural language when converting C++ to Ada.  Is this correct?  If
> so, why doesn't Ada have OO contructs similar to C++,
> Java, Eiffel, and Smalltalk to name a few where one passes a message to
> an instance of a class?

Because it is inconsistent. Method is not a property of a class (=type),
the relation is not 1-1. So the idea of a message sent to invoke a member
of an object is plainly wrong. Consider nasty consequences in C++:

class Device
{
public :
   void Copy (From : Device);
};

The above is infeasible, it will not dispatch in From for:

Printer.Copy (Display);

what is the recipient here? Printer or Display? The only correct answer is
both. So Copy should be defined not on Device, but on Device x Device
(tuple).

The word class as it is used in C++ is just a type. There is no need to
call types classes. BTW, it has nothing to do with OO. Ada uses the word
"class" for types of polymorphic objects. It is specified as T'Class. Using
the same word for something else would be misleading.

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

Re: Ada 2005?

[Jeffrey Carter]

conradwt@runbox.com wrote:

> char* name;

> name : String(1..20);

To be consistent, you should probably have

Name : Ada.Strings.Unbounded.Unbounded_String;

As others have pointed out, there's nothing related to OOP in your 
example, Ada 0X will support the Object.Operation notation, and the 
pointers, while perhaps needed in C++, are unnecessary in Ada. This 
eliminates the many possibilities for error associated with manually 
allocating and deallocating memory.

What is clear from your example is that C++ uses the same construct for 
encapsulation, information hiding, and OOP. Ada separates these concepts.

Other than that, nice troll.

-- 
Jeff Carter
"You've got the brain of a four-year-old boy,
and I bet he was glad to get rid of it."
Horse Feathers
47

Re: Ada 2005?

[Brian May]

>>>>> "conradwt" == conradwt  <conradwt@runbox.com> writes:

    conradwt> If so, why doesn't Ada have OO contructs similar to C++,
    conradwt> Java, Eiffel, and Smalltalk to name a few where one
    conradwt> passes a message to an instance of a class?

Why should Ada have OO constructs that are similar to other languages?

Ada is a different language, different history, and as such has a
different approach to OO.

I like it; in fact the Object.Operation in the next version of Ada
makes me kind of nervous (disclaimer: I have read the details; if I
did, perhaps I would feel differently).
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Ada 2005?

[Randy Brukardt]

"christov" <christov@mac.com> wrote in message
news:1103359624.475636.116510@z14g2000cwz.googlegroups.com...
> Adacore has a short summary of Ada 2005 at
> http://www.adacore.com/ada_2005.php.
> If you want to go to the source then
> http://www.ada-auth.org/arg-minutes.html shows the language design
> process in all of its messy glory.  I really don't recommend it for
> beginers though.  I try to steer clear myself. :-)

John Barnes is preparing a set of articles on Ada 2005 for the Ada User
Journal. I think they will be the definitive introduction to the changes in
Ada 2005. I hope that they'll be available on the web at some point.

                     Randy.

Re: Ada 2005?

[christov]

> John Barnes is preparing a set of articles on Ada 2005 for the Ada
User
> Journal. I think they will be the definitive introduction to the
changes in
> Ada 2005. I hope that they'll be available on the web at some point.

Awesome.

How do I subscribe to the "Ada User Journal"?  Is that a publication of
SIGAda or something else?

Thanks,
          Chris

Ada User Journal (was: Re: Ada 2005?)

[Dirk Craeynest]

In article <1103483481.620841.201320@f14g2000cwb.googlegroups.com>,
christov <christov@mac.com> wrote:
>> John Barnes is preparing a set of articles on Ada 2005 for the Ada
>> User Journal. I think they will be the definitive introduction to
>> the changes in Ada 2005. I hope that they'll be available on the
>> web at some point.
>
>Awesome.
>
>How do I subscribe to the "Ada User Journal"?  Is that a publication
>of SIGAda or something else?

The "Ada User Journal" is the 3-monthly publication of Ada-Europe.
See <http://www.ada-europe.org/journal.html> for more information.

All members of Ada-Europe automatically have a subscription to
the Ada User Journal, i.e. all indirect members through an associate
national Ada organization and all direct members where no such
organization is active (yet).  If you're interested in membership,
please check <http://www.ada-europe.org/join.html>.

Dirk Craeynest - Ada User Journal Editorial Board
(Dirk.Craeynest@cs.kuleuven.ac.be for Ada-Belgium/Europe/WG9 mail)

*** 10th Intl.Conf.on Reliable Software Technologies - Ada-Europe'2005
*** June 20-24, 2005 ***  York, UK  ***  http://www.ada-europe.org ***

Re: Ada User Journal

[Florian Weimer]

* Dirk Craeynest:

> All members of Ada-Europe automatically have a subscription to
> the Ada User Journal, i.e. all indirect members through an associate
> national Ada organization and all direct members where no such
> organization is active (yet).  If you're interested in membership,
> please check <http://www.ada-europe.org/join.html>.

It seems as if GI (Gesellschaft f�r Informatik) membership is a
requirement if you want to join Ada Europe as a German citizen.

Is there a workaround?  I don't particularly like the way GI opposes
an open society and free software.

Re: Ada User Journal

[Martin Krischik]

Florian Weimer wrote:

> * Dirk Craeynest:
> 
>> All members of Ada-Europe automatically have a subscription to
>> the Ada User Journal, i.e. all indirect members through an associate
>> national Ada organization and all direct members where no such
>> organization is active (yet).  If you're interested in membership,
>> please check <http://www.ada-europe.org/join.html>.
> 
> It seems as if GI (Gesellschaft fï¿œr Informatik) membership is a
> requirement if you want to join Ada Europe as a German citizen.

Don't know where you saw that. For me it looks like you have to be a member
of Ada-Deutschland (http://ada-deutschland.de). Have I missed something?
 
> Is there a workaround?  I don't particularly like the way GI opposes
> an open society and free software.

Well, I would not like to be a member of a of an organisation which oposes
an open society and free software, too.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada User Journal

[Florian Weimer]

* Martin Krischik:

> Don't know where you saw that. For me it looks like you have to be a member
> of Ada-Deutschland (http://ada-deutschland.de). Have I missed something?

Ada Deutschland is just a working group within GI, AFAICS.

Re: Ada User Journal

[Thomas Hühn]

Florian Weimer wrote:

>>Don't know where you saw that. For me it looks like you have to be a member
>>of Ada-Deutschland (http://ada-deutschland.de). Have I missed something?
> 
> Ada Deutschland is just a working group within GI, AFAICS.

 From http://ada-deutschland.de/foerder/foerder.html:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Der F�rderverein Ada Deutschland e.V.

     * wurde am 15. Juli 1998 in Karlsruhe gegr�ndet,
     * verfolgt ausschlie�lich und unmittelbar gemeinn�tzige Zwecke und 
ist daher steuerbeg�nstigt,
     * unterst�tzt die Ziele der Fachgruppe 2.1.5 Ada der Gesellschaft 
f�r Informatik und arbeitet eng mit dieser zusammen,
     * steht allen Organisationen und Personen offen, die sich mit den 
Zielen des Vereins identifizieren,
     * finanziert sich bis auf weiteres nur durch Spenden und 
freiwillige Mitgliedsbeitr�ge.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So it seems to be independent (especially money-wise), but does support 
the Ada subgroup of the GI (not necessarily the GI as a whole).

And actually the contact address given on the Ada-Europe website is not 
a GI-address, but an Aonix one. :-)

Thomas

Re: Ada 2005?

[conradwt]

In C++, the word, 'class', is a keyword that one uses to construct
object or instance definitions.  Also, it is very clear as to what
you're trying to do when you see this in the source.  Thus, I guess
that you're saying that Copy is a static member instead of an instance
member.

-Conrad

Re: Ada 2005?

[conradwt]

Hey Jeff, this an an example that I received from your Ada resources.

http://www.adahome.com/Ammo/Cplpl2Ada.html

Thus, if it is incorrect, then thanks for pointing that out to me. I
think that every language has varying levels for information hinding
and some does a better job than others in regards to clarity of it.
-Conrad

Re: Ada 2005?

[conradwt]

Hi Martin, I'm not hung up on a 'class' keyword but this would make it
clear as to what one is trying to do in the converting steps from C++
to Ada.  Also, this was an example from one of the Ada resources and
you'll find it at the following address:

http://www.adahome.com/Ammo/Cplpl2Ada.html

Thus, you're saying that I could have declared the functions as
followed:

function Name return String;
function Major return Integer;
function Minor return Integer;

Then, you're saying that I can use it as follows:

aDevice : Device_Type := Devices.Create( "Test", 1, 1 );

Put_Line( aDevice.Name );
Put_Line( aDevice.Major );
Put_Line( aDevice.Minor );

Thanks in advance,

-Conrad

Re: Ada 2005?

[Dmitry A. Kazakov]

On 20 Dec 2004 10:49:45 -0800, conradwt@runbox.com wrote:

> In C++, the word, 'class', is a keyword that one uses to construct
> object or instance definitions.

You mean type definition? In C++ class {...}; defines a special kind of
types.

> Also, it is very clear as to what
> you're trying to do when you see this in the source.  Thus, I guess
> that you're saying that Copy is a static member instead of an instance
> member.

Copy is a friend, but they are not methods. C++ does not support multiple
dispatch. The point is that:

1. Prefix notation is misleading

2. Methods do not belong to classes

3. (Implied by 2) class definition brackets is a nonsense. This is why Ada
has more flexible rules for the scope where primitive operations can be
declared. Namely: in the same file, but before any non-trivial use.

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

Re: Ada 2005?

[jayessay]

Brian May <bam@snoopy.apana.org.au> writes:

> >>>>> "conradwt" == conradwt  <conradwt@runbox.com> writes:
> 
>     conradwt> If so, why doesn't Ada have OO contructs similar to C++,
>     conradwt> Java, Eiffel, and Smalltalk to name a few where one
>     conradwt> passes a message to an instance of a class?
> 
> Why should Ada have OO constructs that are similar to other languages?
> 
> Ada is a different language, different history, and as such has a
> different approach to OO.
> 
> I like it; in fact the Object.Operation in the next version of Ada
> makes me kind of nervous (disclaimer: I have read the details; if I
> did, perhaps I would feel differently).

I haven't read this either.  That said, I hope it does not in any way
change the basic Ada precept of keeping separate namespace/module
construction and class/type/method definition.  The "distinguished
parameter" notion of other "typical class based OO object models" and
the typical conflation of classes and namespaces that goes with it is
actually a bad idea and broken concept.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Ada 2005?

[jayessay]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Copy is a friend, but they are not methods. C++ does not support multiple
> dispatch.

Yes, but to be clear, neither does Ada.


> The point is that:
> 
> 1. Prefix notation is misleading

Not to mention inflexible and limiting.


> 2. Methods do not belong to classes

Should not, and in Ada (and some others) they do not.


> 3. (Implied by 2) class definition brackets is a nonsense.

More specifically, class definitions defining method/operator
namespaces is broken.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Ada 2005?

[Jeffrey Carter]

conradwt@runbox.com wrote:

> http://www.adahome.com/Ammo/Cplpl2Ada.html

Adahome.com has not been maintained for some time. This page dates from 
1995. Adapower.com and adaworld.com are probably better sources.

-- 
Jeff Carter
"This trial is a travesty. It's a travesty of a mockery of a
sham of a mockery of a travesty of two mockeries of a sham. ...
Do you realize there's not a single homosexual on that jury?"
Bananas
27

Re: Ada 2005?

[David Botton]

See: http://www.adapower.com/index.php?Command=Class&ClassID=GeneralAda

For some articles, etc. on 2005

David Botton

On 2004-12-18 03:47:04 -0500, "christov" <christov@mac.com> said:
> 
> Adacore has a short summary of Ada 2005 at
> http://www.adacore.com/ada_2005.php.
> If you want to go to the source then
> http://www.ada-auth.org/arg-minutes.html shows the language design
> process in all of its messy glory.  I really don't recommend it for
> beginers though.  I try to steer clear myself. :-)

Re: Ada 2005?

[David Botton]

You will in fact find information on this topic in the Official Ada FAQ 
at http://www.adapower.com/faq

David Botton


On 2004-12-20 18:53:51 -0500, Jeffrey Carter <spam@spam.com> said:

> conradwt@runbox.com wrote:
> 
>> http://www.adahome.com/Ammo/Cplpl2Ada.html
> 
> Adahome.com has not been maintained for some time. This page dates from 
> 1995. Adapower.com and adaworld.com are probably better sources.

Re: Ada 2005?

[Alexander E. Kopilovich]

jayessay wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
[...]
> > The point is that:
> > 
> > 1. Prefix notation is misleading
>
> Not to mention inflexible and limiting.

And how about the following alternative (which was posted to Ada-Comment in
June 2003) ?

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

!summary

An alternative syntax is proposed here for AI-252. This alternative uses
new attribute instead of extension for meaning of dot-qualification, which is 
currently proposed in AI-252. This text assumes the context of current AI-252.

!proposal

Let us introduce new attribute Method, which always must be followed by dot
and operation, i.e.

  Object'Method.Operation

for example:

  type T is ... ;
  function F(A1 : T; A2 : Integer) return Integer;
  procedure P(A1: T);
  ...

  X : T;
  Actual_A2 : Integer;
  F_Result : Integer;
  ...

  F_Result := X'Method.F(Actual_A2);
  ...
  X'Method.P;

Conceptually, the attribute Method returns a record -- the table of all
relevant methods; some analogy with C++ code is present here, although the
major difference is obvious: contents of this table depends not only on the
object's type, but on surround and visibility rules also.

Basic visibility rules for Operation may stay as they are stated currently
in AI-252, but with additional option: a programmer can explicitly list all
visible packages for a particular subtype using appropriate "for...use"
statement:

  for Subtype'Method use Package1 [, Package2, ..., PackageN];

Such explicit statement overrides basic visibility rules for all
Object'Method.Operation expressions where Object belongs to Subtype.

Further, with this approach we may easily provide a denotation for the
component-on-demand abstraction, that is, unified notation for an externally
immutable view of a data component and a function; all we need for this is
another attribute Property, which should be used the same way:

  Object'Property.Function_Or_DataField

for example, for both

  type T is ... ;
  function F(P : T) return Integer;

and

  type T is record
     F : Integer;
     ...
  end record;

we can write:

  X : T;
  R : Integer;
  ...

  R := X'Property.F;

Arguments for a function prefixed by the Property attribute naturally
correspond indices for array data component.

Further, arrays (that are indexed by controlling object type) likewise may be
used in conjunction with the Property attribute  (in accordance with analogy
between arrays and functions, supported in Ada). For example:

  type String_Index is new Integer;
  S : String(1..10);
  I : String_Index;
  ...
  ... I'Property.S ...

Even multi-dimensional arrays are permitted here. For example:

  type Cities is (Edinburgh, Glasgow, London, Paris, New_York);
  type Distances is array (Cities, Cities) of Float;
  Km_To : Distances := ...;
  ...
  ... Edinburgh'Property.Km_To(Paris) ...

As for arrays of arrays, only outer array may be used, that is, the subscripts
for inner arrays cannot appear. For example:

  type Table_Index is new Integer;
  type Table_Line is String(1..50);  
  Table : array (Table_Index range 1..10) of Table_Line;
  I : Table_Index;
  ...
  ... I'Property.Table ...     -- legal
  ...
  ... I'Property.Table(1) ...  -- illegal


!discussion

Object.Operation syntax seems as acceptable compromise in a case when
there is a controlling object. Although even then the Operation does not
belong to the Object (as it belongs to a package), it is reasonable to claim
that conceptually, the status of being controlling temporary gives the Object
some additional rights over all its operations, and in particular, extends
visibility rules for the Object.

But in many cases there are no controlling objects, and in those cases this
Object.Operation syntax will act against proper expression and understanding
of program design and logic. Moverover, as this Object.Operation style
potentially conflicts with package-orientation, which is fundamental feature
of Ada 95, and as this Object.Operation notation is compulsory in most of
today's mainstream languages, there is real possibility of massive and
disordered mixture of those design styles if this Object.Operation notation
appear in Ada.

There is also anxiety about possible confusion with component notation.
As Robert I. Eachus recently wrote in comp.lang.ada newsgroup
(message-id <3ED056CB.8000200@attbi.com> ):
"I really don't like the idea of allowing the Object.Operation format to 
Ada.  Yeah, the compilers can usually figure it out understand it. But 
the potential confusion with component notation is going to confuse 
experienced Ada users.  (And eventually other O-O language users when 
the actually run into component references."

An alternative proposed here attains main purpose of AI-252, and it does not
contest AI's propositions concerning all things except Object.Operation
syntax. At the same time it establishes a deterrent for unjustified use of
the feature (by extra wording), makes the expression of programmer's intent
more explicit, and additionally, provides finer control over visibility and
over interchangeability between operation and data field.

The level of uniformity achieved with the notation proposed here is even
higher than with dot-notation proposed in current AI-252 (because the arrays
are included) without sacrificing traditional features and natural ways for
expressing specific intentions.

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

Re: Ada 2005?

[Martin Dowie]

conradwt@runbox.com wrote:
> Hi Martin, I'm not hung up on a 'class' keyword but this would make it
> clear as to what one is trying to do in the converting steps from C++
> to Ada.

I think there was plenty of debate about creating a new reserved word 
'class' in the Ada9X development but 'tagged' won. I'm sure the 
rationale is probably still kicking around on the net somewhere...


> Also, this was an example from one of the Ada resources and
> you'll find it at the following address:
> 
> http://www.adahome.com/Ammo/Cplpl2Ada.html

> Thus, you're saying that I could have declared the functions as
> followed:
> 
> function Name return String;
> function Major return Integer;
> function Minor return Integer;

Nearly but there is no implicit 'this' parameter as there is in C++, so 
will still need to name it (and its type).


> Then, you're saying that I can use it as follows:
> 
> aDevice : Device_Type := Devices.Create( "Test", 1, 1 );

aDevice : Device := ...;


> Put_Line( aDevice.Name );
> Put_Line( aDevice.Major );
> Put_Line( aDevice.Minor );

In Ada200Y, yes.

Cheers

-- Martin

Re: Ada 2005?

[Dmitry A. Kazakov]

On 20 Dec 2004 18:44:14 -0500, jayessay wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Copy is a friend, but they are not methods. C++ does not support multiple
>> dispatch.
> 
> Yes, but to be clear, neither does Ada.

Surprisingly, but it does:

procedure Foo (X, Y : Some_Tagged_Type); -- This is legal

Though it is very limited and cannot be counted as true multiple dispatch.

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

Re: Ada 2005?

[Dmitry A. Kazakov]

On Tue, 21 Dec 2004 04:26:34 +0300 (MSK), Alexander E. Kopilovich wrote:

> jayessay wrote:
> 
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> [...]
>>> The point is that:
>>> 
>>> 1. Prefix notation is misleading
>>
>> Not to mention inflexible and limiting.
> 
> And how about the following alternative (which was posted to Ada-Comment in
> June 2003) ?
[...]
> ---------------------------------------------------------------------------

I would say both. Clearly attributes should be primitive operations to
define and override. Same for the prefix notation which existed already in
Ada 83 in the form of task entry calls. That all is just syntactic sugar.
The programmer should be free in choosing either way of "formatting" calls
to primitive operations.

1. Functional: f(a,b,c,d)
2. Attribute: a'f(b,c,d)
3. Prefix (member) a.f(b,c,d)
4. Infix: a + b, "+" is the operation
5. Index: a(b,c,d), "(" is the operation
6. Aggregate: (a,b,c,d), "(" is the operation

Presently Ada can only 1 and 4 is available. Ada 2005 will provide 3. 4 is
limited because it is not fully multiple dispatch.

[ C++ can 3. Also 4, but broken in the second parameter. Then 5, though
limited. It cannot 1, that won't dispatch. ]

A lot of work to do!

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

Re: Ada 2005?

[Martin Krischik]

conradwt@runbox.com wrote:

> In C++, the word, 'class', is a keyword that one uses to construct
> object or instance definitions.  Also, it is very clear as to what
> you're trying to do when you see this in the source.  Thus, I guess
> that you're saying that Copy is a static member instead of an instance
> member.

Actually it is only a synonym for:

struct { private: 

You can easiely do a:

s/class(.*)\{/struct\1\{private\:/g

and your programm will work just the same. {Ok, the regular expression is
not perfect as they could be CR/LF in the source as well - is't just a
quick example}

"class" is just syntactic sugar, and a great marketing ploy.

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada 2005?

[jimmaureenrogers]

There are actually some other small differences between "struct" and
"class" in C++.
In a "struct" all members are public by default, while in a "class" all
members are private by default.

The "class" syntax provides good defaults for information hiding. The
"struct" syntax provides
compatibility with C code.

Jim Rogers

Re: Ada 2005?

[Martin Krischik]

jimmaureenrogers@worldnet.att.net wrote:

> There are actually some other small differences between "struct" and
> "class" in C++.
> In a "struct" all members are public by default, while in a "class" all
> members are private by default.

But that is exactly what I said. 

For those who can't read regular expression

is you replace "class X {"  with "struct X { private :" then nothing
changes.

> The "class" syntax provides good defaults for information hiding. The
> "struct" syntax provides compatibility with C code.

Only I never rely on defaults in C or C++ and allways specify what I want.
That's because 90% of all C / C++ defaults are "unsave".

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada 2005?

[jayessay]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 20 Dec 2004 18:44:14 -0500, jayessay wrote:
> 
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> > 
> >> Copy is a friend, but they are not methods. C++ does not support multiple
> >> dispatch.
> > 
> > Yes, but to be clear, neither does Ada.
> 
> Surprisingly, but it does:
> 
> procedure Foo (X, Y : Some_Tagged_Type); -- This is legal
> 
> Though it is very limited and cannot be counted as true multiple dispatch.


Right.  All the parameters in a dispatching call to such a case must
resolve to the _same_ type (IIRC) and so it isn't "multiple" dispatch
at all.  True multiple dispatch occurs when such profiles can be
called where the parameters resolve to different types (often not even
in the same branch of the type hierarchy) and the correct method is
dynamically invoked (1,2).


/Jon

1. For an example of of multiple dispatch, see generic functions,
   method resolution and dispatch in CLOS:

http://www.lispworks.com/reference/HyperSpec/Body/07_f.htm
http://www.lispworks.com/reference/HyperSpec/Body/07_ff.htm


2. Overloading gives a kind of static version of this.

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Ada 2005?

[Dmitry A. Kazakov]

On 21 Dec 2004 12:10:21 -0500, jayessay wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On 20 Dec 2004 18:44:14 -0500, jayessay wrote:
>> 
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>> Copy is a friend, but they are not methods. C++ does not support multiple
>>>> dispatch.
>>> 
>>> Yes, but to be clear, neither does Ada.
>> 
>> Surprisingly, but it does:
>> 
>> procedure Foo (X, Y : Some_Tagged_Type); -- This is legal
>> 
>> Though it is very limited and cannot be counted as true multiple dispatch.
> 
> Right.  All the parameters in a dispatching call to such a case must
> resolve to the _same_ type (IIRC) and so it isn't "multiple" dispatch
> at all.  True multiple dispatch occurs when such profiles can be
> called where the parameters resolve to different types (often not even
> in the same branch of the type hierarchy) and the correct method is
> dynamically invoked (1,2).
> 
> 1. For an example of of multiple dispatch, see generic functions,
>    method resolution and dispatch in CLOS:
> 
> http://www.lispworks.com/reference/HyperSpec/Body/07_f.htm
> http://www.lispworks.com/reference/HyperSpec/Body/07_ff.htm

The problem with MD is not target method resolution, which is quite
trivial, but safety in presence of inheritance with combinatorial explosion
of target methods to override. I doubt that CLOS seriously approaches the
problem. Consider Ada. To provide MD on independent type hierarchies, you
should relax freezing rules for primitive operations. Doing so you have a
great problem of keeping the dispatching table consistent.

> 2. Overloading gives a kind of static version of this.

... being absolutely unsafe.

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

Re: Ada 2005?

[jayessay]

"Alexander E. Kopilovich" <aek@VB1162.spb.edu> writes:

> jayessay wrote:
> 
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> [...]
> > > The point is that:
> > > 
> > > 1. Prefix notation is misleading
> >
> > Not to mention inflexible and limiting.
> 
> And how about the following alternative (which was posted to Ada-Comment in
> June 2003) ?

<proposal for including special syntax for "distinguished parameter"
method call>

IMO, this (and the apparent version in AI-252) is a bad idea with no
technical merit, with significant CogSci downside, and more than
likely the result of a misguided "marketing idea".


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Ada 2005?

[Brian May]

>>>>> "jayessay" == jayessay  <nospam@foo.com> writes:

    jayessay> I haven't read this either.  That said, I hope it does
    jayessay> not in any way change the basic Ada precept of keeping
    jayessay> separate namespace/module construction and
    jayessay> class/type/method definition.  The "distinguished
    jayessay> parameter" notion of other "typical class based OO
    jayessay> object models" and the typical conflation of classes and
    jayessay> namespaces that goes with it is actually a bad idea and
    jayessay> broken concept.

I am curious: In what way do you consider the "distinguished
parameter" and the "conflation of classes and namespaces" as broken
concepts?
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Ada 2005?

[jayessay]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 21 Dec 2004 12:10:21 -0500, jayessay wrote:
> 
> > 1. For an example of of multiple dispatch, see generic functions,
> >    method resolution and dispatch in CLOS:
> > 
> > http://www.lispworks.com/reference/HyperSpec/Body/07_f.htm
> > http://www.lispworks.com/reference/HyperSpec/Body/07_ff.htm
> 
> The problem with MD is not target method resolution, which is quite
> trivial, but safety in presence of inheritance with combinatorial
> explosion of target methods to override

Method combination and consistency is part of method resolution by any
reasonable assesment.


> I doubt that CLOS seriously approaches the problem.

That's an odd statement, and it is just uninformed opinion which
happens to be factually incorrect.  If you really would like to
understand the issues you should read the hyperspec sections noted
above as a start.  This will give you a programmer's (user's) view of
things albeit from a language specification angle.

More information as to the what, hows, and wherefores can be found in
(1) and further insight and rationale is detailed in the MOP (2).

It's worth noting that CLOS method combination is actually
programmable.  There are several versions supplied as part of the
specification (including the 'standard method combination'), but the
protocol and semantics of how to define others is also defined and
specified.


/Jon

1. Common Lisp the Language, second edition; Guy Steele

2. The Art of the Metaobject Protocol; Gregor Kiczales, Jim Rivieres,
   Daniel Bobrow

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Ada 2005?

[Dmitry A. Kazakov]

On 21 Dec 2004 16:42:58 -0500, jayessay wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On 21 Dec 2004 12:10:21 -0500, jayessay wrote:
>> 
>>> 1. For an example of of multiple dispatch, see generic functions,
>>>    method resolution and dispatch in CLOS:
>>> 
>>> http://www.lispworks.com/reference/HyperSpec/Body/07_f.htm
>>> http://www.lispworks.com/reference/HyperSpec/Body/07_ff.htm
>> 
>> The problem with MD is not target method resolution, which is quite
>> trivial, but safety in presence of inheritance with combinatorial
>> explosion of target methods to override
> 
> Method combination and consistency is part of method resolution by any
> reasonable assesment.

Yes

>> I doubt that CLOS seriously approaches the problem.
> 
> That's an odd statement, and it is just uninformed opinion which
> happens to be factually incorrect.

Maybe, but the very first page introduces "no-applicable-method". It is a
non-starter for me. In my view the goal of safe MD design is to make
dispatch failures impossible (checked at compile time). BTW, I am deeply
unsatisfied with Ada's "MD" raising run-time exceptions. It is tolerable
because there was no better way, and only as an intermediate state to be
replaced by a "right" MD in the future.

> If you really would like to
> understand the issues you should read the hyperspec sections noted
> above as a start.  This will give you a programmer's (user's) view of
> things albeit from a language specification angle.
>
> More information as to the what, hows, and wherefores can be found in
> (1) and further insight and rationale is detailed in the MOP (2).
> 
> It's worth noting that CLOS method combination is actually
> programmable.  There are several versions supplied as part of the
> specification (including the 'standard method combination'), but the
> protocol and semantics of how to define others is also defined and
> specified.

I don't think it is a good idea. I believe that there must be one right
way. Though, there might be some variations, in the case of commutative
methods for example. But they should be "projections" of the main schemata.
I really, wouldn't allow programmers to play with fire.

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

Re: Ada 2005?

[Larry Kilgallen]

In article <1750748.eDONUVZfBc@linux1.krischik.com>, Martin Krischik <martin@krischik.com> writes:
> jimmaureenrogers@worldnet.att.net wrote:
> 
>> There are actually some other small differences between "struct" and
>> "class" in C++.
>> In a "struct" all members are public by default, while in a "class" all
>> members are private by default.
> 
> But that is exactly what I said. 
> 
> For those who can't read regular expression
> 
> is you replace "class X {"  with "struct X { private :" then nothing
> changes.

I was under the impression the discussions here were to be in English
or Ada, not in some other syntax from particular platforms.

Re: Ada 2005?

[Martin Krischik]

Larry Kilgallen wrote:

> In article <1750748.eDONUVZfBc@linux1.krischik.com>, Martin Krischik
> <martin@krischik.com> writes:
>> jimmaureenrogers@worldnet.att.net wrote:
>> 
>>> There are actually some other small differences between "struct" and
>>> "class" in C++.
>>> In a "struct" all members are public by default, while in a "class" all
>>> members are private by default.
>> 
>> But that is exactly what I said.
>> 
>> For those who can't read regular expression
>> 
>> is you replace "class X {"  with "struct X { private :" then nothing
>> changes.
> 
> I was under the impression the discussions here were to be in English
> or Ada, not in some other syntax from particular platforms.

You are right. Where is the problem?

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada 2005?

[Larry Kilgallen]

In article <22079486.hMfpcNLlTu@linux1.krischik.com>, Martin Krischik <martin@krischik.com> writes:
> Larry Kilgallen wrote:
> 
>> In article <1750748.eDONUVZfBc@linux1.krischik.com>, Martin Krischik
>> <martin@krischik.com> writes:
>>> jimmaureenrogers@worldnet.att.net wrote:
>>> 
>>>> There are actually some other small differences between "struct" and
>>>> "class" in C++.
>>>> In a "struct" all members are public by default, while in a "class" all
>>>> members are private by default.
>>> 
>>> But that is exactly what I said.
>>> 
>>> For those who can't read regular expression
>>> 
>>> is you replace "class X {"  with "struct X { private :" then nothing
>>> changes.
>> 
>> I was under the impression the discussions here were to be in English
>> or Ada, not in some other syntax from particular platforms.
> 
> You are right. Where is the problem?

Someone making a post that expects people to read "regular expression".

Re: Ada 2005?

[Martin Krischik]

Larry Kilgallen wrote:

> In article <22079486.hMfpcNLlTu@linux1.krischik.com>, Martin Krischik
> <martin@krischik.com> writes:
>> Larry Kilgallen wrote:
>> 
>>> In article <1750748.eDONUVZfBc@linux1.krischik.com>, Martin Krischik
>>> <martin@krischik.com> writes:
>>>> jimmaureenrogers@worldnet.att.net wrote:
>>>> 
>>>>> There are actually some other small differences between "struct" and
>>>>> "class" in C++.
>>>>> In a "struct" all members are public by default, while in a "class"
>>>>> all members are private by default.
>>>> 
>>>> But that is exactly what I said.
>>>> 
>>>> For those who can't read regular expression
>>>> 
>>>> is you replace "class X {"  with "struct X { private :" then nothing
>>>> changes.
>>> 
>>> I was under the impression the discussions here were to be in English
>>> or Ada, not in some other syntax from particular platforms.
>> 
>> You are right. Where is the problem?
> 
> Someone making a post that expects people to read "regular expression".

You are right and I did see my error and correted it by translating the
regex to plain english. There are not <sarkasm> marks around the sentence
"For those who can't read regular expression". It was meant as it stays
there and no offence was meant.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada 2005?

[jayessay]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> >> I doubt that CLOS seriously approaches the problem.
> > 
> > That's an odd statement, and it is just uninformed opinion which
> > happens to be factually incorrect.
> 
> Maybe

There is no "maybe" about it.  You clearly have not studied this and
therefore any comment you make on it is indeed uninformed opinion.


> , but the very first page introduces "no-applicable-method". It is a
> non-starter for me. In my view the goal of safe MD design is to make
> dispatch failures impossible (checked at compile time).

For true MD, that requires solving the halting problem in any Turing
complete setting.  Good luck on your hopeless quest.  OTOH, if you
restrict things enough, what you are talking about is simply
overloading.  Ada already has that.


> BTW, I am deeply unsatisfied with Ada's "MD" raising run-time
> exceptions. It is tolerable because there was no better way, and
> only as an intermediate state to be replaced by a "right" MD in the
> future.

First, raising runtime exceptions is not only reasonable, it is the
only thing possible in non trivial situations.

Second, Ada has no MD.  That is a fact.  I make the prediction that it
will never have an MD.  Not because it is not possible to get "right"
(a context sensitive notion if there ever was one), but because the
language simply does not have the proper machinery to support it.  You
basically require a MOP and that will never be added to Ada for many
reasons, not the least of which is that it would simply be "too hard".


> > If you really would like to
> > understand the issues you should read the hyperspec sections noted
> > above as a start.  This will give you a programmer's (user's) view of
> > things albeit from a language specification angle.
> >
> > More information as to the what, hows, and wherefores can be found in
> > (1) and further insight and rationale is detailed in the MOP (2).
> > 
> > It's worth noting that CLOS method combination is actually
> > programmable.  There are several versions supplied as part of the
> > specification (including the 'standard method combination'), but the
> > protocol and semantics of how to define others is also defined and
> > specified.
> 
> I don't think it is a good idea. I believe that there must be one right
> way.

There is no such thing as "one right way" in any non trivial problem
solving context.  It has long been known in problem solving (not just
computation) that multiple ways of attacking a problem, and shifting
among those ways, tends to yield the the better solutions.

I thought Ada folks understood this (Ada being a multiparadigm
language).  The position you state looks much more like a Pythonista,
where the above is not just a mantra but the central dogmatism.  If
you like the idea of "the one right way" for any
computational/software issue, Python is definitely the place to be.
Not that they're "right", but they believe they are.


> Though, there might be some variations, in the case of commutative
> methods for example. But they should be "projections" of the main
> schemata.

I've seen situations where this claim is completely at odds with
reality.  Hence, your position would remove expressivity and force
programmers into pounding square pegs into round holes.  This is
_always_ a bad thing, though it is something that most language models
do impose.


> I really, wouldn't allow programmers to play with fire.

What you call "playing with fire", is simply another tool, with a well
defined and specified protocol.  Can it be abused?  Yes.  Does it
require someone above average to use it properly?  Most likely.  Can
it be exactly the right thing for an elegant solution to a thorny
problem?  Yes.

Being a denizen of cla I realize you are probably a B&D software
development proponent, and I suppose in certain contexts (mediocre
programmers, large beauracracies) your sentiment here makes sense.
But in general it is a bad idea which at best tends to produce what I
like to term "superior mediocrity" (which, to be fair, often wins big
in the "marketplace").


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Ada 2005?

[Dmitry A. Kazakov]

On 22 Dec 2004 13:02:26 -0500, jayessay wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>>> I doubt that CLOS seriously approaches the problem.
>>> 
>>> That's an odd statement, and it is just uninformed opinion which
>>> happens to be factually incorrect.
>> 
>> Maybe
> 
> There is no "maybe" about it.  You clearly have not studied this and
> therefore any comment you make on it is indeed uninformed opinion.
> 
>> , but the very first page introduces "no-applicable-method". It is a
>> non-starter for me. In my view the goal of safe MD design is to make
>> dispatch failures impossible (checked at compile time).
> 
> For true MD, that requires solving the halting problem in any Turing
> complete setting.

What about any proof? [ Hint: Ada is statically typed, freezing rules do
not allow dynamic declaration of primitive operations. ]

> Good luck on your hopeless quest.  OTOH, if you
> restrict things enough, what you are talking about is simply
> overloading.  Ada already has that.

There is no way to restrict dynamic dispatch to make overloading of it.
Care to elaborate?

>> BTW, I am deeply unsatisfied with Ada's "MD" raising run-time
>> exceptions. It is tolerable because there was no better way, and
>> only as an intermediate state to be replaced by a "right" MD in the
>> future.
> 
> First, raising runtime exceptions is not only reasonable, it is the
> only thing possible in non trivial situations.

Again, the goal of proper design is to have no such situations. Dispatch
tables are finite in presence of finite number of types and finite number
of actual parameters. It is quite trivial to check that all cells in each
table are defined.

> Second, Ada has no MD. That is a fact.

MD = "more to have than one dispatching parameter".

So clearly, Ada has MD.

> I make the prediction that it
> will never have an MD.  Not because it is not possible to get "right"
> (a context sensitive notion if there ever was one), but because the
> language simply does not have the proper machinery to support it.  You
> basically require a MOP and that will never be added to Ada for many
> reasons, not the least of which is that it would simply be "too hard".

I do not see any relation. To have any meta language is a wrong idea
anyway. Either generics or parameter pattern matching, anything like that
just indicates language infancy. [Many Ada people disagree with me]

>>> If you really would like to
>>> understand the issues you should read the hyperspec sections noted
>>> above as a start.  This will give you a programmer's (user's) view of
>>> things albeit from a language specification angle.
>>>
>>> More information as to the what, hows, and wherefores can be found in
>>> (1) and further insight and rationale is detailed in the MOP (2).
>>> 
>>> It's worth noting that CLOS method combination is actually
>>> programmable.  There are several versions supplied as part of the
>>> specification (including the 'standard method combination'), but the
>>> protocol and semantics of how to define others is also defined and
>>> specified.
>> 
>> I don't think it is a good idea. I believe that there must be one right
>> way.
> 
> There is no such thing as "one right way" in any non trivial problem
> solving context. It has long been known in problem solving (not just
> computation) that multiple ways of attacking a problem, and shifting
> among those ways, tends to yield the the better solutions.

Non-trivial problem is one for which a particular person knows no solution.
Once solved it becomes trivial.
 
> I thought Ada folks understood this (Ada being a multiparadigm
> language).  The position you state looks much more like a Pythonista,
> where the above is not just a mantra but the central dogmatism.  If
> you like the idea of "the one right way" for any
> computational/software issue, Python is definitely the place to be.
> Not that they're "right", but they believe they are.

I cannot speak for Ada folks...

>> Though, there might be some variations, in the case of commutative
>> methods for example. But they should be "projections" of the main
>> schemata.
> 
> I've seen situations where this claim is completely at odds with
> reality.  Hence, your position would remove expressivity and force
> programmers into pounding square pegs into round holes.

Yes, this is exactly Ada's way (tm). Moreover, both pegs and the plate are
made of hard steel. So the programmer will spend a lot of time pounding on.
This has an important educational effect. Maybe next time [s]he will think
first.

> This is
> _always_ a bad thing, though it is something that most language models
> do impose.
> 
>> I really, wouldn't allow programmers to play with fire.
> 
> What you call "playing with fire", is simply another tool, with a well
> defined and specified protocol.  Can it be abused?  Yes.  Does it
> require someone above average to use it properly?  Most likely.  Can
> it be exactly the right thing for an elegant solution to a thorny
> problem?  Yes.

Bottom line:
*rejected*

> Being a denizen of cla I realize you are probably a B&D software
> development proponent, and I suppose in certain contexts (mediocre
> programmers, large beauracracies) your sentiment here makes sense.
> But in general it is a bad idea which at best tends to produce what I
> like to term "superior mediocrity" (which, to be fair, often wins big
> in the "marketplace").

You have to understand a very simple thing. You cannot get excellent
programmers for each project. They are precious goods. They make errors
too. specially if the language requires permanent attention and high
concentration to each typed character. So you cannot rely on excellence in
mass production. You should do on technology. And technology is the
language. Superior mediocrity? Yes, sure.

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

Re: Ada 2005?

[jayessay]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 22 Dec 2004 13:02:26 -0500, jayessay wrote:
> 
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> > 
> >>>> I doubt that CLOS seriously approaches the problem.
> >>> 
> >>> That's an odd statement, and it is just uninformed opinion which
> >>> happens to be factually incorrect.
> >> 
> >> Maybe
> > 
> > There is no "maybe" about it.  You clearly have not studied this and
> > therefore any comment you make on it is indeed uninformed opinion.
> > 
> >> , but the very first page introduces "no-applicable-method". It is a
> >> non-starter for me. In my view the goal of safe MD design is to make
> >> dispatch failures impossible (checked at compile time).
> > 
> > For true MD, that requires solving the halting problem in any Turing
> > complete setting.
> 
> What about any proof?

One Hint: I/O.  There are many others.


> [ Hint: Ada is statically typed, freezing rules do
> not allow dynamic declaration of primitive operations. ]

Irrelevant to the above point.

However, these rules really have nothing to do with restricting
"dynamic declarations" (Ada is static and so of course there are no
dynamic declarations at all).  The rules are about where the
representation of the entity is frozen and can no longer be added to
even statically.  One consequence of these rules is that they remove a
lot of the potential good from the separation of name space and class
constructs.


> > Good luck on your hopeless quest.  OTOH, if you
> > restrict things enough, what you are talking about is simply
> > overloading.  Ada already has that.
> 
> There is no way to restrict dynamic dispatch to make overloading of it.
> Care to elaborate?

"things" /= DD


> >> BTW, I am deeply unsatisfied with Ada's "MD" raising run-time
> >> exceptions. It is tolerable because there was no better way, and
> >> only as an intermediate state to be replaced by a "right" MD in the
> >> future.
> > 
> > First, raising runtime exceptions is not only reasonable, it is the
> > only thing possible in non trivial situations.
> 
> Again, the goal of proper design is to have no such situations.

Then you should not have dynamic dispatch at all.  Actually, that is a
defensible position - at least for some class of problems.


> Dispatch tables are finite in presence of finite number of types and
> finite number of actual parameters. It is quite trivial to check
> that all cells in each table are defined.

That's completely irrelevant to the problem.  The issue is whether any
given actual call will find a match in the table.  The tables are
trivial, it is the flow analysis that is (in the general case)
impossible.


> > Second, Ada has no MD. That is a fact.
> 
> MD = "more to have than one dispatching parameter".
> 
> So clearly, Ada has MD.

Ah, so you define it away.  MD = "Multiple Dispatch" in the orignal
context of this thread which is /= more than one dispatching
parameter.  This should be obvious.  Ada does not have MD, to argue
otherwise just makes you look silly.


> To have any meta language is a wrong idea anyway.

MOP is not a meta language, it is a meta _protocol_ for object models.
The only extent example (that I am aware of) is CLOS, but there could
be others.

OTOH, I'm not sure why a "meta language" is somehow an intrinsically
"wrong idea".  There are several very important areas where such
things are not only the right idea, but provide the _only_ way to do
something.

If you were more open minded and less dogmatic in outlook, you would
have a much better chance of learning and understanding the value of
many things not matching your preconceived notions.


> Either generics or parameter pattern matching, anything like that
> just indicates language infancy.

What has this to do with a "meta language"?  And what in the world is
"language infancy"?


> Non-trivial problem is one for which a particular person knows no solution.
> Once solved it becomes trivial.

This is clearly (even trivially) incorrect.  First, whether a
particular person knows a solution or not is totally irrelevant to
whether a problem is difficult, easy, trivial, non trivial, etc.  This
should be obvious (as such qualifiers are pretty much defined by how
many people can work the problem and how much effort it takes to work
it.)

Second, there are plenty of solved problems that are highly non
trivial in nature.  And, of course, there are (literally) countless
problems that are trivial to solve.


> > I've seen situations where this claim is completely at odds with
> > reality.  Hence, your position would remove expressivity and force
> > programmers into pounding square pegs into round holes.
> 
> Yes, this is exactly Ada's way (tm). Moreover, both pegs and the plate are
> made of hard steel. So the programmer will spend a lot of time pounding on.
> This has an important educational effect. Maybe next time [s]he will think
> first.

I don't think this is "Ada's way".  I sure hope it isn't because it is
the dumbest thing anyone could advocate.  The "education" any
intelligent person would get from this would be, "this language is an
extremely poor means for expressing elegant correct solutions."
That's pretty damning.


> > What you call "playing with fire", is simply another tool, with a well
> > defined and specified protocol.  Can it be abused?  Yes.  Does it
> > require someone above average to use it properly?  Most likely.  Can
> > it be exactly the right thing for an elegant solution to a thorny
> > problem?  Yes.
> 
> Bottom line:
> *rejected*

Bottom line: You will not be able to solve a large class of (non
trivial) problems as they will require far too much work to find a
means to express their solution.  In theory (of course) they could be
worked, but in practice they won't.  Which is fine.  There are plenty
of mundane problems that need simple perfunctory solutions.


> > Being a denizen of cla I realize you are probably a B&D software
> > development proponent, and I suppose in certain contexts (mediocre
> > programmers, large beauracracies) your sentiment here makes sense.
> > But in general it is a bad idea which at best tends to produce what I
> > like to term "superior mediocrity" (which, to be fair, often wins big
> > in the "marketplace").
> 
> You have to understand a very simple thing. You cannot get excellent
> programmers for each project. They are precious goods. They make errors
> too. specially if the language requires permanent attention and high
> concentration to each typed character. So you cannot rely on excellence in
> mass production. You should do on technology. And technology is the
> language. Superior mediocrity? Yes, sure.

What a sad attitude.  And not even correct, if given a more
enlightened position.  Hints: 1. The number and severity of errors and
bad solutions are in direct relation to how far the language used in
expressing the "solutions" is from the language of the problem
domain. 2. libraries/class systems are not languages. 3. domain
specific languages are very close to the problem space.  4. Use your
"precious goods" to work on the "right" level of the problem.
5. Enjoy how much happier you (and your customers) are with your
mediocre people.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Ada 2005?

[conradwt]

Hi, thanks for all your comments.  It's simply clearer to me as to what
you're doing.  Now, in regards to your example, a struct in C and C++
are very different.  For example, a struct C cannot contain functions
within its declaration.  Most programmers in the C++ community would
use a class to create C++ object types that contain methods because the
struct keyword is somewhat confusing when moving from C to C++ (i.e. do
you mean a C struct or a C++ struct).  Thus, I think that they should
not have extended 'struct' in regards to the C++ language.  I feel that
one shouldn'e get bogged down in the details of a languages syntax but
instead concentrate on the problem that they are trying to solve.  Then
making easier for one easily solve that problem in language A.  In
saying this, I feel that Smalltalk definitely has done an excellent job
in this regard.  This is from my experience of using C++, Ada, Java,
C#, VB, Eiffel, and Smalltalk.

-Conrad

Re: Ada 2005?

[Pascal Obry]

conradwt@runbox.com writes:

> not have extended 'struct' in regards to the C++ language.  I feel that
> one shouldn'e get bogged down in the details of a languages syntax but
> instead concentrate on the problem that they are trying to solve.  Then
> making easier for one easily solve that problem in language A.  

That's only part of the work. This is true if you are the only one to work in
a project and the project is not critical. Otherwise you also need to take
into account the maintenance and stability of the applications. And in this
case there is some other consideration than "making easier for one easily
solve that problem"!

> In saying this, I feel that Smalltalk definitely has done an excellent job
> in this regard.  This is from my experience of using C++, Ada, Java,
> C#, VB, Eiffel, and Smalltalk.

I also know know all of them.

  - Ada / Eiffel : Ok for large, stable and to ease maintenance
  - C++          : Ok for large software, but be prepared to use a debugger,
                   ask for more money and forget about the deadlines :)
  - C#, Java     : If you want to play with the language "du jour", those are
                   languages that have brought just nothing to the software
                   world! IT hype !
  - VB           : Is that really a language :) ?
  - Smalltalk    : Don't know what to say. When you use Smalltalk you have a
                   good feeling, but I won't use it in any important projects.
                   Certainly good to build prototypes.

Pascal.

-- 

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

Re: Ada 2005?

[Dmitry A. Kazakov]

On 23 Dec 2004 13:09:34 -0500, jayessay wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On 22 Dec 2004 13:02:26 -0500, jayessay wrote:
>> 
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>>>> I doubt that CLOS seriously approaches the problem.
>>>>> 
>>>>> That's an odd statement, and it is just uninformed opinion which
>>>>> happens to be factually incorrect.
>>>> 
>>>> Maybe
>>> 
>>> There is no "maybe" about it.  You clearly have not studied this and
>>> therefore any comment you make on it is indeed uninformed opinion.
>>> 
>>>> , but the very first page introduces "no-applicable-method". It is a
>>>> non-starter for me. In my view the goal of safe MD design is to make
>>>> dispatch failures impossible (checked at compile time).
>>> 
>>> For true MD, that requires solving the halting problem in any Turing
>>> complete setting.
>> 
>> What about any proof?
> 
> One Hint: I/O.  There are many others.

You should define MD in a way which would not involve the Great Theory of
All, otherwise anything would become unsolvable...

>> [ Hint: Ada is statically typed, freezing rules do
>> not allow dynamic declaration of primitive operations. ]
> 
> Irrelevant to the above point.
> 
> However, these rules really have nothing to do with restricting
> "dynamic declarations" (Ada is static and so of course there are no
> dynamic declarations at all).

This is wrong. Not all dynamic declarations are of primitive operations.
Ada is a statically *typed* language.

> The rules are about where the
> representation of the entity is frozen and can no longer be added to
> even statically.  One consequence of these rules is that they remove a
> lot of the potential good from the separation of name space and class
> constructs.

I do not know what you mean here... 

>>> Good luck on your hopeless quest.  OTOH, if you
>>> restrict things enough, what you are talking about is simply
>>> overloading.  Ada already has that.
>> 
>> There is no way to restrict dynamic dispatch to make overloading of it.
>> Care to elaborate?
> 
> "things" /= DD

Are we talking about DD or "things"?

>>>> BTW, I am deeply unsatisfied with Ada's "MD" raising run-time
>>>> exceptions. It is tolerable because there was no better way, and
>>>> only as an intermediate state to be replaced by a "right" MD in the
>>>> future.
>>> 
>>> First, raising runtime exceptions is not only reasonable, it is the
>>> only thing possible in non trivial situations.
>> 
>> Again, the goal of proper design is to have no such situations.
> 
> Then you should not have dynamic dispatch at all.

Where that follows from?

>> Dispatch tables are finite in presence of finite number of types and
>> finite number of actual parameters. It is quite trivial to check
>> that all cells in each table are defined.
> 
> That's completely irrelevant to the problem.  The issue is whether any
> given actual call will find a match in the table.  The tables are
> trivial, it is the flow analysis that is (in the general case)
> impossible.

We have different general cases. Ada is not a dynamically typed language.
The reason for that was: not to have your "general case". Back to Ada's
case, it is trivial to find a match. Moreover it requires bounded time.
Otherwise, I guess polymorphic calls would never be adopted in Ada. The
problems with implementation of MD in Ada lie elsewhere.

>>> Second, Ada has no MD. That is a fact.
>> 
>> MD = "more to have than one dispatching parameter".
>> 
>> So clearly, Ada has MD.
> 
> Ah, so you define it away.  MD = "Multiple Dispatch" in the orignal
> context of this thread which is /= more than one dispatching
> parameter.  This should be obvious.  Ada does not have MD, to argue
> otherwise just makes you look silly.

Care to give another definition of MD?

>> To have any meta language is a wrong idea anyway.
> 
> MOP is not a meta language, it is a meta _protocol_ for object models.
> The only extent example (that I am aware of) is CLOS, but there could
> be others.
> 
> OTOH, I'm not sure why a "meta language" is somehow an intrinsically
> "wrong idea".

Because it is difficult to talk two languages for a person who is not
"above average" or else does not suffer from split personality...

>>> I've seen situations where this claim is completely at odds with
>>> reality.  Hence, your position would remove expressivity and force
>>> programmers into pounding square pegs into round holes.
>> 
>> Yes, this is exactly Ada's way (tm). Moreover, both pegs and the plate are
>> made of hard steel. So the programmer will spend a lot of time pounding on.
>> This has an important educational effect. Maybe next time [s]he will think
>> first.
> 
> I don't think this is "Ada's way".  I sure hope it isn't because it is
> the dumbest thing anyone could advocate.  The "education" any
> intelligent person would get from this would be, "this language is an
> extremely poor means for expressing elegant correct solutions."

An *intelligent* person would notice difference in shapes. The level of
intelligence is inversely proportional to the time spent on pounding...

>>> What you call "playing with fire", is simply another tool, with a well
>>> defined and specified protocol.  Can it be abused?  Yes.  Does it
>>> require someone above average to use it properly?  Most likely.  Can
>>> it be exactly the right thing for an elegant solution to a thorny
>>> problem?  Yes.
>> 
>> Bottom line:
>> *rejected*
> 
> Bottom line: You will not be able to solve a large class of (non
> trivial) problems as they will require far too much work to find a
> means to express their solution.

Which quote "would require someone above average to use it properly". How
much above?

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

Re: Ada 2005?

[Martin Krischik]

conradwt@runbox.com wrote:

> Hi, thanks for all your comments.  It's simply clearer to me as to what
> you're doing.  Now, in regards to your example, a struct in C and C++
> are very different. For example, a struct C cannot contain functions
> within its declaration.  Most programmers in the C++ community would
> use a class to create C++ object types that contain methods because the
> struct keyword is somewhat confusing when moving from C to C++ (i.e. do
> you mean a C struct or a C++ struct). 

That is indeed true. But somehow typical for C/C++. Originally designed to
be slim and lightweight they have become the total opposite.

The C99 standart if only a few pages short of Ada95 - But Ada has tasking
and object orientation included. And the C++ standart is +200 pages on
Ada95.

> Thus, I think that they should 
> not have extended 'struct' in regards to the C++ language.

YES! i.E. When has a struct/class a virtual functions table? In Ada it is
clear: when you us the keyword tagged. In C++: when there is at least on
virtual function - something difficult to dertemine.

But more difficult: When can you use dynamic_cast <> ;-)

In Ada: allways. even casting integers is dynamicly checked. I think here
was a great opertunity missed:

long x();

short Y = dynamic_cast <short> x();

(And Yes, I do have a template for this - its called numerc_cast <From, To>,
actually quite tricky to implement)

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada User Journal

[Florian Weimer]

* Thomas H�hn:

> Florian Weimer wrote:
>
>>>Don't know where you saw that. For me it looks like you have to be a member
>>>of Ada-Deutschland (http://ada-deutschland.de). Have I missed something?
>> Ada Deutschland is just a working group within GI, AFAICS.
>
> From http://ada-deutschland.de/foerder/foerder.html:

> So it seems to be independent (especially money-wise), but does support 
> the Ada subgroup of the GI (not necessarily the GI as a whole).

Thanks.  I was misled because the only page that offered some kind of
membership I discovered on the site was a GI mailing list.

Re: Ada 2005?

[jayessay]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:


> On 23 Dec 2004 13:09:34 -0500, jayessay wrote:
> >>> For true MD, that requires solving the halting problem in any Turing
> >>> complete setting.
> >> 
> >> What about any proof?
> > 
> > One Hint: I/O.  There are many others.
> 
> You should define MD in a way which would not involve the Great Theory of
> All, otherwise anything would become unsolvable...

Your comment is irrelevant on a number of counts.  I/O is hardly the
"Great Theory of All", it is simply a part of the real world.  As
another hint: classwide parameters.


> > However, these rules really have nothing to do with restricting
> > "dynamic declarations" (Ada is static and so of course there are no
> > dynamic declarations at all).
> 
> This is wrong.

So where can you _declare_ a new entity at runtime?


> Not all dynamic declarations are of primitive operations.
> Ada is a statically *typed* language.

Yeah.  So?


> >>>> BTW, I am deeply unsatisfied with Ada's "MD" raising run-time
> >>>> exceptions. It is tolerable because there was no better way, and
> >>>> only as an intermediate state to be replaced by a "right" MD in the
> >>>> future.
> >>> 
> >>> First, raising runtime exceptions is not only reasonable, it is the
> >>> only thing possible in non trivial situations.
> >> 
> >> Again, the goal of proper design is to have no such situations.
> > 
> > Then you should not have dynamic dispatch at all.
> 
> Where that follows from?

Try to figure it out.  It will do you good.


> > That's completely irrelevant to the problem.  The issue is whether any
> > given actual call will find a match in the table.  The tables are
> > trivial, it is the flow analysis that is (in the general case)
> > impossible.
> 
> We have different general cases. Ada is not a dynamically typed language.
> The reason for that was: not to have your "general case".

The general case is simply one where you cannot determine at compile
time things like uninitialized variables, the specific type of a class
wide variable at any given point in time, etc.  These still apply to
Ada.  I'm not sure you actually understand any of this as you keep
making these irrelevant or incorrect claims.


> case, it is trivial to find a match. Moreover it requires bounded time.
> Otherwise, I guess polymorphic calls would never be adopted in Ada. The
> problems with implementation of MD in Ada lie elsewhere.

MD is irrelevant to to this point, which is the need for runtime
exceptions.  Ada has these and you can easily get them with it's
polymorphic calls (which cannot be MD), i.e., Constraint_Error can be
raised.  What's more, some of these constraint errors are _exactly_
the equivalent of "method not found" (which is similar to, but _not_
the same as, no-applicable-method).  It is disappointing that you
don't understand this.


> >>> Second, Ada has no MD. That is a fact.
> >> 
> >> MD = "more to have than one dispatching parameter".
> >> 
> >> So clearly, Ada has MD.
> > 
> > Ah, so you define it away.  MD = "Multiple Dispatch" in the orignal
> > context of this thread which is /= more than one dispatching
> > parameter.  This should be obvious.  Ada does not have MD, to argue
> > otherwise just makes you look silly.
> 
> Care to give another definition of MD?

No, the original, as I noted here was and is the one under discussion
and it is quite proper.  In particular it means that Ada has no MD.
There is nothing controversial about this, and several books
(including even the Rationale) mention this and discuss how an Ada
programmer can achieve a simple version of MD by rolling their own via
redispatch.


> > OTOH, I'm not sure why a "meta language" is somehow an intrinsically
> > "wrong idea".
> 
> Because it is difficult to talk two languages for a person who is not
> "above average" or else does not suffer from split personality...

That's so poor an argument/justification that it is not worth
discussing.  It borders on "internet kook" talk.  More on this below.


> >>> I've seen situations where this claim is completely at odds with
> >>> reality.  Hence, your position would remove expressivity and force
> >>> programmers into pounding square pegs into round holes.
> >> 
> >> Yes, this is exactly Ada's way (tm). Moreover, both pegs and the plate
> >> are made of hard steel. So the programmer will spend a lot of time
> >> pounding on.  This has an important educational effect. Maybe next time
> >> [s]he will thinkfirst.
> > 
> > I don't think this is "Ada's way".  I sure hope it isn't because it is
> > the dumbest thing anyone could advocate.  The "education" any
> > intelligent person would get from this would be, "this language is an
> > extremely poor means for expressing elegant correct solutions."
> 
> An *intelligent* person would notice difference in shapes.

The point is an elegant solution cannot be expressed cleanly without
recourse to pounding because the language lacks the proper
expressivity.  An intelligent person will notice and be annoyed that
they are being required by the tool to pound away and/or to abandon
their solution for a lesser one.  Which leads to,


> The level of intelligence is inversely proportional to the time
> spent on pounding...

Yes.  This means that in this case, intelligent people will _abandon_
the tool (in this case the language) so that the elegant correct
solution can be expressed without pounding.


> >>> What you call "playing with fire", is simply another tool, with a well
> >>> defined and specified protocol.  Can it be abused?  Yes.  Does it
> >>> require someone above average to use it properly?  Most likely.  Can
> >>> it be exactly the right thing for an elegant solution to a thorny
> >>> problem?  Yes.
> >> 
> >> Bottom line:
> >> *rejected*
> > 
> > Bottom line: You will not be able to solve a large class of (non
> > trivial) problems as they will require far too much work to find a
> > means to express their solution.
> 
> Which quote "would require someone above average to use it properly". How
> much above?

The question you pose is (mis)leading and pretty irrelevant.  A
slightly better question would be "how many such people do you need?"
Answer: enough.  This is not a facetious answer as the requirements
will vary from project to project, but typically you will not need
more than a few.  Here is an analogy that is pretty apropos:

Does use of the calculus require an engineer above average to use it
properly?  Most likely.  Can it be exactly the right thing for an
elegant solution to a thorny problem?  Yes.  How much above average
does the engineer need to be?  Depends.  How many of these do you
need?  Enough.  Would any of this in any way suggest to anyone who has
any idea of what they are doing that they should not use the calculus
in these circumstances?  No.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Ada 2005?

[Dmitry A. Kazakov]

On 27 Dec 2004 12:09:03 -0500, jayessay wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On 23 Dec 2004 13:09:34 -0500, jayessay wrote:
>>>>> For true MD, that requires solving the halting problem in any Turing
>>>>> complete setting.
>>>> 
>>>> What about any proof?
>>> 
>>> One Hint: I/O.  There are many others.
>> 
>> You should define MD in a way which would not involve the Great Theory of
>> All, otherwise anything would become unsolvable...
> 
> Your comment is irrelevant on a number of counts.  I/O is hardly the
> "Great Theory of All", it is simply a part of the real world.  As
> another hint: classwide parameters.

If you have no definition, then there is nothing to discuss.

>>> However, these rules really have nothing to do with restricting
>>> "dynamic declarations" (Ada is static and so of course there are no
>>> dynamic declarations at all).
>> 
>> This is wrong.
> 
> So where can you _declare_ a new entity at runtime?

See ARM 3.1.

>> Not all dynamic declarations are of primitive operations.
>> Ada is a statically *typed* language.
> 
> Yeah.  So?

So dispatching is not equivalent to halting problem.

>>> That's completely irrelevant to the problem.  The issue is whether any
>>> given actual call will find a match in the table.  The tables are
>>> trivial, it is the flow analysis that is (in the general case)
>>> impossible.
>> 
>> We have different general cases. Ada is not a dynamically typed language.
>> The reason for that was: not to have your "general case".
> 
> The general case is simply one where you cannot determine at compile
> time things like uninitialized variables,

Class-wide variables cannot be left uninitialized.

> the specific type of a class
> wide variable at any given point in time, etc.

Present us any example of (but not one classified as a bounded error).

>> case, it is trivial to find a match. Moreover it requires bounded time.
>> Otherwise, I guess polymorphic calls would never be adopted in Ada. The
>> problems with implementation of MD in Ada lie elsewhere.
> 
> MD is irrelevant to to this point, which is the need for runtime
> exceptions.

So it has nothing to do with halting problem? Fine. Then what's the point?

> Ada has these and you can easily get them with it's
> polymorphic calls (which cannot be MD), i.e., Constraint_Error can be
> raised.  What's more, some of these constraint errors are _exactly_
> the equivalent of "method not found"

Nope, in Ada it is the equivalent of "method is final and defined to raise
Constraint_Error". It is a fundamentally different case.

>>>>> Second, Ada has no MD. That is a fact.
>>>> 
>>>> MD = "more to have than one dispatching parameter".
>>>> 
>>>> So clearly, Ada has MD.
>>> 
>>> Ah, so you define it away.  MD = "Multiple Dispatch" in the orignal
>>> context of this thread which is /= more than one dispatching
>>> parameter.  This should be obvious.  Ada does not have MD, to argue
>>> otherwise just makes you look silly.
>> 
>> Care to give another definition of MD?
> 
> No, the original, as I noted here was and is the one under discussion
> and it is quite proper.

OK, I'll make it easier for you:

MD /= number of controlling parameters > 1 <=>
1) Exists MD with 1 or 0 controlling parameters; or
2) Dispatching subroutine with n>1 controlling parameters is not MD, but
SD, not D.

Go on!

>>>>> I've seen situations where this claim is completely at odds with
>>>>> reality.  Hence, your position would remove expressivity and force
>>>>> programmers into pounding square pegs into round holes.
>>>> 
>>>> Yes, this is exactly Ada's way (tm). Moreover, both pegs and the plate
>>>> are made of hard steel. So the programmer will spend a lot of time
>>>> pounding on.  This has an important educational effect. Maybe next time
>>>> [s]he will thinkfirst.
>>> 
>>> I don't think this is "Ada's way".  I sure hope it isn't because it is
>>> the dumbest thing anyone could advocate.  The "education" any
>>> intelligent person would get from this would be, "this language is an
>>> extremely poor means for expressing elegant correct solutions."
>> 
>> An *intelligent* person would notice difference in shapes.
> 
> The point is an elegant solution cannot be expressed cleanly without
> recourse to pounding because the language lacks the proper
> expressivity.

or that the person lacks some vital knowledge about software design...

> An intelligent person will notice and be annoyed that
> they are being required by the tool to pound away and/or to abandon
> their solution for a lesser one.

How do you compare solutions? Any metric?

> Which leads to, 
> 
>> The level of intelligence is inversely proportional to the time
>> spent on pounding...
> 
> Yes.  This means that in this case, intelligent people will _abandon_
> the tool (in this case the language) so that the elegant correct
> solution can be expressed without pounding.

Then you are in a wrong group. It seems that people in c.l.a are pretty
unintelligent to keep on using Ada, or maybe, there must be something wrong
with your theory...

>>>>> What you call "playing with fire", is simply another tool, with a well
>>>>> defined and specified protocol.  Can it be abused?  Yes.  Does it
>>>>> require someone above average to use it properly?  Most likely.  Can
>>>>> it be exactly the right thing for an elegant solution to a thorny
>>>>> problem?  Yes.
>>>> 
>>>> Bottom line:
>>>> *rejected*
>>> 
>>> Bottom line: You will not be able to solve a large class of (non
>>> trivial) problems as they will require far too much work to find a
>>> means to express their solution.
>> 
>> Which quote "would require someone above average to use it properly". How
>> much above?
> 
> The question you pose is (mis)leading and pretty irrelevant.

I like irrelevant questions so much...

> A
> slightly better question would be "how many such people do you need?"
> Answer: enough.  This is not a facetious answer as the requirements
> will vary from project to project, but typically you will not need
> more than a few.

Refraining from yet another irrelevant question, I immediately deduce that
"few" = "enough".

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

Re: Ada 2005?

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: Nope, in Ada it is the equivalent of "method is final and defined to raise
: Constraint_Error". It is a fundamentally different case.

What is the fundament, then?
 
:>>> Ah, so you define it away.

Or invent a new one?

:>>> MD = "Multiple Dispatch" in the orignal
:>>> context of this thread which is /= more than one dispatching
:>>> parameter.  This should be obvious.  Ada does not have MD, to argue
:>>> otherwise just makes you look silly.
:>> 
:>> Care to give another definition of MD?
:> 
:> No, the original, as I noted here was and is the one under discussion
:> and it is quite proper.
: 
: OK, I'll make it easier for you:
: 
: MD /= number of controlling parameters > 1 <=>
: 1) Exists MD with 1 or 0 controlling parameters; or
: 2) Dispatching subroutine with n>1 controlling parameters is not MD, but
: SD, not D.

This is a mathematical trick, at best?
Obviously, "more than" in the above sentence isn't only about counting the
number of parameters.  You could equally well say that Ada templates
are recursive because they are when you limit the recursion depth to 0.

What did the makers of GNAT think when they invented the error message,

 "operation can be dispatching in only one type"?

So at the very least there must exists a notion of MD that isn't
available with Ada.


-- Georg

Re: Ada 2005?

[Dmitry A. Kazakov]

On Mon, 27 Dec 2004 21:51:07 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: Nope, in Ada it is the equivalent of "method is final and defined to raise
>: Constraint_Error". It is a fundamentally different case.
> 
> What is the fundament, then?

The difference between:

case X is  -- Statically checkable
   when A =>
   when B =>
   when C => raise Constraint_Error;
end case;

and

case Y is  -- Dynamically checkable, when Y isn't constrained
   when A =>
   when B =>
   when others => raise Constraint_Error;
end case;

In Ada all choices are statically known. The only problem is that you
cannot override non-diagonal elements of the dispatch table. I suppose that
my opponent had a dim impression that the table might be unconstrained.
This is irrelevant. The trick is that you do not need to know the whole
table. At a deriving point only its submatrix for the base types of the
given one is of interest. In Ada that submatrix is statically known. This
is what I call "proper design" (and a advantage of static typing, BTW).

>:>>> Ah, so you define it away.
> 
> Or invent a new one?

Where is any other?

>:>>> MD = "Multiple Dispatch" in the orignal
>:>>> context of this thread which is /= more than one dispatching
>:>>> parameter.  This should be obvious.  Ada does not have MD, to argue
>:>>> otherwise just makes you look silly.
>:>> 
>:>> Care to give another definition of MD?
>:> 
>:> No, the original, as I noted here was and is the one under discussion
>:> and it is quite proper.
>: 
>: OK, I'll make it easier for you:
>: 
>: MD /= number of controlling parameters > 1 <=>
>: 1) Exists MD with 1 or 0 controlling parameters; or
>: 2) Dispatching subroutine with n>1 controlling parameters is not MD, but
>: SD, not D.
> 
> This is a mathematical trick, at best?

Trick? What is wrong with above, mathematics or just me? (:-))

> Obviously, "more than" in the above sentence isn't only about counting the
> number of parameters.  You could equally well say that Ada templates
> are recursive because they are when you limit the recursion depth to 0.
> 
> What did the makers of GNAT think when they invented the error message,
> 
>  "operation can be dispatching in only one type"?

Exactly what it tells: no dispatch on distinct types. MD /= dispatch in
distinct type hierarchies. Otherwise, infix dispatching operations were not
MD. See (2) above.
 
> So at the very least there must exists a notion of MD that isn't
> available with Ada.

Right. "Ada has MD" = "Ada has some cases of MD". It does not mean that Ada
has full or proper MD. It all started when my opponent disagreed with a
trivial statement: "... it (Ada's MD) is very limited and cannot be counted
as true multiple dispatch".

The problem with Ada 95 design is that there cannot be any consistent way
to avoid MD. C++ tries with awful results. Ada goes the same, though more
carefully. It defines freezing rules to prevent method declarations on
distinct types. But that is an easy part. What to do with MD within the
same type hierarchy? Nothing, MD creeps in. Differently to MI, you cannot
stopple all holes. Now (in Ada 2005) we'll have MI (called "interfaces" to
not to tease the geese (:-)). Let's see.

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

Re: Ada 2005?

[jayessay]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:


Generally speaking I don't think you understand these issues enough to
have a profitable discussion.  It seems clear that you are only
interested in engaging various sophistries in some weird effort to
"win" something or other.  This is likely my last effort to get dawn
to break over your marblehead.


> >>> However, these rules really have nothing to do with restricting
> >>> "dynamic declarations" (Ada is static and so of course there are no
> >>> dynamic declarations at all).
> >> 
> >> This is wrong.
> > 
> > So where can you _declare_ a new entity at runtime?
> 
> See ARM 3.1.

That section specifically notes that declarations are _declared_ at
_compile_ time.  At _runtime_ they are _elaborated_.  So, you are just
plain wrong.


> >> Not all dynamic declarations are of primitive operations.
> >> Ada is a statically *typed* language.
> > 
> > Yeah.  So?
> 
> So dispatching is not equivalent to halting problem.

I think you need to learn how to read things better.  No one ever said
that multiple dispatching was _equivalent_ to the halting problem.
What I pointed out was that statically determining in all cases that
dispatching will not result in a runtime error is equivalent to the
halting problem.  The reason I pointed this out is that you claimed
that it was indeed possible to never have a runtime error with
dispatching.  You were and are just plain wrong.


> > The general case is simply one where you cannot determine at compile
> > time things like uninitialized variables,
> 
> Class-wide variables cannot be left uninitialized.

It would be nice if you quit playing these silly sophistry games.
Let's take the full quote:

"The general case is simply one where you cannot determine at compile
time things like uninitialized variables, the specific type of a class
wide variable at any given point in time, etc.  These still apply to
Ada.  I'm not sure you actually understand any of this as you keep
making these irrelevant or incorrect claims."

Note the important part about unknown specific types of class wide
variables at any given point.  This is especially apropos wrt class
wide parameters.


> > the specific type of a class
> > wide variable at any given point in time, etc.
> 
> Present us any example of (but not one classified as a bounded error).

Bounded errors are those that are not caught at all.  Are you really
this thick?  I have stated clearly that the issue is that dispatching
in general can result in runtime errors that cannot be determined at
compile time.


> >> case, it is trivial to find a match. Moreover it requires bounded time.
> >> Otherwise, I guess polymorphic calls would never be adopted in Ada. The
> >> problems with implementation of MD in Ada lie elsewhere.
> > 
> > MD is irrelevant to to this point, which is the need for runtime
> > exceptions.
> 
> So it has nothing to do with halting problem? Fine. Then what's the point?

Do you have any idea how stupid this makes you look?


> > Ada has these and you can easily get them with it's
> > polymorphic calls (which cannot be MD), i.e., Constraint_Error can be
> > raised.  What's more, some of these constraint errors are _exactly_
> > the equivalent of "method not found"
> 
> Nope, in Ada it is the equivalent of "method is final and defined to raise
> Constraint_Error". It is a fundamentally different case.

First, you are wrong here - it is indeed the equivalent of "method not
found".  The constraint error will be issued in exactly the same
circumstances.  It is extremely easy to construct examples of this.

Second, I don't see your "method is final" anywhere in the LRM.  But
in any case, the examples I am talking about are _missing_ methods,
not ones that exist but happen to be "final ones".


> > No, the original, as I noted here was and is the one under discussion
> > and it is quite proper.
> 
> OK, I'll make it easier for you:

Let's have the whole quote again you sophist:

"No, the original, as I noted here was and is the one under discussion
and it is quite proper.  In particular it means that Ada has no MD.
There is nothing controversial about this, and several books
(including even the Rationale) discuss how an Ada programmer can
achieve a simple version of MD by rolling their own via redispatch."

MD is all about _multiple_ dispatches, not a single dispatch on
multiple operands of multiple parameters.  That you cannot understand
this is amazing.  Just take a look at the rationale or Barne's book or
Cohen' or ...  They all acknowledge this and that Ada has no MD.
Instead of trying to understand things here you are simply playing
sophist and trying to redefine MD so that you can attempt to claim
that Ada has it.  Why you want to do this is beyond me.


> > The point is an elegant solution cannot be expressed cleanly without
> > recourse to pounding because the language lacks the proper
> > expressivity.
> 
> or that the person lacks some vital knowledge about software design...

I think it has become clear that it is you who lacks the vital
knowledge.


> > Yes.  This means that in this case, intelligent people will _abandon_
> > the tool (in this case the language) so that the elegant correct
> > solution can be expressed without pounding.
> 
> Then you are in a wrong group. It seems that people in c.l.a are
> pretty unintelligent to keep on using Ada, or maybe, there must be
> something wrong with your theory...

Here is a hint:  Neither of your stupid options is correct.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Ada 2005?

[jayessay]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> : Nope, in Ada it is the equivalent of "method is final and defined to raise
> : Constraint_Error". It is a fundamentally different case.
> 
> What is the fundament, then?

The cases I am talking about are situations where constraint error is
raised in exactly the situations that "method not found" is raised in
something like Smalltalk.  They can arise from legal view conversions
to effect runtime dispatching.


> :>>> Ah, so you define it away.
> 
> Or invent a new one?

I think you have the correct interpretation.  DAK seems to want to
simply redefine what MD means.  You can do that, but don't expect
people familiar with the definition in wide use for years to pay it
much attention.

> What did the makers of GNAT think when they invented the error message,
> 
>  "operation can be dispatching in only one type"?

I see you do understand this.  Yes, the GNAT folks are giving the
exact correct error here and it is saying that you cannot dispatch
across multiple types nor that a dispatching operation will
automatically redispath to the secondary operation from the primary.


> So at the very least there must exists a notion of MD that isn't
> available with Ada.

Exactly.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Ada 2005?

[jayessay]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> In Ada all choices are statically known. The only problem is that you
> cannot override non-diagonal elements of the dispatch table.

This is incorrect and it is easy to construct examples that are legal
but will raise constraint error at runtime at a point of attempted
method dispatch.


> >:>>> Ah, so you define it away.
> > 
> > Or invent a new one?
> 
> Where is any other?

The one everyone but you seems to use.


> > Obviously, "more than" in the above sentence isn't only about counting the
> > number of parameters.  You could equally well say that Ada templates
> > are recursive because they are when you limit the recursion depth to 0.
> > 
> > What did the makers of GNAT think when they invented the error message,
> > 
> >  "operation can be dispatching in only one type"?
> 
> Exactly what it tells: no dispatch on distinct types. MD /= dispatch in
> distinct type hierarchies.

More sophistry.  No one said that MD _requires_ dispatch in distinct
type hierarchies, only that it _supports_ this.  Multiple dispatch
does _require_ dispatch on/across multiple types, that is the
definition used everywhere except by you.

> > So at the very least there must exists a notion of MD that isn't
> > available with Ada.
> 
> Right. "Ada has MD" = "Ada has some cases of MD".

More sophistry.

> It does not mean that Ada has full or proper MD. It all started when
> my opponent disagreed with a trivial statement: "... it (Ada's MD)
> is very limited and cannot be counted as true multiple dispatch".

I think this indicates the real problem: "my opponent".  You seem to
see this as some idiotic zero-sum game instead of a discussion.  No
wonder you never seem learn anything.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com