Re: Is this expected behavior or not

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:3gv2jwc95otm.pl2aahsh9ox8.dlg@40tude.net...
> 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.

I agree that latter variant is silly, but the notion that somehow "&" 
becomes a multi-method simply because it exists makes no sense. "=" is not a 
multi-method in Ada today for tagged types; "&" would work the same way - it 
does not take items of different types unless you explicitly convert them. 
Maybe you have a different idea of a multimethod than I do??

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

Huh? There are predefined single-type operations. If you want mixed type 
operations, you have to define them, but it's usually a bad idea to do so. 
You're almost always better off with 'Class operands if you need type 
mixing -- for type resolution reasons (not even mentioning runtime issues).

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

Tagged types need no augmentation -- they only work because they are 
by-reference types. They can't work without that, and you (rightly) want to 
get rid of that.

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

Abstract operations have no implementation to override. Constructor 
functions are a special case where you would never want to share the 
implementation anyway. The fact that other functions aren't extended is a 
mistake in Ada, it makes it impractical to have those in your interfaces.

The Claw Builder has types with a lot of functions and abstract routines, 
and the net effect is that it takes a week or more to create a single 
extension of the type - just to type in all of the bodies required. And the 
result of that is that extensions simply don't get built because the burden 
is too high.

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

That was a bad idea for Ada 95 (there are pretty severe visibility issues 
associated with it), and I don't think it can be extended. In any case, that 
extends the problem of creating extensions -- it would be so diifficult and 
time-consuming that it almost never would be done. (Imagine extending 
Ada.Containers.Vectors if every routine became abstract. You'd never bother, 
because the effort to even write something to compiler would be so extreme. 
It's the exact opposite of agile programming [the only sane way to program, 
IMHO].

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

When you dispatch to an inherited routine, you directly call that routine 
with the operands view converted (which cannot make copies in the general 
case). The only way for this to work is for the low-level operations of the 
type to be implemented with dispatching calls -- this is exactly how generic 
units work in Janus/Ada. This requires a descriptor of some sort with every 
object and has the effect of re-dispatching.

You are suggesting making such operations illegal (no inheritance), which 
does eliminate that problem but would make the resulting language 
unusable -- certainly in an agile sense. (The average private type having 
more than 100 operations once inherited and low-level ones that you want to 
break out are included.)

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

Untagged types already have view conversions (it's what you pass to "in out" 
parameters in calls). You're 20 years too late with that idea.

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

A component is an object; I'm talking about untagged objects with controlled 
components 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.

Wow! And this is supposed to be a *simplification*??? :-)

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

Actually, there is only one model of inheritance in Ada. We're not making 
another one! There are slight differences in how the inheritance happens, 
but it's minor. In any case, there is no reason to separate derived from 
anything else: "type cloning" and "extension without new components" are the 
same thing -- you get a new type that's related to the current one only via 
explicit conversion and class-wide operations.

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

Java interfaces will not work for anything. No need to even try. :-) And 
who's talking about Java, anyway?

I'm interested in what we can do with tagged types. Forget the silly 
interfaces, or call it an interface if that makes people feel better (that's 
what we did with iterators, but it doesn't actually buy you anything). It's 
an Ada 95 abstract type.

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

People how spread "magic numbers" all over the source code are idiots. In a 
real program, these would be constants declared in an appropriate package. 
That's Ada 101. I'm not putting that sort of organization in little 
examples, I would hope that is a given around here.

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

This is a terrible design pattern because it puts unrelated types together 
(and, allows them to be converted to a common ancestor, which almost always 
is a bug - especially if we had Measurement'Class). If I find that in our 
code somewhere, I'm going to remove it and try to find the offending 
programmer for an educational moment. :-)

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

The "generic formal class" = hierarchy in Ada; if you split the hierarchy, 
then it's no longer in the same formal class. (That's the *meaning* of 
"class" in Ada; if you wanted truly unrelated things to work, it would have 
to be a "category" instead -- but there are no shared operations for 
categories as that does not make sense. And "categories" are never 
inherited.)

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

I'm not confusing anything -- they *are* the same thing in Ada. I suppose 
you could introduce a whole new boatload of complexity to the language 
definition to make them different, but how you can call that a 
simplification is beyond me.

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

No, that's a "category" (in Ada terminology). Limited types are a 
"category", because that's not an inherited property. "Class" is always 
inherited: all members of a hierarchy rooted at a class have the same 
properties.

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

If they allow conversion (including implicitly to the class-wide root of the 
class) and instantiation, they're members of the same hierarchy. So it's the 
same as any other kind of extension inheritance (essentially a null 
extension). If it *doesn't* allow conversion and instantiation, then it's 
pretty useless (and it's not the same as Ada is today, which you claim you 
want to support).

You do know that there are special rules for null extension so that you 
don't have to override any functions returning the type? Unlike normal 
extension, you only have to override abstract operations (which there should 
be none). So there would be no semantic difference between writing (if you 
could):
    type T is new W;
and (which you can write):
    type T is new W with null record;

I'm not actually sure why the former is disallowed, I think it's an intent 
to highlight the difference between tagged and untagged types. (And I don't 
know why we would want to highlight that!)

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

Fair enough, we can agree to disagree on all of this. That's how Ada works 
today, and I've hardly ever heard anyone claim that Ada array types are 
"totally useless".

                                    Randy.