Re: To Initialise or not

[Ken Garlington <garlingtonke@lmtas.lmco.com>]

Robert A Duff wrote:
> 
> >1. Use of "others" in an aggregate expression, case statement, etc.
> 
> I don't use "others" very often.  "Others" means, to me, that I mean
> to include all "other" cases, including the ones that haven't been
> invented yet.  Sometimes that makes sense.

So, if you needed to set a long string to all blanks, you
wouldn't use (others => ' ') unless you expected that the size of the
string would change?

> I'm not complaining about implicitness in general.  When I write
> "others", or when I write a default value for a record component, I'm
> the one writing the program and I know what I'm doing.  In the
> implicit null case, Jean Ichbiah decided in 1980 that my pointers
> should be initialized to null, and of course he had no idea what my
> program needs today.

Well, he presumed that you wanted a deference of a pointer to always 
be detected, which certainly seems like a good guess, given the history of
pointers used in other languages.

> My point is that the programmer, not the
> language designer, should be in charge of deciding whether a default
> value is a good idea, and if so, what that default value should be.
> The language should be in charge of detecting uninit vars.

Or, alternately, providing the building blocks for you to effectively
extend the language (which I believe Normalize_Scalars and 'Valid lets
you do, when used with an ADT or GADT).

Which things should be "hard-wired" in the language and which should not
is always going to be a philosophy issue. If your real complaint is that
you would rather have a pragma Normalize_Accesses instead of the default
initialization to null, that's OK I guess (although I don't know how that
would work, since you can't really talk about the range of an access value
in Ada 95). I still don't see how your coding convention helps this issue
in any meaningful way, however.

> Note that I'm not saying you should always initialize to 'null'.  I'm
> perfectly happy to see "X: Some_Pointer := new Something'(...);" or
> "X: Some_Pointer := Some_Other_Pointer;".

Right - there's nothing wrong with those other initializations. The intent
of the initialization is (or should be) clear in each case. It's just the
literal "null" that I find wanting.

> 
> >However, I think it's "philosophy" that's backed up by experience in
> >maintaining code. Have you done experiments that showed the value of adding
> >extra code in this case?
> 
> No, I have no experimental evidence.
> 
> >> Let me be quite clear about what I would *like* in a language: Any type
> >> that's built in to the language, and is treated as a non-composite
> >> entity, should have run-time detection of uninit vars.
> >
> >OK. Why do you feel that you can't achieve this in Ada? With Ada 95, you
> >have the ability to detect uninitialized scalars at any point in the program,
> >so long as the compiler can generate a "marker" value for the object (and
> >it supports the Safety and Security annex, of course).
> 
> Because (1) it only works for types don't need extra bits, and (2) not
> every reference is detected.

Well, assuming that my condition holds (a marker value is possible), and
you use an abstraction for the reads to the type, it should detect every
reference via the abstraction.

Actually, even if a direct marker isn't possible, you can create an
auxiliary marker (a boolean bundled with the "real" type) in the abstraction.

> >However, to do this consistently in Ada, you need to make a data abstraction
> >for each type for which you want such protection. Just providing a redundant
> >initialization fails to meet your goal.
> 
> Agreed.  But I'm not going to invent a new abstraction for indexing
> Strings.  I'm going to use type Integer.

That's your call, of course. However, I don't see the alternative to get
what you want reliably (Normalize_Scalars will still detect an error,
occasionally, of course).

I'm still mystified how initialization to null helps you here...

> I never said "integers are exactly like access types in every
> respect".  So your argument is bogus.  I just said they should be
> alike with respect to detection of uninitialized vars.

My argument was only with respect to initialization -- which is exactly
where you said your argument resided (your previous post mentioned
explicit initialization rules, not detection of uninit vars). All I said was, 
"why not treat integers and aggregates alike with respect to initialization,
just as you want to treat integers and accesses alike with respect to 
initialization?"

Seems perfectly "consistent" for me.

> (I hope we
> both agree that it's good that arithmetic is available for integers,
> but not for access types.)

Actually, when writing OS code in Ada 83, I have had need to do unchecked
conversions to convert access types to integers so that I could do
simple arithmetic on them. I certainly agree that you shouldn't provide
such operations by default, however.

Aren't you making my point? Access types are fundamentally different from
integers, so why should the initialization rules be alike?

Of course, in Ada 95, I _can_ do arithmetic on an access type _portably_.
Ain't Ada grand?

> 
> - Bob

-- 
LMTAS - "Our Brand Means Quality"