Re: Is this expected behavior or not

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:wdlyfbnwcnp7.10c9btwjmpm7j.dlg@40tude.net...
> 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?

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). I don't see any way for a single data type to have two 
different behaviors - as you've argued elsewhere, you can't have a single 
operation doing two different things. I suppose you could make a slice be a 
different type than a regular string object, but then you have problems with 
type matching (you want a slice to be compatible with the equivalent normal 
object).

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

Nobody wants "type cloning". We waste a lot of mental energy getting rid of 
it in generics, for example. I have no idea why anyone that wants 'Class 
would want to avoid maximizing the interoperability of types. 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.

I don't think a version of untagged'Class that did not work on existing 
derived types would fly. For no other reason than the fact that it would 
make tagged and untagged types more different, rather than less different.

In any case, I didn't realize that you were making an entire new kind of 
type derivation - I wouldn't have guessed that someone that has been talking 
repeatedly about simplifying the language would add an entirely new kind of 
type to the language.

> 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!

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

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

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

And you claim that the ARG keeps building gazebos. You're building a 
lakeside floating pavillion. ;-)

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

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

But there is absolutely nothing new about this. 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.

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. And one thing we 
decided on the ARG long ago is that there is no way that a programming 
language can prevent lousy programming management -- any language can be 
misused without much effort. That cannot be prevented by a programming 
language; it's futile to try, and when you do try, you tend to make the 
language harder to use on real problems. So we assume competent management 
is used with Ada; we're not trying to make the language idiot-proof.

                                            Randy.