From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.lang.ada Subject: Re: Pre-condition vs. Post-condition Message-ID: <5074@goanna.cs.rmit.oz.au> Date: 26 Mar 91 22:03:55 GMT References: <20600091@inmet> <23141@as0c.sei.cmu.edu> <2918@sparko.gwu.edu> <2929@sparko.gwu.edu> Organization: Comp Sci, RMIT, Melbourne, Australia List-Id: 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.