Re: Is this expected behavior or not

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

On Mon, 1 Apr 2013 19:40:42 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1gnmajx2fdjju.1bo28xwmzt1nr.dlg@40tude.net...
> ....
>> The point is that whether you create a totally new string hierarchy or
>> create one for already existing string types, you will have the issue with
>> "&" (and any other operation with more than one argument/result of string
>> type). That is *independent* on whatever Ada did or not before. It is in
>> the nature of a multi-method, which "&" is. If you want a hierarchy of
>> strings you *must* face this problem.
> 
> No you don't. There are no language-defined multi-methods. String & String = 
> String is not a multi-method.

Once String becomes member of a class it is. For the operation "&" there
exist only two possibilities, Either it is a primitive operation of the
class and so a multi-method, or else it is declared individually on each
member of the class in separate packages (somewhere after the freezing
point). The later variant is so silly that I don't even consider it.

> You, the user, can define such operations, of 
> course, but then you have the deal with the consequences. Generally, it's 
> best if you don't do that.

What is the use of a string type without operations? 

>>>> The model of Ada 95 tagged types provides a class with shared
>>>> representations. This need to be augmented for the case when
>>>> representations has to be different. Note that this was partially done when
>>>> Java interfaces were added in Ada 2005. Java interface is a type without
>>>> any representation, so there is nothing to inherit from, except for a slot
>>>> for the type tag. Drop that slot, and you will have a workable model for
>>>> building classes of scalar types and arrays.
>>>
>>> I don't know how one could implement "interfaces" without a tag.
>>
>> You have the tag in the representation of untagged'Class. You don't have 
>> it in the representation of untagged.
> 
> Doesn't work, as I've previously explained.

You said that it would not fit into Ada 83 derived types model. I answered
that it never considered within that model. The model to augment is Ada 95
tagged types.

> You have to be able to inherit 
> implementation of operations, for all types.

It is already not so. See Ada 95 abstract primitive operations and
operations dispatching in the result. They are NOT inherited. The
programmer is asked to override them, because the compiler has no idea how
to implement them.

> And there exist plenty of Ada 
> types for which copying is not allowed.

No problem. See above. All primitive operation will be inherited abstract
if the representation is not inherited and no [user-defined] conversion
defined (e.g. for a by-reference type).

> The only way to implement those is 
> via some sort of dispatching, and the need poisons the possibility of 
> omitting tags, even for "specific" operations.

I don't understand where you get this. The model is exactly the model of
tagged types, but without specific objects required to keep the tag. The
only thing it influences is view conversions between T and T'Class. Nothing
else is changed.
 
> The type conversions are view conversions, and they never make copies.

View conversions will be kept for tagged types and not introduced for
untagged ones.

> That 
> forces the representation to be compatible. You could change that for 
> by-copy types (although that would have run-time compatibility issues for 
> controlled objects),

Controlled objects are tagged, hence no change here.

> but you can't change that for types that have no copy 
> operation (like tasks and protected objects). So how to do you implement 
> them? Array of task is an untagged type, too, and it certainly should be 
> able to use 'Class.

Sure. T'Class will be a referential object when T is untagged by-reference
type. It will consist of the type tag and a *pointer* to the specific
object (not much different from 4.1.5), and from view conversions ether,
though formally a new object.

When T is by-copy, T'Class is the type tag + a copy of T.

>> I don't ban inheritance of the representation. I want to be able not to do
>> it when I don't need it, e.g. for character and string types.
> 
> But it's not that easy. If you have an array of tasks:
> 
>     type Foo (1 .. 10) of Some_Task with Component_Size => 32;
> 
> and you derive another array of tasks from it:
> 
>    type New_Foo is new Foo with Component_Size => 64;
> 
> This is legal, and you have different representations.

Irrelevant. Ada 83 derivation (cloning) is orthogonal to Ada 95 extension
model. We are talking about the later.

>>> It really kills the entire idea.
>>
>> No, IF String inherited the representation of Wide_Wide_String, THAT would
>> kill the idea.
>>
>> The whole idea is not to inherit irrelevant representations!
> 
> I don't see the problem here; if Root_String is an abstract tagged type,

Java interfaces will not work for characters/strings. No need even to try
it.

>> The bottom line is, I regard Ada 83 construct "type S is new T;" as very
>> useful, and wished it be valid with all specific types without silly
>> exceptions Ada 95 made for tagged types.
> 
> Fair enough. I regard "type S is new T;" as a junk piece of syntax that was 
> inherited from Ada 83, and should never be used. We completely disagree on 
> this one, and there really is nothing worth talking about.
> 
> You previously asked about:
> 
>     type Velocity is new Float;
> 
> That would get you a repremand if you worked for me. You never, ever use the 
> types in Standard (because they're not necessarily portable to other 
> compilers). You derive types based on your actual application requirements:
> 
>    type Velocity is digits 5 range -1.0E+10 .. 1.0E+10;

This is a bad design pattern because it refers to some magic numbers spread
all over the source code, a huge maintenance problem, potentially. The
proper pattern would be:

   type Measurement is digits 5 range -1.0E+10 .. 1.0E+10;
   ...
   type Velocity is new Measurement;
   type Acceleration is new Measurement;
   ...

>>> Because you need operations that work on every object,
>>> copyable or not. Remember, there are no type conversions between types in
>>> different hierarchies.
>>
>> And, this is what different hierarchies are for.
> 
> For what? To make it impossible to pass integers to Text_IO, or to use them 
> to instantiation Text_IO?

It is in the same generic formal class, thus instantiation is possible.

You are confusing generic classes, and classes induced by cloning, and
classes induced by interface inheritance. They are not same.

There is an infinite number of means by which some types could be lumped
into a class. Class is no more than a set of types. E.g. all types which
declarations start at the source code line 123 is a class. That does not
make them possible or not to be used in Text_IO instantiation. That would
be some other class.

>>>> But they are still the same
>>>> hierarchy. You need some fundamental operation which tells that a type
>>>> breaks off the hierarchy.
>>>
>>> Yes, of course all containers ought to be members of the same hierarchy. 
>>> How else would you create generic algorithms?
>>
>> Easily. Cloning borrows all operations. Define algorithm on the original
>> type. Then clone it. Done!
> 
> But you have cloned nothing.

I did types, literals, operations.

> Either you have a conversion to the original 
> type, in which case they belong to the same hierarchy.

This is a possible way to implement cloning. This is not the semantics of.
The semantics is that there is a new set of types, values and operations
with the properties of the original. Nothing more.

> A string class with a mixed & is nonsense. (I think the String & Character 
> in Ada 83 was nonsense, but it's not a problem here.)

It would be interesting to learn how many c.l.a. readers share such an
extreme view.

To me "&" is one of the most important requirements on string class design.
It is also a good test for the language type system maturity.
 
> The only & is String & String = String, and so on for all types.

Totally useless, IMO.

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