Re: Pre-condition vs. Post-condition

[ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)]

In article <2929@sparko.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes:
> In article <5070@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> >Don't expect default initial values for types to be an unmixed blessing.

> Perhaps we have a terminological problem here. By "default initial value"
> we do _not_ mean "the compiler determines the value." We _do_ mean "the
> programmer has the option of specifying the initializing value, and
> all declared objects then have this value when they are elaborated."
> This is only inconsistently possible in Ada83. 

No, we have no terminological problem here.  I understood quite clearly
what was intended.  For heaven's sake, we were shown an *example*.  We
both agree that a compile can't be expected to pick a sensible "default"
value for a type.  Why should anyone expect the designre of a package to
be able to pick a sensible default value either?  The whole point of
re-usable components is that you don't know _how_ your component is to
be misused.

Perhaps I have completely misunderstood the point of default values for
fields of records.  I thought that this, like default values for
omitted parameters, was a dodge to help people cope with the problem
where there is
	-- a package P providing a record type or procedure, and
	-- a package U using that record type or procedure
and package P is updated to include extra fields in the record type
or procedure, and it may not be practical to update the source of
package U.  (In fact, U may be a customer who won't let you anywhere
near their source.)  In this practically important but conceptually
limited case, the package provider _can_ determine sensible default
values: "those values which make the new version of the software
act just like the old version".

If I've understood correctly, then default initialisation of fields
and arguments makes the most sense for things where package U
*couldn't* have initialised those fields or parameters because
they didn't exist in the previous version of the software.

Now consider the kinds of problems that can arise with default
initialisations, *where the package user knows what the default is*.
Suppose, for argument's sake, that there is a subtype T of integer
with default value 1.  Suppose further that a user of that type wants
a variable initialised to that value.  In Ada83, you *have* to
initialise the variable *explicitly*, you had to write X: T := 1;
But when you *know* that T is initialised by default to 1, you know
that exactly the same effect can be obtained by writing X: T;
Ah, but if the providing package is updated, they do _not_ have the
same effect.  If the package changes so that T's default value is 0,
then X: T := 1; still initialises X to 1, while X: T; will initialise
X to 0.

So there is a temptation here to depend on something you perhaps
ought not to.  One thing which would reduce this temptation would
be to set things up so that a type or subtype can be specified in
a package specification and its default value in the package body.
Something along the lines of
	package FOO is
	    subtype BAZ is INTEGER range -10 .. 10 := deferred;
	    ...
	end FOO;
	...
	package body FOO is
	    subtype BAZ := BAZ'LAST:
	    ...
	end FOO:

> Taking it a step further, the Ada9x standard _could_ REQUIRE that the
> programmer give all types default initial values. I favor this;
> I think it corresponds to the Dijkstra notation you were referring to.

No it does not, not at all, no way!  It is the direct opposite!
Dijkstra's notation leaves the programmer with the obligation of
initialising every variable explicitly.  The point is that this
is defined so simply that it is *easy* for a compiler to detect.
There is no particular reason to expect that two variables of the
same type should be initialised to the same value.  Requiring that
every type be given a default initial value is what I call
"defining the problem away".  The problem of variables which the
programmer has failed to give the appropriate value _remains_,
it just isn't _called_ "being uninitialised" any more.  (It might
be called "the problem of variables which are implicitly
initialised to the wrong value".)

By the way, I never said that the *compiler* should bear all (or even
any) of the responsibility for detecting uninitialised variables.  It
is quite possible to have a debugger or interpreter that does this.
*Requiring* all types to have default initial values would make it
extremely hard, if not impossible, for such a tool to work.  _Allow_
programmer-specified defaults for programmer-defined types if you
wish (it doesn't let you do anything you couldn't do before, I think;
you could always have used records with one component).  But please
don't make a "Saber-Ada" impossible.

-- 
Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.