Re: Is this expected behavior or not

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

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

> How would you tell yourself from year 1992 about Ada 95? The other you
> would not listen to you.

Well, in 1992, we were already working on implementation Ada 9x (which 
became Ada 95), as we were part of one of the user/implementer teams. So it 
wouldn't be hard at all to do. :-) And Ada 9x was described in terms of 
extending existing Ada concepts, so it wasn't that hard to understand at 
all.


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

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

Prime'Succ is thus an operation of Integer'Base (as subtypes like Prime 
don't have operations), and clearly how it behaves is based on that.

And yes, if you want some other behavior, then you have to write it 
yourself -- nothing new about that.

                                        Randy.