Re: Is this expected behavior or not

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

On Thu, 11 Apr 2013 18:02:49 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1o34nhpfuy6yl$.2orlukd1elr7.dlg@40tude.net...
>> On Wed, 10 Apr 2013 17:07:57 -0500, Randy Brukardt wrote:
>>
>>> The compiler shouldn't have trouble with inheriting implementations
>>
>> type Real is tagged record
>>   Value : Float;
>> end record;
>> function "+" (L, R : Real) return Real;
>>
>> type Complex is new Real with record
>>   Img : Float;
>> end record;
>>
>> How is the compiler supposed to inherit "+"?
> 
> Easy, it uses the defined constructor.

You must be joking. How the compiler knows how to add complex numbers?

   type Polar_Complex is new Real with record
      Angle : Float;
   end record;

This one too?

> Of course, I don't think Float and Complex have enough in common for this 
> sort of derivation to make sense. (The only commonality between float "*" 
> and complex "*" is the name.)

The commonality is called "field":

http://en.wikipedia.org/wiki/Field_%28mathematics%29

>>>> You don't make language design dependent and promoting bad practices.
>>>
>>> If you are starting with a blank page, you're right. If you are building 
>>> on 30+ years of practice, even "bad practice" has to be taken into account.
>>
>> Nonsense. Bad practice is bad. Longer it lasts bigger is the damage.
> 
> Not nonsense. You can't break existing programs if you expect people to 
> upgrade.

Show me a program that gets broken by introducing untagged classes.

>> But if performance is your concern, you must be the first to go for
>> multi-methods, because this is the only way to define type-specific
>> operations and to have different representations for different members of
>> the hierarchy. Your proposal was to render all strings as 
>> Wide_Wide_String. And you tell me about efficiency?
> 
> It is never a good idea to mix types in a program: String shouldn't be mixed 
> with Wide_String, Float with Complex, or Integer with Float. In the rare 
> case when you need to do so, you should write an explicit conversion.

Ergo, performance is not your concern when it is about the Principle. But
you tried to justify that very principle with performance in first place.

So, we are the to the square one. Why is it never a good idea to use
Ada.Strings.Unbounded.Append [a mixed type operation]?

> There's nothing wrong with storing all strings in unbounded UTF-8, for 
> instance, but storing them in a variety of formats will just cause you a 
> huge amount of translation overhead. It's not worth it.

This is what you proposed. I did to avoid translations through support of
mixed type operations. They do exactly that.

>>> For instance, I tend to write out the entire name of the conversion 
>>> between string and unbounded string:
>>>
>>>     Ada.Text_IO.Put_Line (Ada.Strings.Unbounded.To_String (My_Object));
>>
>> Hideous. What kind of information this mess should convey to the reader?
>> 2/3 of it is noise. My_Object is a string, why Put_Line does not handle 
>> it?
> 
> It's a "string", not a String.

And *semantically* the difference is?

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