Re: Is this expected behavior or not

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

On Tue, 26 Mar 2013 16:31:35 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1u72u7h5j4jg3$.wlxmaltyzqik.dlg@40tude.net...
>> On Mon, 25 Mar 2013 17:58:26 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:a96esjwiniqy$.op3wh7x9wrsl.dlg@40tude.net...
>>>> On Fri, 22 Mar 2013 21:33:02 -0500, Randy Brukardt wrote:
>>> ...
>>>>> That doesn't necessarily mean copying of the data. If the designer
>>>>> of the abstraction, have put in enough smarts to share 
>>>>> representations --
>>>>> after all,
>>>>
>>>> You should break your mental block. No shared representation, I want
>>>> different representations for different string types.
>>>
>>> I was talking about sharing representations of *different* objects of the
>>> same string type (for instance, a string variable and a slice of that
>>> variable - that case, sharing the data might be preferred to copying it).
>>
>> OK, the representation would be for type-specific string objects:
>>
>>   bounds + pointer
>>
>> and for class-wide string objects:
>>
>>   tag + bounds + pointer
> 
> Sure, but irrelevant. The question is whether slicing copies the data or 
> not. If it is a new object, the data must be copied logically,

No, logically it is a referential object.

> but my point 
> was that it would be possible for an abstraction to defer actually making a 
> copy until an assignment is actually done. It's still a copy.

Exactly the reverse, an implementation could be allowed to use a copy if
that is consistent with the semantics of the slice being a reference.

But regardless of the semantics, why this representation should not work?

>>> Unifying old junk it's possible without serious breakage of existing 
>>> code, which is intolerable.
>>
>> Why is it junk? There is nothing wrong with String, Wide_String,
>> Wide_Wide_String. They should stay.
> 
> They're junk because they can't be unified without serious breakage of 
> existing code.

A common ancestor would not break existing code. An ad-hoc ancestor could
not do it even theoretically, because it is limited to the context where
the ancestor is visible.

>>> And dispatching is incompatible with untagged types, simply because Ada 
>>> 83 got inheritance horribly wrong, and we're stuck with that.
>>
>> I disagree. It seems fully compatible with Ada 83 because T'Class would be
>> a distinct type with objects of that type. It is orthogonal to
>> Ada-subtypes. You will not dispatch on Positive vs. Integer, these will
>> reman specific [sub]types. In order to dispatch you will need a class-wide
>> object of the type Integer'Class (which will be strictly same as
>> Positive'Class, except, possibly, the constraint). That object will have
>> the representation tag + value. For Integer and Positive objects nothing
>> changes. We might consider redefining some existing operations to become
>> class-wide in some arguments, but that is another story.
> 
> 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.

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.

>      overriding
>      procedure Op (A : in out Der; B : in Der);

This is not an overriding since the mode is different.

>      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

Multi-methods (a special case of MD) is another and long story. They should
be properly supported in the end.

> And if you say that Der cannot override Op this way, you're now incompatible 
> with Ada 83- Ada 2012.

I want to preserve and extend type-cloning.
 
>>>>>> You have a very specific use case in mind, namely containers. There is a
>>>>>> whole world outside that, for which what you said is untrue, e.g. for
>>>>>> smart pointers. The thing not only exposes access, it also exposes the
>>>>>> target type.
>>>>>
>>>>> You have to expose the target type in order to have strong typing. How
>>>>> could you hide it and still make type checks?
>>>>
>>>> Why should target type be public?
>>>
>>> How do you enforce strong typing without that being the case? If you don't
>>> know what the target is, how do you determine how the resulting object can
>>> be used?
>>
>> Target and handle types usually implement some public interface. E.g.
>>
>>   type File_Access is limited interface;
>>   procedure Write (File : in out File_Access; Data : ...) is abstract;
>>   ...
>>
>> Somewhere else
>>
>>   type File_Descriptor is ... limited ... and File_Access ...;
>>
>> Somewhere else
>>
>>   type File_Handle is ... and File_Access ...;
> 
> 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.

>>>>> That's my point about static analysis. Such a tool should be able to prove
>>>>> that the majority of run-time checks can't happen, and give you a list of
>>>>> those remaining.
>>>>
>>>> I don't need any list. Should I send it to my customers? I need the
>>>> program fail to compile when writing analogue input.
>>>
>>> Treat the list as failures if you must, and insist that it be empty 
>>> before shipping.
>>
>> So, I need an AI system to parse compiler messages (of various vendors) on
>> top?
> 
> Huh? Why would you "parse" them?

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.

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