Re: Seeking for papers about tagged types vs access to subprograms

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 13-05-12 21:56 , Jeffrey Carter wrote:
> On 05/12/2013 01:10 AM, Niklas Holsti wrote:
>>
>> You mean like this:
>>
>>     function Open  (File : in Closed_File) return Open_File;
>>     function Close (File : in Open_File  ) return Closed_File;
>>
>> I agree that this is a possible approach. This would work, but at the
>> cost of writing the parameter/object name twice in each call:
>>
>>     File : File_Object;
>>     ...
>>     File := Open (File);
>>     File := Close (File);
> 
> I'm not sure I see the point in having an object for a closed file,
> other than the requirements of low-level languages in which such things
> were 1st implemented.

This "file" stuff is only an example of a protocol that can be subjected
to typestate analysis. For "closed file", substitute "an object that is
in its initial state".

> Why not something like
> 
> type File_Info (<>) is tagged limited private;
> 
> function Open   (Name : ...; ...) return File_Info;
> function Create (Name : ...; ...) return File_Info;
> 
> function Read   (File : in out File_Info) return ...;
> procedure Write (File : in out File_Info; Item : in ...);
> 
> declare
>    File : File_Info := Open ("junk", ...);
> begin
>    Data := Read (File);
>    ...
> end;
> 
> A File_Info must be opened or created when declared, and is closed when
> it's finalized.

The point of the example was to illustrate typestate analysis. For this
example, with only Open - (Read/Write)* - Close, your approach collapses
the example into a trivial one, where adherence to the operation
protocol is ensured by the necessity to declare a File_Info object
before it can be used. So it would no longer be a useful example.

Your approach works in some cases, but it is problematic if you cannot
initialize the object to an "active" state in its declaration, for
example because the "activation" is conditional in some way, or must be
delayed. The "activation" must then be done in a statement, and the
declaration leaves the object in some inactive initial state.

Another limitation in your approach is that the opening and closing of
different files must be strictly nested: if you declare and open file A,
then declare and open file B, file B must be closed before file A is
closed (as long as it all happens in the same task). Such forced
constraints between the states of different object is often not wanted.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .