On Thu, 7 Jun 2007, Maciej Sobczak wrote:

> declare
>  I : Integer;
>  P : Positive;
> begin
>  I := Make_Positive; -- OK, looks "innocent", cannot raise
>  P := Make_Integer; -- should be error ("innocent" lies)
>  P := (Positive)Make_Integer; -- OK, beware potential errors
> end;

If I wanted to ensure P := Make_Integer is a compile-time error, I would 
define Positive as a type, instead of a subtype. OK, then I would have to 
write I := Integer(Make_Positive), but � would not regard this as too much 
of a problem. Either I want the ease of mixing my types, see (2) below, in 
which case I use the "subtype" Ada syntax, or I want the firewall between 
types, where I use "type", see (1).

    type    Pos_T is new Integer range 1 .. Integer'Last; -- (1)
    subtype P_Sub is     Integer range 1 .. Integer'Last; -- (2)

The distinction between "subtype" and "type" helps to write correct and 
easy-to-read programs. I don't think however, that making subtypes more 
type-like ("type" in the sense of the Ada syntax) would help at all.

BTW, you would not get rid of innocent lies, anyway. See th following 
exampes:

    Odd_Number := Make_Positive;
    Prime      := Make_Positive;

These are innocent-looking but semantically wrong (assuming the 
constraints suggested by the choice of the identifiers). Now, please 
define an advanced type system to statically enforce such constraints! 
(You could perhaps statically enforce them by the aid of static analysis 
tools, such as the SPARK toolset.)

-- 
Stefan Lucks      (moved to Bauhaus-University Weimar, Germany)
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------