Re: Legit Warnings or not

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

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