Re: Is this expected behavior or not

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

On Wed, 27 Mar 2013 14:42:47 -0500, Randy Brukardt wrote:

> The problem is that a slice ought to be a referential object as you put it, 
> and a "regular" object is definitely *not* a referential object (a copy 
> copies the data).

What is "regular" object here? String?

> I don't see any way for a single data type to have two 
> different behaviors

These are two data types, string and slice. Are you treating slice as an
Ada-subtype of string? I consider slice a member of same class as string,
yet a distinct type (in Ada sense). This is like 4.1.5, but in the same
type hierarchy.

>>> You missed the point altogether. You can't dispatch in general on untagged
>>> types because overriding operations may have different modes and subtypes
>>> for the parameters. So what *is* the profile of the operation for T'Class,
>>> and how can it work?
>>>
>>> Consider:
>>>
>>>      Type Int is range 1 .. 10;
>>>      procedure Op (A, B : in Int);
>>>
>>>      Type Der is new Int;
>>
>> This is not derivation within the class, it is a "type-cloning." Type
>> cloning creates a new class and new a type (all types up the hierarchy). 
>> We need some syntax to indicate the difference.
>>
>>   type Der is new Int <whatever>;
>>
>> It is unfortunate that tagged types reused "is new" for a purpose
>> completely different from type cloning.
> 
> Nobody wants "type cloning".

It is a very useful building block to me. Anyway it is Ada 83 legacy.

> I have no idea why anyone that wants 'Class 
> would want to avoid maximizing the interoperability of types.

Sometimes we want types related, sometimes we don't, while reusing existing
implementations. The language should support programmer's choice.

> The original motivating example for Integer'Class was:
> 
>      Put (Obj : Integer'Class; Width : Count := 0);
> 
> so that one didn't need to understand generic instantiations just to do 
> simple I/O of strongly typed entities.

Yes.

Cloned Integer will "inherit" this Put operation in Ada 83 sense. Ada 83
cloning is orthogonal to type hierarchies. You get a new hierarchy when you
clone a type.

> I don't think a version of untagged'Class that did not work on existing 
> derived types would fly.

Astonishing that you even considered that possibility. In my view they are
completely independent things.

> In any case, I didn't realize that you were making an entire new kind of 
> type derivation

To me it is exactly same as tagged extension when you add nothing to the
existing representation.

We also need "extension" that drops parent's representation altogether.
E.g. something like:

   type Character is new Unsigned_8 -- or enumeration, whatever
      and Wide_Wide_Character'Interface;

Character is member of Wide_Wide_Character'Class with a representation
different from Wide_Wide_Character.

>> Moreover, it is highly desired to that cloning were available for tagged
>> types as well:
>>
>>   package Original is new Ada.Containers.Vectors ...;
>>   type Clone is new Original.Vector; -- Cloning, not extending!
>>
>> Now, I have to hierarchies of Vector, not very useful in this particular
>> case, because of missing helper types, but anyway.
> 
> Pointless complication. I thought you were trying to simplify the language!

Making it regular is a simplification.

>>>      overriding
>>>      procedure Op (A : in out Der; B : in Der);
>>
>> This is not an overriding since the mode is different.
> 
> It *is* an overriding in Ada 83, and it still is in Ada 2012. I agree that 
> it should not have been, but that is irrelevant because we're stuck with it.

Only when Der is derived using Ada 83 construct. Int'Class will be built
using "extension."

>>>      Obj : Int'Class := Der'(1);
>>>      Op (A => 1, B => Obj); -- Legal??
>>
>> MD is not fully implemented in Ada, but anyway, presuming that Op is a
>> multi-method, that the mode is "in" and that 1 is Universal_Integer (is
>> it?), the above is illegal because Op is not a method of
>> Universal_Integer'Class. You would have to write it as:
>>
>>   Op (A => Der'(1), B => Obj);  -- Same tags
>>   Op (A => Int'(1), B => Obj);  -- Different tags, Constraint_Error
> 
> This seems wrong; an integer literal usually gets its type from context. 
> It's only a value of type Universal_Integer if there is no type given from 
> context (as in a type conversion or number declaration). I was presuming 
> that integer literals act as tag-indeterminate functions (the most sensible 
> model; if you have constants for a tagged type you usually would model them 
> as tag-indeterminate functions - for instance, the constants Zero and One in 
> a universal arithmetic package), you don't need multiple dispatch: the Ada 
> dispatching rules simply calls the correct version of the function for the 
> tag of the object. And that's what we would want to happen for integer 
> literals (that's the closest analogy to what happens for existing 
> expressions).

This is one of possible interpretations of Ada semantics. You consider
literals primitive operations, e.g.

   function "1" return Int;

In Ada 95 such function has to be overridden, when Der extends Int.
However, if the representation is inherited and not changed, the rule could
be that the compiler silently overrides all literals:

   overriding function "1" return Der;

In this case you will have 1 overloaded. Op will become ambiguous. The
alternative with different types can be discarded using some preference
rules, e.g. domination, and thus ambiguity resolved.

>>> An interface can't have "..." as the parameter type for Write; there has 
>>> to be something there.
>>
>>   procedure Write (File : in out File_Access; Data : Stream_Element_Array)
>>      is abstract;
>>
>>> And that's the target type! Say again how it is that you
>>> are not exposing this type??
>>
>> The target is File. I would gladly have MD and a hierarchy for the second
>> parameter, but that is another story for now.
> 
> OK, if the target is File, then you know that - that's public information. 
> When you dereference a File_Handle, you get a File. You don't have to make 
> the contents of File public, just it's name. So I still don't see why you 
> think this is a problem.

I don't want to expose File at all. Public views should have no access to
it, otherwise than indirectly through the handle. E.g. they should not be
able to get an access the file object, store it somewhere, deallocate it,
use stream attributes on it, and perform any other fancy stuff.
Furthermore, later on, a decision may fall to replace file descriptor with
something completely different keeping code that uses handles intact. It is
good old information hiding principle.

>> Because whether a message is relevant to the choice if the program were OK
>> to deploy depends now on the message content. The language does not help 
>> me anymore to indicate it as a bug.
> 
> But there is absolutely nothing new about this.

There is nothing new that people die, yet nobody actually likes it.

> GNAT has a variety of 
> warnings (calling everything it displays a "warning" in order to avoid 
> arguments about its particular classifications of message), but most people 
> choose to treat some subset of them as errors that have to be removed before 
> deployment. You would do that same; choose a *class* of warnings that have 
> to be removed; there is no parsing of messages needed. If a warning in the 
> prohibited class exists, the program is not ready for deployment.

Some C compilers give warning when you write:

   if (x = 1) ...

> Yes, this means you need to develop a coding standard and a development 
> standard to ensure that these these things are followed. But not having 
> those in some form is just lousy programming management.

Error checks do not belong to coding standards. Coding standard, and
testing, and code review etc are there when compiler checks were
impossible.

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