Re: Legit Warnings or not

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

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