Re: Is this expected behavior or not

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

"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. The compiler 
shouldn't have trouble with inheriting implementations -- we don't do or 
want multi-methods, after all. Ada only supports that for null extensions; 
it's easy to extend that so long as an information-preserving conversion is 
possible. (That would have to be declared by an aspect, I think.)

...
>>>>> Yes, the language permits compilers implemented poorly, and?
>>>>
>>>> This has nothing to do with compilers. It has to do with *poorly 
>>>> designed
>>>> programs*. It's certainly true that a program that depends on by-copy 
>>>> or
>>>> by-reference passing is wrong; the compiler should be free to choose. 
>>>> But
>>>> this is an undetectable error. And bringing Adjust into it makes it 
>>>> much
>>>> worse, because it's easy to write code that doesn't work if Adjust is
>>>> called (you probably can get infinite recursion that way).
>>>
>>> Are you saying the copy constructors (Adjust) are broken in Ada? They 
>>> are
>>> to me too. Fix them.
>>
>> Not at all (at least for this topic). The act of calling a routine (*any
>> routine*) usually has detectable side-effects. That's certainly true for
>> Adjust. (It might be bad practice to depend on those side-effects, but
>> language standards cannot legislate program morality.)
>
> 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. 
This is one of the reasons that the language you're suggesting really has to 
be different than Ada. Ada has too many existing nasties that have to be 
preserved in order to make the overhaul you're suggesting. We'd be afraid to 
do it even if it appears to be neutral, just because it would be too risky 
to make the change.

I'd like to make objects [and exceptions] overloadable (it would fix a large 
percentage of the problems with use clauses and visibility, and unify 
objects, enumeration literals, and functions - which you should be able to 
switch between without breaking anything). But the idea is deemed too risky; 
there is a very low possibility of silent changes in meaning of programs 
(usually, an illegal program would become legal -- not a problem, or a legal 
program would become illegal -- a problem, but not showstopping, especially 
as it would be rare). So the idea is unlikely to go anywhere. And that is a 
*much* simpler change than what you're suggesting.

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

You're right that you could use unary plus for this purpose -- a lot of 
people do -- but it's also considered an ugly hack. I would never use it to 
cover up expensive conversions -- I *want* those hard to write, so I only 
write them where absolutely necessary. And the use of "+" fills your program 
with ambiguity. OTOH, writing explicit conversions (or function calls with 
real names) does not have this problem.

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

I've used the "+" trick here, but almost exclusively for literals (which 
should have been part of the type from the beginning).

                                     Randy.