Re: Wide Character Problem in Ada.Numerics

["Randy Brukardt" <randy@rrsoftware.com>]

"Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message
news:uwszx93ce.fsf@STRIPCAPStelus.net...
...
> If I recall correctly, GNAT uses a source based model for its package
library,
> in that the "library interface" files for package specs are simply the
sources
> themselves.
>
> This means that package specs are always loaded/compiled on the fly
whenever
> they are WITH'd.
>
> This turns out to have all sorts of advantages and simplifications. I
don't
> know if GNAT is still doing this.

I wouldn't call it "advantages". It's more like trade-offs. Recompiling in
this way means you don't need to invent a compiled symboltable form. But it
does lose a lot of control over how the specs are compiled. This character
encoding issue is one of many similar issues: you lose control over how the
spec is compiled. If you want the spec to be compiled differently than the
units that use it, that becomes hard. Another disadvantage is that you end
up with two compilation modes for a spec, one that generates elaboration
code and one that does not. That's clearly going to complicate things.

I don't think the choice has much impact on compiler performance: on most
programs, GNAT and Janus/Ada compile at similar speeds. (There might have
been a difference visible years ago when computers were much slower, but it
surely isn't evident now, even on my relatively slow work machine.)

So it's just a trade-off, one of the many choices that you have to make when
designing a compiler. This is one area where I see no real issue with the
choice that we made in Janus/Ada - there are lots of things where an
alternative approach is appealing, but this isn't one of them.

                                                   Randy.