Language lawyer question: task activation

Language lawyer question: task activation

[Adam Beneschan]

Should this program deadlock?  I don't think it should (and I think it
should display "E1 accepted"), based on my understanding about when
task activation is supposed to occur for the function result.  But
perhaps there's something about the relation between task activation
and masters that I don't understand.  Anyway, this hangs when I
compile it with GNAT and run it---is this correct or not?

                                        -- thanks, Adam

with Text_IO;
procedure Test is

    task type TType is
        entry E1;
    end TType;

    task body TType is
    begin
         accept E1 do
            Text_IO.Put_Line ("E1 accepted");
         end E1;
    end TType;

    function Func return TType is
    begin
        return X : TType;
    end Func;

    procedure Do_It (X : TType) is
    begin
        X.E1;
    end Do_It;

begin
    Do_It (Func);
end Test;

Re: Language lawyer question: task activation

[Dmitry A. Kazakov]

On Thu, 19 Feb 2009 09:37:31 -0800 (PST), Adam Beneschan wrote:

> with Text_IO;
> procedure Test is
> 
>     task type TType is
>         entry E1;
>     end TType;
> 
>     task body TType is
>     begin
>          accept E1 do
>             Text_IO.Put_Line ("E1 accepted");
>          end E1;
>     end TType;
> 
>     function Func return TType is
>     begin
>         return X : TType;
>     end Func;
> 
>     procedure Do_It (X : TType) is
>     begin
>         X.E1;
>     end Do_It;
> 
> begin
>     Do_It (Func);
> end Test;

Cool! I am not a language lawyer but I think it is a bug. Even more funny
it becomes with:

   function Func return TType is
   begin
      return X : TType do
         X.E1; -- Communicating with not yet returned object!
      end return;
   end Func;

I guess that GNAT does not fire the task until its "construction," which
happens too late in these cases. I cannot tell if this behavior is correct.
Anyway is nicely illustrates why 2005 return statements and Pickwickian
functions are bogus.

Let's see what others say.

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

Re: Language lawyer question: task activation

[Robert A Duff]

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

>    function Func return TType is
>    begin
>       return X : TType do
>          X.E1; -- Communicating with not yet returned object!
>       end return;
>    end Func;

This one, however, should deadlock.  The task is not activated until
after Func returns.  Func never returns, because it is waiting on
an entry call of a not-yet-activated task.

- Bob

Re: Language lawyer question: task activation

[Dmitry A. Kazakov]

On Thu, 19 Feb 2009 18:57:55 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>    function Func return TType is
>>    begin
>>       return X : TType do
>>          X.E1; -- Communicating with not yet returned object!
>>       end return;
>>    end Func;
> 
> This one, however, should deadlock.  The task is not activated until
> after Func returns.  Func never returns, because it is waiting on
> an entry call of a not-yet-activated task.

I.e. the behaviour of X declared of being TType depends on where it is
declared. That's great. Let us consider this:

   function Func return TType is
      function Func_Func return TType is
      begin
         return X : TType;
      end Func_Func;

      Y : TType := Func_Func;
   begin
      return Z : TType := Func_Func do
         Y.E1; -- This is not like X?
         Z.E1; -- An this?
      end return;
   end Func;

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

Re: Language lawyer question: task activation

[Jean-Pierre Rosen]

Dmitry A. Kazakov a �crit :

> I.e. the behaviour of X declared of being TType depends on where it is
> declared. That's great. Let us consider this:
> 
As it has always been. You cannot rendezvous with a task until it's
activated. A task is activated after the "begin" for the frame where it
is declared. Therefore yes, behaviour depends on where the task is declared.

>    function Func return TType is
>       function Func_Func return TType is
>       begin
>          return X : TType;
>       end Func_Func;
> 
>       Y : TType := Func_Func;
>    begin
>       return Z : TType := Func_Func do
>          Y.E1; -- This is not like X?
>          Z.E1; -- An this?
>       end return;
>    end Func;
> 
Y is a local object. Z is a name (like a hidden parameter) that
references the object that's being created by the function call. That
object is declared in the /caller/.

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

Re: Language lawyer question: task activation

[christoph.grein]

On Feb 19, 6:57 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> ... and Pickwickian functions ...

What are Pickwickian functions?

Re: Language lawyer question: task activation

[Dmitry A. Kazakov]

On Thu, 19 Feb 2009 21:43:53 -0800 (PST), christoph.grein@eurocopter.com
wrote:

> On Feb 19, 6:57�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> ... and Pickwickian functions ...
> 
> What are Pickwickian functions?

Ada 2005 functions returning limited objects, now comes it, by what? It is
neither by-value, nor by-reference...

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

Re: Language lawyer question: task activation

[christoph.grein]

On Feb 20, 11:44 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 19 Feb 2009 21:43:53 -0800 (PST), christoph.gr...@eurocopter.com
> wrote:
>
> > On Feb 19, 6:57 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> ... and Pickwickian functions ...
>
> > What are Pickwickian functions?
>
> Ada 2005 functions returning limited objects, now comes it, by what? It is
> neither by-value, nor by-reference...

It's build-in-place.

Re: Language lawyer question: task activation

[mockturtle]

On Feb 20, 12:14 pm, christoph.gr...@eurocopter.com wrote:
> On Feb 20, 11:44 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>
> > On Thu, 19 Feb 2009 21:43:53 -0800 (PST), christoph.gr...@eurocopter.com
> > wrote:
>
> > > On Feb 19, 6:57 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > > wrote:
> > >> ... and Pickwickian functions ...
>
> > > What are Pickwickian functions?
>
> > Ada 2005 functions returning limited objects, now comes it, by what? It is
> > neither by-value, nor by-reference...
>
> It's build-in-place.

Sorry, maybe is slightly OT, but... Why this name?  The
Webster gives the following definition

1 : marked by simplicity and generosity
2 : intended or taken in a sense other than the obvious or literal one

while googling I obtain lots of reference to "Pickwickian syndrome".
The link with "Pickwickian functions" is rather obscure to me...

Re: Language lawyer question: task activation

[Dmitry A. Kazakov]

On Fri, 20 Feb 2009 04:07:42 -0800 (PST), mockturtle wrote:

> On Feb 20, 12:14�pm, christoph.gr...@eurocopter.com wrote:
>> On Feb 20, 11:44�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>> wrote:
>>
>>> On Thu, 19 Feb 2009 21:43:53 -0800 (PST), christoph.gr...@eurocopter.com
>>> wrote:
>>
>>> > On Feb 19, 6:57�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>> > wrote:
>>> >> ... and Pickwickian functions ...
>>
>>> > What are Pickwickian functions?
>>
>>> Ada 2005 functions returning limited objects, now comes it, by what? It is
>>> neither by-value, nor by-reference...
>>
>> It's build-in-place.
> 
> Sorry, maybe is slightly OT, but... Why this name?  The
> Webster gives the following definition
> 
> 1 : marked by simplicity and generosity
> 2 : intended or taken in a sense other than the obvious or literal one

The position two. Function is thought as yielding a value. It is impossible
to return in-place, otherwise than in a sense other than the obvious or
literal one...

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

Re: Language lawyer question: task activation

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:

>  Function is thought as yielding a value.

Do you think of a function as yielding
 "a run-time entity with a given type
  which can be assigned to an object of
  an appropriate subtype of the type"?
(AARM 3.2(10.a))

The thought (idea) of a function yielding a value
is not obsoleted by build-in-place, I think:
One interpretation is that the yield of the constructor
function is an object and the function computes and
assigns the initial value.

The word "in-place" is not in Ada, only "build-in-place".

Then, a procedure returns, too. Consequently, a
function returning yields a value.

So I'd guess that thinking of a constructor function
as yielding a value is still apt. Maybe it is the
idea of a function in need of an overhaul?

Re: Language lawyer question: task activation

[Dmitry A. Kazakov]

On Fri, 20 Feb 2009 17:45:53 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
> 
>>  Function is thought as yielding a value.
> 
> Do you think of a function as yielding
>  "a run-time entity with a given type
>   which can be assigned to an object of
>   an appropriate subtype of the type"?
> (AARM 3.2(10.a))
>
> The thought (idea) of a function yielding a value
> is not obsoleted by build-in-place, I think:
> One interpretation is that the yield of the constructor
> function is an object and the function computes and
> assigns the initial value.

It neither computes nor assigns, because construction/initialization is not
assignment. It is a different thing. The LHS object does not exist prior
construction, but does prior assignment.

> The word "in-place" is not in Ada, only "build-in-place".
> 
> Then, a procedure returns, too. Consequently, a
> function returning yields a value.

What does it return? Note that it does return an object, that were illegal
because the result is limited.

> So I'd guess that thinking of a constructor function
> as yielding a value is still apt. Maybe it is the
> idea of a function in need of an overhaul?

I don't think so. In my view, if an overhaul is needed, then to overcome
the delusion that construction can be expressed by a function. It is bogus.

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

Re: Language lawyer question: task activation

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

> It neither computes nor assigns, because construction/initialization is not
> assignment. It is a different thing. The LHS object does not exist prior
> construction, but does prior assignment.
> 
>> The word "in-place" is not in Ada, only "build-in-place".
>>
>> Then, a procedure returns, too. Consequently, a
>> function returning yields a value.
> 
> What does it return? Note that it does return an object, that were illegal
> because the result is limited.

I suppose it is just a wording question: When
a function returns, there is a yield.

When a procedure P(Object: out T) returns, there
is a yield (in Object).

Assume the following language experiment:
If T is limited, we might write

   X: constant T;

begin  -- not Ada

   T'Initialize(X, Celsius => 27.3);

or some such, with the understanding that the object
named X will be provided by declaration, but will not
be initialized. Instead, it will have its initial
value when T'Initialize has returned.

Initialization is very much part of object construction in
other languages, sometimes resource management is normally
left to the implementation, too, like in Java, or Eiffel.
Can't I even control some aspects of resource
management using storage pools in constructor functions?

Re: Language lawyer question: task activation

[Dmitry A. Kazakov]

On Fri, 20 Feb 2009 23:19:04 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
> 
>> It neither computes nor assigns, because construction/initialization is not
>> assignment. It is a different thing. The LHS object does not exist prior
>> construction, but does prior assignment.
>> 
>>> The word "in-place" is not in Ada, only "build-in-place".
>>>
>>> Then, a procedure returns, too. Consequently, a
>>> function returning yields a value.
>> 
>> What does it return? Note that it does return an object, that were illegal
>> because the result is limited.
> 
> I suppose it is just a wording question: When
> a function returns, there is a yield.
> 
> When a procedure P(Object: out T) returns, there
> is a yield (in Object).

No, it is not so. The actual of Object out T is constructed *prior* to call
to P. In contrast the "actual" of F return T is not constructed (when T is
limited). This is exactly the thing that worries me. Because it makes out T
and return T different, while they are evidently same.

> Assume the following language experiment:
> If T is limited, we might write
> 
>    X: constant T;
> 
> begin  -- not Ada
> 
>    T'Initialize(X, Celsius => 27.3);
> 
> or some such, with the understanding that the object
> named X will be provided by declaration, but will not
> be initialized. Instead, it will have its initial
> value when T'Initialize has returned.

Unfortunately it is impossible to have pure "out". Again, because that is
inconsistent in the same way the return statement is. You cannot pass an
non-existing object to a subprogram, be it an out parameter or a result.
The object simply does not exist, there is nothing to pass. In fact it is a
kind of raw memory being passed. Worse than that it is rather an idea of
raw memory, in the case of function result.

> Initialization is very much part of object construction in
> other languages, sometimes resource management is normally
> left to the implementation, too, like in Java, or Eiffel.

It must be clearly understood and *spelt* in the language, that
initialization is not an assignment. Initialization cannot be implemented
by any operation defined on the type of the object being initialized.
Period.

If you want to do it *consistently* (typed), you have to decompose
initialization into operations of *other* types. But it remains still
impossible without some magic, called "constructor." The best thing you can
do is to allow some hooks in the constructor to be implemented by
user-defined operations.

A constructor of T as a whole is not an operation of T in any properly
typed system.

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

Re: Language lawyer question: task activation

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1vcaimc8kjj30$.kf3rsd670ebp$.dlg@40tude.net...
...
>> When a procedure P(Object: out T) returns, there
>> is a yield (in Object).
>
> No, it is not so. The actual of Object out T is constructed *prior* to 
> call
> to P. In contrast the "actual" of F return T is not constructed (when T is
> limited). This is exactly the thing that worries me. Because it makes out 
> T
> and return T different, while they are evidently same.

To you, maybe, but not in Ada. Even in Ada 83, "out T" and "return T" are 
different:

   procedure Foo (P : out String);
   function Bar return String;

Bar creates a *new* object with unknown bounds; Foo takes an *existing* 
object with whatever bounds it has. Totally different animals. 
Build-in-place is a rather natural extension to this model. (It's annoying 
that we don't have a way to do return-by-reference as well, but that's 
another topic).

Now, I realize you have rather firm ideas about what represents a "proper 
type model", but that's pretty much irrelevant to the Ada type model (which 
isn't going to change for obvious compatibility reasons).

                        Randy.

Why constructing functions is a mess [was Language lawyer question: task activation (was: Language lawyer question: task activation))

[Dmitry A. Kazakov]

On Fri, 27 Feb 2009 17:29:10 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1vcaimc8kjj30$.kf3rsd670ebp$.dlg@40tude.net...
> ...
>>> When a procedure P(Object: out T) returns, there
>>> is a yield (in Object).
>>
>> No, it is not so. The actual of Object out T is constructed *prior* to 
>> call to P. In contrast the "actual" of F return T is not constructed (when T is
>> limited). This is exactly the thing that worries me. Because it makes out 
>> T and return T different, while they are evidently same.
> 
> To you, maybe, but not in Ada. Even in Ada 83, "out T" and "return T" are 
> different:
> 
>    procedure Foo (P : out String);
>    function Bar return String;
> 
> Bar creates a *new* object with unknown bounds; Foo takes an *existing* 
> object with whatever bounds it has. Totally different animals.

It is not the difference I am talking about. Your example refers to the
types (the constraints of) of the objects, not about whether the objects
are constructed or not. The actual of an out parameter is required to be
constrained, obviously.

> Build-in-place is a rather natural extension to this model. (It's annoying 
> that we don't have a way to do return-by-reference as well, but that's 
> another topic).
> 
> Now, I realize you have rather firm ideas about what represents a "proper 
> type model", but that's pretty much irrelevant to the Ada type model (which 
> isn't going to change for obvious compatibility reasons).

No, "proper" merely means self consistent.

The problem with constructing functions is that they are inconsistent.
Whatever number of ridiculous constructions (return statement, limited
aggregate etc) you would add, the mess will show itself. 

As a result they would break almost every aspect of Ada as a safe, clean
language.

We saw what happens with tasks returned by a return statement. They break
the contract. Nice. Now a puzzle to you.

Topic: large system design, information hiding:

      type T (<>) is abstract tagged limited private;
   private
      type T (...constraints...) is abstract tagged limited record
         ...
      end record;

In order to be used in

   type S is new T with ...;
   function Create (....) return S;

Fine? No!

How to write Create, the constructing function? See? As a constructor it
has to call Create of T. In this case it must do it because where you get
the discriminants of T otherwise? But you cannot declare Create on T at all

   function Create return T;  -- You cannot return abstract object!

Remember? Constructor is not function. It never will. See the problem?
There are constructors that do not produce objects, while any function
does. So far. Probably there already is an AI to return abstract objects,
which do not exist, or maybe exist, but have some comic accessibility
rights etc. It is like the Big Bang, a little inconsistency gives a whole
universe of MESS...

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

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

> Topic: large system design, information hiding:
> 
>       type T (<>) is abstract tagged limited private;
>    private
>       type T (...constraints...) is abstract tagged limited record
>          ...
>       end record;
> 
> In order to be used in
> 
>    type S is new T with ...;
>    function Create (....) return S;

How/Why should this derivation be possible? (Deriving publicly
from an abstract limited type with unknown discriminants--to me,
the <> signals the intent of the author of T, namely that T
should be considered none of our business?)


> Remember? Constructor is not function. It never will. See the problem?

Assuming C++ has constructors, will your arguments apply
in the following examples (just trying to understand):

class T
{
public:
  virtual void op() = 0;
private:
  T(char constraint) : c(constraint) {}
  char c;
};

class S : public T
{
public:
  S() {}
};

(Note: no suitable default constructor in T)

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Dmitry A. Kazakov]

On Sat, 28 Feb 2009 13:20:51 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
> 
>> Topic: large system design, information hiding:
>> 
>>       type T (<>) is abstract tagged limited private;
>>    private
>>       type T (...constraints...) is abstract tagged limited record
>>          ...
>>       end record;
>> 
>> In order to be used in
>> 
>>    type S is new T with ...;
>>    function Create (....) return S;
> 
> How/Why should this derivation be possible?

Because it is so in Ada (the discriminants are inherited).

The idea of <> introduced in Ada 95 was to be able to hide the
discriminants. The idea of Pickwickian function was in part to overcome Ada
design bug that the discriminants can be hidden but not abstracted.

Note that if T weren't abstract, a Pickwickian function would work:

   type T (<>) is tagged limited private;
   function Create (...parameters...) return T;
private
   type T (...constraints...) is tagged limited record ..

Observe, that this abstracts the discriminants of T, which in the public
part are represented by the arguments of Create. Now the arguments of
Create are kind of "public discriminants." The private discriminants are of
nobody's interest.

Another Pickwickian construct is limited aggregate in which you can use a
Pickwickian call to the Pickwickian function Create and this incredible
combination gives us an ability to implement Create of S with whatever
parameters you need.

Nevertheless it miserably fails:

1. It does not work with abstract types.

2. It exposes Create of T as a primitive operation of. That means that S
have to provide Create with *exactly* same arguments as ones of T! This is
a catastrophe. There is absolutely no reason for S to implement this
Create. It would have its own with parameters of its own. (Constructors are
NOT inherited)

3. You still cannot publicly extend T if you have to add some new
discriminants. Discriminants still are not properly abstracted.

(This cannot be saved, it is just wrong.)

>> In order to be used in
>> 
>>    type S is new T with ...;
>>    function Create (....) return S;

> (Deriving publicly
> from an abstract limited type with unknown discriminants--to me,
> the <> signals the intent of the author of T, namely that T
> should be considered none of our business?)

Exactly. This is why a user of public T must be able to construct T knowing
nothing about the discriminants of T.

>> Remember? Constructor is not function. It never will. See the problem?
> 
> Assuming C++ has constructors, will your arguments apply
> in the following examples (just trying to understand):
> 
> class T
> {
> public:
>   virtual void op() = 0;
> private:
>   T(char constraint) : c(constraint) {}
>   char c;
> };

No, the constructor in the example must be public. Probably you refer to
the trick when <> is used to prevent uninitialized objects. But T is
already abstract. You cannot create it in any way.

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

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

> 3. You still cannot publicly extend T if you have to add some new
> discriminants. Discriminants still are not properly abstracted.

Yes.

> (This cannot be saved, it is just wrong.)
> 
>>> In order to be used in
>>>
>>>    type S is new T with ...;
>>>    function Create (....) return S;
> 
>> (Deriving publicly
>> from an abstract limited type with unknown discriminants--to me,
>> the <> signals the intent of the author of T, namely that T
>> should be considered none of our business?)
> 
> Exactly. This is why a user of public T must be able to construct T knowing
> nothing about the discriminants of T.

I meant to say that the derivation should not work in the
following sense. T being (<>)ed, abstract, and limited means,
clients are supposed to not even try to create objects of this
type. The choice is deliberate. There is no way to construct
objects of type T. There is no way to construct objects that
somehow involve T objects, e.g. objects of types derived from
T publicly. The (<>)'s message is that T's objects are handled
in the private part.  None of our business.

>>> Remember? Constructor is not function. It never will. See the problem?
>> Assuming C++ has constructors, will your arguments apply
>> in the following examples (just trying to understand):
>>
>> class T
>> {
>> public:
>>   virtual void op() = 0;
>> private:
>>   T(char constraint) : c(constraint) {}
>>   char c;
>> };
> 
> No, the constructor in the example must be public.

The constructor is private because T(<>) has private
constratints only. IOW, clients cannot construct
an object either of class T (C++) or of type T(<>) (Ada).

> Probably you refer to
> the trick when <> is used to prevent uninitialized objects. But T is
> already abstract. You cannot create it in any way.

When S is derived from some public T without a (<>),
I can name T in S'(T with ...) when T is just abstract.
This illustrates that (<>) prevents (meaningful) public derivation.
An abstract T is just a means to allow concrete types derived
from T. (<>)ing T says, "Keep your hands off!".

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Dmitry A. Kazakov]

On Sat, 28 Feb 2009 16:36:43 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
> 
>> Exactly. This is why a user of public T must be able to construct T knowing
>> nothing about the discriminants of T.
> 
> I meant to say that the derivation should not work in the
> following sense. T being (<>)ed, abstract, and limited means,
> clients are supposed to not even try to create objects of this
> type.

It does not create T. It does S.

(an inherited from T part of S is constructed as required by the designer
of T. No any object of T is created. T is abstract.)

>>>> Remember? Constructor is not function. It never will. See the problem?
>>> Assuming C++ has constructors, will your arguments apply
>>> in the following examples (just trying to understand):
>>>
>>> class T
>>> {
>>> public:
>>>   virtual void op() = 0;
>>> private:
>>>   T(char constraint) : c(constraint) {}
>>>   char c;
>>> };
>> 
>> No, the constructor in the example must be public.
> 
> The constructor is private because T(<>) has private
> constratints only. IOW, clients cannot construct
> an object either of class T (C++) or of type T(<>) (Ada).

This only shows that you provided a wrong C++ example. The right one, i.e.
corresponding to the case I presented is

class T
{
public:
   virtual void op() = 0;
   T (char constraint);
private:
   char c;
};

>> Probably you refer to
>> the trick when <> is used to prevent uninitialized objects. But T is
>> already abstract. You cannot create it in any way.
> 
> When S is derived from some public T without a (<>),
> I can name T in S'(T with ...) when T is just abstract.
> This illustrates that (<>) prevents (meaningful) public derivation.

No. A meaningful derivation is prevented by the language bug that confuses
constructors with functions. These two different concepts evidently collide
when types are abstract.

You misinterpret the purpose of <>. If Ada designers wished to prevent
derivation from T(<>), they would simply do it. If they did, they would
also prohibit such *final* types from being abstract. Obviously.

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

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

> This only shows that you provided a wrong C++ example. The right one, i.e.
> corresponding to the case I presented is
> 
> class T
> {
> public:
>    virtual void op() = 0;
>    T (char constraint);
> private:
>    char c;
> };

I don't understand. Your example read

   type T (<>) is abstract tagged limited private;
 private
   type T ( ... constraints ...) is ...

So there is no way for a client to declare an object of type T,
for one thing because there is no way to provide constraints.
Consequenty, a corresponding C++ class T cannot have a public
constructor (I thought).

>>> Probably you refer to
>>> the trick when <> is used to prevent uninitialized objects. But T is
>>> already abstract. You cannot create it in any way.

Yes, from some viewpoint there is overlap in measures
that prevent clients from creating objects of type T.

>> When S is derived from some public T without a (<>),
>> I can name T in S'(T with ...) when T is just abstract.
>> This illustrates that (<>) prevents (meaningful) public derivation.
> 
> No. A meaningful derivation is prevented by the language bug that confuses
> constructors with functions. These two different concepts evidently collide
> when types are abstract.
> 
> You misinterpret the purpose of <>.

How so?  A T(<>) implies that clients cannot explicitly
constrain the set of values in T from (public) outside
when nothing public yields a constrained object.
A declaration, subtypes, derived types or anything
that is not provided by type T(<>) alone is insufficient.
If T is abstract, this is an even bigger sign post.

Why would one want to derive from such a type?

The next thing I will do when seeing such a "restrictive" type
is to look for some factory, or some children.
These may provide constraints and remove restrictions.

> If they did, they would
> also prohibit such *final* types from being abstract. Obviously.

T is not final in T's package hierarchy, is it?
Yes, Ada's O-O type system permits many multiply interwoven effects.
It doesn't look neat, and I guess it is not alway consistent with
definitions external to Ada.

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Dmitry A. Kazakov]

On Sat, 28 Feb 2009 18:19:38 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
> 
>> This only shows that you provided a wrong C++ example. The right one, i.e.
>> corresponding to the case I presented is
>> 
>> class T
>> {
>> public:
>>    virtual void op() = 0;
>>    T (char constraint);
>> private:
>>    char c;
>> };
> 
> I don't understand. Your example read
> 
>    type T (<>) is abstract tagged limited private;
>  private
>    type T ( ... constraints ...) is ...
> 
> So there is no way for a client to declare an object of type T,
> for one thing because there is no way to provide constraints.
> Consequenty, a corresponding C++ class T cannot have a public
> constructor (I thought).

You did wrong.

T is abstract. Its discriminants is an implementation detail to be hidden
in the private part of the package. Period.

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

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Georg Bauhaus]

Dmitry A. Kazakov wrote:
> On Sat, 28 Feb 2009 18:19:38 +0100, Georg Bauhaus wrote:
> 
>> Dmitry A. Kazakov wrote:
>>
>>> This only shows that you provided a wrong C++ example. The right one, i.e.
>>> corresponding to the case I presented is
>>>
>>> class T
>>> {
>>> public:
>>>    virtual void op() = 0;
>>>    T (char constraint);
>>> private:
>>>    char c;
>>> };
>> I don't understand. Your example read
>>
>>    type T (<>) is abstract tagged limited private;
>>  private
>>    type T ( ... constraints ...) is ...
>>
>> So there is no way for a client to declare an object of type T,
>> for one thing because there is no way to provide constraints.
>> Consequenty, a corresponding C++ class T cannot have a public
>> constructor (I thought).
> 
> You did wrong.

I'm not sure I did. Why, if I can bother you on a Saturday?

> T is abstract.

Yes, so is class T. Also, there is no way to provide
an initial value for char c that could constrain
or discriminate the object.

> Its discriminants is an implementation detail

Maybe some discriminant is implementation detail but that
is not for the client to consider. At least when type T(<>) ...
expresses "Don't mess with T(<>)."

   type Power_Plant (<>) is abstract tagged limited private;
private
   type Resource is (Sun, Dung, Coal, Oil, Uranium);

   type Power_Plant (Driven_By: Ressource) is ...

To me, the public view means I should not try do do
anything that isn't cared for in T's public view.

I'd want to turn that discriminant into derived types,
relly, but when I haven't written the package with T in it,
then I can't rewrite it.


Can I ask you again why you want to derive a type
from a "really private"
type T (<>) is abstract tagged limited private;

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Dmitry A. Kazakov]

On Sat, 28 Feb 2009 19:39:44 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
>> On Sat, 28 Feb 2009 18:19:38 +0100, Georg Bauhaus wrote:
>> 
>>> Dmitry A. Kazakov wrote:
>>>
>>>> This only shows that you provided a wrong C++ example. The right one, i.e.
>>>> corresponding to the case I presented is
>>>>
>>>> class T
>>>> {
>>>> public:
>>>>    virtual void op() = 0;
>>>>    T (char constraint);
>>>> private:
>>>>    char c;
>>>> };
>>> I don't understand. Your example read
>>>
>>>    type T (<>) is abstract tagged limited private;
>>>  private
>>>    type T ( ... constraints ...) is ...
>>>
>>> So there is no way for a client to declare an object of type T,
>>> for one thing because there is no way to provide constraints.
>>> Consequenty, a corresponding C++ class T cannot have a public
>>> constructor (I thought).
>> 
>> You did wrong.
> 
> I'm not sure I did. Why, if I can bother you on a Saturday?

Because the case as I put it reads: the parent type is abstract and
limited, its discriminants are private.

>> T is abstract.
> 
> Yes, so is class T. Also, there is no way to provide
> an initial value for char c that could constrain
> or discriminate the object.

Wrong. C++ constructor can set c as necessary. Private constraints of an
object (rather their equivalents, since C++ does not have unconstrained
types), are to be determined by the constructor. This is absolutely no
problem in C++.

>> Its discriminants is an implementation detail
> 
> Maybe some discriminant is implementation detail but that
> is not for the client to consider. At least when type T(<>) ...
> expresses "Don't mess with T(<>)."

I don't get it, sorry. Please do not try to switch the discussion topic to
interpretations of implied intentions beyond language constructs.

>    type Power_Plant (<>) is abstract tagged limited private;
> private
>    type Resource is (Sun, Dung, Coal, Oil, Uranium);
> 
>    type Power_Plant (Driven_By: Ressource) is ...
> 
> To me, the public view means I should not try do do
> anything that isn't cared for in T's public view.
> 
> I'd want to turn that discriminant into derived types,
> relly, but when I haven't written the package with T in it,
> then I can't rewrite it.
> 
> 
> Can I ask you again why you want to derive a type
> from a "really private"
> type T (<>) is abstract tagged limited private;

Ada standard does not define "really private types." A type may have public
and private views. That has nothing to do with inheritance.

If you are asking why certain things were moved to private parts of a
package, then it is the information hiding principle. Ada was designed in
order to support it. The presented example uses (<>) because the language
requires it when the discriminants appear in the private part. 

For the power plant example consider:

   type Power_Plant (<>) is tagged limited private;
   function Create (Name : String) return Power_Plant;
   function Get_Name (Plant : Power_Plant) return String;
private
   type Power_Plant (Name_Length : Natural) is tagged limited record
      Name : String (1..Name_Length);
   end record;

This design is perfectly legal in Ada 2005. Name_Length is hidden because
it is nobody's business. Later on, this implementation might be replaced
with Unbounded_String or whatever.

Now the implementation of Create goes as follows:

   function Create (Name : String) return Power_Plant is
   begin
      return (Name'Length, Name);
   end Create;

A derived type works fine:

   type My_Plant is new Power_Plant with null record;
   function Create return My_Plant is
   begin
      return (Power_Plant'(Create ("my plant")) with null record);
   end Create;

As you see your assumptions about implied meanings of (<>) are wrong, at
least in Ada 2005. It is OK to have a parent type with (<>) and a
constructing function that constructs the parent as necessary without
leaking any details about the discriminants and other implementation
details of the parent type.

Now, the point is that this model of construction does not work with
abstract types because of fundamental reasons. It is not (<>) which is
broken, but the construction model.

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

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:

> A derived type works fine:
> 
>    type My_Plant is new Power_Plant with null record;
>    function Create return My_Plant is
>    begin
>       return (Power_Plant'(Create ("my plant")) with null record);
>    end Create;

> Now, the point is that this model of construction does not work with
> abstract types because of fundamental reasons. It is not (<>) which is
> broken, but the construction model.

OK, got your point, sorry for being so dense.
Should the following work for unconstrained abstract Power_Plant?
(some day, e.g.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34507 )

  return (Power_Plant with null record);


Would you consider dropping a note on AI05-067 to the ARG list?
There is an not by Stephen W. Baird that mentions
(the possibility (or not) of) dispatching to abstract
subprograms in a related case (I think).

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Dmitry A. Kazakov]

On Mon, 02 Mar 2009 17:13:09 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
> 
>> A derived type works fine:
>> 
>>    type My_Plant is new Power_Plant with null record;
>>    function Create return My_Plant is
>>    begin
>>       return (Power_Plant'(Create ("my plant")) with null record);
>>    end Create;
> 
>> Now, the point is that this model of construction does not work with
>> abstract types because of fundamental reasons. It is not (<>) which is
>> broken, but the construction model.
> 
> OK, got your point, sorry for being so dense.

No, you still have not. The problem is that the idea of constructing
functions replacing constructors is broken. The example I presented is just
one consequence of this flaw.

> Should the following work for unconstrained abstract Power_Plant?
> (some day, e.g.
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34507 )

It is not a compiler bug. It is a language bug. Besides, I have GNAT Pro.

> Would you consider dropping a note on AI05-067 to the ARG list?

Thank you for illustrating my point. This AI perfectly illustrates were
assumptions like 2+2=5 lead:

COMING SOON: !! Mutating objects and Spider-Man !!

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

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:
> On Mon, 02 Mar 2009 17:13:09 +0100, Georg Bauhaus wrote:
> 
>> Dmitry A. Kazakov schrieb:
>>
>>> A derived type works fine:
>>>
>>>    type My_Plant is new Power_Plant with null record;
>>>    function Create return My_Plant is
>>>    begin
>>>       return (Power_Plant'(Create ("my plant")) with null record);
>>>    end Create;
>>> Now, the point is that this model of construction does not work with
>>> abstract types because of fundamental reasons. It is not (<>) which is
>>> broken, but the construction model.
>> OK, got your point, sorry for being so dense.
> 
> No, you still have not.

Yes, (Abstract_Function_Call with ...) doesn't hold water,
I think I got it.  Constructor functions are not constructors for
"abstract subobjects", they are primitive which is doubtful
(as is explained in a 1994 thread Constructor in ADA9X) and
so on...

Please let the ARG know, in case this has been overlooked.

(The compiler bug is still a bug insofar as no constructor
function is needed to crash it. This dreadful line in einfo.adb
seems to apply in the case of Ada 95 only.)


Should the following work for all suitable type names T
at least, no function anywhere? I just don't know,
I haven't found anything to the contrary, but all
compilers available crash.  T(<>) ... :> S,

   X: S := (T with ...);


>> Should the following work for unconstrained abstract Power_Plant?
>> (some day, e.g.
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34507 )
> 
> It is not a compiler bug. It is a language bug. Besides, I have GNAT Pro.

Does GNAT Pro not crash on this, which does not have
a constructor function?

...
   package P1 is
      type T1(<>) is abstract tagged limited private;
   private
      type T1(X: Character) is tagged limited null record;
   end P1;

   package P2 is
      type T2 is new P1.T1 with private;
   private
      type T2 is new P1.T1 with null record;
      X: T2 := (P1.T1 with null record);  -- Bang!
   end P2;
...

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Dmitry A. Kazakov]

On Mon, 02 Mar 2009 19:50:53 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
>> On Mon, 02 Mar 2009 17:13:09 +0100, Georg Bauhaus wrote:
>> 
>>> Dmitry A. Kazakov schrieb:
>>>
>>>> A derived type works fine:
>>>>
>>>>    type My_Plant is new Power_Plant with null record;
>>>>    function Create return My_Plant is
>>>>    begin
>>>>       return (Power_Plant'(Create ("my plant")) with null record);
>>>>    end Create;
>>>> Now, the point is that this model of construction does not work with
>>>> abstract types because of fundamental reasons. It is not (<>) which is
>>>> broken, but the construction model.
>>> OK, got your point, sorry for being so dense.
>> 
>> No, you still have not.
> 
> Yes, (Abstract_Function_Call with ...) doesn't hold water,
> I think I got it.  Constructor functions are not constructors for
> "abstract subobjects", they are primitive which is doubtful
> (as is explained in a 1994 thread Constructor in ADA9X) and
> so on...

They are not constrictors for ALL subjects. For abstract ones is just
absolutely evident.

> Please let the ARG know, in case this has been overlooked.

I don't think they did. Anyway, long ago I posted a proposal for
constructors to Ada-Comment. (I also posed it to comp.lang.ada.)

In my eyes it makes absolutely no sense to consider what could be done with
constructing functions, limited aggregates, return statements etc. Nothing
should be. Leave them as they are. The idea I am trying to convey, is that
it cannot be fixed. Move this mess to the Annex J and do construction
(destruction, initialization, factories) *right*.

> (The compiler bug is still a bug insofar as no constructor
> function is needed to crash it. This dreadful line in einfo.adb
> seems to apply in the case of Ada 95 only.)

[...]

Your example does not crash GNAT Pro 6.2.1.

> ...
>    package P1 is
>       type T1(<>) is abstract tagged limited private;
>    private
>       type T1(X: Character) is tagged limited null record;
>    end P1;
> 
>    package P2 is
>       type T2 is new P1.T1 with private;
>    private
>       type T2 is new P1.T1 with null record;
>       X: T2 := (P1.T1 with null record);  -- Bang!
>    end P2;
> ...

However it looks like a bug to me, because T1 is unconstrained.
Nevertheless, GNAT Pro 6.2.1 successfully compiles it.

P.S. The version 6.2.1 is much better than earlier versions. All bugs I
reported (and there were many) are now fixed. Though I didn't report all
assumed bugs since some of them (traditionally in generics) are very tricky
to track down.

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

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[christoph.grein]

On Mar 2, 10:02 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> >    package P1 is
> >       type T1(<>) is abstract tagged limited private;
> >    private
> >       type T1(X: Character) is tagged limited null record;
> >    end P1;
>
> >    package P2 is
> >       type T2 is new P1.T1 with private;
> >    private
> >       type T2 is new P1.T1 with null record;
> >       X: T2 := (P1.T1 with null record);  -- Bang!
> >    end P2;
> > ...
>
> However it looks like a bug to me, because T1 is unconstrained.
> Nevertheless, GNAT Pro 6.2.1 successfully compiles it.

No, it doesn't (I *have* GNAT Pro 6.2.1).

   X: T2 := (P1.T1 with null record);
            | no value supplied for discriminant "X"
gnatmake: "p2.ads" compilation error

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Dmitry A. Kazakov]

On Mon, 2 Mar 2009 23:04:02 -0800 (PST), christoph.grein@eurocopter.com
wrote:

> On Mar 2, 10:02�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>>> � �package P1 is
>>> � � � type T1(<>) is abstract tagged limited private;
>>> � �private
>>> � � � type T1(X: Character) is tagged limited null record;
>>> � �end P1;
>>
>>> � �package P2 is
>>> � � � type T2 is new P1.T1 with private;
>>> � �private
>>> � � � type T2 is new P1.T1 with null record;
>>>       X: T2 := (P1.T1 with null record);  -- Bang!
>>> � �end P2;
>>> ...
>>
>> However it looks like a bug to me, because T1 is unconstrained.
>> Nevertheless, GNAT Pro 6.2.1 successfully compiles it.
> 
> No, it doesn't (I *have* GNAT Pro 6.2.1).
> 
>    X: T2 := (P1.T1 with null record);
>             | no value supplied for discriminant "X"
> gnatmake: "p2.ads" compilation error

Hmm, mine is GNAT Pro 6.2.1 (20090115). Different wavefronts or, maybe,
platforms?

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

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[christoph.grein]

On Mar 3, 9:45 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> >>>    package P1 is
> >>>       type T1(<>) is abstract tagged limited private;
> >>>    private
> >>>       type T1(X: Character) is tagged limited null record;
> >>>    end P1;
>
> >>>    package P2 is
> >>>       type T2 is new P1.T1 with private;
> >>>    private
> >>>       type T2 is new P1.T1 with null record;
> >>>       X: T2 := (P1.T1 with null record);  -- Bang!
> >>>    end P2;
> >>> ...
>
> >> However it looks like a bug to me, because T1 is unconstrained.
> >> Nevertheless, GNAT Pro 6.2.1 successfully compiles it.
>
> > No, it doesn't (I *have* GNAT Pro 6.2.1).
>
> >    X: T2 := (P1.T1 with null record);
> >             | no value supplied for discriminant "X"
> > gnatmake: "p2.ads" compilation error
>
> Hmm, mine is GNAT Pro 6.2.1 (20090115). Different wavefronts or, maybe,
> platforms?

GNAT Pro 6.2.1 (20090115-43) i686-pc-linux-gnu

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Dmitry A. Kazakov]

On Tue, 3 Mar 2009 01:27:17 -0800 (PST), christoph.grein@eurocopter.com
wrote:

> On Mar 3, 9:45�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:

>> Hmm, mine is GNAT Pro 6.2.1 (20090115). Different wavefronts or, maybe,
>> platforms?
> 
> GNAT Pro 6.2.1 (20090115-43) i686-pc-linux-gnu

One I tested with was Windows.

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

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Pascal Obry]

christoph.grein@eurocopter.com a �crit :
> On Mar 3, 9:45 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> Hmm, mine is GNAT Pro 6.2.1 (20090115). Different wavefronts or, maybe,
>> platforms?
> 
> GNAT Pro 6.2.1 (20090115-43) i686-pc-linux-gnu

You are using versions on different GCC backends (GCC 4.1 vs GCC 4.3).

-- 

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

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[christoph.grein]

On Mar 3, 8:13 pm, Pascal Obry <pas...@obry.net> wrote:
> You are using versions on different GCC backends (GCC 4.1 vs GCC 4.3).

So how can the backend influence the compilation of

   X: T2 := (P1.T1 with null record);

being (illegally) accepted or (correctly) rejected?

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Dmitry A. Kazakov]

On Tue, 3 Mar 2009 21:29:46 -0800 (PST), christoph.grein@eurocopter.com
wrote:

> On Mar 3, 8:13�pm, Pascal Obry <pas...@obry.net> wrote:
>> You are using versions on different GCC backends (GCC 4.1 vs GCC 4.3).
> 
> So how can the backend influence the compilation of
> 
>    X: T2 := (P1.T1 with null record);
> 
> being (illegally) accepted or (correctly) rejected?

I investigated it shortly. It compiles only under AdaGIDE. It does not when
compiled from a command line (gcc -c -gnat05) or GPS. It looks like a weird
artefact of...

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

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[christoph.grein]

On Mar 4, 9:32 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> I investigated it shortly. It compiles only under AdaGIDE. It does not when
> compiled from a command line (gcc -c -gnat05) or GPS. It looks like a weird
> artefact of...

Are you really sure AdaGIDE uses the same version? It just forwards
the file to the compiler, so how can there be a difference?

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Dmitry A. Kazakov]

On Wed, 4 Mar 2009 01:05:26 -0800 (PST), christoph.grein@eurocopter.com
wrote:

> On Mar 4, 9:32�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> I investigated it shortly. It compiles only under AdaGIDE. It does not when
>> compiled from a command line (gcc -c -gnat05) or GPS. It looks like a weird
>> artefact of...
> 
> Are you really sure AdaGIDE uses the same version? It just forwards
> the file to the compiler, so how can there be a difference?

There is no others. OK, I have same 6.2.1 for Windows and VxWorks targets
but, I am pretty sure that it is not the VxWorks one that AdaGIDE uses.
(:-)) It is really weird. I have no idea.

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

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Maciej Sobczak]

On 28 Lut, 14:45, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > class T
> > {
> > public:
> >   virtual void op() = 0;
> > private:
> >   T(char constraint) : c(constraint) {}
> >   char c;
> > };
>
> No, the constructor in the example must be public.

It can be also *protected* (which in C++ means hidden from the world,
but exposed to derived types) and I think this would better fit what
you try to explain.

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

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

Re: Why constructing functions is a mess [was Language lawyer question: task activation

[Dmitry A. Kazakov]

On Sat, 28 Feb 2009 15:12:17 -0800 (PST), Maciej Sobczak wrote:

> On 28 Lut, 14:45, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> class T
>>> {
>>> public:
>>> � virtual void op() = 0;
>>> private:
>>> � T(char constraint) : c(constraint) {}
>>> � char c;
>>> };
>>
>> No, the constructor in the example must be public.
> 
> It can be also *protected* (which in C++ means hidden from the world,
> but exposed to derived types) and I think this would better fit what
> you try to explain.

Right.

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

Re: Language lawyer question: task activation

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

> Should this program deadlock?  I don't think it should (and I think it
> should display "E1 accepted"), based on my understanding about when
> task activation is supposed to occur for the function result.

I think you're right.  The task should be activated after Func returns,
before calling Do_It.

>...But
> perhaps there's something about the relation between task activation
> and masters that I don't understand.  Anyway, this hangs when I
> compile it with GNAT and run it---is this correct or not?
>
>                                         -- thanks, Adam
>
> with Text_IO;
> procedure Test is
>
>     task type TType is
>         entry E1;
>     end TType;
>
>     task body TType is
>     begin
>          accept E1 do
>             Text_IO.Put_Line ("E1 accepted");
>          end E1;
>     end TType;
>
>     function Func return TType is
>     begin
>         return X : TType;
>     end Func;
>
>     procedure Do_It (X : TType) is
>     begin
>         X.E1;
>     end Do_It;
>
> begin
>     Do_It (Func);
> end Test;

- Bob

Re: Language lawyer question: task activation

[Robert_Matthews]

Adam Beneschan wrote:

> Should this program deadlock?  I don't think it should (and I think it
> should display "E1 accepted"), based on my understanding about when
> task activation is supposed to occur for the function result.  But
> perhaps there's something about the relation between task activation
> and masters that I don't understand.  Anyway, this hangs when I
> compile it with GNAT and run it---is this correct or not?
> 
>                                         -- thanks, Adam
> 
> with Text_IO;
> procedure Test is
> 
>     task type TType is
>         entry E1;
>     end TType;
> 
>     task body TType is
>     begin
>          accept E1 do
>             Text_IO.Put_Line ("E1 accepted");
>          end E1;
>     end TType;
> 
>     function Func return TType is
>     begin
>         return X : TType;
>     end Func;
> 
>     procedure Do_It (X : TType) is
>     begin
>         X.E1;
>     end Do_It;
> 
> begin
>     Do_It (Func);
> end Test;

But isn't there another issue here: task types are limited, therefore Func 
is a constructor function, but in what object does it construct its returned
value?

Robert

Re: Language lawyer question: task activation

[christoph.grein]

On Feb 20, 11:18 am, Robert_Matthews <igno...@ramatthews.free-
online.co.uk> wrote:
> >     task type TType is
> >         entry E1;
> >     end TType;
>
> >     function Func return TType is
> >     begin
> >         return X : TType;
> >     end Func;

> But isn't there another issue here: task types are limited, therefore Func
> is a constructor function, but in what object does it construct its returned

Ada 95: TType is a by-reference-type, Func returns a read-only view.
Ada 2005: Func is build-in-place.

In both cases, the returned object is local to Do_It and disappears as
soon as Do_It returns. Of course for Do_It to be able to return, the
task has to terminate before.

Re: Language lawyer question: task activation

[Robert A Duff]

Robert_Matthews <ignored@ramatthews.free-online.co.uk> writes:

>>     procedure Do_It (X : TType) is
>>     begin
>>         X.E1;
>>     end Do_It;
>> 
>> begin
>>     Do_It (Func);
>> end Test;
>
> But isn't there another issue here: task types are limited, therefore Func 
> is a constructor function, but in what object does it construct its returned
> value?

In the formal parameter X of Do_It.

- Bob

Re: Language lawyer question: task activation

[Robert_Matthews]

Robert A Duff wrote:

> Robert_Matthews <ignored@ramatthews.free-online.co.uk> writes:
> 
>>>     procedure Do_It (X : TType) is
>>>     begin
>>>         X.E1;
>>>     end Do_It;
>>> 
>>> begin
>>>     Do_It (Func);
>>> end Test;
>>
>> But isn't there another issue here: task types are limited, therefore
>> Func is a constructor function, but in what object does it construct its
>> returned value?
> 
> In the formal parameter X of Do_It.
> 
> - Bob

So X from Do_It is passed as a hidden parameter to Func, so that
X in Func is really whatever X in Do_It actually is - but what
is that? I don't see an actual object of type TType in the example code.
Calling Do_It with parameter Func seems a bit circular from this viewpoint.

Robert