Re: Introductory Ada Programming Book

[Shark8 <onewingedshark@gmail.com>]

On Wednesday, January 4, 2017 at 2:47:05 PM UTC-7, Randy Brukardt wrote:
> "Shark8" wrote in message 
>
> On Wednesday, January 4, 2017 at 6:45:29 AM UTC-7, raph....@gmail.com wrote:
> > Le mercredi 4 janvier 2017 13:49:18 UTC+1, Dmitry A. Kazakov a écrit :
> >> >
> >> > declare
> >> >     I : Integer := 1; -- OK
> >> >     J : Integer; -- Error: not initialized
> >> >     K : Integer := <>; -- OK: uninitialized, I know what I am doing
> >> >
> >>
> >> Or do it Swift's way and use flow analysis to make use of an 
> >> uninitialized variable
> >> a compile time error. Meh. I guess it's complicated enough as it is to 
> >> implement
> >> an Ada compiler :)
> >
> >Well, there are certain times where you *want*/*need* non-initialized 
> >variables;
> > it's usually at [operating] system-level, but it does exist. (A good 
> > example would
> > me memory-mapped I/O ports, where your 'initialization' would 
> > automatically
> > send something down the I/O port when you might need to send nothing.)
> 
> Right. It also might happen if the initialization is very complex and 
> interrelated with initializing other variables. Forcing an initialization 
> just to make the compiler happy would be confusing and potentially expensive 
> (if the item is large).
> 
> I agree with Dmitry. Indeed, I tried hard in Ada 2005 to get (<>) to be an 
> aggregate usable to default initialize for any type, with the intent to 
> combine that with a restriction to essentially allow projects to change Ada 
> to the rule Dmitry suggested. Unfortunately, various technical issues with 
> private types made that much harder than originally thought, and the idea 
> was dropped late in the Ada 2005 work.
> 
> The problem with requiring flow analysis in a language rule is that it 
> requires lengthy specifications of exactly what flow analysis is required 
> for this check, assuming that portability between implementations is 
> important (and that surely is for Ada). Every compiler does some flow 
> analysis, but each it likely to do it differently, in different compiler 
> phases, and having program legality be implementation-defined in that way is 
> a guaranteed way to have code that cannot be moved to a different 
> implementation. (Exception contracts have a similar problem.)
> 
>                                          Randy.

Thank you for the explanation/info -- it's really good.
(I hope we *can* get exception contracts.)