Does the Ada language and its standard library have "circular dependence"?

Question

I read about Ada.Finalization.Controlled, when I was searching for the possibility of having user-defined procedure to be automatically invoked on scope exit, to implement the RAII paradigm, as used in c++ for resource management generally, not just for memory.

I found that to get such automatic scope-exit-invocation, you must extend a type from the standard library. Is that part of the library handled specially by the compiler and language definition? Or the feature is technically available in general, but good-practice reasons dictate the use of the library component?

I am wondering now, whether the Ada language semantics is "dependent" on the standard library?

I am not sure about the terminology, so let me elaborate.

By that I mean whether there is a relationship between the Ada language and Ada.Finalization.Controlled, similar to how in Java the for(x:y) loop "depends" on java.lang.Iterable, or how the String seems to be just a class, but has special handling with operator+ and literals.

I find:

langauge <-- standard library

langauge <-- any other library

langauge <-- application

to be normal.

Where the arrows mean that the behaviour of the shooting side (library,app) cannot be explained without refering to or explaining the pointed-to side (language), that is it "depends" on it, but the pointed-to side (language) can be explained by itself. Furthermore, everything on the shooting side (libraries,apps) can be replaced, without changing language semantics, or breaking anything.

It seems to me that both Ada and Java have a "circular" relationship with their std-libs.

language <--> standard library

or rather:

whole language <-- whole library, and

language feature X --> library component Y

but that library component already depends on other language features, as noted above.

(It seems to me that such could be eliminated by moving that part from being in the library to being only in the language, that is the language could "swallow the semantics" of that library component and the clean situation would arise.)

So my questions are:

Is my above explanation stupid or non-sense or something only language-purists care about?

Isn't such a (potential) source of problems?

Is Ada.Finalization.Controlled involved in such a relationship?

Are any (other) components of the Ada standard library getting special handling from the compiler and language definition?

Answer 1

Yes, certain features of Ada depend on the "predefined language environment", which must be provided as part of any Ada compilation system. Yes, Ada.Finalization.Controlled is one of those features. No, it's not a potential source of problems. It may require a slight adjustment of thinking if you're coming from C or C++, where every language feature (as opposed to a "standard library") is added by adding new keywords or new and interesting sequences of punctuation characters. (OK, I'm sure this is an exaggeration.) Other packages that I can think of that have an intimate relationship with predefined packages: System (the Address attribute uses the type System.Address), Ada.Exceptions (exception when E : others makes E have type Ada.Exceptions.Exception_Occurrence), Ada.Streams, System.Storage_Pools, and others depending on you define your terms. And it does mean that you can't just replace Ada.Finalization or packages like this with some third-party alternate version of the package, since the implementation of Ada.Finalization is likely to be coupled with how the compiler works. I don't see this as a problem.