Re: Is this expected behavior or not

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

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

A non-slice string object.

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

I thought you might do that, but then you're going to have problems of 
compatibility (Ada currently considers them the same type). An operation 
like "&" cannot not allow mixed string operands (if you do allow that, you 
make string literals ambiguous).

...
>> Nobody wants "type cloning".
>
> It is a very useful building block to me. Anyway it is Ada 83 legacy.

Ada 83 derived types are virtually useless, and no one understood how they 
worked. I objected to building tagged types on that foundation during Ada 
9x, but they didn't pay any attention to me on that. :-)

Ada 83 derived types would be one of the first things to get rid of in a new 
Ada-like language -- everything should be related. Indeed, all integer types 
belong to Root_Integer'Class (you just can't name that type in Ada as it 
stands); it would be weird to *break* that.

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

You really have a strange mind. The whole idea of 'Class is to allow 
different but related types to share implementations. You're only allowed to 
convert between related types, which includes derived types.

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

Sure, this I totally agree with. But those are highly related to each other: 
Parent'Class includes the parent and the derivation.

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

I don't think that would work semantically, at least in the 'Class case. 
Unless you expect every operation down to assigning individual components to 
be dispatching, even in primitive routines defined for a specific type. 
That's because you can't copy all tagged types (we have to have limited 
types), and thus calling a parent operation would have to assume that 
extensions have a different representation. That would both have problems of 
re-dispatch and simply would be awfully expensive (you'd have to do full 
program compilation to have any hope of decent code).

The only alternative would be to totally ban implementation inheritance on 
such types, but as implementation inheritance is 10 times more useful than 
interface inheritance, it would make the construct 95% useless.

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

This isn't regular. All numeric types are currently members of a single 
hierarchy, and in practice, the vast majority of tagged types are members of 
two hierarchies (controlled and limited controlled). If I was going to 
simplify this further, I would make all of these into a single hierarchy. 
More hierarchies don't buy anything (you can always move your 'Classes 
around in the hierarchy to get subsets).

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

No way; derived types currently form a hierarchy (that's why you can 
interconvert them); changing that would require fundamentally changing the 
Ada model of hierarchies. The issue today is that you can't name those 
hierarchies, that's what untagged 'Class would allow.

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

Yes, this is how Ada literals work today. This isn't how its described (it's 
an implicit conversion rather than overloading) but the effect is the same.

> The alternative with different types can be discarded using some 
> preference
> rules, e.g. domination, and thus ambiguity resolved.

Preference rules cause Beaujolias effects, and almost never can be 
tolerated. Ada used to have some for literals and they caused all manner of 
problems. The preference rules for universal causes problems as well (as you 
are pointing out here); these are extremely fragile and only work because 
universal types can't have any user-defined operations or visibility 
changes.

As soon as user-defined things are involved, preference rules simply don't 
work. Maybe they would work in a language without nesting and private parts 
and use clauses, but they don't work in Ada. (The problem being that adding 
or removing a single declaration can silently change the meaning of an 
expression without causing an error. This is considered intolerable.)

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

Fine. But then you don't need any user-visible dereferencing, and you surely 
wouldn't use it. My contention remains: if you are going to allow user 
"Handle.all", then you need to expose the type of Handle.all. If you don't 
need to allow that, then you are not going to use 4.1.5 at all. So I fail to 
see your concern.

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

Compiler checks are impossible for these things. Unless you want to drive 
yourself nuts with OOP baloney - and it's never going to be possible to do 
these sorts of checks with type checking. (This is not a type problem, it's 
a subtype (in the Ada sense) problem.) Feel free to pick your poison, as it 
will, but expecting types to do all of the work is just as silly as 
expecting that you can make a correct program with defining any types at 
all.

                                       Randy.