Re: Subtype conformance... not what I was expecting.

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

On Wed, 26 Jul 2006 10:32:20 -0400, Peter C. Chapin wrote:

> Dmitry A. Kazakov wrote:
> 
>>> procedure Check is
>>>     subtype Narrow is Integer range -10..10;
>>>     type Function_Ptr is access function(X : Narrow) return Integer;
>>>
>>>     function F(Para : Integer) return Narrow is
>>>     begin
>>>        return Para;
>>>     end F;
>>>
>>>     G      : Function_Ptr := F'Access;
>>>     Result : Integer;
>>> begin
>>>     Result := G(0);
>>> end Check;
>>>
> 
> [snip]
> 
>> The semantic of "subtype" in Ada is "same type." So if you allow Narrow to
>> appear in place of Integer, you must also allow the reverse:
>> 
>>     subtype Narrow is Integer range -10..10;
>>     type Function_Ptr is access function(X : Narrow) return Narrow;
>>     function F(Para : Integer) return Integer;
>>         -- Constraint_Error-unsafe
>> 
>> If you wanted a one-way road, you'd need function(X : Narrow) return
>> Integer be an override of some primitive subprogram of Integer. That would
>> make you able to legally judge about conformance to *class* (Narrow <:
>> Integer). But that works for only operations defined on the class.
>> Unfortunately Ada does not have either Integer'Class or Narrow'Class.
> 
> Hmmm. I'll have to think about this a little; I don't quite follow you 
> right now. Consider this
> 
> 	subtype Narrow is Integer range -10..10;
> 	X : Integer;
> 	Y : Narrow;
> 	...
> 	X := Y;
> 	Y := X;  -- Might raise Constraint_Error.
> 
> Even though one statement is Constraint_Error-unsafe, both are legal. 
> However, I don't think this is the point I was trying to make. When I do 
> G := F'Access (in my original example) it is type safe in that I can't 
> do anything with G that would cause a problem for F. I might get a 
> Constraint_Error when G's arguments are evaluated or when G's return 
> value is used but no such error can occur because the actual underlying 
> function is actually F.

Yes it is type-safe, and one could allow type-conformant subroutines as
actuals. This would probably impose some minor distributed overhead, I can
only guess if that was the reason. A similar case is requeue statement,
which also requires subtype-conformance.

My point was just, that there is no good choice in-between. It should be
either type- or subtype-conformant.

> Using the notation common in functional languages, let F : t1 -> t2 and 
> G : t1' -> t2'. Then t1 -> t2 is a subtype of t1' -> t2' (that is, 
> t1->t2 <: t1'->t2') iff t2 <: t2' and t1' <: t1. In this case I realize 
> that G is an access type but it "feels" like a function when it is used. 
> Since I'm trying to use F where G is expected and since F and G have the 
> proper subtype relationship to each other one might suppose that the 
> above rule would be obeyed.

Yes, this is close to my view on the issue of subtyping.

If t1' is substitutable (=compiler accepts it) in F as an in parameter,
that means, in my view, that t1' inherits F from t1 and so t1' <in: t1 (1).
Whether substitution causes Constraint_Error or not is no matter. The
result is just an out parameter. So t2' <out: t2. Both combined are
equivalent to:

t1' -> t2'  inherits F 

The inherited F is F', with a different profile. G is type conformant to
F', but not to F. So it should be substitutable for t1'Class -> t2'Class,
but not for t1 -> t2.

This is a possible way to unify "subtype" and "is new ... with" under one
roof, and also have a fine control over substitution (t1 vs. t1'Class).

-------------
(1)  We have to distinguish <in:, <out:, <inout:, and, well, <access:.

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