Legit Warnings or not

Legit Warnings or not

[Anh Vo]

package Warnings_Legit is

   type Warned_Person (Size : Positive := 10) is -- Warnings issued
here
      record
         Name : String (1 .. Size);
      end record;

   type Acceptable_Person (Size : Positive) is
      record
         Name : String (1 .. Size);
      end record;

end Warnings_Legit;

The code segment above triggers a warnings message 'creation of
"Warned_Person" object may raise Storage_Error' at line 3 as marked.
However, no warnings is issued at line 8. The difference between them
is default discriminant. I am using GNAT-GPL-2011.

Is this warnings legitimate? If yes, why line 8 is OK. Otherwise,
should it be a bug?

Anh Vo

Re: Legit Warnings or not

[Robert A Duff]

Anh Vo <anhvofrcaus@gmail.com> writes:

> package Warnings_Legit is
>
>    type Warned_Person (Size : Positive := 10) is -- Warnings issued
> here
>       record
>          Name : String (1 .. Size);
>       end record;
>
>    type Acceptable_Person (Size : Positive) is
>       record
>          Name : String (1 .. Size);
>       end record;
>
> end Warnings_Legit;
>
> The code segment above triggers a warnings message 'creation of
> "Warned_Person" object may raise Storage_Error' at line 3 as marked.
> However, no warnings is issued at line 8. The difference between them
> is default discriminant. I am using GNAT-GPL-2011.

There's a confusing rule in Ada:  If it has defaults, there can be
unconstrained objects of that type (and also constrained ones).
If it doesn't have defaults, then all objects must be constrained.

So if you say "X : Warned_Person;", GNAT will allocate space for
billions of characters (not just 10) because you might assign
a bigger one (like "X := (Size => 1_000_000, Name => Something)").

> Is this warnings legitimate? If yes, why line 8 is OK. Otherwise,
> should it be a bug?

It's not a bug.  An object of type Warned_Person might need huge amounts
of memory, so Storage_Error might well be raised.  It's illegal to say
"X : Acceptable_Person;", so that one doesn't get a warning.

If you want unconstrained objects, use a reasonably-small size, like:

   subtype Name_Length is Natural range 0..1000;

   type Not_Warned_Person (Size : Name_Length := 0) is
      record
         Name : String (1 .. Size);
      end record;

Unconstrained objects of type Not_Warned_Person will then require space
for 1000 characters.

On the other hand, if you don't want unconstrained objects, don't give a
default (as in your Acceptable_Person).

- Bob

Re: Legit Warnings or not

[Anh Vo]

On Jul 20, 4:16 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Anh Vo <anhvofrc...@gmail.com> writes:
>
> > The code segment above triggers a warnings message 'creation of
> > "Warned_Person" object may raise Storage_Error' at line 3 as marked.
> > However, no warnings is issued at line 8. The difference between them
> > is default discriminant. I am using GNAT-GPL-2011.
>
> There's a confusing rule in Ada:  If it has defaults, there can be
> unconstrained objects of that type (and also constrained ones).
> If it doesn't have defaults, then all objects must be constrained.
>
> So if you say "X : Warned_Person;", GNAT will allocate space for
> billions of characters (not just 10) because you might assign
> a bigger one (like "X := (Size => 1_000_000, Name => Something)").
>
> > Is this warnings legitimate? If yes, why line 8 is OK. Otherwise,
> > should it be a bug?
>
> It's not a bug.  An object of type Warned_Person might need huge amounts
> of memory, so Storage_Error might well be raised.  It's illegal to say
> "X : Acceptable_Person;", so that one doesn't get a warning.

I got it now. Thanks.

> If you want unconstrained objects, use a reasonably-small size, like:
>
>    subtype Name_Length is Natural range 0..1000;
>
>    type Not_Warned_Person (Size : Name_Length := 0) is
>       record
>          Name : String (1 .. Size);
>       end record;

Good suggestion. Again, thanks.

Anh Vo

Re: Legit Warnings or not

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccy5zslezc.fsf@shell01.TheWorld.com...
...
>> The code segment above triggers a warnings message 'creation of
>> "Warned_Person" object may raise Storage_Error' at line 3 as marked.
>> However, no warnings is issued at line 8. The difference between them
>> is default discriminant. I am using GNAT-GPL-2011.
>
> There's a confusing rule in Ada:  If it has defaults, there can be
> unconstrained objects of that type (and also constrained ones).
> If it doesn't have defaults, then all objects must be constrained.
>
> So if you say "X : Warned_Person;", GNAT will allocate space for
> billions of characters (not just 10) because you might assign
> a bigger one (like "X := (Size => 1_000_000, Name => Something)").

Right, but I personally consider this a bug. The bug is in the Ada market 
(and ACATS) in that implementations that do this by default are allowed --  
it's not a bug in the Ada standard or a bug with GNAT (this is commonly 
accepted -- by everyone other than me) behavior.

>> Is this warnings legitimate? If yes, why line 8 is OK. Otherwise,
>> should it be a bug?
>
> It's not a bug.  An object of type Warned_Person might need huge amounts
> of memory, so Storage_Error might well be raised.

And that to me is a bug. It's not that hard to implement on-demand 
allocation if the object turns out to be huge.

I understand the requirements to avoid secondary allocation and the like, 
and it makes perfect sense to me for this behavior to occur when certain 
restrictions are in place. But it doesn't make sense to me for this behavior 
to be the default. It makes Ada less useful than it otherwise would be, and 
often forces programmers to use access types when they otherwise would not 
need them. The fewer explicit access types in a program, the better!!

                                    Randy.

Re: Legit Warnings or not

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Right, but I personally consider this a bug. The bug is in the Ada market 
> (and ACATS) in that implementations that do this by default are allowed --  
> it's not a bug in the Ada standard or a bug with GNAT (this is commonly 
> accepted -- by everyone other than me) behavior.

No, not everyone other than you.  There are lots of folks who agree
with you on this point.

>>> Is this warnings legitimate? If yes, why line 8 is OK. Otherwise,
>>> should it be a bug?
>>
>> It's not a bug.  An object of type Warned_Person might need huge amounts
>> of memory, so Storage_Error might well be raised.
>
> And that to me is a bug. It's not that hard to implement on-demand 
> allocation if the object turns out to be huge.
>
> I understand the requirements to avoid secondary allocation and the like, 
> and it makes perfect sense to me for this behavior to occur when certain 
> restrictions are in place. But it doesn't make sense to me for this behavior 
> to be the default. It makes Ada less useful than it otherwise would be, and 
> often forces programmers to use access types when they otherwise would not 
> need them. The fewer explicit access types in a program, the better!!

Pragma Restrictions is one of my favorite features.  I'd be perfectly
happy if the language had all sorts of features that require implicit
pointers and implicit heap allocation, so long as there's a Restriction
to turn that off.  And maybe also a feature to control which storage
pool is used.  For example, I think "X : String;" should be allowed,
both as a stand-alone variable and as a record component.
And "array (...) of String".

But none of that is allowed in Ada, which makes me think the original
designers went to a lot of trouble to avoid implicit heap allocation,
which makes me lean toward the "allocate-the-max" implementation
for defaulted-discrims.  But I do have some sympathy for the opposite
view.

I also think all Ada compilers should do it the same way.  Perhaps if
Ada 83 had had some Implementation Requirement/Advice pushing in one
or the other direction, that would have happened.  It's "just an
efficiency issue" (wasted space, versus wasted alloc/dealloc time),
but it's such a huge one that in practice it's really a functionality
issue.

- Bob

Re: Legit Warnings or not

[Jeffrey Carter]

On 07/20/2011 03:30 PM, Anh Vo wrote:
> package Warnings_Legit is
>
>     type Warned_Person (Size : Positive := 10) is -- Warnings issued
> here
>        record
>           Name : String (1 .. Size);
>        end record;
>
>     type Acceptable_Person (Size : Positive) is
>        record
>           Name : String (1 .. Size);
>        end record;
>
> end Warnings_Legit;
>
> The code segment above triggers a warnings message 'creation of
> "Warned_Person" object may raise Storage_Error' at line 3 as marked.
> However, no warnings is issued at line 8. The difference between them
> is default discriminant. I am using GNAT-GPL-2011.
>
> Is this warnings legitimate? If yes, why line 8 is OK. Otherwise,
> should it be a bug?

Duff has given you a good answer as to why GNAT has that warning. What he didn't 
say is that some compilers not only won't give any warning, but a declaration of

X : Warned_Person;

will not raise Storage_Error on those compilers, either.

There are 2 ways to handle such unconstrained objects. The easy way, which GNAT 
uses, is to allocate enough space for the largest variant. The harder way only 
allocates enough space for the current value, and actually changes the space of 
the object if the size is changed through an assignment.

Some who have gone to the trouble to implement the 2nd way say they think it was 
the intention of the language designers.

-- 
Jeff Carter
"He didn't get that nose from playing ping-pong."
Never Give a Sucker an Even Break
110

Re: Legit Warnings or not

[Brian Drummond]

On Wed, 20 Jul 2011 19:37:48 -0700, Jeffrey Carter wrote:

> On 07/20/2011 03:30 PM, Anh Vo wrote:
>> package Warnings_Legit is
>>
>>     type Warned_Person (Size : Positive := 10) is -- Warnings issued
>> here
>>        record
>>           Name : String (1 .. Size);
>>        end record;
> some compilers not only won't give any warning,
> but a declaration of
> 
> X : Warned_Person;
> 
> will not raise Storage_Error on those compilers, either.
[...]
> The harder way only allocates enough space for the current value, and
> actually changes the space of the object if the size is changed through
> an assignment.
> 
> Some who have gone to the trouble to implement the 2nd way say they
> think it was the intention of the language designers.

Interesting. Do you mean they allocate a new object?
Then how do they handle the following declarations   
   X : aliased Warned_Person;
   Y : access Warned_Person := X'access;
when X.Name is resized?

- Brian

Re: Legit Warnings or not

[Dmitry A. Kazakov]

On Thu, 21 Jul 2011 09:50:26 +0000 (UTC), Brian Drummond wrote:

> Interesting. Do you mean they allocate a new object?

New implementation of.

> Then how do they handle the following declarations   
>    X : aliased Warned_Person;
>    Y : access Warned_Person := X'access;
> when X.Name is resized?

There exist approaches to this:

1. The varying component can allocated outside the object. The object would
keep a reference to it.

2. The access types to the object can be fat pointers or indirect pointers.
E.g. Y may actually point to a descriptor keeping a pointer to the object.

3. "aliased" can be disabled for roaming objects.

4. Certain types of access can be disabled, eventually allowing only
downward closures of the object.

Except for #1 aliasing is a problem:

   procedure Foo (X : in out Warned_Person; Y : Warned_Person) is
   begin
      X := ...; -- Changes the object

   Foo (X, X); -- Will Y be consistent in Foo?

I think that Ada should not try to support this stuff. The proper way to
handle this IMO is to allow the programmer to implement it himself by
making the component "Name" a primitive operation (getter/setter). I don't
know how close "aspects" are to this but this would be the right way.

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

Re: Legit Warnings or not

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1rx6dwrxmc81p.eazb4fjqztox$.dlg@40tude.net...
...
> There exist approaches to this:
>
> 1. The varying component can allocated outside the object. The object 
> would
> keep a reference to it.

This is the only approach that works for Ada (at least as far as I can 
tell). And it already works for Janus/Ada; we've used it as long as we've 
have discriminanted components (late 1980s).

...
> I think that Ada should not try to support this stuff.

Ada *does* support this stuff. As Adam noted, there are rules preventing the 
creation of accesses/renames of/into components that might change size. 
There also are rules supporting allocation/deallocation of objects that have 
multiple parts. So far as I know, those are the only rules needed to do so.

And, as noted, Janus/Ada always has worked this way. I originally thought 
Ada compilers were expected to work this way, because there is no good 
reason not to support this as the default (as noted, some target 
environments might not want such objects, and pragma Restrictions can surely 
be used to prevent them from being generated). But apparently, implementers 
are lazy enough to avoid it, and customers have never pushed hard enough to 
get it added as an option.

                                   Randy.

Re: Legit Warnings or not

[Dmitry A. Kazakov]

On Fri, 22 Jul 2011 19:36:26 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1rx6dwrxmc81p.eazb4fjqztox$.dlg@40tude.net...
> ...
>> I think that Ada should not try to support this stuff.
> 
> Ada *does* support this stuff. As Adam noted, there are rules preventing the 
> creation of accesses/renames of/into components that might change size.

But it should not. Programmers expect types constructed by the compiler be
contiguous in their private view.

> There also are rules supporting allocation/deallocation of objects that have 
> multiple parts. So far as I know, those are the only rules needed to do so.

Meaningful X'Size? Expectations in an implementation of
Ada.Finalization.Adjust?

> There also are rules supporting allocation/deallocation of objects that have 
> multiple parts. So far as I know, those are the only rules needed to do so.

E.g. in a user-defined specific pool?

> And, as noted, Janus/Ada always has worked this way. I originally thought 
> Ada compilers were expected to work this way, because there is no good 
> reason not to support this as the default (as noted, some target 
> environments might not want such objects, and pragma Restrictions can surely 
> be used to prevent them from being generated). But apparently, implementers 
> are lazy enough to avoid it, and customers have never pushed hard enough to 
> get it added as an option.

As a customer I see that the language separates definite and indefinite
types. If this distinction is necessary, then the same logic applies to the
implementation. I prefer transparent and simple implementations in order to
know what to expect. In cases where I need referential semantics I prefer
to implement it by myself, rather than to rely on the compiler.

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

Re: Legit Warnings or not

[Simon Wright]

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

> But it should not. Programmers expect types constructed by the
> compiler be contiguous in their private view.

Maybe, but if they have no reason to care (eg, they're not at a
communications boundary) why should they care? I might have all sorts of
expectations about what the compiler might do (vide recent discussions
in this thread).

Re: Legit Warnings or not

[Dmitry A. Kazakov]

On Sat, 23 Jul 2011 12:07:28 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> But it should not. Programmers expect types constructed by the
>> compiler be contiguous in their private view.
> 
> Maybe, but if they have no reason to care (eg, they're not at a
> communications boundary) why should they care?

They should not if the semantics does not change. But it seems that this is
too difficult to ensure when the type is used as a building block for other
types.

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

Re: Legit Warnings or not

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:bvr7wfbofhal$.10mess7c3uv9j.dlg@40tude.net...
> On Fri, 22 Jul 2011 19:36:26 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1rx6dwrxmc81p.eazb4fjqztox$.dlg@40tude.net...
>> ...
>>> I think that Ada should not try to support this stuff.
>>
>> Ada *does* support this stuff. As Adam noted, there are rules preventing 
>> the
>> creation of accesses/renames of/into components that might change size.
>
> But it should not. Programmers expect types constructed by the compiler be
> contiguous in their private view.

Why? Only the semantics of the objects should matter to the programmer; the 
rest of it should be left to the implementers.

Besides that, it is impossible to implement Ada with solely contiguous 
objects -- the ability to pass slices means that array descriptors and the 
actual data have to be handled separately. These clearly are parts of a 
single object (you cannot replicate the semantics of the Ada object without 
the descriptor part).

>> There also are rules supporting allocation/deallocation of objects that 
>> have
>> multiple parts. So far as I know, those are the only rules needed to do 
>> so.
>
> Meaningful X'Size?

X'Size is not meaningful for unconstrained types and never has been. I'd 
probably go further and say that the language definition is 'Size is close 
to useless; only what GNAT calls 'Object_Size is valuable (and it is 
unfortunate that we couldn't get agreement to put that into the language).

> Expectations in an implementation of
> Ada.Finalization.Adjust?

The semantics of the language doesn't care if objects are contiguous or not. 
This is all invisible to the programmer if done right.

>> There also are rules supporting allocation/deallocation of objects that 
>> have
>> multiple parts. So far as I know, those are the only rules needed to do 
>> so.
>
> E.g. in a user-defined specific pool?

Correct; the language allows multiple calls to Allocate for a single use of 
"new". It also allows Allocate to be called on assignment if the object 
needs to change size (by far the most complex part of handling mutable 
objects properly).

>> And, as noted, Janus/Ada always has worked this way. I originally thought
>> Ada compilers were expected to work this way, because there is no good
>> reason not to support this as the default (as noted, some target
>> environments might not want such objects, and pragma Restrictions can 
>> surely
>> be used to prevent them from being generated). But apparently, 
>> implementers
>> are lazy enough to avoid it, and customers have never pushed hard enough 
>> to
>> get it added as an option.
>
> As a customer I see that the language separates definite and indefinite
> types. If this distinction is necessary, then the same logic applies to 
> the
> implementation. I prefer transparent and simple implementations in order 
> to
> know what to expect. In cases where I need referential semantics I prefer
> to implement it by myself, rather than to rely on the compiler.

I don't think the distinction between definite and indefinite types IS 
necessary; it just one of many expediencies in the Ada language designed to 
ease implementation. They don't always help, and there is little value to 
forcing the same mistake on users.

                                  Randy.

Re: Legit Warnings or not

[Dmitry A. Kazakov]

On Tue, 26 Jul 2011 16:25:03 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:bvr7wfbofhal$.10mess7c3uv9j.dlg@40tude.net...
>> On Fri, 22 Jul 2011 19:36:26 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:1rx6dwrxmc81p.eazb4fjqztox$.dlg@40tude.net...
>>> ...
>>>> I think that Ada should not try to support this stuff.
>>>
>>> Ada *does* support this stuff. As Adam noted, there are rules preventing 
>>> the
>>> creation of accesses/renames of/into components that might change size.
>>
>> But it should not. Programmers expect types constructed by the compiler be
>> contiguous in their private view.
> 
> Why? Only the semantics of the objects should matter to the programmer; the 
> rest of it should be left to the implementers.

Yes, but 'Size, 'Address, 'Access, ":=" (deep vs. shallow), "=" (identity
vs. equality) are parts of the semantics, which aren't invariant to the
implementation.

> Besides that, it is impossible to implement Ada with solely contiguous 
> objects -- the ability to pass slices means that array descriptors and the 
> actual data have to be handled separately.

To the programmer constraints are not a part of the object. E.g. it is OK
to have discriminants and bounds allocated elsewhere or not allocated at
all.

>> Expectations in an implementation of
>> Ada.Finalization.Adjust?
> 
> The semantics of the language doesn't care if objects are contiguous or not. 
> This is all invisible to the programmer if done right.

This presumes a definition of the semantics of "bitwise copy". What is to
be copied before Adjust called? (The idea behind Adjust is broken anyway)
 
>>> There also are rules supporting allocation/deallocation of objects that have
>>> multiple parts. So far as I know, those are the only rules needed to do 
>>> so.
>>
>> E.g. in a user-defined specific pool?
> 
> Correct; the language allows multiple calls to Allocate for a single use of 
> "new".

Does it require this? How to enforce all parts to land into a pool? It can
be crucial for certain implementations.

>> As a customer I see that the language separates definite and indefinite
>> types. If this distinction is necessary, then the same logic applies to the
>> implementation. I prefer transparent and simple implementations in order to
>> know what to expect. In cases where I need referential semantics I prefer
>> to implement it by myself, rather than to rely on the compiler.
> 
> I don't think the distinction between definite and indefinite types IS 
> necessary; it just one of many expediencies in the Ada language designed to 
> ease implementation. They don't always help, and there is little value to 
> forcing the same mistake on users.

This is the core issue. I think it is important to have this distinction as
well as contiguous objects in order to be able to use the language for
low-level programming. I want Ada to remain a universal programming
language.

I also think that a fully by-reference Java-like type system would be
necessarily inconsistent and incomplete.

I prefer a simpler language with means to hide references behind primitive
operations accessing fake components, fake array element etc. Moving the
mess to the library level. E.g. it should be OK to declare

   type A is array (...) of S'Class;

but not as an implementation, because there could be many of them. Instead
of the compiler vendor choosing one for me, I prefer to make my own choice
out of several library implementations, or be able to implement it myself.

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

Re: Legit Warnings or not

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1hi6gva8jhf7o.tq1yp29jn3qu.dlg@40tude.net...
> On Tue, 26 Jul 2011 16:25:03 -0500, Randy Brukardt wrote:
...
>> Why? Only the semantics of the objects should matter to the programmer; 
>> the
>> rest of it should be left to the implementers.
>
> Yes, but 'Size, 'Address, 'Access, ":=" (deep vs. shallow), "=" (identity
> vs. equality) are parts of the semantics, which aren't invariant to the
> implementation.

'Address is obsolete junk that should never be used in new code (with the 
possible exception of static address clauses). For both 'Size and 'Address, 
they are meaningless in general unless the type is elementary or has a 
representation clause requiring a continuous representation.

All of the other things are high-level concepts which work the same whether 
or not the objects are contiguous. ":=" and "=" are defined in terms of the 
subcomponents, 'Access provides an access to the object - the compiler has 
to chose the same representation for all such (aliased) objects, but there 
is no need for it to be contiguous.

>> Besides that, it is impossible to implement Ada with solely contiguous
>> objects -- the ability to pass slices means that array descriptors and 
>> the
>> actual data have to be handled separately.
>
> To the programmer constraints are not a part of the object. E.g. it is OK
> to have discriminants and bounds allocated elsewhere or not allocated at
> all.

Maybe that's the way you think of these, but I'm sure it's not universal. 
Discriminants, in particular, are defined by the language to be part of the 
object. And in any case, you are saying that discontiguous representations 
are fine so long as you think they are good idea. When did you get elected 
to be in charge of programmers? :-)

>>> Expectations in an implementation of
>>> Ada.Finalization.Adjust?
>>
>> The semantics of the language doesn't care if objects are contiguous or 
>> not.
>> This is all invisible to the programmer if done right.
>
> This presumes a definition of the semantics of "bitwise copy". What is to
> be copied before Adjust called? (The idea behind Adjust is broken anyway)

The phrase "bit-wise copy" does not appear in the Standard, and plays no 
role in the formal definition of assignment and Adjust. ("bitwise" as you 
spelled it doesn't appear in the Standard or AARM at all.) I assume you got 
that from some informal description of how assignment works, but that's 
irrelevant in terms of a description of the language.

Assignment of composite types is defined in terms of assigning all of the 
(elementary) subcomponents of the type (and then calling Adjust as needed). 
That does not require contiguous objects.

>>>> There also are rules supporting allocation/deallocation of objects that 
>>>> have
>>>> multiple parts. So far as I know, those are the only rules needed to do
>>>> so.
>>>
>>> E.g. in a user-defined specific pool?
>>
>> Correct; the language allows multiple calls to Allocate for a single use 
>> of
>> "new".
>
> Does it require this? How to enforce all parts to land into a pool? It can
> be crucial for certain implementations.

Require what? All of the parts of an designated object have to come from the 
same pool (I don't know how else it could work), the pool associated with 
the access type that the allocation is for -- that's the language 
requirement for "new". But there is no requirement that it be exactly one 
part.

>>> As a customer I see that the language separates definite and indefinite
>>> types. If this distinction is necessary, then the same logic applies to 
>>> the
>>> implementation. I prefer transparent and simple implementations in order 
>>> to
>>> know what to expect. In cases where I need referential semantics I 
>>> prefer
>>> to implement it by myself, rather than to rely on the compiler.
>>
>> I don't think the distinction between definite and indefinite types IS
>> necessary; it just one of many expediencies in the Ada language designed 
>> to
>> ease implementation. They don't always help, and there is little value to
>> forcing the same mistake on users.
>
> This is the core issue. I think it is important to have this distinction 
> as
> well as contiguous objects in order to be able to use the language for
> low-level programming. I want Ada to remain a universal programming
> language.

If you want contiguous objects to do low-level programming, I think it is 
reasonable to require you to declare that fact to the compiler. And a 
compiler that never supported such objects would clearly be a problem. But 
to require implementations to *never* use multiple parts for an object 
because someone, somewhere, might use some types for low-level programming 
is silly.

After all, you can't use an Ada.Container type for low-level programming. 
Does that mean that Ada should not have container types?

> I also think that a fully by-reference Java-like type system would be
> necessarily inconsistent and incomplete.

I don't want or advocate requiring much of anything to be by-reference. But 
I think that Ada compilers should be able to do the easy things (like 
T'Class and discriminant-dependent arrays) for clients without burdening 
them with the details.

> I prefer a simpler language with means to hide references behind primitive
> operations accessing fake components, fake array element etc. Moving the
> mess to the library level. E.g. it should be OK to declare
>
>   type A is array (...) of S'Class;
>
> but not as an implementation, because there could be many of them. Instead
> of the compiler vendor choosing one for me, I prefer to make my own choice
> out of several library implementations, or be able to implement it myself.

Experience with containers shows that no one would use such things unless 
they were part of the predefined libraries. (Hardly any containers got any 
traction at all until Ada 2005 came along, even though they were plenty easy 
to define in any version of Ada.) So hardly anyone would use such 
abstractions.

Moreover, you cannot create a *better* implementation than the one 
built-into the compiler (which doesn't have to have overhead to enforce 
Ada's rules as any abstracted version would). You might be able to generate 
one that works as well, but it would take heroic efforts in code generation 
to do so. (Keep in mind that hardly any compilers optimize finalization, 
even though it is possible and reasonably practical, mainly because of the 
difficulty of allowing arbitrary user code in such optimizations. The same 
would be true for your sorts of abstractions.)

In any case, what I want is more power and more flexibility from Ada 
compilers (to do both contiguous and non-contiguous objects) to let the 
compiler do more hard work, rather than the programmer. You seem to want the 
programmer to work harder (and apparently never want anyone to use dynamic 
array objects in Ada, since those have the sort of implicit-reference 
semantics that you claim to hate). And it seems that further discussion is a 
waste of time, since there is no reason for either of us to change our 
opinions on this basic topic.

                                         Randy.

Re: Legit Warnings or not

[Dmitry A. Kazakov]

On Wed, 27 Jul 2011 19:37:55 -0500, Randy Brukardt wrote:

> 'Address is obsolete junk that should never be used in new code (with the 
> possible exception of static address clauses). For both 'Size and 'Address, 
> they are meaningless in general unless the type is elementary or has a 
> representation clause requiring a continuous representation.

And conversely, if types are "elementary", then 'Size and 'Address are not
junk.

> All of the other things are high-level concepts which work the same whether 
> or not the objects are contiguous. ":=" and "=" are defined in terms of the 
> subcomponents,

which is ambiguous when components are referential. Does ":=" copy the
reference or the target object?

>>> Besides that, it is impossible to implement Ada with solely contiguous
>>> objects -- the ability to pass slices means that array descriptors and 
>>> the
>>> actual data have to be handled separately.
>>
>> To the programmer constraints are not a part of the object. E.g. it is OK
>> to have discriminants and bounds allocated elsewhere or not allocated at
>> all.
> 
> Maybe that's the way you think of these, but I'm sure it's not universal. 
> Discriminants, in particular, are defined by the language to be part of the 
> object.

That was an error. They should have been handled in the way array bounds
are. The same does apply to the type tag.

> And in any case, you are saying that discontiguous representations 
> are fine so long as you think they are good idea.

I don't consider constraints and more generally the type information a
"representation".

> When did you get elected to be in charge of programmers? :-)

Because I am not a compiler vendor! (:-))

>>> Correct; the language allows multiple calls to Allocate for a single use 
>>> of "new".
>>
>> Does it require this? How to enforce all parts to land into a pool? It can
>> be crucial for certain implementations.
> 
> Require what? All of the parts of an designated object have to come from the 
> same pool (I don't know how else it could work),

It could allocate some components in other pools. Unrelated but similar,
when Unbounded_String is a component it is not required that its body were
allocated in the container's pool. Is it?

> the pool associated with 
> the access type that the allocation is for -- that's the language 
> requirement for "new".

which is ill-defined if 'Size is. I understand that there are object parts
which are "more parts" than other "parts". And I don't like it.

>> This is the core issue. I think it is important to have this distinction as
>> well as contiguous objects in order to be able to use the language for
>> low-level programming. I want Ada to remain a universal programming
>> language.
> 
> If you want contiguous objects to do low-level programming, I think it is 
> reasonable to require you to declare that fact to the compiler. And a 
> compiler that never supported such objects would clearly be a problem. But 
> to require implementations to *never* use multiple parts for an object 
> because someone, somewhere, might use some types for low-level programming 
> is silly.
> 
> After all, you can't use an Ada.Container type for low-level programming. 
> Does that mean that Ada should not have container types?

No, and that is my point, It is fully OK to have non-contiguous objects at
the library level, but I want all "magical" objects be strictly contiguous
(maybe, except for tasks). They are atomic building blocks of which
semantics must be lucid. Ada.Container types are not atomic in their
private views.

>> I also think that a fully by-reference Java-like type system would be
>> necessarily inconsistent and incomplete.
> 
> I don't want or advocate requiring much of anything to be by-reference. But 
> I think that Ada compilers should be able to do the easy things (like 
> T'Class and discriminant-dependent arrays) for clients without burdening 
> them with the details.

This is what I want too. But I don't want to push it into the language
"magic". I want it laid open.

>> I prefer a simpler language with means to hide references behind primitive
>> operations accessing fake components, fake array element etc. Moving the
>> mess to the library level. E.g. it should be OK to declare
>>
>>   type A is array (...) of S'Class;
>>
>> but not as an implementation, because there could be many of them. Instead
>> of the compiler vendor choosing one for me, I prefer to make my own choice
>> out of several library implementations, or be able to implement it myself.
> 
> Experience with containers shows that no one would use such things unless 
> they were part of the predefined libraries.

What experience? It never was possible in Ada.

> Moreover, you cannot create a *better* implementation than the one 
> built-into the compiler

See, this is where you approach leads.

> (Keep in mind that hardly any compilers optimize finalization, 
> even though it is possible and reasonably practical, mainly because of the 
> difficulty of allowing arbitrary user code in such optimizations. The same 
> would be true for your sorts of abstractions.)

Maybe because compiler vendors are too overwhelmed by implementing more and
more magical stuff?
 
> You seem to want the 
> programmer to work harder (and apparently never want anyone to use dynamic 
> array objects in Ada, since those have the sort of implicit-reference 
> semantics that you claim to hate).

No, I want that dynamic arrays were *arrays*. I want that Ada.Container
could be selected as an implementation of that array by mere renaming or
other kind of delegation:

   type A is array (Positive range <>) of S'Class;
private
   package My_Arrays is
      new Ada.Container.Indefinite_Vector (Positive, S'Class);
   type A is new My_Array.Container_Type with null record;

Is it too much?

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

Re: Legit Warnings or not

[Robert A Duff]

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

> On Wed, 27 Jul 2011 19:37:55 -0500, Randy Brukardt wrote:

>> All of the other things are high-level concepts which work the same whether 
>> or not the objects are contiguous. ":=" and "=" are defined in terms of the 
>> subcomponents,
>
> which is ambiguous when components are referential. Does ":=" copy the
> reference or the target object?

There's no ambiguity.  "X := Y;" copies all components of Y.
If the compiler chooses to implement some of those components
via some sort of indirection, then ":=" will need to do a deep copy,
in general.

The indirection must be invisible (except, as you mentioned, for
low-level stuff like 'Size and Unchecked_Conversion).

- Bob

Re: Legit Warnings or not

[Dmitry A. Kazakov]

On Thu, 28 Jul 2011 10:22:28 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Wed, 27 Jul 2011 19:37:55 -0500, Randy Brukardt wrote:
> 
>>> All of the other things are high-level concepts which work the same whether 
>>> or not the objects are contiguous. ":=" and "=" are defined in terms of the 
>>> subcomponents,
>>
>> which is ambiguous when components are referential. Does ":=" copy the
>> reference or the target object?
> 
> There's no ambiguity.  "X := Y;" copies all components of Y.
> If the compiler chooses to implement some of those components
> via some sort of indirection, then ":=" will need to do a deep copy,
> in general.

So the compiler is not allowed to do reference counting with cloning upon
update?

> The indirection must be invisible (except, as you mentioned, for
> low-level stuff like 'Size and Unchecked_Conversion).

I.e. it leaks.

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

Re: Legit Warnings or not

[Robert A Duff]

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

> On Thu, 28 Jul 2011 10:22:28 -0400, Robert A Duff wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Wed, 27 Jul 2011 19:37:55 -0500, Randy Brukardt wrote:
>> 
>>>> All of the other things are high-level concepts which work the same whether 
>>>> or not the objects are contiguous. ":=" and "=" are defined in terms of the 
>>>> subcomponents,
>>>
>>> which is ambiguous when components are referential. Does ":=" copy the
>>> reference or the target object?
>> 
>> There's no ambiguity.  "X := Y;" copies all components of Y.
>> If the compiler chooses to implement some of those components
>> via some sort of indirection, then ":=" will need to do a deep copy,
>> in general.
>
> So the compiler is not allowed to do reference counting with cloning upon
> update?

Sure it is.  The compiler can do anything it likes, so long as the
external behavior obeys the RM.

That's the "as if" rule.  Which isn't really a rule -- more of a "meta
rule" which applies to all higher-level programming language
definitions, whether the language definition says so or not.  That's the
difference between an assembly language and a higher-level language --
the "as if" meta-rule doesn't apply to assembly languages.

So yes, the compiler can do the deep copy in a lazy fashion, as you
suggest.  There are lots of other things the compiler can do.  For
example:

    X : constant String := Func(...);
    Y : constant String := X;

The compiler can allocate X and Y (or parts of them) at the same
memory location.  And X'Address could equal Y'Address.

Without the "constant"s, it could still do that optimization, if
it can prove there are no modifications to X or Y.  Or, as you say,
if it detects such modifications at run time.

(But if they were aliased, then X'Access cannot equal Y'Access.)

>> The indirection must be invisible (except, as you mentioned, for
>> low-level stuff like 'Size and Unchecked_Conversion).
>
> I.e. it leaks.

Right.  Somebody famous said "all abstractions leak".
And chapter 13 is where you'll find a lot of leaks.
But that's OK, because the semantics of 'Size and U_D aren't
really nailed down anyway.  (Well, 'Size is nailed down for
scalar subtypes, but we're talking about cases where the compiler
might want to introduce extra levels of indirection.)

- Bob

Re: Legit Warnings or not

[Dmitry A. Kazakov]

On Thu, 28 Jul 2011 11:10:09 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> I.e. it leaks.
> 
> Right.  Somebody famous said "all abstractions leak".

That is why I would prefer to move this stuff out of the language. A full
view of a type must tell what is going on.

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

Re: Legit Warnings or not

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:5o7ldmlcjx4y.182r17y6vir8z.dlg@40tude.net...
> On Thu, 28 Jul 2011 11:10:09 -0400, Robert A Duff wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>
>>> I.e. it leaks.
>>
>> Right.  Somebody famous said "all abstractions leak".
>
> That is why I would prefer to move this stuff out of the language. A full
> view of a type must tell what is going on.

And that's the fundamental disagreement. I much prefer the technique the Ada 
uses: the compiler can do anything it wants, but the user can request a 
specific representation when that is necessary. (Which is a fairly rare 
occurrence). I want languages to get higher-level -- without sacrificing 
performance -- not lower level.

                                 Randy.

Re: Legit Warnings or not

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:go2nk5b4odfy.fpdttridydu6$.dlg@40tude.net...
> On Wed, 27 Jul 2011 19:37:55 -0500, Randy Brukardt wrote:
...
>> Experience with containers shows that no one would use such things unless
>> they were part of the predefined libraries.
>
> What experience? It never was possible in Ada.

No one uses predefined libraries of any kind in Ada unless they either wrote 
them themselves or they are part of the standard. Otherwise, people claim 
that Ada cannot do X even though it is simple to write a package to do X.

That would absolutely be the result if we adopted your approach. Hardly 
anyone would use it, and Ada would be purceived as substantially less 
powerful.

>> Moreover, you cannot create a *better* implementation than the one
>> built-into the compiler
>
> See, this is where you approach leads.

The compiler can do virtually *anything* better than the programmer. The 
only question is where to draw the line.

>> (Keep in mind that hardly any compilers optimize finalization,
>> even though it is possible and reasonably practical, mainly because of 
>> the
>> difficulty of allowing arbitrary user code in such optimizations. The 
>> same
>> would be true for your sorts of abstractions.)
>
> Maybe because compiler vendors are too overwhelmed by implementing more 
> and
> more magical stuff?

Not at all. This is true because to build a better approach in a library 
form, you have to know every possible usage of the library (otherwise, you 
have to support the most general case which by definition would have lots of 
overhead unnecessary in your specific circumstances). That is not practical 
in a language that supports separate compilation and it is not possible at 
all if you support shared libraries.

When the compiler does it, it can share the overhead (for pools and 
finalization, just to take two examples) and in many cases eliminate it 
altogether, based on the form of the type declaration and other properties 
that cannot be available inside of a generic container.

>> You seem to want the
>> programmer to work harder (and apparently never want anyone to use 
>> dynamic
>> array objects in Ada, since those have the sort of implicit-reference
>> semantics that you claim to hate).
>
> No, I want that dynamic arrays were *arrays*. I want that Ada.Container
> could be selected as an implementation of that array by mere renaming or
> other kind of delegation:
>
>   type A is array (Positive range <>) of S'Class;
> private
>   package My_Arrays is
>      new Ada.Container.Indefinite_Vector (Positive, S'Class);
>   type A is new My_Array.Container_Type with null record;
>
> Is it too much?

Yes, for Ada it is too much. Anything implemented now has to be compatible 
with the existing language and implementations. For the "Dmitry" language, 
feel free.

After all, I'm probably tilting at windmills on this topic, and *the 
language already allows this approach*. You want a vastly different approach 
that would require massive language and implementation changes. (The above 
would be completely impossible with the Janus/Ada shared generic approach, 
for instance.) That's not happening any time soon.

                                Randy.

Re: Legit Warnings or not

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> No one uses predefined libraries of any kind in Ada unless they either
> wrote them themselves or they are part of the standard. Otherwise,
> people claim that Ada cannot do X even though it is simple to write a
> package to do X.
>
> That would absolutely be the result if we adopted your
> approach. Hardly anyone would use it, and Ada would be purceived as
> substantially less powerful.

"No one"?

There have always been real users for the Booch Components. 257
downloads in the last year isn't zero. I don't know how many of those
were for commercial use, but I do know that real projects, some in
aerospace (but I hope not safety-related) have used them.

Most people who use sockets with GNAT Ada use GNAT.Sockets (OK, they
quite likely think GNAT=Ada) and I'd guess that most of the others use
AdaSockets.


That said, I've always found Ada's low-level facilities perfectly
adequate, even if at times they can be hard work!

Re: Legit Warnings or not

[Jeffrey Carter]

On 07/28/2011 11:57 PM, Simon Wright wrote:
>
> There have always been real users for the Booch Components. 257
> downloads in the last year isn't zero. I don't know how many of those
> were for commercial use, but I do know that real projects, some in
> aerospace (but I hope not safety-related) have used them.

Right. The PragmARCs have been downloaded 55 times this year.

-- 
Jeff Carter
"That was the most fun I've ever had without laughing."
Annie Hall
43

Re: Legit Warnings or not

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:m2oc0d4lql.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> No one uses predefined libraries of any kind in Ada unless they either
>> wrote them themselves or they are part of the standard. Otherwise,
>> people claim that Ada cannot do X even though it is simple to write a
>> package to do X.
>>
>> That would absolutely be the result if we adopted your
>> approach. Hardly anyone would use it, and Ada would be purceived as
>> substantially less powerful.
>
> "No one"?
>
> There have always been real users for the Booch Components. 257
> downloads in the last year isn't zero. I don't know how many of those
> were for commercial use, but I do know that real projects, some in
> aerospace (but I hope not safety-related) have used them.

Yes, I know some people do. But the people who use Booch and the like are 
not the norm. We found this out early on when Ada didn't provide 
trignometric functions. Even though every implementation had such a library 
and there was a secondary standard for such a library that was widely 
available, the perception was that Ada (especially from prospective Ada 
users) did not have such facilities. It simply was bad marketing.

We saw this again with the containers libraries and with the facilities in 
Ada.Directories. Many people felt Ada did not have these facilities even 
though they were widely available. Thus they were moved into the standard.

I'd predict the same result for any library. I'm sure most of the world 
thinks Ada doesn't have a GUI, despite the existence and wide usage of 
libraries like Claw and GTKAda.

I think it has to do with the perception of Ada as a language with a strong 
standard. That leads many to discount anything that is non-standard, even if 
it portable enough to work on whatever Ada compiler you use (like Claw).

Remember that comp.lang.ada users, SIGAda and Ada Europe members, and the 
like are not typical Ada users (something Robert Dewar likes to say 
often) -- you are plugged in far more than the average Ada user, and 
especially the potential Ada user.

                                         Randy.

Re: Legit Warnings or not

[Dmitry A. Kazakov]

On Thu, 28 Jul 2011 18:48:30 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:go2nk5b4odfy.fpdttridydu6$.dlg@40tude.net...

>> See, this is where you approach leads.
> 
> The compiler can do virtually *anything* better than the programmer.

It can, but there is absolutely no guarantee that it does. In fact the
opposite is true. The resources of a compiler vendor are incomparable with
there resources of the community. More you do at the language level worse
it becomes. (I think this was a discussion in late 60s. Already then it was
clear.)

> The only question is where to draw the line.

Right.

>> No, I want that dynamic arrays were *arrays*. I want that Ada.Container
>> could be selected as an implementation of that array by mere renaming or
>> other kind of delegation:
>>
>>   type A is array (Positive range <>) of S'Class;
>> private
>>   package My_Arrays is
>>      new Ada.Container.Indefinite_Vector (Positive, S'Class);
>>   type A is new My_Array.Container_Type with null record;
>>
>> Is it too much?
> 
> Yes, for Ada it is too much. Anything implemented now has to be compatible 
> with the existing language and implementations.

And where is any incompatibility? Why array or record cannot be interfaces?

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

Re: Legit Warnings or not

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:a47trh2rfxvh.fy7nhwxd9kpi$.dlg@40tude.net...
> On Thu, 28 Jul 2011 18:48:30 -0500, Randy Brukardt wrote:
...
>> Yes, for Ada it is too much. Anything implemented now has to be 
>> compatible
>> with the existing language and implementations.
>
> And where is any incompatibility? Why array or record cannot be 
> interfaces?

Interfaces require multiple inheritance. Multiple inheritance is 
unimplementable (at least efficiently). It's completely unimplementable in 
Janus/Ada which is based on fixed, statically sized objects and components. 
(Generic code sharing is a lot easier.)

                                    Randy.

Re: Legit Warnings or not

[Dmitry A. Kazakov]

On Fri, 29 Jul 2011 19:17:25 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:a47trh2rfxvh.fy7nhwxd9kpi$.dlg@40tude.net...
>> On Thu, 28 Jul 2011 18:48:30 -0500, Randy Brukardt wrote:
> ...
>>> Yes, for Ada it is too much. Anything implemented now has to be compatible
>>> with the existing language and implementations.
>>
>> And where is any incompatibility? Why array or record cannot be 
>> interfaces?
> 
> Interfaces require multiple inheritance. Multiple inheritance is 
> unimplementable (at least efficiently). It's completely unimplementable in 
> Janus/Ada which is based on fixed, statically sized objects and components. 
> (Generic code sharing is a lot easier.)

1. Ada 2005 has interfaces.

2. The case I gave is fully static, without classes (of arrays or records).
This is not a dynamic interface it is just same thing as "type X is
private;" Private and limited private were interfaces already in Ada 83.

3. It was you arguing for objects which size were indeterminable and
components dynamically allocated. And now?

4. Why a built-in implementation of array of S'Class (what you seemed to be
arguing for) should be easier/more efficient/more compatible to Ada than an
implementation trough Ada.Container only publicly visible as an array?

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

Re: Legit Warnings or not

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:gfjkj1eowd8x.1q86rn9zvkfd.dlg@40tude.net...
> On Fri, 29 Jul 2011 19:17:25 -0500, Randy Brukardt wrote:
...
>> Interfaces require multiple inheritance. Multiple inheritance is
>> unimplementable (at least efficiently). It's completely unimplementable 
>> in
>> Janus/Ada which is based on fixed, statically sized objects and 
>> components.
>> (Generic code sharing is a lot easier.)
>
> 1. Ada 2005 has interfaces.

Ada 2005 interfaces are unimplementable in Janus/Ada. (That's a tiny bit 
strong, there is a way to implement them, but no one would ever want to use 
the result.)

> 2. The case I gave is fully static, without classes (of arrays or 
> records).
> This is not a dynamic interface it is just same thing as "type X is
> private;" Private and limited private were interfaces already in Ada 83.

If you have a generic sharing compiler,  there is nothing that is not a 
dynamic interface. *All* properties of a type are dynamic.

The presence or absence of array manipulations is pretty much the only 
exception, which makes it reasonably efficient. Changing that would make a 
decent implementation impossible.

This certainly could be done in an all-new language (which wouldn't have the 
generic baggage of Ada), but not in Ada.

> 3. It was you arguing for objects which size were indeterminable and
> components dynamically allocated. And now?

No, I was arguing for "non-contiguous objects". I *am* guilty of mixing up 
Janus/Ada terminology with Ada's, however; for Janus/Ada, all top-level 
objects are contiguous and statically allocated. They may, however, have 
implicitly managed sub-parts that are neither. That's why Janus/Ada 
considers the array descriptor (which is static sized) the object and not 
the data. That's not quite the meaning of "object" in Ada, and presumably 
you read it to mean something closer to that definition - sorry.

So far as I can tell, it is impossible to come up with anything reasonable 
which would allow multiple inheritance in this scheme, because the compiler 
has to know in advance how many parts there are and where to find them --  
and that is not possible with multiple inheritance.

 > 4. Why a built-in implementation of array of S'Class (what you seemed to 
be
> arguing for) should be easier/more efficient/more compatible to Ada than 
> an
> implementation trough Ada.Container only publicly visible as an array?

There is no new magic needed to allow S'Class as a component type -- only 
the removal of a single legality rule (much like Ada 2005 eliminated the 
library-level requirement on derived tagged types). That means it fits much 
better into the existing structure - from a user perspective, nothing 
significant has changed.

New kinds of interfaces ("gazebos", you once called them), are a much more 
significant change to the structure of the language. They have an effect on 
both user understanding *and* and implementations. These sorts of things 
have a much higher bar to cross.

Besides, Ada 2012 already has user-defined indexing. I find it hard to 
imagine that we'd add a second way to do that.

                                      Randy.

Re: Legit Warnings or not

[Dmitry A. Kazakov]

On Mon, 1 Aug 2011 17:12:23 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:gfjkj1eowd8x.1q86rn9zvkfd.dlg@40tude.net...
>> On Fri, 29 Jul 2011 19:17:25 -0500, Randy Brukardt wrote:
> ...
>>> Interfaces require multiple inheritance. Multiple inheritance is
>>> unimplementable (at least efficiently). It's completely unimplementable 
>>> in
>>> Janus/Ada which is based on fixed, statically sized objects and 
>>> components.
>>> (Generic code sharing is a lot easier.)
>>
>> 1. Ada 2005 has interfaces.
> 
> Ada 2005 interfaces are unimplementable in Janus/Ada. (That's a tiny bit 
> strong, there is a way to implement them, but no one would ever want to use 
> the result.)

It is sad. Ada needs a compiler diversity. There is a huge niche which GNAT
didn't gnaw - the microcontrollers. A reasonably priced Ada compiler could
be a hit there, because the alternatives are either C (unbearable
developing costs) or Java (catastrophic performance). The customer
mentality is: buy the processor first, search for a compiler afterwards.

>> 2. The case I gave is fully static, without classes (of arrays or records).
>> This is not a dynamic interface it is just same thing as "type X is
>> private;" Private and limited private were interfaces already in Ada 83.
> 
> If you have a generic sharing compiler,  there is nothing that is not a 
> dynamic interface. *All* properties of a type are dynamic.

> The presence or absence of array manipulations is pretty much the only 
> exception, which makes it reasonably efficient. Changing that would make a 
> decent implementation impossible.

As you know, I don't value generics in whatever implementation.

>> 3. It was you arguing for objects which size were indeterminable and
>> components dynamically allocated. And now?
> 
> No, I was arguing for "non-contiguous objects". I *am* guilty of mixing up 
> Janus/Ada terminology with Ada's, however; for Janus/Ada, all top-level 
> objects are contiguous and statically allocated. They may, however, have 
> implicitly managed sub-parts that are neither. That's why Janus/Ada 
> considers the array descriptor (which is static sized) the object and not 
> the data. That's not quite the meaning of "object" in Ada, and presumably 
> you read it to mean something closer to that definition - sorry.
> 
> So far as I can tell, it is impossible to come up with anything reasonable 
> which would allow multiple inheritance in this scheme, because the compiler 
> has to know in advance how many parts there are and where to find them --  
> and that is not possible with multiple inheritance.

The language needs a scheme to support "an instance of the type S viewed as
the type T".

>  > 4. Why a built-in implementation of array of S'Class (what you seemed to be
>> arguing for) should be easier/more efficient/more compatible to Ada than an
>> implementation trough Ada.Container only publicly visible as an array?
> 
> There is no new magic needed to allow S'Class as a component type -- only 
> the removal of a single legality rule (much like Ada 2005 eliminated the 
> library-level requirement on derived tagged types).

That is because your compiler already implements this magic. Other
compilers may have problems with that.

And for a programmer the problem is to have control over the constraints
(when the tag can be changed and when not) and over copying (when dynamic
components get copied, when shared). You will need a lot of new keywords
and syntax constructs to specify all possible and needed combinations of
these, plus terrible rules about how these constraints are propagated upon
composition and inheritance. What happens in generics etc.

To me it is just an overkill. Ada already suffers a plethora of unorganized
special cases of types instead of a clean and *small* type system.

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

Re: Legit Warnings or not

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:110nibt4tsn7q.162t6eli286tt.dlg@40tude.net...
> On Mon, 1 Aug 2011 17:12:23 -0500, Randy Brukardt wrote:
...
>>  > 4. Why a built-in implementation of array of S'Class (what you seemed 
>> to be
>>> arguing for) should be easier/more efficient/more compatible to Ada than 
>>> an
>>> implementation trough Ada.Container only publicly visible as an array?
>>
>> There is no new magic needed to allow S'Class as a component type -- only
>> the removal of a single legality rule (much like Ada 2005 eliminated the
>> library-level requirement on derived tagged types).
>
> That is because your compiler already implements this magic. Other
> compilers may have problems with that.

True enough, but that surely was true for removing the library-level 
requirement -- no compiler had that magic. My point was that such a change 
does not change the model of the language at all -- the only cost 
(admittedly, not trivial) would be for implementations.

> And for a programmer the problem is to have control over the constraints
> (when the tag can be changed and when not) and over copying (when dynamic
> components get copied, when shared). You will need a lot of new keywords
> and syntax constructs to specify all possible and needed combinations of
> these, plus terrible rules about how these constraints are propagated upon
> composition and inheritance. What happens in generics etc.

That's taking a simple change and making it far more complex. I'm suggesting 
changing 3.6(10) [only] to allow S'Class. Nothing further, and this isn't 
making any attempt to allow more of anything else.

Indeed, allowing this would have to be tied to eliminating the bogus 
possibility of having partially constrained S'Class subtypes. (The vast 
majority of compilers don't support this possibility, even though the 
language insists on it). Thus there are no constraints to "have control 
over". Either you are allowing changing the object to anything in the class, 
or you are not allowing it to be changed at all. No middle ground there.

And there is no "control over copying". These are normal "parts" of the 
object, and they're always copied. If you don't want copying, then you need 
to use some sort of reference (cursor or access type). (Of course, an 
implementation can always do an "as-if" implementation, but the model is 
always deep copying.)

There is no need or value to trying to go beyond that. "Shallow copying" is 
nasty; pretty much the only value is for performance reasons and it is best 
to leave those to the compiler. (Premature optimization and all of that.)

> To me it is just an overkill. Ada already suffers a plethora of 
> unorganized
> special cases of types instead of a clean and *small* type system.

This would *eliminate* some of the special cases (allowing more types 
unfettered as components and objects). Ada is at the point in its life where 
only incremental changes can happen -- so redoing the Ada type system isn't 
happening.

                                         Randy.

Re: Legit Warnings or not

[Dmitry A. Kazakov]

On Tue, 2 Aug 2011 16:30:24 -0500, Randy Brukardt wrote:

> Either you are allowing changing the object to anything in the class, 
> or you are not allowing it to be changed at all. No middle ground there.

When I declare

   type A is array (...) of S'Class;

1. Are all elements constrained to same specific type?

2. May object types change after being initialized?

3. Which rules apply to view conversions, e.g. T'Class (A (10)). Could it
be then assigned to which types, same, others?

4. In which relation are slices of the array and arrays of T'Class when T
is related to S? [Classes of arrays vs. arrays of classes vs. classes of
arrays of classes etc.]

5. I am horrified what kind of "accessibility rules" might get invented for
passing elements of this "array" here and there.

[The behavior of types upon composition is a very non-trivial issue.]

> And there is no "control over copying". These are normal "parts" of the 
> object, and they're always copied. If you don't want copying, then you need 
> to use some sort of reference (cursor or access type). (Of course, an 
> implementation can always do an "as-if" implementation, but the model is 
> always deep copying.)

Which would make the compiler implementation unusable in so many cases.

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

Re: Legit Warnings or not

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1wg90w555yp7f.1lhp1szkc0cu5$.dlg@40tude.net...
> On Tue, 2 Aug 2011 16:30:24 -0500, Randy Brukardt wrote:
>
>> Either you are allowing changing the object to anything in the class,
>> or you are not allowing it to be changed at all. No middle ground there.
>
> When I declare
>
>   type A is array (...) of S'Class;
>
> 1. Are all elements constrained to same specific type?

Assuming the model I'm suggesting is adopted, no.

> 2. May object types change after being initialized?

Yes. These are completely unconstrained entities.

> 3. Which rules apply to view conversions, e.g. T'Class (A (10)). Could it
> be then assigned to which types, same, others?

The same rules as currently for a parameter of S'Class. I would not want to 
make any changes there, the rules are messy enough as it is.

> 4. In which relation are slices of the array and arrays of T'Class when T
> is related to S? [Classes of arrays vs. arrays of classes vs. classes of
> arrays of classes etc.]

Nothing special; there is no attempt to address the issues with inheritance 
of composition. I don't think those issues *can* be addressed in an Ada-like 
type system.

> 5. I am horrified what kind of "accessibility rules" might get invented 
> for
> passing elements of this "array" here and there.

For me, (dynamic) accessibility is a waste of time; it adds overhead, adds a 
failure hazard, and buys nothing in terms of safety. (I have to use 
'Unchecked_Access in 99% of my programs; 'Access fails for one reason or 
another.)

But that's irrelevant; no new accessibility would be needed because there is 
no new capability here. These are exactly the same as mutable discriminanted 
objects (i.e.the type has defaults for the discriminants). It would be 
erroneous to change the tag of a statically bound parameter (just like it is 
erroneous to change the discriminant in such a case) -- there is no way to 
avoid that without requiring programmers to effectively ignore all 
constraints (because they could change), which is too bogus of a model to 
contemplate.

> [The behavior of types upon composition is a very non-trivial issue.]

I would not make any change there; to the extent that it is a problem now it 
would stay that way.

>> And there is no "control over copying". These are normal "parts" of the
>> object, and they're always copied. If you don't want copying, then you 
>> need
>> to use some sort of reference (cursor or access type). (Of course, an
>> implementation can always do an "as-if" implementation, but the model is
>> always deep copying.)
>
> Which would make the compiler implementation unusable in so many cases.

If so, you would be abusing the intent of the feature. It's intended for 
composition uses only; if you need to represent dynamically changing 
connections between objects, then you clearly need references of some sort 
(cursors preferrably, access types otherwise). If, however, you are 
statically combining objects, then having to manage references explicitly is 
just busywork -- it harms readability, does nothing for performance, and the 
like. Obviously, there is a gray area between these -- but you would never 
to use direct components to represent connections, only composition. 
Otherwise you are hiding structure; I'm only interested in cases where there 
is only one object whose parts consist of previously existing objects that 
will lose their independent identity.

                            Randy.

Re: Legit Warnings or not

[Dmitry A. Kazakov]

On Wed, 3 Aug 2011 15:35:04 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1wg90w555yp7f.1lhp1szkc0cu5$.dlg@40tude.net...
>> On Tue, 2 Aug 2011 16:30:24 -0500, Randy Brukardt wrote:
>>
>>> Either you are allowing changing the object to anything in the class,
>>> or you are not allowing it to be changed at all. No middle ground there.
>>
>> When I declare
>>
>>   type A is array (...) of S'Class;
>>
>> 1. Are all elements constrained to same specific type?
> 
> Assuming the model I'm suggesting is adopted, no.

But this is one of the most important use cases.

>> 2. May object types change after being initialized?
> 
> Yes. These are completely unconstrained entities.

Unconstrained to S'Class?

   type S is new T with ...;
   type A is array (1..1) of S'Class;
   X : T;
   Y : A;
begin
   T'Class (Y (1)) := X; -- Is this OK?

>> 3. Which rules apply to view conversions, e.g. T'Class (A (10)). Could it
>> be then assigned to which types, same, others?
> 
> The same rules as currently for a parameter of S'Class. I would not want to 
> make any changes there, the rules are messy enough as it is.

So S'Class, a component will have a different treatment than S'Class a
parameter? When passed to a subprogram it suddenly becomes constrained?

>> 5. I am horrified what kind of "accessibility rules" might get invented for
>> passing elements of this "array" here and there.
> 
> For me, (dynamic) accessibility is a waste of time; it adds overhead, adds a 
> failure hazard, and buys nothing in terms of safety. (I have to use 
> 'Unchecked_Access in 99% of my programs; 'Access fails for one reason or 
> another.)

Right, accessibility rules is an evil, but if you allow unconstrained
S'Class, actually implicitly constrained to something somewhere, then these
implicit constraints must be handled somehow, and there is no other way to
do this than by accessibility rules.

IMO, all constraints must be explicitly stated as proper subtypes. Only
this would exclude a need in accessibility rules, but it also would your
approach. If you want an unconstrained S'Class as a component (or whatever)
you have to have a special *static* supertype for this, e.g. S'Class(<>).
Then you could deal with that in some sane way.

>> [The behavior of types upon composition is a very non-trivial issue.]
> 
> I would not make any change there; to the extent that it is a problem now it 
> would stay that way.

But you have to address it in array slices and in all other rules
concerning type and subtype equivalence. You could ignore them for T vs. S,
because these are different types, but you cannot do this for differently
constrained class-wide subtypes, e.g. S'Class(<>) vs. S'Class + fixed tag.

>>> And there is no "control over copying". These are normal "parts" of the
>>> object, and they're always copied. If you don't want copying, then you need
>>> to use some sort of reference (cursor or access type). (Of course, an
>>> implementation can always do an "as-if" implementation, but the model is
>>> always deep copying.)
>>
>> Which would make the compiler implementation unusable in so many cases.
> 
> If so, you would be abusing the intent of the feature. It's intended for 
> composition uses only; if you need to represent dynamically changing 
> connections between objects, then you clearly need references of some sort 
> (cursors preferrably, access types otherwise). If, however, you are 
> statically combining objects, then having to manage references explicitly is 
> just busywork -- it harms readability, does nothing for performance, and the 
> like. Obviously, there is a gray area between these -- but you would never 
> to use direct components to represent connections, only composition. 
> Otherwise you are hiding structure; I'm only interested in cases where there 
> is only one object whose parts consist of previously existing objects that 
> will lose their independent identity.

I mean the cases of composition sharing components. I don't know how usable
the new "aliased" parameter subtype in Ada 2012 is, but presently there is
a big problem of getting rid of unnecessary copying. All container
implementations try to eliminate this overhead. In my view on the language
design it is OK, because the type system must be small, but have flexible
interfaces. Your approach is the opposite, clumsy interfaces, much
manipulation behind them. But where is the promised performance? Nowhere,
huge S'Class are intended to be copied on any occasion!

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

Re: Legit Warnings or not

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:gekuq4047oj3.bkgqgse5pikq$.dlg@40tude.net...
> On Wed, 3 Aug 2011 15:35:04 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1wg90w555yp7f.1lhp1szkc0cu5$.dlg@40tude.net...
>>> On Tue, 2 Aug 2011 16:30:24 -0500, Randy Brukardt wrote:
>>>
>>>> Either you are allowing changing the object to anything in the class,
>>>> or you are not allowing it to be changed at all. No middle ground 
>>>> there.
>>>
>>> When I declare
>>>
>>>   type A is array (...) of S'Class;
>>>
>>> 1. Are all elements constrained to same specific type?
>>
>> Assuming the model I'm suggesting is adopted, no.
>
> But this is one of the most important use cases.
>
>>> 2. May object types change after being initialized?
>>
>> Yes. These are completely unconstrained entities.
>
> Unconstrained to S'Class?
>
>   type S is new T with ...;
>   type A is array (1..1) of S'Class;
>   X : T;
>   Y : A;
> begin
>   T'Class (Y (1)) := X; -- Is this OK?

No, of course not. Unconstrained to S'Class is right.

>>> 3. Which rules apply to view conversions, e.g. T'Class (A (10)). Could 
>>> it
>>> be then assigned to which types, same, others?
>>
>> The same rules as currently for a parameter of S'Class. I would not want 
>> to
>> make any changes there, the rules are messy enough as it is.
>
> So S'Class, a component will have a different treatment than S'Class a
> parameter? When passed to a subprogram it suddenly becomes constrained?

Huh? The only time S'Class is "constrained" is when it is a constant.

>>> 5. I am horrified what kind of "accessibility rules" might get invented 
>>> for
>>> passing elements of this "array" here and there.
>>
>> For me, (dynamic) accessibility is a waste of time; it adds overhead, 
>> adds a
>> failure hazard, and buys nothing in terms of safety. (I have to use
>> 'Unchecked_Access in 99% of my programs; 'Access fails for one reason or
>> another.)
>
> Right, accessibility rules is an evil, but if you allow unconstrained
> S'Class, actually implicitly constrained to something somewhere, then 
> these
> implicit constraints must be handled somehow, and there is no other way to
> do this than by accessibility rules.

I don't see any implicit constraints. If there are any, they ought to be 
eliminated.

> IMO, all constraints must be explicitly stated as proper subtypes. Only
> this would exclude a need in accessibility rules, but it also would your
> approach. If you want an unconstrained S'Class as a component (or 
> whatever)
> you have to have a special *static* supertype for this, e.g. S'Class(<>).
> Then you could deal with that in some sane way.

I don't disagree with this; there are no implicit constraints in my model. 
I'm not sure what you have in mind here.

>>> [The behavior of types upon composition is a very non-trivial issue.]
>>
>> I would not make any change there; to the extent that it is a problem now 
>> it
>> would stay that way.
>
> But you have to address it in array slices and in all other rules
> concerning type and subtype equivalence. You could ignore them for T vs. 
> S,
> because these are different types, but you cannot do this for differently
> constrained class-wide subtypes, e.g. S'Class(<>) vs. S'Class + fixed tag.

"Fixed tag"? No such thing for a variable. (And the rules for constants 
handle the other cases.) My entire point is that there are no constrained 
class-wide subtypes.

I think I see what you are driving at, and I agree that I oversimplified my 
original idea. Clearly, you would have to allow changing the tags of 
variables and in out parameters as well (if the actual is S'Class). We 
already have the notion in Ada of 'Constrained for parameters, and that 
would also have to be True for statically tagged objects and False when an 
object or component of S'Class is passed.

>>>> And there is no "control over copying". These are normal "parts" of the
>>>> object, and they're always copied. If you don't want copying, then you 
>>>> need
>>>> to use some sort of reference (cursor or access type). (Of course, an
>>>> implementation can always do an "as-if" implementation, but the model 
>>>> is
>>>> always deep copying.)
>>>
>>> Which would make the compiler implementation unusable in so many cases.
>>
>> If so, you would be abusing the intent of the feature. It's intended for
>> composition uses only; if you need to represent dynamically changing
>> connections between objects, then you clearly need references of some 
>> sort
>> (cursors preferrably, access types otherwise). If, however, you are
>> statically combining objects, then having to manage references explicitly 
>> is
>> just busywork -- it harms readability, does nothing for performance, and 
>> the
>> like. Obviously, there is a gray area between these -- but you would 
>> never
>> to use direct components to represent connections, only composition.
>> Otherwise you are hiding structure; I'm only interested in cases where 
>> there
>> is only one object whose parts consist of previously existing objects 
>> that
>> will lose their independent identity.
>
> I mean the cases of composition sharing components. I don't know how 
> usable
> the new "aliased" parameter subtype in Ada 2012 is, but presently there is
> a big problem of getting rid of unnecessary copying. All container
> implementations try to eliminate this overhead. In my view on the language
> design it is OK, because the type system must be small, but have flexible
> interfaces. Your approach is the opposite, clumsy interfaces, much
> manipulation behind them. But where is the promised performance? Nowhere,
> huge S'Class are intended to be copied on any occasion!

What promised performance? If you don't want the components to be copied, 
then they can't be components! That's been True in Ada since the beginning, 
and I can't imagine trying to change that.

But performance doesn't matter to 90% of the code; readability, 
maintainability, and the avoidance of errors are much more important. 
Requiring the user to manually create, copy, and destroy objects is far more 
error prone than building it into the language. (This is the same reason why 
I am so strongly opposed to having any access types in the interface of an 
object.)

                           Randy.

Re: Legit Warnings or not

[Dmitry A. Kazakov]

On Fri, 5 Aug 2011 18:57:43 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 

>> Unconstrained to S'Class?
>>
>>   type S is new T with ...;
>>   type A is array (1..1) of S'Class;
>>   X : T;
>>   Y : A;
>> begin
>>   T'Class (Y (1)) := X; -- Is this OK?
> 
> No, of course not. Unconstrained to S'Class is right.

[...]
>> So S'Class, a component will have a different treatment than S'Class a
>> parameter? When passed to a subprogram it suddenly becomes constrained?
> 
> Huh? The only time S'Class is "constrained" is when it is a constant.

[...]
>> Right, accessibility rules is an evil, but if you allow unconstrained
>> S'Class, actually implicitly constrained to something somewhere, then these
>> implicit constraints must be handled somehow, and there is no other way to
>> do this than by accessibility rules.
> 
> I don't see any implicit constraints. If there are any, they ought to be 
> eliminated.

Then:

   procedure Carcinogenic (X : in out T'Class) is
      Y : T;
   begin
      X := T;
   end Carcinogenic;

   Z : S'Class; -- Constrained to S'Class?
begin
   Carcinogenic (T'Class (Z)); -- Ignore the constraint!

[ Your idea is to make all classes subtypes of some huge dynamic type. This
is not a workable type model as so many OOPLs already showed. ]

>>>> [The behavior of types upon composition is a very non-trivial issue.]
>>>
>>> I would not make any change there; to the extent that it is a problem now it
>>> would stay that way.
>>
>> But you have to address it in array slices and in all other rules
>> concerning type and subtype equivalence. You could ignore them for T vs. S,
>> because these are different types, but you cannot do this for differently
>> constrained class-wide subtypes, e.g. S'Class(<>) vs. S'Class + fixed tag.
> 
> "Fixed tag"? No such thing for a variable. (And the rules for constants 
> handle the other cases.) My entire point is that there are no constrained 
> class-wide subtypes.

You must have them constrained in order to honor type-specific arguments
passed to class-wide operations:

   Z : S;
begin
   Carcinogenic (Z);

When you lift a constraint, you have to check it dynamically. Compare:

   procedure Foo (X : in out String) is
   begin
      X := "abc";
   end Foo;

   Z : String (1..80);
begin
   Foo (Z);

>> I mean the cases of composition sharing components. I don't know how usable
>> the new "aliased" parameter subtype in Ada 2012 is, but presently there is
>> a big problem of getting rid of unnecessary copying. All container
>> implementations try to eliminate this overhead. In my view on the language
>> design it is OK, because the type system must be small, but have flexible
>> interfaces. Your approach is the opposite, clumsy interfaces, much
>> manipulation behind them. But where is the promised performance? Nowhere,
>> huge S'Class are intended to be copied on any occasion!
> 
> What promised performance? If you don't want the components to be copied, 
> then they can't be components! That's been True in Ada since the beginning, 
> and I can't imagine trying to change that.
> 
> But performance doesn't matter to 90% of the code; readability, 
> maintainability, and the avoidance of errors are much more important.

Right, then your argument that the compiler could do something better than
the programmer was invalid.

> Requiring the user to manually create, copy, and destroy objects is far more 
> error prone than building it into the language.

Right, but the language forces manual manipulation, because interface and
implementation are not properly separated. The developer of a type must
expose all dirty washes to the user.

> (This is the same reason why 
> I am so strongly opposed to having any access types in the interface of an 
> object.)

Again, right, but this requires means to enforce identity semantics in the
interfaces.

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

Re: Legit Warnings or not

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:fopu9zln3g4f.1ocdgf28k7s69.dlg@40tude.net...
> On Fri, 5 Aug 2011 18:57:43 -0500, Randy Brukardt wrote:
...
>> I don't see any implicit constraints. If there are any, they ought to be
>> eliminated.
>
> Then:
>
>   procedure Carcinogenic (X : in out T'Class) is
>      Y : T;
>   begin
>      X := T;
>   end Carcinogenic;
>
>   Z : S'Class; -- Constrained to S'Class?
> begin
>   Carcinogenic (T'Class (Z)); -- Ignore the constraint!
>
> [ Your idea is to make all classes subtypes of some huge dynamic type. 
> This
> is not a workable type model as so many OOPLs already showed. ]

As I said, there shouldn't be any partial constraints. But S'Class is not a 
constraint, it is a type. The problem here is that the type system is being 
violated by back conversion of Z from the less restrictive type. So I think 
this conversion should be illegal.

However, I have to agree that such a rule would be too incompatible for Ada. 
So we'll have to forget my idea.

Unfortunately, I think this proves that we've pretty much taken the core of 
Ada as far as it can go. (We can still add stuff around the edges, as with 
the contracts.) If we really want to advance, we're going to have to start 
over.

                               Randy.

Re: Legit Warnings or not

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> This is the only approach that works for Ada (at least as far as I can 
> tell). And it already works for Janus/Ada; we've used it as long as we've 
> have discriminanted components (late 1980s).
>
> ...
>> I think that Ada should not try to support this stuff.
>
> Ada *does* support this stuff. As Adam noted, there are rules preventing the 
> creation of accesses/renames of/into components that might change size. 

Right, but those rules are necessary for the allocate-the-max
implementation, too -- otherwise you can have dangling pointers.
So I don't think the existence of these rules gives us any clue
as to what was the intent of the original designers.

> There also are rules supporting allocation/deallocation of objects that have 
> multiple parts. So far as I know, those are the only rules needed to do so.
>
> And, as noted, Janus/Ada always has worked this way. I originally thought 
> Ada compilers were expected to work this way, 

You may be right about that.  I wonder if there's anything in the Ada 83
Rationale that would tell us.

(On another topic, it's pretty clear to me that the original designers
thought garbage collection should and would be supported.)

>...because there is no good 
> reason not to support this as the default (as noted, some target 
> environments might not want such objects, and pragma Restrictions can surely 
> be used to prevent them from being generated). But apparently, implementers 
> are lazy enough to avoid it, and customers have never pushed hard enough to 
> get it added as an option.

I don't think it was laziness.  It was an honest belief that implicit
heap allocation is evil.

- Bob

Re: Legit Warnings or not

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccipqtawza.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
...
>>...because there is no good
>> reason not to support this as the default (as noted, some target
>> environments might not want such objects, and pragma Restrictions can 
>> surely
>> be used to prevent them from being generated). But apparently, 
>> implementers
>> are lazy enough to avoid it, and customers have never pushed hard enough 
>> to
>> get it added as an option.
>
> I don't think it was laziness.  It was an honest belief that implicit
> heap allocation is evil.

You'd still have to do that to return unconstrained objects, to declare 
dynamically sized objects, and probably other things as well. (I realize 
that some implementations have gone to heroic lengths -- wasting large 
amounts of address space for an extra stack -- to avoid using heap 
allocation for that -- but it is essentially the same mechanism, and heap 
allocations have a decided advantage of not wasting any address space [a 
critical need on our early 16-bit targets]). So I don't think you can 
implement Ada without some sort of implicit memory allocation, so I fail to 
see any good reason to avoid it in this one particular case. And in any 
case, there is a restriction which would force a compiler to reject any such 
allocations -- why make life harder for everyone that doesn't need that 
restriction?

                                 Randy.

Re: Legit Warnings or not

[Adam Beneschan]

On Jul 21, 2:50 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:
> On Wed, 20 Jul 2011 19:37:48 -0700, Jeffrey Carter wrote:
> > On 07/20/2011 03:30 PM, Anh Vo wrote:
> >> package Warnings_Legit is
>
> >>     type Warned_Person (Size : Positive := 10) is -- Warnings issued
> >> here
> >>        record
> >>           Name : String (1 .. Size);
> >>        end record;
> > some compilers not only won't give any warning,
> > but a declaration of
>
> > X : Warned_Person;
>
> > will not raise Storage_Error on those compilers, either.
> [...]
> > The harder way only allocates enough space for the current value, and
> > actually changes the space of the object if the size is changed through
> > an assignment.
>
> > Some who have gone to the trouble to implement the 2nd way say they
> > think it was the intention of the language designers.
>
> Interesting. Do you mean they allocate a new object?
> Then how do they handle the following declarations  
>    X : aliased Warned_Person;
>    Y : access Warned_Person := X'access;
> when X.Name is resized?

You don't have to allocate a whole new Warned_Person, just a new Name.

                         -- Adam

Re: Legit Warnings or not

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

> You don't have to allocate a whole new Warned_Person, just a new Name.

Right.  If you allocate a whole new Warned_Person, you can get
dangling pointers and dangling renamings.  If I remember correctly,
the rules prevent renaming or 'Access of parts of Name (assuming
it has aliased parts).

- Bob

Re: Legit Warnings or not

[Adam Beneschan]

On Jul 21, 8:41 am, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Adam Beneschan <a...@irvine.com> writes:
> > You don't have to allocate a whole new Warned_Person, just a new Name.
>
> Right.  If you allocate a whole new Warned_Person, you can get
> dangling pointers and dangling renamings.  If I remember correctly,
> the rules prevent renaming or 'Access of parts of Name (assuming
> it has aliased parts).

3.10.2(26), 8.5.1(5).  However, I think the language now says that
'Access and rename of a component are OK if the discriminated object
is known to be constrained; that means that the implementation has to
be smart enough to know that it can't allocate a new Name in that case
(when the entire record is assigned) but keep the same pointer and
just copy over the data that it points to.

                                 -- Adam

Re: Legit Warnings or not

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:b760b2c4-b774-43b6-b29e-4882470be1f4@a2g2000prf.googlegroups.com...
>On Jul 21, 8:41 am, Robert A Duff <bobd...@shell01.TheWorld.com>
>wrote:
>> Adam Beneschan <a...@irvine.com> writes:
>> > You don't have to allocate a whole new Warned_Person, just a new Name.
>>
>> Right. If you allocate a whole new Warned_Person, you can get
>> dangling pointers and dangling renamings. If I remember correctly,
>> the rules prevent renaming or 'Access of parts of Name (assuming
>> it has aliased parts).
>
>3.10.2(26), 8.5.1(5).  However, I think the language now says that
>'Access and rename of a component are OK if the discriminated object
>is known to be constrained; that means that the implementation has to
>be smart enough to know that it can't allocate a new Name in that case
>(when the entire record is assigned) but keep the same pointer and
>just copy over the data that it points to.

That's a good idea anyway, just because allocating and deallocating memory 
is expensive. We do that any time the component does not change size - which 
has the side-effect of working in any case that would be allowed by the 
mentioned rules.

                          Randy.


                                 -- Adam 

Re: Legit Warnings or not

[Jeffrey Carter]

On 07/21/2011 02:50 AM, Brian Drummond wrote:
>
> Interesting. Do you mean they allocate a new object?
> Then how do they handle the following declarations
>     X : aliased Warned_Person;
>     Y : access Warned_Person := X'access;
> when X.Name is resized?

I should have said such compilers change the space for the variable-sized 
components, not the space for the entire object, so X remains in a constant 
position. I'm not a compiler writer so I'm not entirely sure what's involved in 
implementing such an approach.

If this approach had been required by the language, it would make some things 
much easier:

type Unbounded_String (Length : Natural := 0) is record
    Value : String (1 .. Length);
end record;

-- 
Jeff Carter
"I spun around, and there I was, face to face with a
six-year-old kid. Well, I just threw my guns down and
walked away. Little bastard shot me in the ass."
Blazing Saddles
40

Re: Legit Warnings or not

[Brian Drummond]

On Thu, 21 Jul 2011 10:40:38 -0700, Jeffrey Carter wrote:

> On 07/21/2011 02:50 AM, Brian Drummond wrote:
>>
>> Interesting. Do you mean they allocate a new object? Then how do they
>> handle the following declarations
>>     X : aliased Warned_Person;
>>     Y : access Warned_Person := X'access;
>> when X.Name is resized?
> 
> I should have said such compilers change the space for the
> variable-sized components, not the space for the entire object, so X
> remains in a constant position. I'm not a compiler writer so I'm not
> entirely sure what's involved in implementing such an approach.
> 

Seems that this implies that either (a: unlikely) the variable-sized 
component MUST remain in place in the record (which makes resizing it all 
but impossible) or (b: would work) the record must contain an ACCESS to 
it (in which case the implementation silently does something other than 
the declaration says).

Either way has surprises : if the actual result is (c: Dmitry option 3) 
the prohibition of aliasing for e.g. records with default discriminants, 
I would not lose any sleep and probably be relieved...

- Brian

Re: Legit Warnings or not

[Adam Beneschan]

On Jul 21, 2:30 pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:

> Seems that this implies that either (a: unlikely) the variable-sized
> component MUST remain in place in the record (which makes resizing it all
> but impossible) or (b: would work) the record must contain an ACCESS to
> it (in which case the implementation silently does something other than
> the declaration says).

(b) is pretty much how this would be implemented.  With regard to your
comment "the implementation silently does something other than the
declaration says": the implication, that the declaration says one
thing and the implementation is contradicting what the declaration
says and doing something different, isn't warranted.  If there are no
representation items, then a declaration says *nothing* about how a
type is represented.  If this means hidden pointers (which aren't
really ACCESS objects since the pointers aren't Ada and don't have to
follow Ada semantics), there's nothing wrong with that (and there are
places in the AARM that envision the possibility of hidden pointers).
If you read the declaration and conclude that there can't be any
pointers because the declaration doesn't have any access objects in
it, the problem is with your assumptions, not with the implementation.

                               -- Adam

Re: Legit Warnings or not

[Brian Drummond]

On Thu, 21 Jul 2011 14:54:35 -0700, Adam Beneschan wrote:

> On Jul 21, 2:30 pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:
> 
>> Seems that this implies that either (a: unlikely) the variable-sized
>> component MUST remain in place in the record (which makes resizing it
>> all but impossible) or (b: would work) the record must contain an
>> ACCESS to it (in which case the implementation silently does something
>> other than the declaration says).
> 
> (b) is pretty much how this would be implemented.  With regard to your
> comment "the implementation silently does something other than the
> declaration says":  the implication, [...] isn't warranted.  If there  
> are no representation items, then a declaration says *nothing* about 
> how a type is represented.

Thank you for the correction.
... the implementation silently does something other than I wrongly 
inferred from the declaration.
I can live with that!

I considered adding a comment that this would make representation clauses 
difficult, as you suggest. 

On the one hand, I would find it difficult to think of a practical use 
for a representation clause for this object ... on the other, unless 
aliasing this monster is specifically prohibited, there appears to be 
room for nasty corner cases. Is there such a rule?

- Brian

Re: Legit Warnings or not

[Adam Beneschan]

On Jul 22, 3:16 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:
> On Thu, 21 Jul 2011 14:54:35 -0700, Adam Beneschan wrote:
> > On Jul 21, 2:30 pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:
>
> >> Seems that this implies that either (a: unlikely) the variable-sized
> >> component MUST remain in place in the record (which makes resizing it
> >> all but impossible) or (b: would work) the record must contain an
> >> ACCESS to it (in which case the implementation silently does something
> >> other than the declaration says).
>
> > (b) is pretty much how this would be implemented.  With regard to your
> > comment "the implementation silently does something other than the
> > declaration says":  the implication, [...] isn't warranted.  If there  
> > are no representation items, then a declaration says *nothing* about
> > how a type is represented.
>
> Thank you for the correction.
> ... the implementation silently does something other than I wrongly
> inferred from the declaration.
> I can live with that!
>
> I considered adding a comment that this would make representation clauses
> difficult, as you suggest.
>
> On the one hand, I would find it difficult to think of a practical use
> for a representation clause for this object ... on the other, unless
> aliasing this monster is specifically prohibited, there appears to be
> room for nasty corner cases. Is there such a rule?

Bob and I discussed this a little, above.  There's no rule against
aliasing the whole record, but that shouldn't pose a problem.  As for
aliasing just the dynamic array component, you can declare it
"aliased", but you can't do anything that would actually result in
aliasing (like use X.Name'Access) unless it is known that Name's size
can't change (which means that the compiler has to make sure the
pointer doesn't change either).  So I think the rules are sufficient
to avoid problems.

                                   -- Adam

Re: Legit Warnings or not

[Randy Brukardt]

"Brian Drummond" <brian@shapes.demon.co.uk> wrote in message 
news:j0bilg$mr4$2@dont-email.me...
...
> I considered adding a comment that this would make representation clauses
> difficult, as you suggest.

There is no requirement that an implementation support representation 
clauses on discriminant-dependent components - 13.1(23). An implementation 
could do so of course (depending on it's implementation model), but the 
language does not require it and portable code therefore should avoid using 
such clauses. As you note, they're not very useful anyway.

                                      Randy.

Re: Legit Warnings or not

[Randy Brukardt]

"Brian Drummond" <brian@shapes.demon.co.uk> wrote in message 
news:j0a5qa$lqg$2@dont-email.me...
> ..(b: would work) the record must contain an ACCESS to
> it (in which case the implementation silently does something other than
> the declaration says).

Adam answered this adequately. But I take it you have never passed a 
by-reference type as a parameter? Or are you surprised that that an access 
to that parameter is what is really passed, even though the declaration says 
something else??

My point being that hidden pointers are extremely common in the 
implementation of modern programming languages, and certainly are common in 
Ada implementations. The only language I know of that insists on making such 
things explicit is C, and I think even it has some cases where the pointers 
are implicit (struct parameters).

                                    Randy.

Re: Legit Warnings or not

[Niklas Holsti]

Randy Brukardt wrote:

> My point being that hidden pointers are extremely common in the 
> implementation of modern programming languages, and certainly are common in 
> Ada implementations. The only language I know of that insists on making such 
> things explicit is C, and I think even it has some cases where the pointers 
> are implicit (struct parameters).

Continuing that parenthesis: struct parameters in C are passed by value 
unless you explicitly declare the parameters as pointers. I think the 
only implicit introduction of "pointer" in C is when a function 
parameter is declared as an array or a function, in which case the 
formal parameter type is actually a pointer to the declared type. Other 
rules let you omit the "address of" operator (&) on the actual parameters.

<anecdote>
This reminds me that an early version of GNAT (perhaps 3.03?) was 
designed to be "compatible" with C in this respect and to pass all 
record-type parameters by value. We upgraded to this version of GNAT in 
the middle of an application development and in consequence had to tell 
the users to run the relatively small application with a 10 MB stack 
allocation -- rather a lot in those days. As I recall, the next version 
of GNAT went back to call-by-reference for record types.
</anecdote>

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Legit Warnings or not

[David Thompson]

On Sat, 23 Jul 2011 12:20:53 +0300, Niklas Holsti
<niklas.holsti@tidorum.invalid> wrote:

> Randy Brukardt wrote:
> 
> > My point being that hidden pointers are extremely common in the 
> > implementation of modern programming languages, and certainly are common in 
> > Ada implementations. The only language I know of that insists on making such 
> > things explicit is C, and I think even it has some cases where the pointers 
> > are implicit (struct parameters).
> 
> Continuing that parenthesis: struct parameters in C are passed by value 
> unless you explicitly declare the parameters as pointers. I think the 

Yes. Or at least as-if; it would be legal for an ABI to actually pass
a pointer to a copy used only by the callee, or to a value which the
callee copies-in, but I've never seen anyone do so.

> only implicit introduction of "pointer" in C is when a function 
> parameter is declared as an array or a function, in which case the 
> formal parameter type is actually a pointer to the declared type. Other 
> rules let you omit the "address of" operator (&) on the actual parameters.
> 
Nearly.

If you declare a parameter as a function type F, it is actually a
pointer-to-F. An expression which is a function name is implicitly
converted to a pointer to that function, which is the correct type to
pass to a pointer-to-F parameter, and if you write &f it also creates
the same pointer. The function-call operation f(x) actually takes a
pointer-to-F as its left operand, which could either be a 'decayed'
actual function or a stored pointer including a parameter. Thus 
ptrf(x) calls the function ptrf points to; (*ptrf)(x) takes the target
of ptrf and re-forms a pointer and calls the same target; (**ptrf)(x)
takes the target, re-forms a pointer, derefences it, re-forms the
pointer again, and calls the same target, etc ad nauseam.

If you declare a parameter as an array type A with element E, it is
actually a pointer-to-E (not A). If an expression is an array lvalue
it is implicitly converted to a pointer to its first element, which is
the correct type to pass to pointer-to-E. Pointer-to-E doesn't 'know'
the array bound so void f (float x []) aka void f (float * x) can be
passed an array of float of any bound -- and the actual bound, or a
smaller used extent, must be passed or known by other means. 

The subscript operation a[i] effectively takes a pointer-to-E. 
Even more pedantic: subscripting in C is actually defined in terms of
pointer arithmetic: ptr +- integer yields a pointer moved up or down
by integer elements, usually integer*sizeof(element) bytes, and + is
commutative, and a[i] is _defined_ as *( (a) + (i) ), so actually i[a]
is equivalent to a[i], which was useful for early IOCCC entries.

But if you declare a parameter as pointer-to-array, that's a different
type that does know the bound (except if the bound is variable, 
a new feature in C99) and not passable or assignable from a
pointer-to-element. In that case you must explicitly write &array
(where array is the correct size) to get a suitable argument value.
Or write a cast, but that's uglier and often less robust.

Note that strings in C are just array of char(acter), or wchar_t,
containing a null terminator; thus the literal "xyz" in an expression
yields a pointer to char. (In C++ it's at least pointer to const char,
but in C 20 years of code existed before const was invented.)
This is actually just a case of the general array-element-pointer
rules above, but it is a very common case that has no syntactic
indication of an array and thus tends to confuse people.

What _is_ often done and might easily be confused is for struct
_returns_ from functions in C to be implemented using a pointer. 
Like all function return types, these are by-value in the abstract
semantics. But many C ABIs return primitive scalars (int, float, etc.)
in a register, which doesn't work for a (potentially) large struct. 
So it is common for the call sequence to provide temp space -- which
it can because C struct layout and size is fixed -- and pass a hidden
pointer which the callee epilogue uses to store the return value,
which the caller then uses. It is also possible, but more confusing,
to use a hybrid scheme where a struct type that is small enough to fit
in the desired register, typically 4 or 8 bytes, is returned there,
and only larger structs use caller-created space and pointer.
The issue doesn't arise for arrays because C can't return an array --
only a pointer used to access an array (in memory) or a struct
_containing_ an array (of static bound) in which case see above.

Re: Legit Warnings or not

[Dmitry A. Kazakov]

On Fri, 22 Jul 2011 19:42:00 -0500, Randy Brukardt wrote:

> My point being that hidden pointers are extremely common in the 
> implementation of modern programming languages, and certainly are common in 
> Ada implementations.

Yes, but you cannot hide all pointers. There exist infinitely recursive
objects like trees and graphs. They cannot be described without explicit
pointers. So the question is not references or no references. It is rather
about where to draw the line behind which referential semantics must be
exposed (e.g. properly typed). Many feel that non-contiguous
representations are behind the line.

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

Re: Legit Warnings or not

[Brian Drummond]

On Fri, 22 Jul 2011 19:42:00 -0500, Randy Brukardt wrote:

> "Brian Drummond" <brian@shapes.demon.co.uk> wrote in message
> news:j0a5qa$lqg$2@dont-email.me...
>> ..(b: would work) the record must contain an ACCESS to it (in which
>> case the implementation silently does something other than the
>> declaration says).
> 
> Adam answered this adequately. But I take it you have never passed a
> by-reference type as a parameter? 

I have, and I accepted it there ... so why did I have a blind spot 
against the same principle inside a record? I think, because of the 
simultaneous but quite separate discussion on representation clauses.

anyway, my thanks , and I think my misgivings have been completely 
answered.

- Brian

Re: Legit Warnings or not

[Robert A Duff]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> There are 2 ways to handle such unconstrained objects. The easy way,
> which GNAT uses, is to allocate enough space for the largest
> variant. The harder way only allocates enough space for the current
> value, and actually changes the space of the object if the size is
> changed through an assignment.

Right.  I know of two Ada compilers that used this
"deallocate-and-reallocate" method to change the size.
One of them got it wrong.  I don't remember the details,
but I think it had to do with renaming a subcomponent,
and then an assignment to the whole record caused the
renaming to become a dangling pointer.  The other compiler,
as far as I know, got it right.

> Some who have gone to the trouble to implement the 2nd way say they
> think it was the intention of the language designers.

Could be -- I don't know.  I think for a low-level language like Ada,
it's probably not a good idea to introduce implicit heap allocation.
I'd at least want a way to turn it off.

Implicit heap allocation could be a good feature in a different
language, but then I'd want that language to allow:

    type Tree is tagged
        record
            Left, Right : Tree'Class; -- doubly illegal!
        end record;

- Bob

Re: Legit Warnings or not

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcc8vrrbrb6.fsf@shell01.TheWorld.com...
...
> Implicit heap allocation could be a good feature in a different
> language, but then I'd want that language to allow:
>
>    type Tree is tagged
>        record
>            Left, Right : Tree'Class; -- doubly illegal!
>        end record;

Yes, of course Ada should support this, too. ;-) As noted, it's not 
particularly hard.

Note that these sorts of allocations aren't really the same as heap 
allocations -- their lifetime is similar to that of the secondary stack. 
Janus/Ada does allocate them on the heap (with them being deallocated when 
scope goes away), but I've been thinking about ways to reduce/eliminate 
that. One obvious idea is to allocate the initial sizes off of the secondary 
stack, and only allocate from the heap if they get bigger via assignment in 
a different master (which is fairly rare). Not sure if that would save 
enough to be worth the extra complication.

                                     Randy.

Re: Legit Warnings or not

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wcc8vrrbrb6.fsf@shell01.TheWorld.com...
> ...
>> Implicit heap allocation could be a good feature in a different
>> language, but then I'd want that language to allow:
>>
>>    type Tree is tagged
>>        record
>>            Left, Right : Tree'Class; -- doubly illegal!
>>        end record;
>
> Yes, of course Ada should support this, too. ;-) As noted, it's not 
> particularly hard.

Maybe in Ada 2020?  ;-)

":=" and "=" need to walk the whole tree of subcomponents.
Many folks (not me) would find that disconcerting.
Unchecked_Deallocation would too, unless you use garbage collection.

> Note that these sorts of allocations aren't really the same as heap 
> allocations -- their lifetime is similar to that of the secondary stack. 

Their lifetime is, but you want to use heap allocation because the
sizes can change.  Note that I'm assuming the Tag can change
(which is highly not-Ada).  E.g.:

    type This_Tree is new Tree with ...;
    type That_Tree is new Tree with ...;

    X : Tree'Class;
    X := This_Tree'(...);
    X.Left := This_Tree'(...);
    X.Left := That_Tree'(...);

Or are you suggesting that you just keep growing the secondary stack?
I don't like memory leaks.

> Janus/Ada does allocate them on the heap (with them being deallocated when 
> scope goes away), but I've been thinking about ways to reduce/eliminate 
> that. One obvious idea is to allocate the initial sizes off of the secondary 
> stack, and only allocate from the heap if they get bigger via assignment in 
> a different master (which is fairly rare). Not sure if that would save 
> enough to be worth the extra complication.

- Bob

Re: Legit Warnings or not

[anon]

This is funny. Because if you add definition of Positive

   subtype Positive is Integer range 1 .. Integer'Last ;                           

-- or 
  
  -- copied from created standard ( gnat standard )
   subtype Positive is Integer range 1 .. +(2 ** 31 - 1);

it stops the warning message. So, its a compile error. Even 
GNAT 3.10 .. 2007 | 2011 has this error so this one goes back 
a few years.



In <531193e0-3305-4292-9ed8-0176226c1d00@x12g2000yql.googlegroups.com>, Anh Vo <anhvofrcaus@gmail.com> writes:
>package Warnings_Legit is
>
>   type Warned_Person (Size : Positive := 10) is -- Warnings issued
>here
>      record
>         Name : String (1 .. Size);
>      end record;
>
>   type Acceptable_Person (Size : Positive) is
>      record
>         Name : String (1 .. Size);
>      end record;
>
>end Warnings_Legit;
>
>The code segment above triggers a warnings message 'creation of
>"Warned_Person" object may raise Storage_Error' at line 3 as marked.
>However, no warnings is issued at line 8. The difference between them
>is default discriminant. I am using GNAT-GPL-2011.
>
>Is this warnings legitimate? If yes, why line 8 is OK. Otherwise,
>should it be a bug?
>
>Anh Vo