The nature of FILE_TYPE in Ada 83 TEXT_IO

General
1

Thinking about the Ada 83 TEXT_IO.FILE_TYPE implementation, what must be the underlying nature of this limited private type ?

At first, one could think that a private record type could do the job of keeping necessary information, but it appears not to be the case because a file is an implicitly global object which is not confined to a frame context.
The existence of the default IO’s (with TEXT_IO.SET_INPUT, SET_OUTPUT, CURRENT_INPUT, CURRENT_OUTPUT) implies that even when a FILE_TYPE variable disappears, the file object still exists in some hidden form.
This allows some funny, though not so pleasant inventions : several files can be opened and rendered inaccessible for closing ; though one of them can still be used as default IO if it has been defined so by SET_INPUT or SET_OUTPUT. A careful programmer will normally avoid this and define the file variable in a scope such that closing with the FILE_TYPE variable is possible.

The FILE_TYPE must then be some index in an array of file control blocks (FCBs) or an access to a queued FCB with allocation in the heap.

Thinking at it, it seems to me not very satisfactory : when a FILE_TYPE variable disappears with the frame which defined it, wouldn’t it be better to close the access path a CREATE or OPEN call generated ? This would appear as a kind of finalization of a file access path object. Then the default IO should fail (STATUS_ERROR exception) if the original FILE_TYPE variable used to set the default IO has disappeared.

2

Yes.
One thing that you have to understand is that Ada was designed when there were radically different OSes, indeed even notions/base-designs of computers were different (consider Lisp-machines, Database-machines, object-oriented machines, etc); because the nature of these vastly different “computational models”, having something that interfaces with the “host environment” must necessarily be dependent on that environment. (Consider, for a moment, what a machine with one-complement integers, [iron] core-memory, and persistent-objects/-files, would be like compared to the now-uniform Windows/Intel.)

I don’t remember if there was anything in the RM requiring or prohibiting auto-finalizing files.

I think you’re misunderstanding. It’s not [necessarily] that they’re global-objects, but that they’re [mapped-to/interfaces-of] external-objects.