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

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Adam Beneschan <adam@irvine.com> writes:

> On Tuesday, June 18, 2013 10:09:21 AM UTC-7, Robert A Duff wrote:
>
>> It is certainly a big language-design flaw that the elab order is
>> implementation defined.  Ada code tends to be pretty portable for the
>> most part, but elab order is one of the top issues that cause
>> non-portability.  That and overuse of representation clauses.
>
> Yeah, but if they had decided to specify the order instead of leaving
> it implementation-defined, what order could they have chosen?
> Alphabetical?

Lexicographic order would work.  Or backwards of that.  Or apply
"rot-13" to the bytes and then do lexicographic order.  ;-)

Or you could base it on the order in which 'with' clauses
happen to appear.

Programmers shouldn't be depending on lexicographic (or whatever) order,
but if they do so by accident, it's best that their program still works
10 years later when it is ported (probably by a different set of
programmers).

>...(Think about what joy that would have caused the ARG
> when Unicode support was added to the language!!!)  I think the
> problem is that, unlike some cases (like subprogram parameters, where
> the language designers *could* have specified left-to-right evaluation
> instead of implementation-defined order), there's no natural ordering
> of library packages in a program.

There's no reason the order has to be "natural".  I'm just saying it
should be the same on all implementations.

The situation with parameters is different:  Allowing the compiler to
choose any order has a disadvantage (portability problems) and an
advantage (efficiency).  There's a tradeoff.  I happen to think
they made the wrong choice, but reasonable people can disagree
on that point.

But with elab order, there is exactly ZERO benefit to allowing
arbitrary orders.  And the disadvantage is huge:  I've seen people
wasting boatloads of money on this!

>...So I don't even see the beginning
> of a solution.

I don't see what the big deal is.  Any legal Ada identifier can be
represented as a Wide_Wide_String, and every Ada 2012 implementation
supports the "<" operator on those.  So one trivial solution is to
simply sort based on that "<", in cases where the current rules about
'with' clauses and pragmas leave the order undefined.

Another solution just occurred to me:  Require the programmer
to put in enough pragmas Elaborate_All (etc) that there is only
one possible order.  Probably not a good idea, but it would
solve the portability problem.

- Bob