Re: Is this expected behavior or not

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

"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:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:8bj2k30k7i19.w7ehsldwbf7x.dlg@40tude.net...
>>> On Tue, 9 Apr 2013 18:24:29 -0500, Randy Brukardt wrote:
>> ...
>>>>> Why there should be many?
>>>>
>>>> If you've got operations like "+" or "*", you'll have a lot of 
>>>> functions
>>>> returning objects of the type. That's a bad idea for the reasons I
>>>> mentioned.
>>>
>>> You have + and * of GUI objects? That is weird. Anyway if you have
>>> arithmetic upon a hierarchy how the compiler is supposed to deduce
>>> implementations for derived types?
>>
>> Tagged types and extension is used for more than just GUIs.
>
> Tagged types are useless when arithmetic operations get involved. It does
> not work with present design, because type hierarchies are not handled for
> such operations.
>
>> 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. I explained that in the part of the 
message that you deleted. That's a feature Ada is missing but could easily 
have, especially as we already have something like it for null extensions.

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

...
>>> 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. I've got a million or so lines of Ada code; I can't use a new 
upgraded language on those if they are going to be broken, and I can't 
support a different compiler for every version of code ever written.

If you can detect the "bad practice" at compile-time *and* its rare enough, 
then, and only then, can we consider an incompatibility. Differences at 
run-time are intolerable unless the likelihood of it occurring in practice 
are very small. We've made exceptions to that, but only after many attempts 
to adopt other solutions and a lot of research of existing databases of 
code. (And they're always controversial.)

>> This is one of the reasons that the language you're suggesting really has 
>> to
>> be different than Ada.
>
> We already discussed that. I want to preserve Ada semantics. It is you who
> wants completely change the way string types are used in Ada.

But you're not going to come close to preserving Ada semantics. The model of 
the language is a very important part of that semantics, as it is encoded in 
countless books and articles and tutorials. The gain from abandoning it (and 
we'd have to abandon it to adopt a model like yours) would have to be 
immense.

...
>>>> That isn't very likely to
>>>> happen. The only way to define these conversions would be through a
>>>> Wide_Wide_String intermediate - the net effect is that the conversions
>>>> will be quite expensive and you would never, ever want to use such
>>>> implementations.
>>>
>>> This is exactly the overhead of doing this using the infamous unary plus
>>> operation. I don't understand the point you are trying to make. You 
>>> don't
>>> want to override for custom types, you don't want automatic conversion 
>>> as
>>> too expensive. There is no third way. You want to apply explicit
>>> conversions at all call points? This is exactly the solution you 
>>> declared
>>> inefficient. It not only inefficient, it is extremely error prone and a
>>> major overhead for those unfortunate who have to use the package defined
>>> in such manner. The compiler rejects a program. What you do? Erratically
>>> place unary pluses before all arguments? But that is invisible. Actually 
>>> some
>>> hundred of them are already visible. For each of them the compiler spits
>>> some garbage error messages on you. But the right one you need is not
>>> visible. Were was it declared? Was it declared anywhere? Have fun!
>>
>> You're confusing expensive *implicit* operations with expensive explicit
>> ones. I don't care that an explicit type conversion is expensive -- you
>> wrote it, you meant it, and you can see the consequences -- it's right 
>> there
>> in the source code.
>
> Right, I don't care about performance I care about usability of the
> packages. Only when performance becomes a problem I address that. But I
> never let performance issues to cripple my design.

Fair enough, as I agree in general. But it is important, especially for 
embedded systems, that there is a correlation between the "expense" of the 
construct and how "expensive" it looks. I don't think expensive operations 
should occur automatically, especially if they're a dubious idea to begin 
with.

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

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.

The Wide_Wide_Strings are only used for conversions between types and 
literals. (And for slice emulation, although I'm dubious that we need that; 
the operations in Ada.Strings.Fixed are easier to understand and use for 
most things.)

>> 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. Of course it shouldn't handle it. I'd like a 
shorter name for this conversion (preferably a user-defined type 
conversion), but I definitely do not want to get rid of it here.

    Ada.Text_IO.Put_Line (String (My_Object));

seems perfect.

Of course, "General_Text_IO" would take Root_String'Class, so you could 
write what you want with it.

    Ada.General_Text_IO.Put_Line (My_Object);

The internals of the Put_Line operation would be a lot more expensive in 
that case, whether that matters or not depends on the problem (probably not 
for Put_Line).

Anyway, our programming styles are probably 180 degrees apart -- it's not 
surprising that we don't agree on any of this.

                                     Randy.