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

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Sun, 12 May 2013 10:10:01 +0200, Niklas Holsti  
<niklas.holsti@tidorum.invalid> a écrit:
> 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:

Yes, that was that. I don't bother about writing more when it that makes  
things more readable.

>    File : File_Object;
>    ...
>    File := Open (File);
>    File := Close (File);
>
> But this code seems to cause a problem:
>
>    File1, File2 : File_Object;
>    ...
>    File1 := Open (File1);
>    File2 := Close (File1);
>
> Now File2 is a clone of File1, and the underlying system file is closed,
> but File1 still considers it open.

Interesting point. Note the the procedural way present the same issue, as  
the object may be copied too, even if limited, using component by  
component copy (as with actual Ada, the type cannot be private for the  
reason given before). Less likely to occurs, but if it can occurs, it's  
enough to say the issue is still there.

>
> The "function" approach thus tends to clone objects, and to lose the
> "object identity".

The topic of object identity is interesting, I have not though about it.  
That's finally an issue similar to aliasing here… as the file type is  
finally a kind of reference, via its handle.

> If we want to preserve object identity under that approach, I think we
> need a "linear type system"
> (http://en.wikipedia.org/wiki/Linear_type_system)

Your nickname must Santa Clause :) Thanks for the new pointer, again.


> Yes, that could be a problem. The language might allow the declaration
> of subtypes of opaque types, with opaque constraints.

But the subtype would not have readable sense if the constraints would be  
opaque. Or else as an alternative, may be Ada could allow partly unknown  
discriminant (something I miss):


     -- Valid actual Ada:

     type T1 (<>) is private;


     -- Invalid, actual Ada don't permits this:

     type T2 (Foo: Foo_Type; <>) is private;


As an unrelated side note, something I miss too with private types, is the  
ability for the completion to be a subtype (actual Ada requires it to be a  
type‑new or a record).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University