Re: Ada 2005 puzzle

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

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