Re: Elaboration order handling (Was: Bug in 'gnatmake')

[Adam Beneschan <adam@irvine.com>]

On Wednesday, June 19, 2013 1:47:29 PM UTC-7, Georg Bauhaus wrote:
> On 19.06.13 17:46, Adam Beneschan wrote:
> > On Wednesday, June 19, 2013 5:22:30 AM UTC-7, Robert A Duff wrote:
> 
> >> Lexicographic order would work.  Or backwards of that.  Or apply
> 
> >> "rot-13" to the bytes and then do lexicographic order.  ;-)
> 
> > I guess it could work, but I gotta tell you--that seems really weird.  I've never heard of another language where the semantics could depend on the lexicographical order of the identifiers.
> 
> Having had to live with products of programmers favoring symbolic
> cleverness, I naturally think of what happens when some project
> depend on lexicographical order and then someone wishes to give
> packages different names. ARGH!

Yeah, I thought about that.  It would seem strange to have a program that had been tested suddenly quit working when a programmer decides to change the name of a package, and makes no other change.  That would certainly be a frustrating occurrence.  

On the other hand, the current situation isn't any better.  If you have two packages whose elaboration order isn't defined by the language, the compiler could elaborate them in one order, and then in a future build, could choose the reverse order for whatever reason it chooses.  Depending on the compiler, changing the name of a package could cause that to happen, if (say) that causes an old package name to be removed from the middle of some internal list and then inserted at the end of the list with the new name, which could cause a difference in how the compiler determines the elaboration order.

The more I think about it, the more I think the answer is that the elaboration of library package P should just be prohibited from calling subprograms in another package Q, or accessing variables declared in Q's specification, unless there is an Elaborate(_All) pragma, or unless there's some other reason Q must be elaborated before P (e.g. P's *specification* says "with Q"), or Q is Pure, or perhaps some other things.  Writing the rules to make sure this happens wouldn't be easy.  It probably means that P's elaboration code also can't call a subprogram in P unless that subprogram is also declared as "promising not to call anything outside this package".  There would have to be restrictions on dispatching calls and calls through access-to-subprograms.  I'm not sure this would be a feasible solution.  But to me, having the language defined so that "if the elaboration order is undefined, we'll put restrictions on things so that the order can't possibly matter" seems better, theoretically, than coming up with some unnatural order just so that we can say "something is defined".  That's just my gut feeling.  Since I doubt anyone is really going to think about adding this to Ada, all this is hypothetical until Bob decides to finally define and implement his hobby language.   :-)

                               -- Adam