Re: Legit Warnings or not

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

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