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

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

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wccip1acmt5.fsf@shell01.TheWorld.com...
> ...
>> 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.
>
> That doesn't work because Ada identifiers are case-insensitive, while "<" is 
> case-sensitive. You could get orders that depend on the case of the 
> identifiers, 

Groan.  More proof of the theorem, "Nothing is simple."

>...and in fact you could get children coming before parents.

No, no.  All the existing elab-order requirements would still apply.
I'm suggesting only that we'd be better off if the cases where the
current rules allow an implementation-defined order were language
defined.

Certainly a child package spec can't be elaborated before its parent spec!

> A direct conversion to some specific case doesn't work portably in Unicode 
> (because it depends on what version Unicode you are using, while the 
> case-insensitive compare is guarenteed to work the same in all versions of 
> Unicode).

Wait, are you saying that it's impossible to implement a
case-insensitive sort in unicode?  Such a sort is all that's needed
here.

Anyway, there's some "perfect/enemy/good-enough" thing going on here.
Even solving the problem for programs that use only plain-old 7-bit ASCII
would have saved zillions of dollars.

> The net effect is that ordering is not very reliable in case-insensitive 
> Unicode identifiers, like Ada's. Cool, huh?

Bleah.

- Bob