Re: Is this expected behavior or not

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

On Fri, 15 Mar 2013 16:17:11 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:ewe0v3ck1xdo$.e8rtuof27ke6$.dlg@40tude.net...
>> On Thu, 14 Mar 2013 17:12:28 -0500, Randy Brukardt wrote:
>>
>>> There are some differences in *dynamic* behavior, but that has nothing to do
>>> with the available values and operations. (The text you quoted from the RM
>>> about values "belonging" to a subtype is defining dynamic behavior.) I
>>> recall some Dmitry guy telling us that dynamic behavior is different from
>>> static behavior, and even claiming that dynamic behavior cannot constitute a
>>> contract. So it if is not a *contract*, how come it matters for a *type*
>>> (which is an integral part of describing a contract)?
>>
>> I don't understand the point you are making. You cannot derive contract
>> from behavior, simply because it is converse: contract is imposed to
>> restrain possible behaviors.
>>
>> You might claim that implied contracts of Integer and Positive are exactly
>> same. I doubt that many would agree with that.
> 
> I certainly wouldn't, because *I* consider the dynamic behavior to be part 
> of the contract. But, clearly, you don't (and you've indicated that above 
> again. So yes, given your world view, the contracts of Integer and Positive 
> are exactly the same. That's clear, because they're interchangable in terms 
> of legality and resolution (anything having to do with compile-time 
> checking). The quote above says that you disagree with yourself. :-)

That would be a consequence of considering them same type. I already said,
that this a path towards weak typing.

But I don't see where I disagree with myself. Contract /= type. You can
have same contract and different types. What about:

   type Same is new Integer;

You also can have different contracts put on the same type in different
contexts. You can have contracts on something that does not involve types
at all. Anyway, I fail to see how contracts are relevant here.

> "I doubt that many would agree with that." That's certainly true, but that's 
> because few would agree with you on the notion that the contract does not 
> include the dynamic behavior. In any case, either *you* have to agree with 
> this premise (and thus all of your arguments on type vs. subtypes are 
> nonsense), or you are no longer agreeing with your previous statements about 
> contracts (which I for one would welcome, but it's seems pretty unlikely of 
> a change).

I don't see why. How *any* contract could make something like Positive a
non-type? There is not many possibilities:

A. Positive is not a type. This is what Georg says. I have no idea what
this is supposed to mean. That 123 is not Positive, or that "+" is not
applied to positives? He escapes into some kind of vague philosophy each
time I ask.

B. Positive is a type. The type is Integer. So Positive = Integer. This is
evidently wrong because there exist programs which semantics sufficiently
change when 'Integer' is replaced by 'Positive'. If the language treats
them same, worse to the language. Luckily Ada checks if Positive is indeed
positive (well, not always, but almost).

C. not (A or B) = my point.

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