Re: Issue with GNAT GPL 2009 and GtkAda

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 26 Jun 2009 16:38:45 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1hi0km5xe1802.17l3qjn1g9525$.dlg@40tude.net...
> ...
>> I would remove anonymous access types altogether, fixing the real language
>> problems, which led to introducing them in first place.
> 
> I don't think that there were any *real* language reasons for introducing 
> them; the reasons came from wanting to make Ada more appealing to C and Java 
> programmers. (A horrible reason for language design, IMHO.) They can be used 
> to work around some of Ada's other limitations.

Even so, pointers were introduced in C and Java to for a reason. If this
reason did not apply to Ada, then programmers would have ignored anonymous
access types as superfluous. That did not happen.

> In any case, it appears likely that Amendment 2 will repeal the prohibition 
> on "in out" parameters on functions (adding a conservative call check to 
> prevent obvious ordering dependencies).

Promising...

> We're also planning on adding a way to force by-reference parameter passing. 
> The motivating use is for the containers, but I'm sure it will find other 
> uses as well.

This makes no sense to me. It is another mistake of making after C++. There
is no reason why by-reference must be enforced anywhere if not required by
the type.

> As far as the use of class-wide components, I think that would be easily 
> fixed by just allowing them.

That would make objects non-contiguous. It is not obvious to me how that
will work with streams and pools. I prefer a more transparent model when
all components of a constrained object are constrained.

> That would reduce the need to use access types some more. (But it can never 
> be completely eliminated; sometimes you really do need reference semantics, 
> especially for returns.)

No, this is the mental trap. If something requires by-reference semantics
that is not a return. Considering containers:

   A (I) := X;

It is a semantic mistake to treat A (I) as a function "returning"
something. This can only lead to introducing more and more strange
constructs like limited aggregates, return statements and other mess. 

   A (I) := X;

must be treated as a syntax sugar for a procedure call

   Put (A, I, X);

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