Re: operation can be dispatching in only one type

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

On Tue, 1 Dec 2015 17:05:28 +0100, in comp.lang.ada you wrote:

> On 01.12.15 14:56, Dmitry A. Kazakov wrote:
>> On Tue, 1 Dec 2015 12:19:02 +0100, G.B. wrote:
>>
>>> On 01.12.15 09:46, Dmitry A. Kazakov wrote:
>>
>>>> There is no reason why indexing or record member access
>>>> should be less efficient when a user-defined implementation allowed, but
>>>> not actually used.
>>>
>>> Sounds a bit like user defined aspects of compilation?
>>
>> It is not an aspect. Aspect is a view, characteristic, feature:
>>
>> http://www.thefreedictionary.com/aspect
>>
>> It means that aspect may not change the semantics.
>>
>> User-defined operation is exactly the opposite. It does not change the
>> view. The object is still viewed as an array or a record. It is the
>> semantics that gets changed.
> 
> I take it that by "semantics" you mean the simplest meaning
> of this word, viz. the operations that happen to become generated
> for a ".X" function, say, as a consequence of compilation?
> 
> If, however, a user may define what "rec.x" will do, then
> this changes an aspect (sic) of compilation: what was previously
> defined by the LRM (or would appear to be defined by the
> language) does now seem to flow from the job of the programmer,
> and becomes a property of the program, as it redefines certain
> occurrences of ".".

Who cares? Less defined by the RM then better. Any predefined semantics is
a necessary evil. If not necessary, then just evil.

> The compiler now needs to ensure something different when
> translating "rec.x".

The compiler needs to ensure what the programmer means (assuming correct
language use)

>>> What
>>> guarantees would the compiler be able to generate that user
>>> defined mechanics will work at the same level of assurance
>>> as that of "regular" records?
>>
>> Generated guaranties? You lost me here.
> 
> The current Ada language makes the compiler emit code for "Rec.X"
> that is going to have a somewhat predictable effect.

It does not make sense. For *any* legal construct the compiler should emit
code with a predictable effect. Otherwise the language is ill-defined.

The correct sentence is probably related to the program readability. That
is up to the programmer and how he expresses the problem space in the
language terms. I don't see how Employee.Salary is less readable,
predictable, etc than Get_Salary(Employee).

> If users are allowed to change the semantics of "rec.x", then
> what level of assurance do we get?

Same level as when the users are allowed to change the semantics of Foo(x),
x+y etc.

> We'd take away a basic building
> block from the set of unequivocally predictable building blocks.

Member extraction/setting operations is not a basic building block.

Oh, I forgot, that you are in the anti-typed camp. So let me explain. There
is *no* free operations. There are only types. The member operation .X is
one of the built-in operations of the built-in record type. You don't loose
it in no way if you allow *other* types have operations named this way or
implementing same abstract interface. If you don't believe me, look at
fully qualified names, they have "." inside. What a horror!

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