Re: Is this expected behavior or not

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

On Mon, 18 Mar 2013 17:52:03 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:a9ivriefwvbm.1mwi80nz4jz6h$.dlg@40tude.net...
>> On Fri, 15 Mar 2013 16:43:47 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:1xsmzl7alqflb$.oz1qkrleisa7$.dlg@40tude.net...
>>>> On Thu, 14 Mar 2013 16:51:11 -0500, Randy Brukardt wrote:
>>>>
>>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>>>> news:13y3efy877tjl$.5yuu230sknnq$.dlg@40tude.net...
> ...
>>>>>> How do you describe tagged types in Ada 83 terms?
>>>>>
>>>>> Why would I want to?
>>>>
>>>> You insisted on that claiming that Ada can be only discussed in 
>>>> Ada-terms.
>>>
>>> You didn't answer the question. Why would you want to describe something
>>> from a recent version of the language in terms of an obsolete one?
>>
>> To illustrate the point that one cannot extend/modify the language
>> discussing it in its terms, like baron Munchausen pulling yourself out of 
>> a swamp by your hair.
> 
> We're not talking about extending or modifying the language, so that would 
> not be relevant.

It is the same context though.

>>>> Ada's subtype as defined by RM is a fact to explain (and to predict
>>>> consequences of the choices made). The theory does it quite well. The rant
>>>> about how Ada's RM names its subtypes is absolutely irrelevant.
>>>
>>> But no one cares, because such matching has no relevance to anything: it's
>>> not going to change the design of Ada (compatibility concerns would prevent
>>> that in any case)
>>
>> There is no compatibility concerns. Robert said in this thread that
>> Prime'Range, Prime'First, Prime'Last are all illegal. So it is already
>> incompatible, if under compatibility you understand that a subtype must
>> inherit everything.
> 
> Huh? In this content, "Compatibility" means new versions of Ada should not 
> break existing Ada code. For the definition of 'Succ, for example, we cannot 
> change it without potentially breaking existing code, so it is unlikely that 
> we would make such a change.

Of course you can do it without breaking anything. Making an operation
primitive and allowing it to be overridden, can break nothing.

But actually S'Succ (X) shall go straight to the section J. We should
introduce X'Succ, a primitive operation of the interface Ordered and forget
about the mess. Instead of deriving Prime from Integer and inheriting what
should not be there, you would do from Copyable, add user-defined literals
(=inherit some integer literals, which are functions, of course), and
privately implement it as Integer.

>>> and nothing about it would help you be a better Ada
>>> programmer (especially as the terminology clash makes it close to 
>>> impossible to think about one and make sense of the other).
>>
>> On the contrary, understanding that a subtype is a type with values and
>> operation helps a lot. Especially when it comes to aberrations like with
>> Prime'Succ. It is an operation of Prime and the programmer should know that
>> in Ada he has no influence on its implementation which is always inherited
>> from the base type. If that does not correspond his intent he must change
>> the design and use other means, e.g. tagged types or unrelated types
>> (derive Prime privately).
> 
> You seem to get the right conclusion from the wrong premise.

So, the theory works.

> If you 
> understand that Positive is not a type, but rather *has* a type, and 
> operations are chosen based on the type that Positive has (not by the 
> subtype), then the behavior of  'Succ makes perfect sense, because its the 
> same behavior that you get for "+" and "*" and all of the other predefined 
> operations.

No, it does not make sense, because the semantics of Prime is not defined
by RM, it is in the realm of mathematics.

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