Re: Problems with 'class, help anyone?

Re: Problems with 'class, help anyone?

[Alexandre E. Kopilovitch]

>> There is another way, with perhaps even less incompatibility: let's introduce
>> third mode for a formal parameter - "return" mode (in addition to conventional
>> "in" and "out"). That "return" may be applied to the procedure's first parameter
>> only, and it means the same as "out" mode, with single exception: if the first
>> parameter of a procedure is in "return" mode then the procedure *may* be called
>> without the corresponding (first) argument, and in such a case it returns value.
>> For example:
>> 
>> procedure Two_Fold(Result : return Boolean; Something : in Integer);
>> 
>> X : Boolean;
>> Two_Fold(X, 0);  -- "return" as "out", procedure does not return value
>> 
>> if Two_Fold(0) then  -- first argument omitted, procedure returns value
>>   ...
>> end if;
>
>But an out parameter and a return value are not the same, i.e. they cannot 
>generally be interchanged!
>
>Consider e.g.
>     function F return String;
>vs.
>     procedure P (S: out String);
>The former has no idea how long the object is that will get the result (if any), 
>the latter takes the length from the parameter.

Well, I was not writing an AI (perhaps, I should?), therefore I did not look
at the details. Surely, you are right - there must be a limitation for a
parameter in "return" mode: if one is of indefinite type then the currently
undefined attributes (Length, First, etc.) cannot be used for that parameter.
  Did you notice any other hole in that proposal?


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Problems with 'class, help anyone?

[Dmitry A. Kazakov]

Alexandre E. Kopilovitch wrote:

>>> There is another way, with perhaps even less incompatibility: let's
>>> introduce third mode for a formal parameter - "return" mode (in addition
>>> to conventional "in" and "out"). That "return" may be applied to the
>>> procedure's first parameter only, and it means the same as "out" mode,
>>> with single exception: if the first parameter of a procedure is in
>>> "return" mode then the procedure *may* be called without the
>>> corresponding (first) argument, and in such a case it returns value. For
>>> example:
>>> 
>>> procedure Two_Fold(Result : return Boolean; Something : in Integer);
>>> 
>>> X : Boolean;
>>> Two_Fold(X, 0);  -- "return" as "out", procedure does not return value
>>> 
>>> if Two_Fold(0) then  -- first argument omitted, procedure returns value
>>>   ...
>>> end if;
>>
>>But an out parameter and a return value are not the same, i.e. they cannot
>>generally be interchanged!
>>
>>Consider e.g.
>>     function F return String;
>>vs.
>>     procedure P (S: out String);
>>The former has no idea how long the object is that will get the result (if
>>any), the latter takes the length from the parameter.
> 
> Well, I was not writing an AI (perhaps, I should?), therefore I did not
> look at the details. Surely, you are right - there must be a limitation
> for a parameter in "return" mode: if one is of indefinite type then the
> currently undefined attributes (Length, First, etc.) cannot be used for
> that parameter.

If the goal of your proposal is to expose the result as a variable within 
the body, then some equilibristic is indeed required. For instance, you 
could require that such a parameter has to be overridden within the body:

procedure Read (Item : result String) is
   Length : Natural;
begin
   Get (Length); -- Get the actual string length
   declare
      Text : String (1..Length) renames Item; -- Override
   begin
      Get (Text);
   end;
end Read;

Honestly, I do not like it. Further, if you go this way, then you should 
consequently say, OK, let's allow multiple-return functions capable to 
return more than one potentially unlimited result. Maybe then it will worth 
the efforts.

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

Re: Problems with 'class, help anyone?

[Grein, Christoph]

> There is another way, with perhaps even less incompatibility: let's introduce
> third mode for a formal parameter - "return" mode (in addition to conventional
> "in" and "out"). That "return" may be applied to the procedure's first 
parameter
> only, and it means the same as "out" mode, with single exception: if the first
> parameter of a procedure is in "return" mode then the procedure *may* be 
called
> without the corresponding (first) argument, and in such a case it returns 
value.
> For example:
> 
> procedure Two_Fold(Result : return Boolean; Something : in Integer);
> 
> X : Boolean;
> Two_Fold(X, 0);  -- "return" as "out", procedure does not return value
> 
> if Two_Fold(0) then  -- first argument omitted, procedure returns value
>   ...
> end if;

But an out parameter and a return value are not the same, i.e. they cannot 
generally be interchanged!

Consider e.g.
     function F return String;
vs.
     procedure P (S: out String);
The former has no idea how long the object is that will get the result (if any), 
the 
latter takes the length from the parameter.

Re: Problems with 'class, help anyone?

[Alexandre E. Kopilovitch]

Robert A Duff (bobduff@shell01.TheWorld.com) wrote:
>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
[skip]
>> just allow procedures with results:
>>
>>    procedure Foo (...) return Bar;
>
>Yeah, and then eliminate the "function Foo..." syntax.
>That would solve the problem!
>
>Slight incompatibility...  ;-)

There is another way, with perhaps even less incompatibility: let's introduce
third mode for a formal parameter - "return" mode (in addition to conventional
"in" and "out"). That "return" may be applied to the procedure's first parameter
only, and it means the same as "out" mode, with single exception: if the first
parameter of a procedure is in "return" mode then the procedure *may* be called
without the corresponding (first) argument, and in such a case it returns value.
For example:

procedure Two_Fold(Result : return Boolean; Something : in Integer);

X : Boolean;
Two_Fold(X, 0);  -- "return" as "out", procedure does not return value

if Two_Fold(0) then  -- first argument omitted, procedure returns value
  ...
end if;



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Problems with 'class, help anyone?

[@ 2002-10-29 4:48 UTC (permalink / raw)]

I'm trying to use 'class
here in a way I hope works :)
apparently it doesn't tough..

I'm using example code from:
http://www.ankh-morpork.com/Simon/adabook/x6.htm

Abit old I guess but it's supposed to be for Ada95

I've done almost exactly as this but now I get:
bash-2.03$ gnatmake  main
gcc -c main.adb
main.adb:13:24: no selector "Humanoid" for private type "Instance" defined at mob.ads:7
main.adb:15:27: no selector "Instance" for private type "Instance" defined at mob.ads:7
main.adb:23:18: type of object cannot be abstract
main.adb:28:12: expected type "Pointer" defined at line 8
main.adb:28:12: found private type "Instance" defined at mob-humanoid.ads:11
main.adb:29:12: expected type "Pointer" defined at line 8
main.adb:29:12: found private type "Instance" defined at mob.ads:7
gnatmake: "main.adb" compilation error


According to the webpage above this should work (If I understood it
correctly).

/M�rten Woxberg

Re: Problems with 'class, help anyone?

[Jim Rogers]

M�rten Woxberg wrote:

> I'm trying to use 'class
> here in a way I hope works :)
> apparently it doesn't tough..
> 
> I'm using example code from:
> http://www.ankh-morpork.com/Simon/adabook/x6.htm
> 
> Abit old I guess but it's supposed to be for Ada95
> 
> I've done almost exactly as this but now I get:
> bash-2.03$ gnatmake  main
> gcc -c main.adb
> main.adb:13:24: no selector "Humanoid" for private type "Instance" defined at mob.ads:7
> main.adb:15:27: no selector "Instance" for private type "Instance" defined at mob.ads:7
> main.adb:23:18: type of object cannot be abstract
> main.adb:28:12: expected type "Pointer" defined at line 8
> main.adb:28:12: found private type "Instance" defined at mob-humanoid.ads:11
> main.adb:29:12: expected type "Pointer" defined at line 8
> main.adb:29:12: found private type "Instance" defined at mob.ads:7
> gnatmake: "main.adb" compilation error
> 
> 
> According to the webpage above this should work (If I understood it
> correctly).


I see you are doing something *almost* exactly the same. The almost seems
to be your problem.

The GNAT error messages are pretty clear. To give you a detailed analysis of
your code I would need to see your code, not just the compiler error messages.

Jim Rogers

Re: Problems with 'class, help anyone?

[@ 2002-10-29 19:10 UTC (permalink / raw)]

On Tue, 29 Oct 2002 06:08:40 +0000, Jim Rogers wrote:

> M�rten Woxberg wrote:
> 
>> I'm trying to use 'class
>> here in a way I hope works :)
>> apparently it doesn't tough..
>> 
>> I'm using example code from:
>> http://www.ankh-morpork.com/Simon/adabook/x6.htm
>> 
>> Abit old I guess but it's supposed to be for Ada95
>> 
>> I've done almost exactly as this but now I get:
>> bash-2.03$ gnatmake  main
>> gcc -c main.adb
>> main.adb:13:24: no selector "Humanoid" for private type "Instance" defined at mob.ads:7
>> main.adb:15:27: no selector "Instance" for private type "Instance" defined at mob.ads:7
>> main.adb:23:18: type of object cannot be abstract
>> main.adb:28:12: expected type "Pointer" defined at line 8
>> main.adb:28:12: found private type "Instance" defined at mob-humanoid.ads:11
>> main.adb:29:12: expected type "Pointer" defined at line 8
>> main.adb:29:12: found private type "Instance" defined at mob.ads:7
>> gnatmake: "main.adb" compilation error
>> 
>> 
>> According to the webpage above this should work (If I understood it
>> correctly).
> 
> 
> I see you are doing something *almost* exactly the same. The almost seems
> to be your problem.
> 
> The GNAT error messages are pretty clear. To give you a detailed analysis of
> your code I would need to see your code, not just the compiler error messages.

I thought I attached the files with my post but this seem not to be the
case.
http://k27.ryd.student.liu.se/ada/

The sources are located at the above URL.


> Jim Rogers

/M�rten

Re: Problems with 'class, help anyone?

[@ 2002-10-30 5:27 UTC (permalink / raw)]

On Tue, 29 Oct 2002 06:08:40 +0000, Jim Rogers wrote:

> M�rten Woxberg wrote:
> 
<snip> 

> I see you are doing something *almost* exactly the same. The almost seems
> to be your problem.
> 
> The GNAT error messages are pretty clear. To give you a detailed analysis of
> your code I would need to see your code, not just the compiler error messages.

Ok I've tried the Code from the webpage now and that produces the same
errors.. thus it doesnt work with gnat either.. gnat is version 3.13 and
the code on the page was tested with 3.03 and 3.06 so it should
work shouldn't it?

 
> Jim Rogers

/M�rten

Re: Problems with 'class, help anyone?

[Simon Wright]

"M�rten Woxberg" <marwo264@student.liu.se> writes:

> On Tue, 29 Oct 2002 06:08:40 +0000, Jim Rogers wrote:
> 
> > M�rten Woxberg wrote:
> > 
> <snip> 
> 
> > I see you are doing something *almost* exactly the same. The almost seems
> > to be your problem.
> > 
> > The GNAT error messages are pretty clear. To give you a detailed analysis of
> > your code I would need to see your code, not just the compiler error messages.
> 
> Ok I've tried the Code from the webpage now and that produces the same
> errors.. thus it doesnt work with gnat either.. gnat is version 3.13 and
> the code on the page was tested with 3.03 and 3.06 so it should
> work shouldn't it?

No, sorry! GNAT's error checking has become much more severe (correct)
since then.

Re: Problems with 'class, help anyone?

[Jim Rogers]

M�rten Woxberg wrote:

> On Tue, 29 Oct 2002 06:08:40 +0000, Jim Rogers wrote:
> 
> 
>>M�rten Woxberg wrote:
>>
>>
> <snip> 
> 
> 
>>I see you are doing something *almost* exactly the same. The almost seems
>>to be your problem.
>>
>>The GNAT error messages are pretty clear. To give you a detailed analysis of
>>your code I would need to see your code, not just the compiler error messages.
>>
> 
> Ok I've tried the Code from the webpage now and that produces the same
> errors.. thus it doesnt work with gnat either.. gnat is version 3.13 and
> the code on the page was tested with 3.03 and 3.06 so it should
> work shouldn't it?


Several of the package specifications are presented with out corresponding
package bodies. The class wide access types are defined as general access types,
but the corresponding instances are not defined as aliased.

The code frequently tries to make an instance of an abstract type. This is not
allowed.

In general, these examples are both incomplete and incorrect. You might try
contacting Simon Johnston to find an errata page for this document.

I have thrown together an example of using 'class that works.

-----------------------------------------------------------------------
-- Person tagged type.
-- A tagged type is an extensible data structure.
-----------------------------------------------------------------------
with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;

package Persons is
    type Person is tagged private;
    procedure Set_Name (The_Person : out Person; Name : in String);
    function Get_Name(The_Person : Person) return String;
    procedure Set_Age(The_Person : out Person; Age : in Natural);
    function Get_Age(The_Person : Person) return Natural;
    procedure Display(The_Person : Person);
    package Builder is
       function Create(Name : String; Age : Natural) return Person;
    end Builder;
    procedure Print(The_Person : Person'Class);
private
    type Person is tagged record
       Name : Unbounded_String := Null_Unbounded_String;
       Age   : Natural := 0;
    end record;
end Persons;



with Ada.Text_Io;
use Ada.Text_Io;

package body Persons is
    procedure Set_Name (
          The_Person :    out Person;
          Name       : in     String  ) is
    begin
       The_Person.Name := To_Unbounded_String(Name);
    end Set_Name;

    function Get_Name (
          The_Person : Person )
      return String is
    begin
       return To_String(The_Person.Name);
    end Get_Name;

    procedure Set_Age (
          The_Person :    out Person;
          Age        : in     Natural ) is
    begin
       The_Person.Age := Age;
    end Set_Age;

    function Get_Age (
          The_Person : Person )
      return Natural is
    begin
       return The_Person.Age;
    end Get_Age;

    procedure Display (
          The_Person : Person ) is
    begin
       Put_Line(Get_Name(The_Person) & " is" &
          Integer'Image(Get_Age(The_Person)) &
          " years old.");
    end Display;
    package body Builder is
       function Create (
             Name : String;
             Age  : Natural )
         return Person is
          Temp : Person;
       begin
          Set_Name(Temp, Name);
          Set_Age(Temp, Age);
          return Temp;
       end Create;
    end Builder;
    procedure Print (
          The_Person : Person'Class ) is
    begin
       Display(The_Person);
    end Print;
end Persons;


with Persons;
use Persons;

package Employees is
    type Employee is new Person with private;
    procedure Set_Id (
          The_Employee :    out Employee;
          Id           : in     Positive  );
    function Get_Id (
          The_Employee : Employee )
      return Positive;
    procedure Display (
          The_Employee : Employee );
    package Builder is
       function Create (
             Name : String;
             Age  : Natural;
             Id   : Positive )
         return Employee;
    end Builder;
private
    type Employee is new Person with
       record
          Id : Positive;
       end record;
end Employees;


with Ada.Text_Io;
use Ada.Text_Io;

package body Employees is
    procedure Set_Id (
          The_Employee :    out Employee;
          Id           : in     Positive  ) is
    begin
       The_Employee.Id := Id;
    end Set_Id;

    function Get_Id (
          The_Employee : Employee )
      return Positive is
    begin
       return The_Employee.Id;
    end Get_Id;

    procedure Display (
          The_Employee : Employee ) is
    begin
       Display(Person(The_Employee));
       Put_Line("Id:" & Integer'Image(The_Employee.Id));
    end Display;

    package body Builder is
       function Create (
             Name : String;
             Age  : Natural;
             Id   : Positive )
         return Employee is
          Temp : Employee;
       begin
          Set_Name(Temp, Name);
          Set_Age(Temp, Age);
          Set_Id(Temp, Id);
          return Temp;
       end Create;
    end Builder;
end Employees;



with Employees;
use Employees;
with Persons;
use Persons;

procedure Employee_Test is
    E1 : Employee := Employees.Builder.Create (Name => "Fred W. Flintstone",
                       Age => 46, Id => 12345);
    E2 : Employee := Employees.Builder.Create (Name => "Barney Rubble",
                       Age => 43, Id => 10101);
    P1 : Person   := Persons.Builder.Create (Name => "Betty Rubble", Age => 39);
begin
    Print(E1);
    Print(E2);
    Print(P1);
end Employee_Test;


Jim Rogers

Re: Problems with 'class, help anyone?

[@ 2002-11-02 4:02 UTC (permalink / raw)]

On Wed, 30 Oct 2002 08:13:07 +0000, Jim Rogers wrote:

> M�rten Woxberg wrote:
> 
>> On Tue, 29 Oct 2002 06:08:40 +0000, Jim Rogers wrote:
>> 
>> 
>>>M�rten Woxberg wrote:
>>>
>>>
>> <snip> 
>> 
>> 
>>>I see you are doing something *almost* exactly the same. The almost seems
>>>to be your problem.
>>>
>>>The GNAT error messages are pretty clear. To give you a detailed analysis of
>>>your code I would need to see your code, not just the compiler error messages.
>>>
>> 
>> Ok I've tried the Code from the webpage now and that produces the same
>> errors.. thus it doesnt work with gnat either.. gnat is version 3.13 and
>> the code on the page was tested with 3.03 and 3.06 so it should
>> work shouldn't it?
> 
> 
> Several of the package specifications are presented with out corresponding
> package bodies. The class wide access types are defined as general access types,
> but the corresponding instances are not defined as aliased.
> 
> The code frequently tries to make an instance of an abstract type. This is not
> allowed.
> 
> In general, these examples are both incomplete and incorrect. You might try
> contacting Simon Johnston to find an errata page for this document.

Yeah I might have to...
 
> I have thrown together an example of using 'class that works.
> 


Thanks I'll check your code... 

<snip code> 

> Jim Rogers

/M�rten

Re: Problems with 'class, help anyone?

[@ 2002-11-05 2:40 UTC (permalink / raw)]

On Wed, 30 Oct 2002 08:13:07 +0000, Jim Rogers wrote:

> M�rten Woxberg wrote:
> 
>> On Tue, 29 Oct 2002 06:08:40 +0000, Jim Rogers wrote:
>> 
>> 
>>>M�rten Woxberg wrote:
>>>
>>>
>> <snip> 
<snip>
> 
> In general, these examples are both incomplete and incorrect. You might try
> contacting Simon Johnston to find an errata page for this document.
> 
> I have thrown together an example of using 'class that works.
> 
<snip code> 


Thanks. I got it working now... 
To bad my math course started this Monday.. well I'll have time later...
btw is is it common NOT to include the "in out" statements in procedure
headers or didn't you do it cause it was a quick example?

 
> Jim Rogers

/M�rten

Re: Problems with 'class, help anyone?

[Jim Rogers]

M�rten Woxberg wrote:

>
> Thanks. I got it working now... 
> To bad my math course started this Monday.. well I'll have time later...
> btw is is it common NOT to include the "in out" statements in procedure
> headers or didn't you do it cause it was a quick example?
> 


The default mode is IN. This means that not stating a mode
is the same as stating IN mode.

Jim Rogers

Re: Problems with 'class, help anyone?

[Stephen Leake]

Jim Rogers <jimmaureenrogers@worldnet.att.net> writes:

> M�rten Woxberg wrote:
> 
> > btw is is it common NOT to include the "in out" statements in procedure
> > headers or didn't you do it cause it was a quick example?
> >
> 
> The default mode is IN. This means that not stating a mode
> is the same as stating IN mode.

But in _my_ style guide (and some others), leaving out the "in"
(relying on the default) is forbidden.

-- 
-- Stephe

Re: Problems with 'class, help anyone?

[Robert A Duff]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> But in _my_ style guide (and some others), leaving out the "in"
> (relying on the default) is forbidden.

I think the "in" should *always* be left out.  It's just noise.

- Bob

Re: Problems with 'class, help anyone?

[Pascal Obry]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
> 
> > But in _my_ style guide (and some others), leaving out the "in"
> > (relying on the default) is forbidden.
> 
> I think the "in" should *always* be left out.  It's just noise.

Well, as Stephen, I think "in" should always be there. This is also part of my
style guide. With a nice formatting it reads very well:

   procedure Call
     (P1 : in     Integer;
      P2 : in out Integer;
      P4 :    out Integer;
      P3 : access Integer);

Just my 2 cents,
Pascal.

-- 

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

Re: Problems with 'class, help anyone?

[Georg Bauhaus]

Pascal Obry <p.obry@wanadoo.fr> wrote:
: Well, as Stephen, I think "in" should always be there. This is also part of my
: style guide. With a nice formatting it reads very well:

No,	with	nice	formatting	it	is	easy	to
use	the	procedure	specification	as	a	lookup
table.		It	is	never	easy	to	read	text
that	is	presented	in	tabular	layout.	Lots	of
effort	have	gone	into	formatting	algorithms	that
"minimize"	space	between	words.		The	reason	is
related to	exhausting	eye	movements	when	reading.
Reading	as	opposed	to,	for	example,	browsing
an	index.

:   procedure Call
:     (P1 : in     Integer;
:      P2 : in out Integer;
:      P4 :    out Integer;
:      P3 : access Integer);

Whether this layout is helpful may depend on context.
A possible thought when "reading" Call's specification for the first time:
 ah, there is a P1, an "in" parameter of type Integer, which 
 is just read.  Then comes P2, which is inout and also an Integer.
 And what else does this procedure need? Hm, P4, another Integer, and
 this is a result parameter...
another thought, later:
 I do remember the types and such of the parameters of Call, but what has
 been the name of that out parameter? Lets see, ah, yes, P4 is the one
 I want.

In the second case (looking at something "I already know"), tabular
layout helps (me). In the first case, when reading _from left to right_,
it doesn't help (me) at all.

-- georg

Re: Problems with 'class, help anyone?

[Stephen Leake]

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

> In the second case (looking at something "I already know"), tabular
> layout helps (me). In the first case, when reading _from left to right_,
> it doesn't help (me) at all.

Ok. So sometimes it helps, and it never hurts. Sounds like a good idea :).

-- 
-- Stephe

Re: Problems with 'class, help anyone?

[Georg Bauhaus]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote:
:> it doesn't help (me) at all.
: 
: Ok. So sometimes it helps, and it never hurts. Sounds like a good idea :).

Interesting to see an instance of non-back-or-white logic
in a computing discussion :-)

-- georg

Re: Problems with 'class, help anyone?

[Ted Dennison]

Pascal Obry <p.obry@wanadoo.fr> wrote in message news:<upttjnkmb.fsf@wanadoo.fr>...
> Well, as Stephen, I think "in" should always be there. This is also part of my
> style guide. With a nice formatting it reads very well:
> 
>    procedure Call
>      (P1 : in     Integer;
>       P2 : in out Integer;
>       P4 :    out Integer;
>       P3 : access Integer);

I used to feel that way too. However, a couple of years ago Robert
Dewar mananged to convince me that it should not not be put in
functions, as its essentially a redundancy there ("out" isn't
allowed). So now my personal style guide reads the same as yours, with
an exception for functions, which should not have any modes on their
parameters (unless "access" is used).

Re: Problems with 'class, help anyone?

[Stephen Leake]

dennison@telepath.com (Ted Dennison) writes:

> Pascal Obry <p.obry@wanadoo.fr> wrote in message
> news:<upttjnkmb.fsf@wanadoo.fr>... > Well, as Stephen, I think "in"
> should always be there. This is also part of my > style guide. With
> a nice formatting it reads very well:
> > 
> >    procedure Call
> >      (P1 : in     Integer;
> >       P2 : in out Integer;
> >       P4 :    out Integer;
> >       P3 : access Integer);
> 
> I used to feel that way too. However, a couple of years ago Robert
> Dewar mananged to convince me that it should not not be put in
> functions, as its essentially a redundancy there ("out" isn't
> allowed). So now my personal style guide reads the same as yours, with
> an exception for functions, which should not have any modes on their
> parameters (unless "access" is used).

I'd almost go along with that; it's a good reason to leave it out.
However, the One True Editor* relies on the presence of "in" to
correctly colorize the following type name. I'm really used to seeing
types in green, so I'm leaving in the "in". At least until the editor
is "fixed".

-- 
-- Stephe

*Emacs, of course :).

Re: Problems with 'class, help anyone?

[Preben Randhol]

Stephen Leake wrote:
> However, the One True Editor* relies on the presence of "in" to
> correctly colorize the following type name. I'm really used to seeing
> types in green, so I'm leaving in the "in". At least until the editor
> is "fixed".

I think you should change to The Best Text Editor* you are using an OS/WP
wannabie.

____________
* Vim, of course ;-)

Preben
-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
                 "Vim : simply the best text editor out there."

Re: Problems with 'class, help anyone?

[Stephen Leake]

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

> Stephen Leake wrote:
> > However, the One True Editor* relies on the presence of "in" to
> > correctly colorize the following type name. I'm really used to seeing
> > types in green, so I'm leaving in the "in". At least until the editor
> > is "fixed".
> 
> I think you should change to The Best Text Editor* you are using an OS/WP
> wannabie.

Well, I want an Integrated Development Environment, _not_ a "Text
Editor". If I wanted a "Text Editor", I'd use Notepad :).

-- 
-- Stephe

Re: Problems with 'class, help anyone?

[John English]

Robert A Duff wrote:
> 
> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
> 
> > But in _my_ style guide (and some others), leaving out the "in"
> > (relying on the default) is forbidden.
> 
> I think the "in" should *always* be left out.  It's just noise.

I leave it out for functions (where it's the only possibility -- well,
it was in Ada 83 anyway) and put it in explicitly for procedures where
there is a choice of possible modes.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Problems with 'class, help anyone?

[Robert A Duff]

John English <je@brighton.ac.uk> writes:

> Robert A Duff wrote:
> > 
> > Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
> > 
> > > But in _my_ style guide (and some others), leaving out the "in"
> > > (relying on the default) is forbidden.
> > 
> > I think the "in" should *always* be left out.  It's just noise.
> 
> I leave it out for functions (where it's the only possibility -- well,
> it was in Ada 83 anyway) and put it in explicitly for procedures where
> there is a choice of possible modes.

Yeah, I've seen that style before.  The reason I don't like it is that
IMHO the rule about no out params in functions is a kludge, and I don't
want to base my style on a kludge.  They shouldn't be called
"functions",  either -- they are procedures that happen to return a
value.

Anyway, clearly folks could argue about this forever.  And it's a simple
enough issue that *everybody* can have an opinion.  IMHO it would have
been better if Jean Ichbiah had decided on one particulary style,
and enforced it in the syntax.  There is absolutely no value in having
some people use 'in' and some not (and some sometimes).

- Bob

Re: Problems with 'class, help anyone?

[Dmitry A. Kazakov]

Robert A Duff wrote:

> Yeah, I've seen that style before.  The reason I don't like it is that
> IMHO the rule about no out params in functions is a kludge, and I don't
> want to base my style on a kludge.  They shouldn't be called
> "functions",  either -- they are procedures that happen to return a
> value.

That's right, but there is a case where "function" really differs from 
"procedure". I mean protected objects. "function" vs. "procedure" for a 
protected object could potentially mean different implementation and 
performance. So I think that one should leave "function"s as they are, and 
just allow procedures with results:

   procedure Foo (...) return Bar;

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

Re: Problems with 'class, help anyone?

[Robert A Duff]

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

> That's right, but there is a case where "function" really differs from 
> "procedure". I mean protected objects. ...

That's *another* example of basing things on a kludge.
Certainly, it makes sense to distinguish read-only from read-write
locking.  But to base that on "function" vs "procedure" is ...
well, Yuck.

Protected functions are *not* functions (in the maths sense),
and therefore should not be so called.

>... "function" vs. "procedure" for a 
> protected object could potentially mean different implementation and 
> performance. So I think that one should leave "function"s as they are, and 
> just allow procedures with results:
> 
>    procedure Foo (...) return Bar;

Yeah, and then eliminate the "function Foo..." syntax.
That would solve the problem!

Slight incompatibility...  ;-)

- Bob

Re: Problems with 'class, help anyone?

[Jean-Pierre Rosen]

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


"Robert A Duff" <bobduff@shell01.TheWorld.com> a �crit dans le message news:
wcc1y5wi3bw.fsf@shell01.TheWorld.com...
> > So I think that one should leave "function"s as they are, and
> > just allow procedures with results:
> >
> >    procedure Foo (...) return Bar;
>
> Yeah, and then eliminate the "function Foo..." syntax.
> That would solve the problem!
>
FWIW, early Ada (ca 1979) made the difference between functions (that had to
be pure) and "value returning procedures" with the above syntax, which
allowed arbitrary side-effects. This has been dropped in the process, but at
least it means that the issue has been considered.

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

Re: Problems with 'class, help anyone?

[Dmitry A. Kazakov]

Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> That's right, but there is a case where "function" really differs from
>> "procedure". I mean protected objects. ...
> 
> That's *another* example of basing things on a kludge.
> Certainly, it makes sense to distinguish read-only from read-write
> locking.  But to base that on "function" vs "procedure" is ...
> well, Yuck.

Absolutely

> Protected functions are *not* functions (in the maths sense),
> and therefore should not be so called.

Well, strictly speaking "+" is also not the mathematical +. Who cares. But I 
agree that protected function is not the best name for the thing.

>>... "function" vs. "procedure" for a
>> protected object could potentially mean different implementation and
>> performance. So I think that one should leave "function"s as they are,
>> and just allow procedures with results:
>> 
>>    procedure Foo (...) return Bar;
> 
> Yeah, and then eliminate the "function Foo..." syntax.
> That would solve the problem!
> 
> Slight incompatibility...  ;-)

I am not afraid of! (:-))

But we still need some keywords for:

1. Subroutine (=procedure)
2. Subroutine with no side-effects other than on the arguments (=?)
3. Subroutine with only one side-effect on the result (=?)

"function" in Ada is sort of 1. dressed as 3. (:-()

{1,2,3} is multiplied to:

A. Subroutine with no queue
B. Subroutine with a queue (entry)

Well together it makes 3x2=6 different variants!

And not to forget the "notation" axis:

i.   operational x+y
ii.  prefix (subroutines of protected objects, tasks, attributes)
iii. functional A(x,y)
iv.  aggregated (x,y,z) (should Ada have user-defined ones?)

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

Re: Problems with 'class, help anyone?

[Lutz Donnerhacke]

* Dmitry A. Kazakov wrote:
> But we still need some keywords for:
> 
> 1. Subroutine (=procedure)

procedure

> 2. Subroutine with no side-effects other than on the arguments (=?)

Pure procedure (pragma Pure)

> 3. Subroutine with only one side-effect on the result (=?)

Pure Function


> {1,2,3} is multiplied to:
> 
> A. Subroutine with no queue
> B. Subroutine with a queue (entry)

You may add inline/shared_generic as a parameter.

Re: Problems with 'class, help anyone?

[Dmitry A. Kazakov]

Lutz Donnerhacke wrote:

> * Dmitry A. Kazakov wrote:
>> But we still need some keywords for:
>> 
>> 1. Subroutine (=procedure)
> 
> procedure
> 
>> 2. Subroutine with no side-effects other than on the arguments (=?)
> 
> Pure procedure (pragma Pure)

Pragma Pure is for compilation units only.

>> 3. Subroutine with only one side-effect on the result (=?)
> 
> Pure Function
> 
>> {1,2,3} is multiplied to:
>> 
>> A. Subroutine with no queue
>> B. Subroutine with a queue (entry)
> 
> You may add inline/shared_generic as a parameter.

Well, C++ has "inline" as a keyword. I doubt that it is a good idea. Inline 
vs. not inline should have no impact on the program semantics (at least it 
should look so (:-)). Therefore it should not be reflected in the language 
syntax.

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

Re: Problems with 'class, help anyone?

[Lutz Donnerhacke]

* Dmitry A. Kazakov wrote:
> Lutz Donnerhacke wrote:
>> Pure procedure (pragma Pure)
> 
> Pragma Pure is for compilation units only.

pragma Pure_Function exists in GNAT. Sorry.

Re: Problems with 'class, help anyone?

[Robert A Duff]

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

> Robert A Duff wrote:
> 
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> > 
> >> That's right, but there is a case where "function" really differs from
> >> "procedure". I mean protected objects. ...
> > 
> > That's *another* example of basing things on a kludge.
> > Certainly, it makes sense to distinguish read-only from read-write
> > locking.  But to base that on "function" vs "procedure" is ...
> > well, Yuck.
> 
> Absolutely
> 
> > Protected functions are *not* functions (in the maths sense),
> > and therefore should not be so called.
> 
> Well, strictly speaking "+" is also not the mathematical +. Who cares.

You mean because it can overflow?  And because (for floats), it can give
a "close-but-wrong" answer?

Or do you mean, because the user can redefine it to do something else,
including having side effects?

>... But I 
> agree that protected function is not the best name for the thing.
> 
> >>... "function" vs. "procedure" for a
> >> protected object could potentially mean different implementation and
> >> performance. So I think that one should leave "function"s as they are,
> >> and just allow procedures with results:
> >> 
> >>    procedure Foo (...) return Bar;
> > 
> > Yeah, and then eliminate the "function Foo..." syntax.
> > That would solve the problem!
> > 
> > Slight incompatibility...  ;-)
> 
> I am not afraid of! (:-))

I can assure you that if the ARG changed the syntax in this way,
they would be tarred and feathered (or at least ignored)!  ;-)

> But we still need some keywords for:
> 
> 1. Subroutine (=procedure)
> 2. Subroutine with no side-effects other than on the arguments (=?)
> 3. Subroutine with only one side-effect on the result (=?)

I think 2 and 3 should use the same syntax on the declaration.
To me, it's a minor point whether a subroutine returns results
via a "function result" vs out parameter(s).

I would advocate a notation at the call site that indicates
out-parameterness.

> "function" in Ada is sort of 1. dressed as 3. (:-()
> 
> {1,2,3} is multiplied to:
> 
> A. Subroutine with no queue
> B. Subroutine with a queue (entry)

I am not convinced that these need a syntactic distinction.

> Well together it makes 3x2=6 different variants!
> 
> And not to forget the "notation" axis:
> 
> i.   operational x+y
> ii.  prefix (subroutines of protected objects, tasks, attributes)

I don't much like the prefix notation.

> iii. functional A(x,y)
> iv.  aggregated (x,y,z) (should Ada have user-defined ones?)

I don't know about Ada, but if I were designing a language from scratch,
I think I would include user-defined aggregates.  Also, user-defined
semantics for various other notations, like literals, "in", indexing,
and maybe a few others.

I would not go so far as Lisp, where you can redefine the meaning of
'if' statements, and you can even redefine the lexical rules of the
language.

- Bob

Re: Problems with 'class, help anyone?

[Dmitry A. Kazakov]

Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Well, strictly speaking "+" is also not the mathematical +. Who cares.
> 
> You mean because it can overflow?  And because (for floats), it can give
> a "close-but-wrong" answer?
> 
> Or do you mean, because the user can redefine it to do something else,
> including having side effects?

Both and more. Any computer objects at best only simulate mathematical ones. 
They never *are* mathematical objects.

> I can assure you that if the ARG changed the syntax in this way,
> they would be tarred and feathered (or at least ignored)!  ;-)

Alas

>> But we still need some keywords for:
>> 
>> 1. Subroutine (=procedure)
>> 2. Subroutine with no side-effects other than on the arguments (=?)
>> 3. Subroutine with only one side-effect on the result (=?)
> 
> I think 2 and 3 should use the same syntax on the declaration.
> To me, it's a minor point whether a subroutine returns results
> via a "function result" vs out parameter(s).

OK

> I would advocate a notation at the call site that indicates
> out-parameterness.
> 
>> "function" in Ada is sort of 1. dressed as 3. (:-()
>> 
>> {1,2,3} is multiplied to:
>> 
>> A. Subroutine with no queue
>> B. Subroutine with a queue (entry)
> 
> I am not convinced that these need a syntactic distinction.

So let's allow timed and conditional entry calls for all kinds of 
subroutines! Let's allow results for entries.

>> Well together it makes 3x2=6 different variants!
>> 
>> And not to forget the "notation" axis:
>> 
>> i.   operational x+y
>> ii.  prefix (subroutines of protected objects, tasks, attributes)
> 
> I don't much like the prefix notation.

OO-people would not give it away. They like to write comical things like 
"x.sin". It is almost as sacral as only-in-parameters-for-functions (:-))

If we want to abolish postfix notation, then we should consequently allow 
protected operations on multiple objects and entries of multiple tasks. 
[and multiple dispatch, of course]

>> iii. functional A(x,y)
>> iv.  aggregated (x,y,z) (should Ada have user-defined ones?)
> 
> I don't know about Ada,

Surely it is not about C++#* (:-))

> but if I were designing a language from scratch,
> I think I would include user-defined aggregates.  Also, user-defined
> semantics for various other notations, like literals, "in", indexing,
> and maybe a few others.

Yes

> I would not go so far as Lisp, where you can redefine the meaning of
> 'if' statements, and you can even redefine the lexical rules of the
> language.

Agreed. The problem of Ada is not in lexical rules, they are almost perfect 
in my view. The problem is that ADT implementation is far incomplete in 
Ada. One cannot create a record and expose it as an array. One cannot 
define a constructor for every new type. One cannot have discriminants for 
every type. One cannot override implementation of a type while deriving 
from it, etc.

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