Re: Ada 2005 puzzle

["Randy Brukardt" <randy@rrsoftware.com>]

"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.