Ada 2005 puzzle

Ada 2005 puzzle

[Dmitry A. Kazakov]

Here is a simplified case illustrating an issue with constructing functions
and limited aggregates:

-------------------------------------------- package P
with Ada.Finalization;
package P is
   type T (<>) is new Ada.Finalization.Limited_Controlled with private;
   function Create return T;
private
   type T is new Ada.Finalization.Limited_Controlled with null record;
end P;
- - - - - - - - - - - - - - - - - - - - - - - - 
package body P is
   function Create return T is
   begin
      return (Ada.Finalization.Limited_Controlled with null record);
   end Create;
end P;
-------------------------------------------- package Q
with P;  use P;
package Q is
   type S is abstract new T with null record;
   type R is new S with null record;
   overriding function Create return R;
end Q;
- - - - - - - - - - - - - - - - - - - - - - - - 
package body Q is
   function Create return R is
   begin
      return (T'(Create) with null record); -- Error!
   end Create;
end Q;

Is there a way to implement Create (without compromising the package P)?

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

Re: Ada 2005 puzzle

[Adam Beneschan]

On Thursday, July 12, 2012 5:54:08 AM UTC-7, Dmitry A. Kazakov wrote:
> Here is a simplified case illustrating an issue with constructing functions
> and limited aggregates:
> 
> -------------------------------------------- package P
> with Ada.Finalization;
> package P is
>    type T (<>) is new Ada.Finalization.Limited_Controlled with private;
>    function Create return T;
> private
>    type T is new Ada.Finalization.Limited_Controlled with null record;
> end P;
> - - - - - - - - - - - - - - - - - - - - - - - - 
> package body P is
>    function Create return T is
>    begin
>       return (Ada.Finalization.Limited_Controlled with null record);
>    end Create;
> end P;
> -------------------------------------------- package Q
> with P;  use P;
> package Q is
>    type S is abstract new T with null record;
>    type R is new S with null record;
>    overriding function Create return R;
> end Q;
> - - - - - - - - - - - - - - - - - - - - - - - - 
> package body Q is
>    function Create return R is
>    begin
>       return (T'(Create) with null record); -- Error!
>    end Create;
> end Q;
> 
> Is there a way to implement Create (without compromising the package P)?

Well, there seem to be a couple bogus things about your example: (1) your extension aggregate in Q doesn't have any additional components, and (2) the title of your post is "Ada 2005 puzzle".  I'm guessing that the error is supposed to refer to 4.3.2(5.1ff), which puts some restrictions on when the ancestor part of an extension aggregate can be a function call whose return subtype is an unconstrained subtype.  (T is unconstrained because it is declared with (<>).)  However, those restrictions only apply only if the rest of the aggregate needs at least one component (and yours doesn't).  Furthermore, the restrictions were added in Ada 2012, so this shouldn't have been illegal in Ada 2005 even if there were another component.  So I think there's a compiler bug.  I can't find another reason why the above example would be illegal.

However, if you were to make R (or S) a type extension with at least one new component, rather than a null extension, there would be a problem.  This was made illegal because in the private part of P, you *could* define T like this:

   type T (D : Positive) is new Ada.Finalization.Limited_Controlled with record
       Name : String (1 .. D);
   end record;

and now the size of T would depend on the discriminant.  Since the extension aggregate has to be built in place (no copying allowed, since this is a limited type), this means that the caller (in Q) has to reserve an unknown amount of space for the ancestor part of the aggregate before it calls P.Create to fill in that space.  Or something like that.  I haven't really studied all the details of the problem, but it does appear that there's a major implementation difficulty.  See 

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0067-1.txt?rev=1.18

for a discussion of the problem.  (Yes, I know that it isn't a problem in your case because the full definition of T doesn't have discriminants.  But the language rules about what's legal and what isn't aren't supposed to depend on private parts that aren't visible.)

I'm guessing that if you really want this to work in a case where T has a varying size, it's just asking too much.  It's not feasible to implement, apparently.  However, if you want to declare T with unknown discriminants in the visible part, but the intent is that the full declaration of T has a fixed size, then perhaps this could be solved with a language change that lets you put a "Fixed_Size" aspect on the first declaration of T.  That would make it illegal for the full declaration of T to contain anything that would make its size variable, and it could mean that the rule in 4.3.2(5.1ff) wouldn't have to apply.   If this is a real issue (and not simply a hypothetical one), then maybe ARG would be open to a proposed change like this.  

Hope this helps, but please keep in mind that I don't fully understand the issues involved because I haven't studied them carefully.

                             -- Adam

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Thu, 12 Jul 2012 08:48:05 -0700 (PDT), Adam Beneschan wrote:

> On Thursday, July 12, 2012 5:54:08 AM UTC-7, Dmitry A. Kazakov wrote:
>> Here is a simplified case illustrating an issue with constructing functions
>> and limited aggregates:
>> 
>> -------------------------------------------- package P
>> with Ada.Finalization;
>> package P is
>>    type T (<>) is new Ada.Finalization.Limited_Controlled with private;
>>    function Create return T;
>> private
>>    type T is new Ada.Finalization.Limited_Controlled with null record;
>> end P;
>> - - - - - - - - - - - - - - - - - - - - - - - - 
>> package body P is
>>    function Create return T is
>>    begin
>>       return (Ada.Finalization.Limited_Controlled with null record);
>>    end Create;
>> end P;
>> -------------------------------------------- package Q
>> with P;  use P;
>> package Q is
>>    type S is abstract new T with null record;
>>    type R is new S with null record;
>>    overriding function Create return R;
>> end Q;
>> - - - - - - - - - - - - - - - - - - - - - - - - 
>> package body Q is
>>    function Create return R is
>>    begin
>>       return (T'(Create) with null record); -- Error!
>>    end Create;
>> end Q;
>> 
>> Is there a way to implement Create (without compromising the package P)?
> 
> Well, there seem to be a couple bogus things about your example: (1) your
> extension aggregate in Q doesn't have any additional components,

Of course it does not work with components too. Actually it never works if
the depth of types hierarchy >2. Initially I thought that the problem is
because there was an abstract type in between.

> and (2) the title of your post is "Ada 2005 puzzle".

Sorry for "puzzle." It is just because there is no way to know in advance
if it will be possible to create objects of a derived limited type using
the constructing function of the/a parent.

Furthermore inventing an "aggregate" for a limited type with ancestors is
always a challenge with about 70% chances to lose.

> However, if you were to make R (or S) a type extension with at least one
> new component, rather than a null extension, there would be a problem.

Thus with components it is impossible per language design?

The motivation of the example is enforcing initialization (with parameters)
on a limited ancestor type. I gather, from your post, that this is
fundamentally impossible in Ada.

So far it was somehow possible in Ada 2005, with, as I said 30% chances of
success.

> If this is a real issue (and not simply a hypothetical one), then maybe
> ARG would be open to a proposed change like this.

Well, it is an on-going battle of finding a work-around with least losses.
Because the problem appears only later in other packages, when the train
already left the station.

(I never doubted that limited aggregates were broken, but I didn't think
that nobody intended them to work.)

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

Re: Ada 2005 puzzle

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1f9q6vk5z2r3t$.1hayo9rmxfwu7$.dlg@40tude.net...
...
> (I never doubted that limited aggregates were broken, but I didn't think
> that nobody intended them to work.)

We intended them to work. It's just that we found out after the fact that 
the extension aggregate case is very difficult to implement on most 
compilers.

(It's no problem for Janus/Ada, which uses a fixed size for all objects; any 
dynamically sized part is handled using implicit pointer and allocation. But 
that solution is hated by almost everyone.)

My personal feeling always was that this restriction was not acceptable, but 
I couldn't explain why. Thus, I think it would be a good idea to send your 
problem to Ada-Comment, so that the ARG can consider the problem. I'm pretty 
sure that your example is reasonable in all respects, and I can't figure out 
any good reason that you shouldn't be able to do it.

(With the obvious exception that "limited" almost never is really what you 
want in Ada, and I don't think that ever could change. I try to use 
non-limited types for almost everything; clever use of Adjust fixes most 
problems. That's why windows are non-limited in Claw, for example.)

                                            Randy.

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Thu, 19 Jul 2012 01:53:35 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1f9q6vk5z2r3t$.1hayo9rmxfwu7$.dlg@40tude.net...
> ...
>> (I never doubted that limited aggregates were broken, but I didn't think
>> that nobody intended them to work.)
> 
> We intended them to work. It's just that we found out after the fact that 
> the extension aggregate case is very difficult to implement on most 
> compilers.
> 
> (It's no problem for Janus/Ada, which uses a fixed size for all objects; any 
> dynamically sized part is handled using implicit pointer and allocation. But 
> that solution is hated by almost everyone.)
> 
> My personal feeling always was that this restriction was not acceptable, but 
> I couldn't explain why. Thus, I think it would be a good idea to send your 
> problem to Ada-Comment, so that the ARG can consider the problem. I'm pretty 
> sure that your example is reasonable in all respects, and I can't figure out 
> any good reason that you shouldn't be able to do it.

ARG should concentrate on the real problem instead. Which is:

It shall be possible to write a constructing function for any type derived
from a type having a constructing function.

(Possible addition: even if there existed abstract ancestors between two
types)

> (With the obvious exception that "limited" almost never is really what you 
> want in Ada, and I don't think that ever could change.

Why not to fix that too? Objects with the no-copies semantics are
everywhere. Larger/complex the object become, less likely anybody would
copy it. Clearly, Ada as a language for *large* projects shall support
this.

There should have been no limited returns and no limited aggregates in
first place. But since ARG decided to invent the mess for the purpose
object construction, it is now the ARG's problem to live up to the promise.

I wouldn't mean ARG threw them into the bin (read: leave it is as is) and
provided a more clean, usable, universal alternative.

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

Re: Ada 2005 puzzle

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:wd9m63dfb4hn.1feik6xrauuel$.dlg@40tude.net...
> On Thu, 19 Jul 2012 01:53:35 -0500, Randy Brukardt wrote:
...
>> My personal feeling always was that this restriction was not acceptable, 
>> but
>> I couldn't explain why. Thus, I think it would be a good idea to send 
>> your
>> problem to Ada-Comment, so that the ARG can consider the problem. I'm 
>> pretty
>> sure that your example is reasonable in all respects, and I can't figure 
>> out
>> any good reason that you shouldn't be able to do it.
>
> ARG should concentrate on the real problem instead. Which is:
>
> It shall be possible to write a constructing function for any type derived
> from a type having a constructing function.

The ARG isn't going to do anything unless real users (like yourself) report 
reasonable examples that don't appear to be possible with the current rules. 
Generally, we're not interested in *solutions* from the public (we're happy 
to figure out the best solution for the language as a whole), but we are 
interested in *problems*.

So far as (most) of the ARG is aware, there is no problem with this feature, 
and in the absence of reports of real problems I doubt that anything will 
change.

...
> Why not to fix that too? Objects with the no-copies semantics are
> everywhere. Larger/complex the object become, less likely anybody would
> copy it. Clearly, Ada as a language for *large* projects shall support
> this.

It can't be fixed; you almost always need copying in some circumstances. The 
language definition admits this with the notion of build-in-place.

I personally don't believe that there are truly no-copy objects; the issue 
is that it is *easier* to define them that way, and it often isn't worth the 
effort to make an appropriate assignment abstraction.

(Claw could not work sanely with limited windows, and the implementation 
effort to provide non-limited windows was insane. So neither option really 
works -- I don't see a way to eliminate this.)

> There should have been no limited returns and no limited aggregates in
> first place. But since ARG decided to invent the mess for the purpose
> object construction, it is now the ARG's problem to live up to the 
> promise.

As I said, you need to report problematical examples to the ARG (via 
Ada-Comment). So far as we know, limited aggregates work just fine... (I've 
never had any problems with them, for example.)

And if you expect me to take your problems to the ARG, let me say that they 
will have a lot more weight if they come from real Ada users and not just me 
(or Adam, or Bob, all of whom are "tainted" as implementors).

                                          Randy.

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Thu, 19 Jul 2012 21:22:27 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:wd9m63dfb4hn.1feik6xrauuel$.dlg@40tude.net...
>> On Thu, 19 Jul 2012 01:53:35 -0500, Randy Brukardt wrote:
> ...
>>> My personal feeling always was that this restriction was not acceptable, but
>>> I couldn't explain why. Thus, I think it would be a good idea to send your
>>> problem to Ada-Comment, so that the ARG can consider the problem. I'm pretty
>>> sure that your example is reasonable in all respects, and I can't figure out
>>> any good reason that you shouldn't be able to do it.
>>
>> ARG should concentrate on the real problem instead. Which is:
>>
>> It shall be possible to write a constructing function for any type derived
>> from a type having a constructing function.
> 
> The ARG isn't going to do anything unless real users (like yourself) report 
> reasonable examples that don't appear to be possible with the current rules. 
> Generally, we're not interested in *solutions* from the public (we're happy 
> to figure out the best solution for the language as a whole), but we are 
> interested in *problems*.

The problem is just same it was when ARG invented limited aggregates and
function returns.

> So far as (most) of the ARG is aware, there is no problem with this feature, 
> and in the absence of reports of real problems I doubt that anything will 
> change.

You could simply say that you agree/disagree with the principle.

>> Why not to fix that too? Objects with the no-copies semantics are
>> everywhere. Larger/complex the object become, less likely anybody would
>> copy it. Clearly, Ada as a language for *large* projects shall support
>> this.
> 
> It can't be fixed; you almost always need copying in some circumstances.

No, you never need copying except for scalar objects and marshaling.
Remember that Ada is used for systems programming where all objects are
strictly referential, some allocated at dedicated memory addresses.

> (Claw could not work sanely with limited windows, and the implementation 
> effort to provide non-limited windows was insane. So neither option really 
> works -- I don't see a way to eliminate this.)

It is clearly a very worrying language problem when GUI elements could not
be made limited. But as you say, when nobody reports, you included,
everything is fine.

> And if you expect me to take your problems to the ARG, let me say that they 
> will have a lot more weight if they come from real Ada users and not just me 
> (or Adam, or Bob, all of whom are "tainted" as implementors).

You mean ARG is unaware that constructing functions cannot be written in
the cases like presented? Or that they would not believe you or Bob telling
so?

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

Re: Ada 2005 puzzle

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1agfifqlayl3y.1bp09z5i37ewk$.dlg@40tude.net...
> On Thu, 19 Jul 2012 21:22:27 -0500, Randy Brukardt wrote:
...
>> The ARG isn't going to do anything unless real users (like yourself) 
>> report
>> reasonable examples that don't appear to be possible with the current 
>> rules.
>> Generally, we're not interested in *solutions* from the public (we're 
>> happy
>> to figure out the best solution for the language as a whole), but we are
>> interested in *problems*.
>
> The problem is just same it was when ARG invented limited aggregates and
> function returns.

Sorry, I meant *specific* examples of useful things that you cannot find a 
legal way to write. No one is likely to be that interested in philosophical 
concerns.

>> So far as (most) of the ARG is aware, there is no problem with this 
>> feature,
>> and in the absence of reports of real problems I doubt that anything will
>> change.
>
> You could simply say that you agree/disagree with the principle.

I actually see little wrong with the Ada model. Had we designed constructor 
functions into Ada 2005, they would have been nearly identical with the 
build-in-place functions that we have now. (Indeed, there was such a 
proposal early on that was discarded in favor of making the semantics more 
general.)

Indeed, until you sent your question the other day, I wouldn't have believed 
that there was any significant problem with the rules. And the "problem" 
that you had was artifically introduced because some implementers thought 
implementing that would be hard. It's not fundamental to the model at all.

So you need to work harder to convince me. And I'm not going to be able to 
do a very good job of convincing anyone else. As I said, we need realistic 
examples of problems that cannot be solved with the current rules.

(And that isn't just addressed to you; it's really addressed to every user 
of Ada. Too many people work around problems without pointing out their 
language difficulties to us; we're never going to be able to fix language 
problems we don't know about!)

>>> Why not to fix that too? Objects with the no-copies semantics are
>>> everywhere. Larger/complex the object become, less likely anybody would
>>> copy it. Clearly, Ada as a language for *large* projects shall support
>>> this.
>>
>> It can't be fixed; you almost always need copying in some circumstances.
>
> No, you never need copying except for scalar objects and marshaling.

All objects need marshalling, and that's one of the obvious problems.

...
>> And if you expect me to take your problems to the ARG, let me say that 
>> they
>> will have a lot more weight if they come from real Ada users and not just 
>> me
>> (or Adam, or Bob, all of whom are "tainted" as implementors).
>
> You mean ARG is unaware that constructing functions cannot be written in
> the cases like presented? Or that they would not believe you or Bob 
> telling
> so?

Definitely unaware -- I've never previously seen a case that couldn't be 
written with a bit of effort. And this particular problem is caused by an 
ill-advised restriction, not by some problem with the general model.

As far as me "telling them", I could do that, but by then I'll totally have 
forgotten the details and no one will (rightly) pay much attention to "I 
vaguely remember that there is a problem of some sort there." The only way 
to avoid that is to put a specific question on the agenda, and I don't want 
to be the source of every such question (it leads to questions as to whether 
I'm selecting problems for my own benefit) -- and I particularly don't want 
to be forced to be the author of an AI that I personally don't have an 
interest in. (The person who submits the question usually has to write the 
AI, if they are an ARG member.)

Anyway, spend a few minutes and send an example like your original one to 
Ada-Comment, and it will get discussed properly. Otherwise, don't gripe 
about it, because it surely isn't going to change.

                                       Randy.

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Fri, 20 Jul 2012 19:04:05 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1agfifqlayl3y.1bp09z5i37ewk$.dlg@40tude.net...
>> On Thu, 19 Jul 2012 21:22:27 -0500, Randy Brukardt wrote:
> ...
>>> The ARG isn't going to do anything unless real users (like yourself) report
>>> reasonable examples that don't appear to be possible with the current rules.
>>> Generally, we're not interested in *solutions* from the public (we're happy
>>> to figure out the best solution for the language as a whole), but we are
>>> interested in *problems*.
>>
>> The problem is just same it was when ARG invented limited aggregates and
>> function returns.
> 
> Sorry, I meant *specific* examples of useful things that you cannot find a 
> legal way to write.

The example I posted illustrates the problem as found in original code,
which is too large and proprietary anyway. 

> No one is likely to be that interested in philosophical concerns.

Huh, what were *specific* examples caused ARG to accept limited aggregates
and functions?

>>> So far as (most) of the ARG is aware, there is no problem with this feature,
>>> and in the absence of reports of real problems I doubt that anything will
>>> change.
>>
>> You could simply say that you agree/disagree with the principle.
> 
> I actually see little wrong with the Ada model.

Rightness here would mean conformance to the principle that a limited
aggregate were *always* possible to write when the nearest non-abstract
ancestor had visible constructing function, or something else?

> And the "problem" 
> that you had was artifically introduced because some implementers thought 
> implementing that would be hard.

I don't understand that, I am not a language lawyer. You are. Is my example
legal and GNAT wrong? In case it is illegal, then how do I change the
aggregate to make it legal.

> So you need to work harder to convince me. And I'm not going to be able to 
> do a very good job of convincing anyone else.

Adam, another language lawyer, wrote that he was aware of the cases when
aggregates were impossible to write. That that point all alarm bells should
start ringing, no?

> As I said, we need realistic 
> examples of problems that cannot be solved with the current rules.

You would have plenty if you tried to make Claw objects limited. Working
around such aggregates is one of the worst Ada issues I have. On top of
that consider the case when the function is to return a class-wide object
constructed using such an aggregate.

> (And that isn't just addressed to you; it's really addressed to every user 
> of Ada. Too many people work around problems without pointing out their 
> language difficulties to us; we're never going to be able to fix language 
> problems we don't know about!)

People actually using Ada have deadlines to meet. The best we could do is
to record the issue and start working it around. If anybody had time to
report a problem, he would be asked for an AI. Should he spent even more
time and forged some AI, that would be discarded on whatever grounds. 

Don't get me wrong, I don't say this is wrong. Wrong is to expect us, Ada
programmers, doing ARG's job. We can only point out that something is
missing/wrong/difficult. The rest is up to ARG. Especially when it is about
such fundamental issues as construction of limited objects.

>>>> Why not to fix that too? Objects with the no-copies semantics are
>>>> everywhere. Larger/complex the object become, less likely anybody would
>>>> copy it. Clearly, Ada as a language for *large* projects shall support
>>>> this.
>>>
>>> It can't be fixed; you almost always need copying in some circumstances.
>>
>> No, you never need copying except for scalar objects and marshaling.
> 
> All objects need marshalling, and that's one of the obvious problems.

Nope. There is no way you would marshal GUI button, network socket, task,
linked data structure etc.

>>> And if you expect me to take your problems to the ARG, let me say that they
>>> will have a lot more weight if they come from real Ada users and not just me
>>> (or Adam, or Bob, all of whom are "tainted" as implementors).
>>
>> You mean ARG is unaware that constructing functions cannot be written in
>> the cases like presented? Or that they would not believe you or Bob telling
>> so?
> 
> Definitely unaware -- I've never previously seen a case that couldn't be 
> written with a bit of effort.

Well, well, you knew that it did not work, but hoped that laymen could
never be able to discover that? (:-))

> Anyway, spend a few minutes and send an example like your original one to 
> Ada-Comment, and it will get discussed properly. Otherwise, don't gripe 
> about it, because it surely isn't going to change.

This is what I was afraid of, because the problem is not fixing this
particular example but to ensure that no other examples like this existed.

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

Re: Ada 2005 puzzle

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1nnq1oprn6h4f.1s5myl3oupdds$.dlg@40tude.net...
> On Fri, 20 Jul 2012 19:04:05 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1agfifqlayl3y.1bp09z5i37ewk$.dlg@40tude.net...
>>> On Thu, 19 Jul 2012 21:22:27 -0500, Randy Brukardt wrote:
>> ...
>>>> The ARG isn't going to do anything unless real users (like yourself) 
>>>> report
>>>> reasonable examples that don't appear to be possible with the current 
>>>> rules.
>>>> Generally, we're not interested in *solutions* from the public (we're 
>>>> happy
>>>> to figure out the best solution for the language as a whole), but we 
>>>> are
>>>> interested in *problems*.
>>>
>>> The problem is just same it was when ARG invented limited aggregates and
>>> function returns.
>>
>> Sorry, I meant *specific* examples of useful things that you cannot find 
>> a
>> legal way to write.
>
> The example I posted illustrates the problem as found in original code,
> which is too large and proprietary anyway.

The example you posted would be just fine as an example of a real-world 
problem.

>> No one is likely to be that interested in philosophical concerns.
>
> Huh, what were *specific* examples caused ARG to accept limited aggregates
> and functions?

I couldn't tell you all of them off-hand (go look at the appropriate AIs). 
Certainly the problems I had defining the (constant) registry keys in Claw 
fed into it; I know that I showed the difficulty it detail where we started 
discussing the problem. And the original problem was the inability to define 
limited constants. The rest of it grew from there.

>>>> So far as (most) of the ARG is aware, there is no problem with this 
>>>> feature,
>>>> and in the absence of reports of real problems I doubt that anything 
>>>> will
>>>> change.
>>>
>>> You could simply say that you agree/disagree with the principle.
>>
>> I actually see little wrong with the Ada model.
>
> Rightness here would mean conformance to the principle that a limited
> aggregate were *always* possible to write when the nearest non-abstract
> ancestor had visible constructing function, or something else?

I'm not sure what exactly you mean by this principle. Please explain (and do 
so on Ada-Comment!).

>> And the "problem"
>> that you had was artifically introduced because some implementers thought
>> implementing that would be hard.
>
> I don't understand that, I am not a language lawyer. You are. Is my 
> example
> legal and GNAT wrong? In case it is illegal, then how do I change the
> aggregate to make it legal.

The example you have is illegal. But the reason it is illegal is not because 
there are any semantic problems with the construct -- it's illegal purely 
because it is difficult to implement on some compilers.

That's why I want you to report this properly, because the only problem in 
allowing your example is to find an implementation model for those 
compilers. It's not at all like some problems that aren't possible in the 
Ada model (like a full redefinition of assignment); this one is probably 
easy to fix. But that won't happen if you don't complain!!

>> So you need to work harder to convince me. And I'm not going to be able 
>> to
>> do a very good job of convincing anyone else.
>
> Adam, another language lawyer, wrote that he was aware of the cases when
> aggregates were impossible to write. That that point all alarm bells 
> should
> start ringing, no?

You can't write aggregates of private types, but those don't really make 
sense (you don't have visibility on the parts that you need to write an 
aggregate). My point being that there are plenty of aggregates that you 
can't write, but those don't make sense in Ada.

We weren't aware of any *useful* aggregates that you can't write, but it 
seems that you have an example. But you're too darn bull-headed to report it 
appropriately. So forget it, you obviously don't really want Ada to be 
improved.

>> As I said, we need realistic
>> examples of problems that cannot be solved with the current rules.
>
> You would have plenty if you tried to make Claw objects limited. Working
> around such aggregates is one of the worst Ada issues I have. On top of
> that consider the case when the function is to return a class-wide object
> constructed using such an aggregate.

Actually, it was the limited registry keys that caused the existing 
facilities to be created. But Claw objects are not created with functions 
(they are initialized in an "invalid" state, and get created with procedures 
at some later point), so I don't think we would have run into those 
particular problems.

The intractable problem we would have had would have been passing a window 
to another task. If windows were not copyable, you could only do that if you 
declare a library-level access type and used allocators. It would have been 
terrible to *require* that organization, so we went through a lot of work to 
make them "clone-able" instead.

>> (And that isn't just addressed to you; it's really addressed to every 
>> user
>> of Ada. Too many people work around problems without pointing out their
>> language difficulties to us; we're never going to be able to fix language
>> problems we don't know about!)
>
> People actually using Ada have deadlines to meet. The best we could do is
> to record the issue and start working it around. If anybody had time to
> report a problem, he would be asked for an AI. Should he spent even more
> time and forged some AI, that would be discarded on whatever grounds.

Not at all; we don't want feature proposals from users; we'd much rather get 
problem reports. And only ARG members can write AIs.

As far as "discarding on whatever grounds", that happens for a variety of 
reasons: problem not important enough, easy workaround, proposed solution 
too complex for problem. We have to look at the complete picture of the 
effects on all Ada users, after all, not just your (or my) problems.

> Don't get me wrong, I don't say this is wrong. Wrong is to expect us, Ada
> programmers, doing ARG's job. We can only point out that something is
> missing/wrong/difficult. The rest is up to ARG. Especially when it is 
> about
> such fundamental issues as construction of limited objects.

That's all I've asked you to do. Report the example that you posted here 
with some explanation as to how it came up. I'm tired of carrying everyone's 
elses problems to the ARG, especially when I don't understand them that 
well. Please do it youself.

...
>>>> And if you expect me to take your problems to the ARG, let me say that 
>>>> they
>>>> will have a lot more weight if they come from real Ada users and not 
>>>> just me
>>>> (or Adam, or Bob, all of whom are "tainted" as implementors).
>>>
>>> You mean ARG is unaware that constructing functions cannot be written in
>>> the cases like presented? Or that they would not believe you or Bob 
>>> telling
>>> so?
>>
>> Definitely unaware -- I've never previously seen a case that couldn't be
>> written with a bit of effort.
>
> Well, well, you knew that it did not work, but hoped that laymen could
> never be able to discover that? (:-))

Not at all. You think that any human can figure out every possible use of 
Ada features? It's simply not possible. Some of you are using program 
construction patterns that we didn't think about. You need to tell us when 
those don't work, or we may never fund out.

>> Anyway, spend a few minutes and send an example like your original one to
>> Ada-Comment, and it will get discussed properly. Otherwise, don't gripe
>> about it, because it surely isn't going to change.
>
> This is what I was afraid of, because the problem is not fixing this
> particular example but to ensure that no other examples like this existed.

That's of course completely impossible. Steve Baird has the role in the ARG 
of coming up with obscure interactions, and he very often amazes me by the 
things that ought to be unrelated that would have an effect. There is no way 
that anyone can think of every possible interaction, and those are were the 
trouble often lies.

And we're not looking for problems; we have plenty of them that have been 
reported - we have plenty of work to do. If you're not willing to report 
problems, then they won't get fixed unless by some happy accident someone 
else reports the same problem. (This the same way that Janus/Ada compiler 
bugs get fixed; we aren't looking for them unless someone has a particular 
problem, or if we're rewriting something anyway. So if you don't report 
them, they'll never get fixed.)

                                                      Randy.

Re: Ada 2005 puzzle

[Adam Beneschan]

On Monday, July 23, 2012 7:38:30 PM UTC-7, Randy Brukardt wrote:
> >
> > I don't understand that, I am not a language lawyer. You are. Is my 
> > example
> > legal and GNAT wrong? In case it is illegal, then how do I change the
> > aggregate to make it legal.
> 
> The example you have is illegal. But the reason it is illegal is not because 
> there are any semantic problems with the construct -- it's illegal purely 
> because it is difficult to implement on some compilers.

Just to forestall any possible confusion: I think Dmitry's example *would* be illegal if it didn't involve a null extension.  But since his original post did involve a null extension, I think the example in his post was legal and GNAT was wrong.  I'm guessing, though, that Dmitry probably started with a non-null type extension and just understandably simplified it too far.

                              -- Adam

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Mon, 23 Jul 2012 21:23:50 -0700 (PDT), Adam Beneschan wrote:

> On Monday, July 23, 2012 7:38:30 PM UTC-7, Randy Brukardt wrote:
>>>
>>> I don't understand that, I am not a language lawyer. You are. Is my example
>>> legal and GNAT wrong? In case it is illegal, then how do I change the
>>> aggregate to make it legal.
>> 
>> The example you have is illegal. But the reason it is illegal is not because 
>> there are any semantic problems with the construct -- it's illegal purely 
>> because it is difficult to implement on some compilers.
> 
> Just to forestall any possible confusion: I think Dmitry's example *would*
> be illegal if it didn't involve a null extension.  But since his original
> post did involve a null extension, I think the example in his post was
> legal and GNAT was wrong.  I'm guessing, though, that Dmitry probably
> started with a non-null type extension and just understandably simplified
> it too far.

Exactly.

I repeat it again. It is not about any concrete example. It is about the
principle that constructing function would allow writing an aggregate for a
derived type.

[where the later is fully visible of course, when only abstract ancestors
extended by null record are in between. Put whatever *rational*
restrictions here].

If it does not, then I really fail to understand the purpose of.

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

Re: Ada 2005 puzzle

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:e3lpckmcck22$.eqnl4sn38ezy$.dlg@40tude.net...
> On Mon, 23 Jul 2012 21:23:50 -0700 (PDT), Adam Beneschan wrote:
...
> I repeat it again. It is not about any concrete example. It is about the
> principle that constructing function would allow writing an aggregate for 
> a
> derived type.

Fine. Then report the *principle* to Ada-Comment, along with some examples 
where it doesn't work. As I said, we're not spending our time trolling for 
language bugs -- someone has to report them. And I'm not doing it for other 
anymore. If you don't care enough to report things to Ada-Comment, then we 
(the ARG) shouldn't care enough to look at changing them. We've got plenty 
of hard problems to work on as it is (and I'm sure will get more).

                                         Randy.

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Wed, 25 Jul 2012 18:39:20 -0500, in comp.lang.ada you wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:e3lpckmcck22$.eqnl4sn38ezy$.dlg@40tude.net...
>> On Mon, 23 Jul 2012 21:23:50 -0700 (PDT), Adam Beneschan wrote:
> ...
>> I repeat it again. It is not about any concrete example. It is about the
>> principle that constructing function would allow writing an aggregate for 
>> a derived type.
> 
> Fine. Then report the *principle* to Ada-Comment, along with some examples 
> where it doesn't work. As I said, we're not spending our time trolling for 
> language bugs -- someone has to report them. And I'm not doing it for other 
> anymore. If you don't care enough to report things to Ada-Comment, then we 
> (the ARG) shouldn't care enough to look at changing them. We've got plenty 
> of hard problems to work on as it is (and I'm sure will get more).

Well, no. Because:

1. You have already answered my question. To paraphrase the answer: limited
objects cannot be constructed using that "junk", it was not intended for
this.

2. I actually want the "junk" removed from the language and consider
anybody's work on extending or implementing it as wasting resources.
Especially because I doubt very much that the goal could be achieved.

As a side note. It would be nice if the next Ada Rationale would have a
chapter, kind of "it is not what you think", warning Ada programmers
against attempts to use the "junk" for the purpose of limited object
factories and suggesting some working patterns instead.

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

Re: Ada 2005 puzzle

[Simon Wright]

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

> 2. I actually want the "junk" removed from the language and consider
> anybody's work on extending or implementing it as wasting resources.
> Especially because I doubt very much that the goal could be achieved.

Well, then, you need to tell the ARG that through the official route.

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Thu, 26 Jul 2012 14:08:51 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> 2. I actually want the "junk" removed from the language and consider
>> anybody's work on extending or implementing it as wasting resources.
>> Especially because I doubt very much that the goal could be achieved.
> 
> Well, then, you need to tell the ARG that through the official route.

No. As Randy said, without pressure from customers ARG would not move a
finger. This is why I rather make the case here.

It seems that people in c.l.a. are not aware that limited objects are
virtually impossible to create and that limited aggregates and functions
were apparently never intended to help this. The latter was a surprise even
to disillusioned me.

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

Re: Ada 2005 puzzle

[AdaMagica]

On Thursday, July 26, 2012 3:55:52 PM UTC+2, Dmitry A. Kazakov wrote:
>>
>> Well, then, you need to tell the ARG that through the official route.
> 
> No. As Randy said, without pressure from customers ARG would not move a
> finger. This is why I rather make the case here.

Dmitry, that's nonsense. You are too bull-headed (as Randy said) to understand that what you call customers here is real Ada users that ARG want input from about problems they encounter with the language standard.

We are the customers here. So, zum Teufel noch mal, send it in...

> It seems that people in c.l.a. are not aware that limited objects are
> virtually impossible to create and that limited aggregates and functions
> were apparently never intended to help this. The latter was a surprise even
> to disillusioned me.

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Fri, 27 Jul 2012 02:42:57 -0700 (PDT), AdaMagica wrote:

> On Thursday, July 26, 2012 3:55:52 PM UTC+2, Dmitry A. Kazakov wrote:
>>>
>>> Well, then, you need to tell the ARG that through the official route.
>> 
>> No. As Randy said, without pressure from customers ARG would not move a
>> finger. This is why I rather make the case here.
> 
> Dmitry, that's nonsense. You are too bull-headed (as Randy said) to
> understand that what you call customers here is real Ada users that ARG
> want input from about problems they encounter with the language standard.

How is it different from what I wrote?
 
> We are the customers here. So, zum Teufel noch mal, send it in...

What should I send them? Presently I don't even know the purpose of limited
aggregates and functions. Anybody gasped "how could it be impossible to
create objects using our wonderful stuff? There must be something wrong!"
Or "here is how you do it right." No. It is considered *OK*.

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

Re: Ada 2005 puzzle

[Georg Bauhaus]

On 27.07.12 12:32, Dmitry A. Kazakov wrote:
> I don't even know the purpose of limited
> aggregates


For limited aggregates I'd suggest that it is good to have
statically initialized, read-only objects. For example,
deferred constants that are initialized, from static values,
in the private part of a package.  These limited
objects could be stored in ROM, yet have primitive subprograms
associated with them as (more or less) usual.

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Fri, 27 Jul 2012 13:58:25 +0200, Georg Bauhaus wrote:

> On 27.07.12 12:32, Dmitry A. Kazakov wrote:
>> I don't even know the purpose of limited
>> aggregates
> 
> For limited aggregates I'd suggest that it is good to have
> statically initialized, read-only objects. For example,
> deferred constants that are initialized, from static values,
> in the private part of a package.  These limited
> objects could be stored in ROM, yet have primitive subprograms
> associated with them as (more or less) usual.

If you cannot derive? Primitive operations make little sense if there is
only one type.

Abstract types fall short either because you could not have:

   type T is abstract ... with private;
   function Create (...) return T; -- Non-abstract
      -- initializes private parts of T, called from the overriding

The stuff just does not make any sense to me.

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

Re: Ada 2005 puzzle

[AdaMagica]

On Friday, July 27, 2012 3:04:12 PM UTC+2, Dmitry A. Kazakov wrote:
> If you cannot derive? Primitive operations make little sense if there is
> only one type.
>
> Abstract types fall short either because you could not have:
>
>    type T is abstract ... with private;
>    function Create (...) return T; -- Non-abstract
>       -- initializes private parts of T, called from the overriding
>
> The stuff just does not make any sense to me.

I see what you mean. But since no objects of abstract types may exist and somehow you have to provide the private components of derived nonprivate objects, the proper Ada way (as intended by ARG, I guess) is child packages. They can see the private part and provide the necessary information. (I'm sure you know this.)
So you *can* derive:

package Root is
  type T is abstract tagged private;
private
  ...
end Root;
package Root.Child is  -- body can see private part of Root
  type S is new T with private;
  function Create (...) return S;
private
  ...
end Root.Child;

-- I guess that's what you want:
with Root;
package Derived is  -- this does not work, there's no way to provide the
                    -- private part of T.
  type S is new Root.T with private;
  function Create (...) return S;

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Sat, 28 Jul 2012 02:48:43 -0700 (PDT), AdaMagica wrote:

> On Friday, July 27, 2012 3:04:12 PM UTC+2, Dmitry A. Kazakov wrote:
>> If you cannot derive? Primitive operations make little sense if there is
>> only one type.
>>
>> Abstract types fall short either because you could not have:
>>
>>    type T is abstract ... with private;
>>    function Create (...) return T; -- Non-abstract
>>       -- initializes private parts of T, called from the overriding
>>
>> The stuff just does not make any sense to me.
> 
> I see what you mean. But since no objects of abstract types may exist and
> somehow you have to provide the private components of derived nonprivate
> objects, the proper Ada way (as intended by ARG, I guess) is child
> packages.

That changes nothing. An abstract type remains abstract. You can derive a
non-abstract (and thus necessarily broken) type from it and expose the
latter.

And you forgot that this was not intended to work anyway. Because a limited
derived object cannot be created this way. Which is so far the
authoritative answer.

It was the starting point of the discussion that the kludge is useless for
object creation. Georg suggested a case of a flat type hierarchy (one type)
where it might be used. I answered that with one type you need no primitive
operations at all. And if it were just a bit thicker: 1 abstract + 1
concrete it would not work already.

So whatever use it might have it is clearly marginal. Introducing an
extremely difficult to implement and semantically twisted features for this
single case, there must have been mass demonstrations of customers on the
streets seven years ago! (:-))

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

Re: Ada 2005 puzzle

[AdaMagica]

On Saturday, July 28, 2012 12:37:21 PM UTC+2, Dmitry A. Kazakov wrote:
>> I see what you mean. But since no objects of abstract types may exist and
>> somehow you have to provide the private components of derived nonprivate
>> objects, the proper Ada way (as intended by ARG, I guess) is child
>> packages.
>
> That changes nothing. An abstract type remains abstract. You can derive a
> non-abstract (and thus necessarily broken) type from it and expose the
> latter.

I don't understand what you mean (for non-limited types; I see the problem for limited ones).
Why is it necessarily broken? It has private and visible parts, so what?

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Sat, 28 Jul 2012 09:59:27 -0700 (PDT), AdaMagica wrote:

> On Saturday, July 28, 2012 12:37:21 PM UTC+2, Dmitry A. Kazakov wrote:
>>> I see what you mean. But since no objects of abstract types may exist and
>>> somehow you have to provide the private components of derived nonprivate
>>> objects, the proper Ada way (as intended by ARG, I guess) is child
>>> packages.
>>
>> That changes nothing. An abstract type remains abstract. You can derive a
>> non-abstract (and thus necessarily broken) type from it and expose the
>> latter.
> 
> I don't understand what you mean (for non-limited types; I see the problem for limited ones).
> Why is it necessarily broken? It has private and visible parts, so what?

You derive from the type for the sole purpose of being able to write a
function returning an instance of. But the initial reason of being abstract
was to prevent very existence of such functions because the type is
non-functional, abstract.

(The concept of construction per a function is unsound independently on the
limited/non-limited issue with regard to abstract types. An abstract type
may require initialization, but shall have no objects. Even if the
"limited" kludge worked, it would remain broken.)

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

Re: Ada 2005 puzzle

[Maciej Sobczak]

W dniu czwartek, 19 lipca 2012 08:53:35 UTC+2 użytkownik Randy Brukardt napisał:


> (With the obvious exception that "limited" almost never is really what you 
> want in Ada,

I disagree. Limited is a very frequent case - this seems to be very much in the Ada spirit, which in many places promotes reduction of available operations in order to ease analysis and increase safety.
Note also that protected objects are limited by nature and in Ada 2005 that fact has to play well with interfaces, and so on.

> clever use of Adjust fixes

If you have to be *clever* to *fix* something and make it kinda sorta work, then this is just hacking around and has little to do with software engineering.

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Thu, 19 Jul 2012 21:41:46 -0500, Randy Brukardt wrote:

> For example, you can't put limited objects into containers. We spent quite a 
> bit of mental energy trying to come up with some way to do so, but 
> eventually it proved futile, because you need some sort of copy to get the 
> objects into (and something out of) the container.

Of course futile, because the concept is flawed. You cannot copy limited
objects, you cannot return them from a function, you cannot have aggregates
of. Construction is not copying, though copying indeed requires
construction.

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

Re: Ada 2005 puzzle

[Vasiliy Molostov]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Fri,  
20 Jul 2012 11:30:02 +0400:

> On Thu, 19 Jul 2012 21:41:46 -0500, Randy Brukardt wrote:
> Construction is not copying, though copying indeed requires
> construction.
>

...initialization.

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Sat, 21 Jul 2012 21:21:18 +0400, Vasiliy Molostov wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> яПНяПНяПНяПНяПН(яПН) яПН яПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПН Fri,  
> 20 Jul 2012 11:30:02 +0400:
> 
>> On Thu, 19 Jul 2012 21:41:46 -0500, Randy Brukardt wrote:
>> Construction is not copying, though copying indeed requires
>> construction.
> 
> ...initialization.

Initialization is more specific than construction. There can be
uninitialized objects. But any accessible object is conceptually
constructed.

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

Re: Ada 2005 puzzle

[Vasiliy Molostov]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Sat,  
21 Jul 2012 23:03:31 +0400:
> Initialization is more specific than construction. There can be
> uninitialized objects. But any accessible object is conceptually
> constructed.
>

I am afraid that this concept came from lisp and smalltalk where these  
languages declared as functional.

Ada seems procedural, like pascal, and standard refers to initialization,  
not construction. Perhaps, this misconception is the purpose for such  
things: for any embedded system this construction may be done by  
translator/compiler, and in a resulting flash-rom image there is only  
initialization with actual values is needed (being minimized and optimized  
already). Ada prefers static definitions, and even has a special term for  
this job: elaboration.

I doubt that you can construct complex object without elaboration and  
initialization of it and its components in ada.

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Sat, 21 Jul 2012 23:37:21 +0400, Vasiliy Molostov wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> яПНяПНяПНяПНяПН(яПН) яПН яПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПН Sat,  
> 21 Jul 2012 23:03:31 +0400:
>> Initialization is more specific than construction. There can be
>> uninitialized objects. But any accessible object is conceptually
>> constructed.
> 
> I am afraid that this concept came from lisp and smalltalk where these  
> languages declared as functional.

In any typed language construction is an operation that converts raw memory
into a properly typed object.

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

Re: Ada 2005 puzzle

[Vasiliy Molostov]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Sun,  
22 Jul 2012 00:23:38 +0400:

> In any typed language construction is an operation that converts raw  
> memory
> into a properly typed object.
>

what language is untyped?

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Sun, 22 Jul 2012 00:53:39 +0400, Vasiliy Molostov wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> яПНяПНяПНяПНяПН(яПН) яПН яПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПН Sun,  
> 22 Jul 2012 00:23:38 +0400:
> 
>> In any typed language construction is an operation that converts raw  
>> memory into a properly typed object.
> 
> what language is untyped?

None, even if proclaimed such. Though very few languages are properly
typed. Anyway taking Ada:

declare
   X : Boolean;
   Y : Boolean := False;
begin

Note, I intentionally take a most elementary type.

X is constructed, but not initialized. Y is constructed and initialized. 

The postcondition of construction is: X in Boolean. The postcondition of
initialization is [Y in Boolean and then] Y = False.

Construction operates on the object's type. Initialization does on the
object's value/state.

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

Re: Ada 2005 puzzle

[Vasiliy Molostov]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Sun,  
22 Jul 2012 11:41:04 +0400:

> declare
>    X : Boolean;
>    Y : Boolean := False;
> begin
>
> Note, I intentionally take a most elementary type.

its better set it to tagged type. and in this case you will get  
"initialize(x)".

Does you mean that initialize should be renamed to construct?

Does "False" is a construction for Y?

> Construction operates on the object's type. Initialization does on the
> object's value/state.

Before you told that this one converts from raw memory into well formed  
typed object.

I suppose that setting up state/value of raw memory can completely define  
any typed object.

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Sun, 22 Jul 2012 12:00:33 +0400, Vasiliy Molostov wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> яПНяПНяПНяПНяПН(яПН) яПН яПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПН Sun,  
> 22 Jul 2012 11:41:04 +0400:
> 
>> declare
>>    X : Boolean;
>>    Y : Boolean := False;
>> begin
>>
>> Note, I intentionally take a most elementary type.
> 
> its better set it to tagged type. and in this case you will get  
> "initialize(x)".
> 
> Does you mean that initialize should be renamed to construct?

No. Ada's Initialize is not a constructor. A constructor cannot be a
procedure because there is no way to operate a not yet existing object.
Initialize takes already constructed argument, it is indeed an
[user-defined] initialization.

[Constructors are always generated by the language. They could call some
hooks, like Initialize, at certain stages of construction process. These
hooks can be shaped as functions and procedures.]

> Does "False" is a construction for Y?

False is a value (actually, an expression yielding a value of the
designated type). Y is constructed in a way that False becomes its first
value.

>> Construction operates on the object's type. Initialization does on the
>> object's value/state.
> 
> Before you told that this one converts from raw memory into well formed  
> typed object.

Yes. It is a type conversion: none -> a type
 
> I suppose that setting up state/value of raw memory can completely define  
> any typed object.

Accompanied by setting the designated type. Initialization is a part of
construction.

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

Re: Ada 2005 puzzle

[Vasiliy Molostov]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Sun,  
22 Jul 2012 12:19:20 +0400:

>>> Initialization does on the
>>> object's value/state.
>>
>> Before you told that this one converts from raw memory into well formed
>> typed object.
>
> Yes. It is a type conversion: none -> a type

Since you have considered that initialisation is the same as construction,  
I suppose you agree.

>> I suppose that setting up state/value of raw memory can completely  
>> define
>> any typed object.
>
> Accompanied by setting the designated type. Initialization is a part of
> construction.

How do you setup compile-time designators in run-time? "designated type"  
is a compilation time syntax rule helping translator to distinguish type  
of the object and which differs from source code context where used.  
Initialization, being executed in run-time, can not be a part of  
compile-time syntax. But, perhaps, you mean designators that are variable  
(change their values) in run-time?

Perhaps, you tend to define type of the object outside of the memory it  
holds. this refers to dynamyc (run-time) type resolution (language  
predefined), and consequently - anonymous (unknown, but existing)  
predefined types and objects. Do you suppose that well formed and strong  
typed language is based on anonynous type (or anyobject) ? Do you mean  
java indeed?

The way Ada goes is to minimize run-time execution and memory that hold by  
objects, via evaluating them before, e.g. in compile-time.

Also, Ada is a procedural language.

Perhaps you mean some construct which is out of bounds of ada language,  
e.g. it is an application feature.

Also, It is not clear why not to return a pointer (access reference) to  
the object instead?

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Sun, 22 Jul 2012 13:06:17 +0400, Vasiliy Molostov wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> яПНяПНяПНяПНяПН(яПН) яПН яПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПН Sun,  
> 22 Jul 2012 12:19:20 +0400:
> 
>>>> Initialization does on the object's value/state.
>>>
>>> Before you told that this one converts from raw memory into well formed
>>> typed object.
>>
>> Yes. It is a type conversion: none -> a type
> 
> Since you have considered that initialisation is the same as construction,  
> I suppose you agree.

Initialization can be a part of construction. It is not same and applies to
different aspects of the object: value vs. type [+/-value].

>>> I suppose that setting up state/value of raw memory can completely  
>>> define
>>> any typed object.
>>
>> Accompanied by setting the designated type. Initialization is a part of
>> construction.
> 
> How do you setup compile-time designators in run-time?

By applying a constructor.

> "designated type"  
> is a compilation time syntax rule helping translator to distinguish type  
> of the object and which differs from source code context where used.

I don't understand this. In a typed language any object has a type.
  
> Perhaps, you tend to define type of the object outside of the memory it  
> holds.

I don't understand this either. Certainly type is a part of program
semantics and thus cannot be inside the object.

> The way Ada goes is to minimize run-time execution and memory that hold by  
> objects, via evaluating them before, e.g. in compile-time.

Objects cannot be evaluated at compile time, they are run-time entities.
Values can be. But I don't understand your point.

> Also, Ada is a procedural language.

Rather it supports procedural decomposition.

> Also, It is not clear why not to return a pointer (access reference) to  
> the object instead?

Instead of what? A pointer is an object too. As such it requires
construction. E.g. in Ada all pointers are constructed initialized by null
if not explicitly set otherwise by the programmer.

Furthermore, a pointer if not dangled, must point to an object, again
constructed.

I don't see how pointers may help the problem of construction.

Regarding limited objects, pointers usually do things only worse. You
should write instead of

    return (... some complicated not working aggregate ...);

this

   return new T'(... the same messy aggregate ...);

But in reality it might quickly become as bad as:

   return P ((S (new T'(...)).all)'Unchecked_Access);

with practically no chance to get through the compiler, even if legal.
Actually nobody, even all Ada language lawyer together, could tell if the
mess were legal or not.

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

Re: Ada 2005 puzzle

[Maciej Sobczak]

W dniu piątek, 20 lipca 2012 04:41:46 UTC+2 użytkownik Randy Brukardt napisał:

> Sure, it's frequent. But it's still not what you *really* want, because you 
> almost always need some copying.

No, or at least I cannot find any extensive support for your claim in my work. If I say that I don't need copying, then it means that I *really* don't need it, not that this is still not what I *really* want (I have messed that sentence on purpose). If I'm forced to provide some copy semantics even if it was not identified in the design stage, then it is because some other things (language rules? container design? others?) are messed up.
We should fix what is broken.

> For example, you can't put limited objects into containers.

Then we have poor containers.

Let's take existing Query_Element-like operations for inspiration. What about:

   procedure Insert (C : in out Container;
      Constructor : not null access function return T);

with intended support for downward closures via local and non-local constructor functions. T can be limited or even class-wide limited (which is even more useful).

With existing rules for in-place return that should be enough - there is no need for explicit access types *outside* of the container and consequently no need for Unchecked_Deallocation. The container might need to use them internally, but this is nothing new and we need not care anyway.

Is there any language corner that I have missed?

Interestingly, I cannot succeed with a test program for the above concept:

procedure Test is

    type T is limited null record;
    
    function Create_T return T is
    begin
        return V : T do
            null;
        end return;
    end Create_T;

    procedure Insert (Constructor : not null access function return T) is
        type T_Ptr is access T;
        P : T_Ptr;
    begin
        P := new T'(Constructor.all);  -- compiler error
    end Insert;

begin
    Insert (Create_T'Access);
end Test;

In the marked line the compiler says: "initialization not allowed for limited types". What initialization?

It *does* work when instead of this:

        P := new T'(Constructor.all);

I use this:

        P := new T'(Create_T);

This suggest that the compiler error message is misleading and in fact the compiler just cannot process what seems to be a valid construct (pun intended).
Is this a compiler bug?

> you need some sort of copy to get the 
> objects into (and something out of) the container.

I argue that with appropriate container interface you don't need any copying and you don't need to expose explicit memory management (not counting compiler bugs).

> I 
> personally would rather be *clever* to *fix* something than to retreat into 
> 1980's programming that cannot be done right by any technique. But your 
> mileage may vary.

My mileage is that we have to fix what is broken, instead of hacking around it.

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Fri, 20 Jul 2012 01:09:45 -0700 (PDT), Maciej Sobczak wrote:

> W dniu pi�tek, 20 lipca 2012 04:41:46 UTC+2 u�ytkownik Randy Brukardt napisa�:
> 
>> For example, you can't put limited objects into containers.
> 
> Then we have poor containers.
> 
> Let's take existing Query_Element-like operations for inspiration. What about:
> 
>    procedure Insert (C : in out Container;
>       Constructor : not null access function return T);

The problem is that a *new* limited object cannot be result of a function,
this is conceptually broken. The factory of limited objects passed to
Insert must provide means to:

1. determine the constraints of the object (using some set of arguments);

2. construct the object in place (using the arguments again);

3. optionally, construct the class-wide object upon the specific object
(using the arguments)

1-3 cannot be effectively fused into single operation, e.g. constructing
function wrapping an aggregate. This is the root problem.

P.S. I think you could probably go further with

   procedure Insert (C : in out Container;
      Constructor : not null access function return not null access T);

But that is not we all wanted to get from a language like Ada.

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

Re: Ada 2005 puzzle

[Maciej Sobczak]

W dniu piątek, 20 lipca 2012 10:27:15 UTC+2 użytkownik Dmitry A. Kazakov napisał:

> The problem is that a *new* limited object cannot be result of a function,
> this is conceptually broken.

Yes, we have already concluded long time ago that one of the priorities for Ada is to fix the concept of object construction. But in this case I think that Ada has everything that is needed.

> The factory of limited objects passed to
> Insert must provide means to:
> 
> 1. determine the constraints of the object (using some set of arguments);

This is not the container's business and will usually come with the factory itself - or from the context of the factory. That is why I expect this to be used with access to *local* functions, which can drag along all the information that is needed to construct the object.

> 2. construct the object in place (using the arguments again);

Same as above - the constructor function can bring the "arguments" from its surrounding context. You can even create wrappers like this:

procedure Insert_From_Arguments
   (C : in out Container;
    X : in Integer; Y : in Integer; Z : in Integer) is

   function Construct return T is
   begin
      return V : T do
         V.X := X;  -- constructing T from arguments X, Y, Z
         -- ...
      end return;
   end Construct;
begin
   C.Insert (Construct'Access);
end Insert_From_Arguments;

Above, the arguments are passed as part of the Construct's environment.

> 3. optionally, construct the class-wide object upon the specific object
> (using the arguments)

I expect that class-wide is what the container sees (for example, by being instantiated with such a type) - the rest happens the usual way, by initializing the class-wide placeholder with specific constructed object. This way you could naturally have a container of OO objects.

> 1-3 cannot be effectively fused into single operation

Why? What's wrong (ie. what is ineffective) with the above?

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Fri, 20 Jul 2012 04:30:27 -0700 (PDT), in comp.lang.ada you wrote:

> W dniu pi�tek, 20 lipca 2012 10:27:15 UTC+2 u�ytkownik Dmitry A. Kazakov napisa�:
> 
>> The problem is that a *new* limited object cannot be result of a function,
>> this is conceptually broken.
> 
> Yes, we have already concluded long time ago that one of the priorities
> for Ada is to fix the concept of object construction.

we = you and me? I bet 99% of c.l.a still firmly believe that functions 
returning limited objects were all OK.

> But in this case I think that Ada has everything that is needed.

On paper. But practically (because the concept is bogus) I suspect that 
there is no way to make it working in real-life scenarios. I cannot count 
number of cases when I was forced to redesign because of the damn problem. 

If Randy himself, who is a compiler designer and language lawyer, gave up, 
what would you expect from laymen?

>> The factory of limited objects passed to
>> Insert must provide means to:
>> 
>> 1. determine the constraints of the object (using some set of arguments);
> 
> This is not the container's business and will usually come with the
> factory itself - or from the context of the factory. That is why I expect
> this to be used with access to *local* functions, which can drag along all
> the information that is needed to construct the object.

Yes, this one of possible forms of factory.
 
>> 2. construct the object in place (using the arguments again);
> 
> Same as above - the constructor function can bring the "arguments" from
> its surrounding context. You can even create wrappers like this:
> 
> procedure Insert_From_Arguments
>    (C : in out Container;
>     X : in Integer; Y : in Integer; Z : in Integer) is
> 
>    function Construct return T is
>    begin
>       return V : T do
>          V.X := X;  -- constructing T from arguments X, Y, Z
>          -- ...
>       end return;
>    end Construct;
> begin
>    C.Insert (Construct'Access);
> end Insert_From_Arguments;
> 
> Above, the arguments are passed as part of the Construct's environment.
> 
>> 3. optionally, construct the class-wide object upon the specific object
>> (using the arguments)
> 
> I expect that class-wide is what the container sees (for example, by being
> instantiated with such a type) - the rest happens the usual way, by
> initializing the class-wide placeholder with specific constructed object.
> This way you could naturally have a container of OO objects.

I meant here a different thing. If you have some dispatching operations to 
be performed upon initialization, these must be called on the class-wide 
instances, when all ancestors are already initialized.

Let you have a hierarchy of types  T1:>T2:>T3. Then construction should run 
as follows:

stage 1
T1 constraints evaluation
T2 constraints
T3 constraints

allocation

stage 2
T1 initialization
T2 initialization
T3 initialization

stage 3
T1'Class initialization, only here we could dispatch on T1'Class
T2'Class initialization
T3'Class initialization

>> 1-3 cannot be effectively fused into single operation
> 
> Why? What's wrong (ie. what is ineffective) with the above?

ARG tried and failed.

The technical reason IMO is that steps 1,2,3 are intermixed. This prevents 
encapsulation of T1/1 + T1/2 + T1/3 into single subprogram. Furthermore at 
the stage 1 there is no any object allocated. It cannot be an argument. 
Stage 2 needs a type-specific argument. Stage 3 needs a class-wide 
argument.

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

Re: Ada 2005 puzzle

[Maciej Sobczak]

W dniu piątek, 20 lipca 2012 14:49:14 UTC+2 użytkownik Dmitry A. Kazakov napisał:

> we = you and me?

Unfortunately, yes (although we want it for slightly different reasons, I guess).

[...]
> I meant here a different thing. If you have some dispatching operations to 
> be performed upon initialization,

I'm not sure what possible use-case would motivate it - I don't see any in the container's interface. Containers are not supposed to be more smart than necessary, they just have to keep objects.

> Let you have a hierarchy of types  T1:>T2:>T3. Then construction should run 
> as follows:
> 
> stage 1
> T1 constraints evaluation
> T2 constraints
> T3 constraints
> 
> allocation
> 
> stage 2
> T1 initialization
> T2 initialization
> T3 initialization
> 
> stage 3
> T1'Class initialization, only here we could dispatch on T1'Class
> T2'Class initialization
> T3'Class initialization
> 
> >> 1-3 cannot be effectively fused into single operation

Stage 3 is implicit, so we don't have to care, but I see the problem with 1 and 2.

> The technical reason IMO is that steps 1,2,3 are intermixed. This prevents 
> encapsulation of T1/1 + T1/2 + T1/3 into single subprogram.

Right - we would have to allow non-contiguous objects (multiple allocations for each component) and that would break the object model in almost all possible places.

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Sat, 21 Jul 2012 15:46:47 -0700 (PDT), Maciej Sobczak wrote:

> W dniu pi�tek, 20 lipca 2012 14:49:14 UTC+2 u�ytkownik Dmitry A. Kazakov napisa�:
> 
>> I meant here a different thing. If you have some dispatching operations to 
>> be performed upon initialization,
> 
> I'm not sure what possible use-case would motivate it - I don't see any in
> the container's interface. Containers are not supposed to be more smart
> than necessary, they just have to keep objects.

But they cannot be more stupid than objects they keep. The use case is a
container of T'Class. T is abstract. Upon its initialization, which is
non-abstract, the initialization calls to an abstract operation Foo:

procedure Initialize (X : in out T) is
begin
   ...
   Foo (T'Class (X));
end Initialize;
 
>> Let you have a hierarchy of types  T1:>T2:>T3. Then construction should run 
>> as follows:
>> 
>> stage 1
>> T1 constraints evaluation
>> T2 constraints
>> T3 constraints
>> 
>> allocation
>> 
>> stage 2
>> T1 initialization
>> T2 initialization
>> T3 initialization
>> 
>> stage 3
>> T1'Class initialization, only here we could dispatch on T1'Class
>> T2'Class initialization
>> T3'Class initialization
>> 
>> 1-3 cannot be effectively fused into single operation
> 
> Stage 3 is implicit, so we don't have to care,

Actually we have to, not only because people want to dispatch upon
initialization. The same problem arise with Rosen's trick. Most typically
when a component of T1 is a task carrying T1'Class as an access
discriminant. When you wanted a rendezvous with the task upon
initialization, you get a nice deadlock (or Tasking_Error). Component tasks
are created during 2. They start no earlier than during 3.

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

Re: Ada 2005 puzzle

[Florian Weimer]

* Dmitry A. Kazakov:

> The problem is that a *new* limited object cannot be result of a function,
> this is conceptually broken.

The compiler can rewrite the function and its call, passing the new
object to a continuation, so it's not really impossible to implement.

Re: Ada 2005 puzzle

[Dmitry A. Kazakov]

On Sun, 22 Jul 2012 12:08:44 +0200, Florian Weimer wrote:

> * Dmitry A. Kazakov:
> 
>> The problem is that a *new* limited object cannot be result of a function,
>> this is conceptually broken.
> 
> The compiler can rewrite the function and its call, passing the new
> object to a continuation, so it's not really impossible to implement.

Broken concepts are indeed possible to implement. Such implementations are
sometimes called "logical errors" or just "bugs."

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

Re: Ada 2005 puzzle

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:72bc2c23-4a1c-4c09-985e-8cc4c0fd957f@googlegroups.com...
W dniu piatek, 20 lipca 2012 04:41:46 UTC+2 uzytkownik Randy Brukardt 
napisal:

...
>> For example, you can&#39;t put limited objects into containers.
>
>Then we have poor containers.

A group of us tried to come up with a workable design for limited containers 
and were unable to do so.

>Let's take existing Query_Element-like operations for inspiration. What 
>about:
>
>  procedure Insert (C : in out Container;
>     Constructor : not null access function return T);
>
>with intended support for downward closures via local and non-local 
>constructor functions.
> T can be limited or even class-wide limited (which is even more useful).

It would be obnoxious to use, as you'd have to write all manner of 
constructor functions and wrappers of the same. We thought Query_Element is 
too much of a pain to use, which is why Ada 2012 adds user-defined indexing 
and user-defined dereferencing so no one has to use those functions.

I also believe that there other operations that would be problems -- but in 
any case, I don't remember the details of what we talked about years ago.

...
>> I personally would rather be *clever* to *fix* something than to retreat 
>> into
>> 1980&#39;s programming that cannot be done right by any technique. But 
>> your
>> mileage may vary.
>
>My mileage is that we have to fix what is broken, instead of hacking around 
>it.

That's the best option, but we couldn't do it. Perhaps we weren't clever 
enough!

It's definitely the case that there are applications where limited is too 
limiting, and full non-limited is too hard to support.

(Another problem is the inability to change limitedness within a hierarchy; 
you can't have limited descendants of non-limited types, or vice-versa. This 
essentially forces using non-limited in the whole hierarchy if it is needed 
at any level. This is necessary because of dispatching and conversions: if 
you can have mixed limited and non-limited types, you can always convert to 
a place where assignment is allowed. And then what?)

                                           Randy.

Re: Ada 2005 puzzle

[Florian Weimer]

* Randy Brukardt:

> (With the obvious exception that "limited" almost never is really what you 
> want in Ada, and I don't think that ever could change. I try to use 
> non-limited types for almost everything; clever use of Adjust fixes most 
> problems. That's why windows are non-limited in Claw, for example.)

I use limited types for almost all objects which need finalization.  I
think this makes perfect sense.  I also used limited types to emulate
interfaces in Ada 95, which made sense to me as well, but was broken
by the introduction of limited returns in Ada 2005.

(I've received close to zero training in Ada, so I often make unusual
design choices.)