From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Issue with GNAT GPL 2009 and GtkAda
Date: Tue, 30 Jun 2009 10:31:29 +0200
Date: 2009-06-30T10:28:16+02:00 [thread overview]
Message-ID: <1rq9846uwv807.qsr8exwb1sf9.dlg@40tude.net> (raw)
In-Reply-To: h2bdhm$cme$1@munin.nbi.dk
On Mon, 29 Jun 2009 16:59:40 -0500, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:u7txi934iaog$.gw40yhq8811x.dlg@40tude.net...
>> On Fri, 26 Jun 2009 16:38:45 -0500, Randy Brukardt wrote:
> ...
>>> 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.
>
> Well, Ada has always allowed non-continguous objects. There is no problem
> with streams: the stream attributes take care of any non-contiguous parts.
> As for pools, multiple calls to Allocate are allowed; again there is no
> requirement that the objects are contiguous. (That's been confirmed by
> AI05-0107-1, but it has always been true for Ada 95; there are plenty of
> AARM notes making that clear).
OK, but I still feel bad about it. (:-))
>>> 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);
>
> That works for full object assignment, but not in any sane way for in-place
> component updating. And full object assignment really doesn't need any
> special syntax (Replace_Element works just fine); the problem is when you
> need to update a single element of a container which is itself an element.
Ah, that is an interesting issue. Let us compare it on the example of
multi-dimensional arrays. Should A(I,J) should better be A(I)(J)?
I do not think that LHS indexing is "composable" in "C-way" without further
assumptions. It should not be taken for granted. In cases of genuine
reference semantics I would prefer a container of controlled access types
to T rather than a container of aliased T returned by reference. I want it
explicit like it is now:
type Container is array (...) of access T;
What is missing is finalization of access T by Unchecked_Deallocation and
assignment T to access T by new T'(...).
BTW, the public view of such container could be array of T. For example:
type Container is array (...) of T is private; -- Not Ada!
private
type Container is array (...) of access T;
-- implementation per controlled references
> It doesn't make sense to try to think of these sorts of operations as a
> single procedure.
Why not? In general case of container composition, I would indeed provide
the syntax:
A (I, J, ...) := X;
implemented by a primitive operation
Put (A, I, J, ..., X);
With introducing index types (tuples) it does not depend on dimension:
Put (A, (I, J, ...), X);
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
next prev parent reply other threads:[~2009-06-30 8:31 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-23 21:52 Issue with GNAT GPL 2009 and GtkAda Damien Carbonne
2009-06-24 7:40 ` Dmitry A. Kazakov
2009-06-24 10:15 ` Stephen Leake
2009-06-25 9:06 ` Stephen Leake
2009-06-25 9:39 ` Dmitry A. Kazakov
2009-06-25 19:02 ` Damien Carbonne
2009-06-26 9:31 ` Stephen Leake
2009-06-26 11:18 ` Niklas Holsti
2009-06-26 16:29 ` Damien Carbonne
2009-06-26 17:28 ` Dmitry A. Kazakov
2009-06-26 19:27 ` Damien Carbonne
2009-06-26 19:50 ` Dmitry A. Kazakov
2009-06-26 21:51 ` Randy Brukardt
2009-06-27 11:11 ` Stephen Leake
2009-06-27 17:04 ` Robert A Duff
2009-06-30 11:11 ` Stephen Leake
2009-06-30 18:10 ` Robert A Duff
2009-06-29 22:11 ` Randy Brukardt
2009-06-30 11:13 ` Stephen Leake
2009-06-30 15:26 ` Adam Beneschan
2009-06-30 15:59 ` Adam Beneschan
2009-06-30 23:11 ` Randy Brukardt
2009-06-27 9:56 ` Stephen Leake
2009-06-26 21:03 ` Damien Carbonne
2009-06-27 11:21 ` Stephen Leake
2009-06-27 12:25 ` Damien Carbonne
2009-06-27 12:35 ` Damien Carbonne
2009-06-29 22:15 ` Randy Brukardt
2009-07-01 19:22 ` Damien Carbonne
2009-06-30 0:48 ` Adam Beneschan
2009-06-30 11:18 ` Stephen Leake
2009-06-25 20:49 ` Randy Brukardt
2009-06-26 7:20 ` Dmitry A. Kazakov
2009-06-26 8:17 ` Georg Bauhaus
2009-06-26 8:52 ` Dmitry A. Kazakov
2009-06-26 21:38 ` Randy Brukardt
2009-06-27 7:47 ` Dmitry A. Kazakov
2009-06-29 21:59 ` Randy Brukardt
2009-06-30 8:31 ` Dmitry A. Kazakov [this message]
2009-06-26 21:31 ` Randy Brukardt
2009-06-27 7:53 ` Dmitry A. Kazakov
2009-06-26 8:39 ` Alex R. Mosteo
2009-06-26 9:07 ` Dmitry A. Kazakov
2009-06-27 9:53 ` Stephen Leake
2009-06-26 21:40 ` Randy Brukardt
2009-06-29 10:04 ` Alex R. Mosteo
2009-06-26 9:02 ` Stephen Leake
2009-06-26 9:14 ` Dmitry A. Kazakov
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox